CPU foldig에 대하여 (vpm_fold_policy)

 CPU folding은 shared processor LPAR, 즉 micro-partition에서 주로 사용하는 것인데, 당장의 workload에 비해 virtual CPU 개수가 너무 많으면 공연히 불필요한 context switching만 늘어나서, 당장 사용되지 않는 CPU 자원을 다른 LPAR들이 가져다 쓰는 것을 방해하므로, virtual CPU 개수를 그대로 놔두면서도 schedulding에서만 제외시키는 기법입니다.  이렇게 하면 fold된 CPU 자원을 다른 LPAR들이 더 효율적으로 가져다 쓸 수 있게 됩니다.   

Dedicated LPAR에서도 Power Savig Mode가 “Static Power Saving”으로 enable 되어 있는 경우 CPU folding이 사용됩니다.

vpm_fold_policy=4 disables processor folding in all conditions.

vpm_fold_policy=0 disables processor folding when “vpm_xvcpus”=-1

vpm_fold_policy=1 enables processor folding in shared partition.

vpm_fold_policy=2 enables processor folding in dedicated partition.

vpm_fold_policy=3 enables processor folding in both shared and dedicated partitions.

경우에 따라 성능을 위해 CPU folding을 disable하는 것이 더 유리할 수도 있습니다.  아래 간단한 테스트를 통해 그 효과를 보시겠습니다.

테스트를 수행할 LPAR는 shared processor를 사용하되 vCPU는 8개이고, EC (entitleed capacity)는 0.8개인 Power8 서버입니다.    관찰의 편의를 위해 SMT는 4개를 사용하는 것으로 설정했습니다.

aix7200-05-04:/ > lparstat -i

Node Name                                  : aix7200-05-04

Partition Name                             : AIX7200_05_04

Partition Number                           : 5

Type                                       : Shared-SMT-4

Mode                                       : Uncapped

Entitled Capacity                          : 0.80

Partition Group-ID                         : 32773

Shared Pool ID                             : 0

Online Virtual CPUs                        : 8

Maximum Virtual CPUs                       : 8

Minimum Virtual CPUs                       : 1

Online Memory                              : 4096 MB

Maximum Memory                             : 8192 MB

Minimum Memory                             : 4096 MB

Variable Capacity Weight                   : 128

Minimum Capacity                           : 0.10

Maximum Capacity                           : 2.00

Capacity Increment                         : 0.01

Maximum Physical CPUs in system            : 24

Active Physical CPUs in system             : 24

Active CPUs in Pool                        : 24

Shared Physical CPUs in system             : 24

Maximum Capacity of Pool                   : 2400

Entitled Capacity of Pool                  : 350

Unallocated Capacity                       : 0.00

Physical CPU Percentage                    : 10.00%

Unallocated Weight                         : 0

Memory Mode                                : Dedicated

Total I/O Memory Entitlement               : -

Variable Memory Capacity Weight            : -

Memory Pool ID                             : -

Physical Memory in the Pool                : -

Hypervisor Page Size                       : -

Unallocated Variable Memory Capacity Weight: -

Unallocated I/O Memory entitlement         : -

Memory Group ID of LPAR                    : -

Desired Virtual CPUs                       : 8

Desired Memory                             : 4096 MB

Desired Variable Capacity Weight           : 128

Desired Capacity                           : 0.80

Target Memory Expansion Factor             : -

Target Memory Expansion Size               : -

Power Saving Mode                          : Dynamic Power Savings (Favor Performance)

Sub Processor Mode                         : -

여기서 CPU 에 부하를 주기 위해서는 netperf를 이용했습니다.  다음과 같이 2개 process를 background로 동시에 구동했습니다.

aix7200-05-04:/ > netperf -l 30 -t TCP_RR -H 10.10.14.86 &  

aix7200-05-04:/ > netperf -l 30 -t TCP_RR -H 10.10.14.86 &  

먼저 default 상태인 CPU folding ON 상태로 테스트를 해보겠습니다.

aix7200-05-04:/ > schedo -o vpm_fold_policy=1

이렇게 ON 상태에서 부하를 걸어주면 다음과 같이 EC는 124.9%를 쓰면서 명목상의 CPU 사용률은 비교적 높게 나옵니다.  즉, 명목상의 idle%가 41.2%로 나옵니다.   이는 hypervisor가 판단하기에, 이 정도의 부하는 SMT thread 5개만 있어도 충분하다고 판단하여 전체 8 vCPU * 4 SMT thread = 32개 thread 중 17개를 fold 시켜 버린 것입니다.    

(실제로는 32개 thread가 필요에 따라 켜졌다 꺼졌다 하므로, nmon을 띄워놓고 보면 계속 끊임 없이 전체 CPU 개수가 32개와 5개 사이를 오가며 화면이 전환됩니다.)

아래 nmon 화면의 TOP process 부분을  자세히 보면  netperf 및 netserver process들이 총 4개가 떠있는데, 개당 대략 12%씩의 CPU를 사용하므로 CPU 1개의 45% 정도를 사용하는 셈입니다.

(확대해서 보려면 그림을 click하세요)

이어서 CPU folding을 OFF 시킨 상태로 테스트를 해보겠습니다.

aix7200-05-04:/ > schedo -o vpm_fold_policy=4

이렇게 OFF 상태에서 부하를 걸어주면 다음과 같이 EC는 238.4%를 쓰면서 명목상의 CPU 사용률은 비교적 낮게 나옵니다.  즉, 명목상의 idle%가 68.5%로 나옵니다.   이는 CPU folding을 하지 않으므로, 전체 8 vCPU * 4 SMT thread = 32개 thread가 모두 살아있고, 또 그만큼 많은 physical CPU 자원을 이 LPAR가 쥐고 있기 때문입니다.    

(확대해서 보려면 그림을 click하세요)

성능은 당연히 더 많은 physical CPU 자원을 사용하는 CPU folding OFF 상황이 더 좋게 나옵니다.

그러니 CPU folding은 OFF 시키는 것이 유리할까요?  꼭 그렇지는 않습니다.  원래 shared processor LPAR의 장점은 한정된 CPU 자원을 여러 LPAR들이 실시간으로 나누어 쓰며 CPU 자원의 활용율을 극대화하는 것인데, 이렇게 CPU folding을 OFF 시키면 이 LPAR가 CPU 자원을 더 많이 쓰는 만큼, 같은 box 내의 다른 LPAR들이 CPU 자원을 효율적으로 끌어다 쓰지 못하기 때문입니다.   

물론 CPU folding을 OFF 시킨다고 해서 CPU 자원 공유가 전혀 안 되는 것은 아닙니다.  다만 그만큼 자원 공유의 효율성이 떨어지게 되는 것은 사실입니다.  가령 저 위의 예에서 EC를 238.4%나 끌어다 쓰면서도 명목상의 CPU idle이 68.5%로 나오는 것이 그것을 보여줍니다.

결론적으로, 어느 특정 LPAR의 성능이 매우 중요하여, CPU 자원 공유의 효율이 떨어지더라도 성능을 더 높이고 싶은 경우에는 CPU folding을 OFF 시키는 것이 좋을 수 있습니다.

lsmemopt에서 -r lpar에 대한 점수와 --id 'lpar_id' 에 대한 점수가 달라요!

 

lsmemopt 사용시, -r lpar를 주어서 보는 점수와, --id (lpar_id)를 주어서 보는 점수가 각각 다르게 나와 이상하게 여기실 수 있습니다.

lsmemopt 사용시 --id 등을 주었을 때와 주지 않았을 때의 차이점은, 결국 system 전체에 대한 score (curr_sys_score)이냐 각각의 lpar에 대한 score (curr_lpar_score)이냐의 차이입니다.  

즉, -r sys를 주고 수행하면 언제나 시스템 전체에 대한 점수, 즉 curr(predidcted)_sys_score를 보여주고, -r lpar를 주고 수행하면 언제나 각각의 lpar 레벨에서의 점수, 즉 curr(predidcted)_sys_score를 보여줍니다.  

그냥 -r 옵션을 아예 안 쓰고 그냥 --id 만 주고 수행할 수도 있으나, -r 옵션을 생략하면 그건 언제나 default 옵션인 -r sys로 간주되기 때문에 항상 시스템 전체에 대한 점수인 curr(predidcted)_sys_score 값을 보여줍니다.

hscroot@icchmc:~> lsmemopt -m Server-8286-42A-SN84D7B4V -r sys -o calcscore

curr_sys_score=92,predicted_sys_score=98,requested_lpar_ids=none,protected_lpar_ids=none

: 즉, 전체 시스템의 현재 점수는 92점인데 최적화를 통해 98점까지 올라갈 수 있다는 뜻입니다.

hscroot@icchmc:~> lsmemopt -m Server-8286-42A-SN84D7B4V -r lpar -o calcscore

lpar_name=s824_vios2,lpar_id=1,curr_lpar_score=100,predicted_lpar_score=100

lpar_name=AIX7100_04_08,lpar_id=2,curr_lpar_score=0,predicted_lpar_score=90

lpar_name=s824_vios1,lpar_id=3,curr_lpar_score=100,predicted_lpar_score=100

lpar_name=AIX72CloudVM_00,lpar_id=4,curr_lpar_score=100,predicted_lpar_score=90

lpar_name=DB2CF01,lpar_id=5,curr_lpar_score=none,predicted_lpar_score=none

lpar_name=kctest,lpar_id=8,curr_lpar_score=100,predicted_lpar_score=100

lpar_name=bsyu-test1,lpar_id=9,curr_lpar_score=100,predicted_lpar_score=100

lpar_name=aix-test-02-71188692-0000000e,lpar_id=10,curr_lpar_score=none,predicted_lpar_score=none

: 여기서 모든 lpar들의 점수는 위치에 따라서 제각각입니다만 대부분 100점이고 (일부 lpar들은 not activated 상태입니다) 최적화 이후 점수도 100점입니다.  다만 lpar_id 4인 AIX72CloudVM_00 lpar는 현재 점수가 100점인데 최적화 이후 점수는 90점으로 오히려 줄어듭니다.  이는 현재 점수가 0점인 AIX7100_04_08 (lpar_id=2)를 최적화하여 90점으로 끌어올리려면 lpar_id 4의 점수가 다소 희생된다는 뜻입니다.

여기서 -r lpar를 빼고 그냥 --id만 줘서 lsmemopt를 돌리면 HMC에서는 이를 -r sys라고 간주하고 항상 system 점수를 보여줍니다.  따라서 --id 값을 무엇으로 지정하든 항상 똑같은 점수, 즉 전체 시스템 점수인 현재 점수 92점과 향후 점수 98점이 보여집니다.  자세히 보시면 curr_lpar_score가 아니라 curr_sys_score가 display됩니다.

hscroot@icchmc:~> lsmemopt -m Server-8286-42A-SN84D7B4V --id 9 -o calcscore     

curr_sys_score=92,predicted_sys_score=98,requested_lpar_names=bsyu-test1,requested_lpar_ids=9,protected_lpar_ids=none

hscroot@icchmc:~> lsmemopt -m Server-8286-42A-SN84D7B4V --id 2 -o calcscore

curr_sys_score=92,predicted_sys_score=98,requested_lpar_names=AIX7100_04_08,requested_lpar_ids=2,protected_lpar_ids=none

hscroot@icchmc:~> lsmemopt -m Server-8286-42A-SN84D7B4V --id 10 -o calcscore

curr_sys_score=92,predicted_sys_score=98,requested_lpar_names=aix-test-02-71188692-0000000e,requested_lpar_ids=10,protected_lpar_ids=none

이렇게 시스템 전체 점수만 보여줄 것이면 --id를 지정하는 것이 무슨 의미가 있느냐고 반문하실 수 있는데, 실제로 큰 의미는 없습니다.  그러나 반대로 --xid를 지정하는 것은 큰 의미가 있습니다.  --xid는 해당 lpar는 최적화 작업에서 제외시키라는 뜻입니다.  즉, 해당 lpar가 매우 중요한 시스템이라서 그 lpar는 건드리지 않고 최적화 작업을 하면 전체 시스템 점수가 어떻게 될 것인가를 알고 싶을 때 요긴하게 사용될 수 있습니다.

가령 아래에서 lpar_id 5번은 최적화 작업에서 제외시키더라도 전체 curr_sys_score 92점이 predicted_sys_score 98점으로 개선되는 것에 별 영향을 주지 않습니다.  

hscroot@icchmc:~> lsmemopt -m Server-8286-42A-SN84D7B4V --xid 5 -o calcscore

curr_sys_score=92,predicted_sys_score=98,requested_lpar_ids=none,protected_lpar_names=DB2CF01,protected_lpar_ids=5

하지만 아래처럼 lpar_id 2번를 최적화 작업에서 제외시키는 경우, 현재 점수와 향후 점수가 똑같이 92점인 것을 보실 수 있습니다.  즉, lpar_id 2번을 제외하면 전체 최적화 작업에서 거의 나아지는 것이 없습니다. 

hscroot@icchmc:~> lsmemopt -m Server-8286-42A-SN84D7B4V --xid 2 -o calcscore

curr_sys_score=92,predicted_sys_score=92,requested_lpar_ids=none,protected_lpar_names=AIX7100_04_08,protected_lpar_ids=2

Approximate Computing 관련 문답

Q1. Single-precision floating point (32-bit)로 훈련된 딥 러닝 모델에서 half-precision (16-bit) inferencing을 사용할 수 있습니까?

A1. 예, Single-precision floating point (단정밀도)로 훈련된 딥 러닝 모델에서  half-precision (반정밀도) 추론을 사용할 수 있습니다.

반정밀도 추론을 사용하는 경우 가중치 및 활성화가 16비트 형식으로 저장되므로 단정밀도(32비트) 형식을 사용할 때보다 추론 시간이 빨라지고 메모리 요구 사항이 줄어들 수 있습니다. 그러나 모델이 단정밀도 형식으로 학습되면 가중치는 32비트 부동 소수점 숫자로 저장됩니다. 따라서 반정밀도로 추론을 수행하려면 먼저 가중치(weight)를 16비트 형식으로 변환해야 합니다.

이 변환 프로세스를 가중치 양자화(weight quantization)라고 하며 모델 정확도의 손실을 최소화하면서 가중치의 정밀도를 32비트에서 16비트로 줄이는 작업이 포함됩니다. 주어진 범위에서 가중치를 균일하게 양자화하는 것과 관련된 선형 양자화와 같은 다양한 가중치 양자화 기술이 있습니다.

반정밀도 추론을 사용하면 때때로 단정밀도 추론에 비해 모델 정확도가 떨어질 수 있다는 점에 유의해야 합니다. 따라서 가중치 양자화 과정을 거친 후 모델의 정확도를 평가하고 필요한 경우 모델을 미세 조정하는 것이 좋습니다.

Q2. 가중치 양자화 외에 단정밀도 학습 모델에서 반정밀도 추론을 사용하려면 어떤 기술을 적용해야 합니까?

A2. 가중치 양자화 외에도 단정밀도 학습 모델에서 반정밀도 추론을 사용하기 위해 적용할 수 있는 몇 가지 다른 기술이 있습니다. 이러한 기술 중 일부는 다음과 같습니다.

활성화 양자화(Activation quantization): 가중치 양자화와 유사하게 활성화 양자화는 활성화의 정밀도를 32비트에서 16비트로 줄이는 것과 관련됩니다. 이를 통해 메모리 요구 사항을 줄이고 추론 속도를 높일 수 있습니다.

혼합 정밀도 훈련(Mixed-precision training): 여기에는 단정밀도 및 반정밀도 데이터 유형의 조합으로 모델을 훈련하는 것이 포함됩니다. 모델의 정방향 및 역방향 전달은 반정밀도 데이터 유형을 사용하여 수행되는 반면 가중치 업데이트는 단정밀도 데이터 유형을 사용하여 수행됩니다. 이를 통해 훈련 중 메모리 요구 사항을 줄이고 훈련 프로세스 속도를 높일 수 있습니다.

기울기 누적(Gradient accumulation): 반정밀도 추론 중에 모델이 GPU 메모리에 맞지 않는 경우 기울기 누적을 사용하여 가중치 업데이트를 수행하기 전에 여러 배치에 걸쳐 기울기를 누적할 수 있습니다. 이렇게 하면 추론 중에 메모리 요구 사항을 줄이는 데 도움이 될 수 있습니다.

손실 조정(Loss scaling): 여기에는 감소된 정밀도를 보상하기 위해 반정밀도 훈련 중에 손실 함수를 확장하는 작업이 포함됩니다. 이는 모델의 수치적 안정성을 개선하고 언더플로와 같은 문제를 방지하는 데 도움이 될 수 있습니다.

이러한 기술은 반정밀도 추론 중에 모델의 성능을 최적화하기 위해 가중치 양자화와 함께 사용할 수 있습니다. 그러나 최적의 기술 조합은 사용 중인 특정 모델 아키텍처 및 데이터 세트에 따라 달라질 수 있다는 점에 유의해야 합니다.

Q3. CUDA 소프트웨어 스택이 없는 Xilinx FPGA와 같이 비 CUDA 환경에서 추론하기 위해 CUDA 환경에서 훈련된 딥 러닝 모델을 사용할 수 있습니까?

A3. 예, CUDA 소프트웨어 스택 없이 Xilinx FPGA와 같은 비 CUDA 환경에서 추론하기 위해 CUDA 환경에서 훈련된 딥 러닝 모델을 사용할 수 있습니다. 이는 훈련된 모델을 원래 형식(예: TensorFlow, PyTorch)에서 대상 하드웨어(예: FPGA)에서 실행할 수 있는 형식으로 변환하는 것과 관련된 "모델 변환"(model conversion) 또는 "모델 최적화"(model optimization)라는 기술을 사용하여 달성할 수 있습니다. ).

모델 최적화를 위한 인기 있는 도구 중 하나는 TensorFlow의 "TensorFlow Lite" 프레임워크로, FPGA를 비롯한 다양한 대상 하드웨어 플랫폼에 대한 모델 변환을 지원합니다. 모델 변환 프로세스에는 일반적으로 다음과 같은 여러 단계가 포함됩니다.

양자화(Quantization): 원래 모델의 부동 소수점 가중치 및 활성화를 고정 소수점 형식으로 변환하여 모델의 메모리 및 계산 요구 사항을 줄입니다.

형식 변환(Format conversion): Xilinx의 DPU(Deep Learning Processor Unit) 형식과 같이 대상 하드웨어와 호환되는 형식으로 모델을 변환합니다.

최적화(Optimization): 가지치기 또는 가중치 공유와 같은 모델에 다양한 최적화를 적용하여 모델 크기를 줄이고 추론 속도를 향상시킵니다.

편집(Compilation): 대상 하드웨어에 최적화된 모델을 컴파일하여 FPGA에서 실행할 수 있는 실행 가능 코드를 생성합니다.

모델이 대상 하드웨어용으로 변환 및 컴파일되면 CUDA 소프트웨어 스택 없이도 추론에 배포하고 사용할 수 있습니다. 그러나 모델의 성능은 대상 플랫폼의 하드웨어 아키텍처에 영향을 받을 수 있으며 최적의 성능을 달성하기 위해 추가 최적화가 필요할 수 있다는 점에 유의해야 합니다.

Q4. 딥러닝에서의 Approximate Computing에 대해 알려주세요.

A4. 근사 컴퓨팅(Approximate Computing)은 성능 또는 에너지 효율성을 위해 정확도를 절충하기 위해 딥 러닝에서 사용할 수 있는 기술입니다. 아이디어는 여전히 허용 가능한 수준의 정확도를 달성하면서 교육 또는 추론과 관련된 계산 속도를 높이기 위해 단순화된 계산 또는 근사 계산을 사용하는 것입니다.

다음을 포함하여 근사 컴퓨팅을 딥 러닝에 적용할 수 있는 몇 가지 방법이 있습니다.

감소된 정밀도 산술(Reduced-precision arithmetic): 32비트 부동 소수점 숫자의 전체 정밀도를 사용하는 대신 근사 계산에서는 16비트 부동 소수점 또는 고정 소수점 숫자와 같은 감소된 정밀도 산술을 사용할 수 있습니다. 이것은 약간의 정확도 손실을 감수하면서 딥 러닝에 필요한 메모리 대역폭과 계산 리소스를 크게 줄일 수 있습니다.

가지치기(Pruning): 근사 컴퓨팅을 사용하여 심층 신경망에서 중요하지 않은 연결이나 뉴런을 가지치기하여 모델의 크기와 훈련 및 추론에 필요한 계산 리소스를 줄일 수 있습니다. 또한 일반화를 개선하고 모델의 과적합을 줄일 수 있습니다.

양자화(Quantization): 이 기술은 신경망에서 가중치 또는 활성화를 나타내는 데 사용되는 개별 값의 수를 줄이는 것과 관련됩니다. 예를 들어 32비트 부동 소수점 숫자를 사용하는 대신 가중치 및 활성화를 8비트 정수로 양자화할 수 있습니다. 이를 통해 딥 러닝에 필요한 메모리 대역폭과 계산 리소스를 줄이면서 여전히 합리적인 정확도를 달성할 수 있습니다.

전반적으로 근사 컴퓨팅은 CPU, GPU 및 특수 하드웨어 가속기와 같은 다양한 컴퓨팅 플랫폼에서 심층 신경망을 보다 효율적이고 확장 가능하게 구현할 수 있기 때문에 딥 러닝에서 유망한 연구 분야입니다. 그러나 정확도와 성능/에너지 효율성 사이의 균형을 신중하게 유지하고 결과 모델이 의도한 응용 프로그램에 여전히 적합한지 확인하는 것이 중요합니다.

NPU와 GPU의 차이점에 대한 문답

 

Q1. NPU와 GPU의 차이점을 알려주세요.

A1. NPU와 GPU는 둘 다 특정 유형의 계산을 위해 설계된 특수 프로세서 유형입니다. NPU는 Neural Processing Unit의 약자이고 GPU는 Graphics Processing Unit의 약자입니다. 두 가지 주요 차이점은 다음과 같습니다.

기능: GPU는 주로 그래픽 처리 및 렌더링용으로 설계된 반면 NPU는 딥 러닝 워크로드를 가속화하기 위해 특별히 설계되었습니다.

아키텍처: GPU에는 일반적으로 다양한 유형의 계산에 사용할 수 있는 더 많은 범용 처리 장치가 있으며 NPU는 딥 러닝 알고리즘의 핵심 작업인 행렬 곱셈에 최적화되어 있습니다.

메모리: GPU는 일반적으로 NPU보다 메모리 용량과 대역폭이 더 큽니다. 이는 많은 양의 데이터를 빠르게 처리해야 하는 특정 유형의 애플리케이션에 중요할 수 있습니다.

전력 효율성: NPU는 딥 러닝 워크로드가 계산 집약적일 수 있고 많은 에너지가 필요할 수 있으므로 GPU보다 전력 효율적으로 설계되었습니다.

소프트웨어 호환성: GPU는 훨씬 더 오래 사용되어 왔으며 더 성숙한 소프트웨어 생태계를 가지고 있는 반면, NPU는 여전히 상대적으로 새롭고 소프트웨어 지원이 제한적일 수 있습니다.

전반적으로 NPU와 GPU의 주요 차이점은 NPU는 딥 러닝 워크로드를 가속화하도록 특별히 설계된 반면 GPU는 그래픽 처리 및 기타 다양한 작업에 적합한 범용 프로세서라는 것입니다.

Q2. GPU에서 범용 처리 장치의 사용 사례에 대한 몇 가지 예를 알려주십시오. CUDA 코어가 범용 처리 장치로도 설명될 수 있다는 것을 몰랐습니다.

A2. 확신하는! GPU는 주로 그래픽 처리 및 렌더링에 사용되는 것으로 알려져 있지만 고성능 컴퓨팅이 필요한 다양한 기타 응용 프로그램에도 사용됩니다. 다음은 몇 가지 예입니다.

기계 학습: GPU는 일반적으로 기계 학습 모델의 학습 및 추론을 가속화하는 데 사용됩니다. 대량의 데이터를 처리하고 기존 CPU보다 훨씬 빠르게 신경망에 필요한 행렬 곱셈 및 기타 작업을 수행할 수 있습니다.

과학적 시뮬레이션: GPU는 물리학, 화학, 생물학과 같은 과학 분야에서 시뮬레이션을 가속화하는 데 사용됩니다. 복잡한 물리적 시스템을 시뮬레이션하고 CPU보다 훨씬 효율적으로 대규모 계산을 수행하는 데 사용할 수 있습니다.

암호화폐 채굴: GPU는 채굴 알고리즘에 필요한 복잡한 계산을 수행하여 암호화폐를 채굴하는 데 사용됩니다. Ethereum, Bitcoin 및 Litecoin을 포함한 다양한 암호 화폐를 채굴하는 데 사용할 수 있습니다.

비디오 인코딩: GPU는 매우 계산 집약적인 비디오 인코딩 및 디코딩을 가속화하는 데 사용됩니다. 많은 양의 비디오 데이터를 처리하고 CPU보다 훨씬 빠르게 처리할 수 있습니다.

게임: 물론 GPU는 게임에도 사용됩니다! 고품질 그래픽을 렌더링하고 최신 비디오 게임에서 원활한 게임 플레이를 가능하게 하는 일을 담당합니다.

두 번째 질문과 관련하여 CUDA 코어는 실제로 그래픽 처리를 넘어 광범위한 작업에 사용할 수 있는 범용 처리 장치입니다. 병렬 처리 작업을 가속화하도록 특별히 설계되었으며 다양한 계산을 수행하도록 프로그래밍할 수 있습니다. 실제로 CUDA 프로그래밍 언어 및 툴킷은 기계 학습, 과학 시뮬레이션 및 비디오 처리와 같은 작업에 널리 사용됩니다.

Q3. NPU의 제한된 소프트웨어 생태계에 대해 자세히 알려주십시오. 그렇다면 tensorflow 또는 pytorch와 같은 잘 알려진 프레임워크가 NPU를 지원하지 않는 경우 NPU는 기계 학습에 어떻게 사용됩니까?

A3. NPU는 여전히 상대적으로 새로운 기술이므로 NPU의 소프트웨어 생태계는 GPU만큼 성숙하지 않습니다. TensorFlow, PyTorch 및 MXNet과 같은 인기 있는 기계 학습 프레임워크는 기본적으로 NPU를 지원하지 않지만 NPU를 기계 학습에 사용할 수 있는 몇 가지 방법이 있습니다.

공급업체별 라이브러리: Huawei 및 Cambricon과 같은 일부 NPU 공급업체는 해당 NPU에 최적화된 자체 기계 학습 라이브러리를 개발했습니다. 이러한 라이브러리는 공급업체의 NPU에서 실행할 수 있는 기계 학습 모델을 작성하는 데 사용할 수 있습니다.

컴파일러 기반 최적화: 컴파일러 기반 최적화 도구를 사용하여 머신 러닝 모델을 자동으로 최적화하여 NPU에서 실행할 수 있습니다. 이러한 도구는 모델을 분석하고 NPU의 특정 아키텍처에 최적화된 코드를 생성할 수 있습니다.

프레임워크 확장: TensorFlow 및 PyTorch와 같은 일부 기계 학습 프레임워크에는 NPU에서 실행할 수 있는 확장이 있습니다. 이러한 확장은 이러한 프레임워크의 친숙한 API를 사용하여 기계 학습 모델을 작성하는 동시에 NPU 가속의 이점을 계속 활용할 수 있는 방법을 제공합니다.

NPU 지원 프레임워크로 모델 포팅: 또 다른 옵션은 기계 학습 모델을 NPU를 지원하는 프레임워크로 포팅하는 것입니다. 예를 들어 TensorFlow로 작성된 모델은 Huawei에서 개발한 MindSpore와 같은 NPU 지원 프레임워크로 내보낼 수 있습니다.

NPU를 위한 제한된 소프트웨어 에코시스템으로 인해 머신 러닝에 NPU를 사용하는 것이 어려울 수 있지만 NPU를 머신 러닝 워크플로에 통합할 수 있는 몇 가지 방법이 여전히 있습니다. NPU의 사용이 보다 널리 보급됨에 따라 더 많은 소프트웨어 지원이 제공될 가능성이 높습니다.

Q4. 일반적으로 NPU는 서버에 어떻게 연결됩니까? PCIe 버스 또는 특수 커넥터 기술을 통해 연결됩니까?

A4. 일반적으로 NPU는 고속 직렬 컴퓨터 확장 버스 표준인 PCIe(Peripheral Component Interconnect Express) 인터페이스를 사용하여 서버에 연결됩니다. NPU는 일반적으로 서버 마더보드의 사용 가능한 PCIe 슬롯에 연결되는 확장 카드로 설치됩니다. PCIe 인터페이스는 NPU와 서버의 CPU 및 메모리 간에 고속 데이터 전송을 제공합니다.

일부 공급업체는 특수 커넥터 또는 상호 연결과 같은 NPU에 대한 다른 인터페이스 옵션도 제공할 수 있지만 PCIe는 NPU를 서버에 연결하기 위한 가장 일반적이고 널리 지원되는 인터페이스입니다. PCIe 인터페이스는 NPU에서 처리해야 하는 대량의 데이터에 적합한 고대역폭, 저지연 연결을 제공합니다.

서버에 연결되면 NPU를 사용하여 서버의 CPU에서 특정 유형의 계산을 오프로드하여 CPU가 다른 작업을 수행할 수 있도록 할 수 있습니다. 이는 많은 계산이 필요한 기계 학습 또는 데이터 분석과 같은 특정 유형의 워크로드를 가속화하는 데 도움이 될 수 있습니다.

Q5. 10개의 NPU 공급업체와 그들의 NPU 제품을 인기순으로 나열할 수 있습니까? 목록에서 GPU 공급업체를 제외하세요.

A5. 물론입니다. GPU 공급업체를 제외하는 목록은 다음과 같습니다.

Google: Google의 TPU(Tensor Processing Unit)는 딥 러닝 워크로드에 사용하도록 설계되었습니다. 최신 제품인 TPU v4는 교육 및 추론 워크로드를 위해 설계되었습니다.

Intel: Intel의 Nervana 신경망 프로세서(NNP)는 딥 러닝 워크로드에 사용하도록 설계되었습니다. 최신 제품인 NNP-T1000은 교육용으로 설계되었으며 NNP-I1000은 추론용으로 설계되었습니다.

Qualcomm: Qualcomm의 AI 엔진에는 딥 러닝을 포함한 기계 학습 워크로드를 실행하기 위한 하드웨어 가속기가 포함되어 있습니다. 최신 제품인 AI Engine 880은 모바일 장치용으로 설계되었습니다.

Huawei: Huawei의 NPU Ascend 시리즈에는 기계 학습 워크로드를 실행하기 위한 하드웨어가 포함되어 있습니다. 최신 제품인 Ascend 910은 데이터 센터 및 클라우드 컴퓨팅에서 사용하도록 설계되었습니다.

Amazon: Amazon의 Inferentia는 클라우드 컴퓨팅 환경에서 사용하도록 설계된 NPU입니다. 최신 제품인 Inferentia 2는 기계 학습 및 추론 워크로드를 실행하도록 설계되었습니다.

Xilinx: Xilinx의 Alveo 가속기 카드 시리즈에는 기계 학습 및 데이터 분석을 위한 하드웨어가 포함되어 있습니다. 최신 제품인 Alveo U50은 데이터 센터 및 클라우드 컴퓨팅 환경에서 워크로드를 가속화하도록 설계되었습니다.

Habana Labs: Habana Labs는 Gaudi 및 Goya를 비롯한 여러 NPU 제품을 생산하는 이스라엘 회사입니다. 이러한 NPU는 클라우드 컴퓨팅, 데이터 센터 및 에지 컴퓨팅에서 사용하도록 설계되었습니다.

Cambricon: Cambricon은 Cambricon 1M, Cambricon 1H 및 Cambricon 1H2를 비롯한 여러 NPU 제품을 생산하는 중국 회사입니다. 이러한 NPU는 클라우드 컴퓨팅, 데이터 센터 및 에지 컴퓨팅에서 사용하도록 설계되었습니다.

Graphcore: Graphcore의 IPU(Intelligence Processing Unit)는 딥 러닝 애플리케이션에 사용하도록 설계되었습니다. 최신 제품인 IPU-M2000은 교육 및 추론 워크로드 모두를 위해 설계되었습니다.

Tenstorrent: Tenstorrent의 Grayskull 아키텍처는 딥 러닝 및 머신 러닝 워크로드에 사용하도록 설계되었습니다. 최신 제품인 Tensix 칩은 훈련과 추론을 위해 설계되었습니다.

다시 말하지만, 인기도는 주관적일 수 있으며 특정 산업이나 사용 사례에 따라 달라질 수 있다는 점에 유의할 가치가 있습니다. 그럼에도 불구하고 이러한 NPU 공급업체와 해당 제품은 모두 업계의 핵심 업체로 인식되고 있습니다.

Q6. Habana Labs Gaudi에서 ML/DL에 어떤 종류의 소프트웨어 환경을 사용할 수 있습니까?

A6. Habana Labs Gaudi NPU는 ML/DL 워크로드를 위한 다양한 소프트웨어 환경에서 작동하도록 설계되었습니다. 여기 몇 가지 예가 있어요.

TensorFlow: Habana Labs는 Gaudi에서 실행하도록 최적화된 TensorFlow-Habana라는 맞춤형 TensorFlow 배포판을 제공합니다. 이 배포판에는 컨볼루션 및 순환 신경망과 같은 널리 사용되는 ML/DL 작업에 대한 지원이 포함되며 Gaudi의 아키텍처를 최대한 활용하도록 설계되었습니다.

PyTorch: Gaudi는 인기 있는 오픈 소스 ML/DL 프레임워크인 PyTorch도 지원합니다. Habana Labs는 Gaudi에 최적화된 HabanaPytorch라는 맞춤형 PyTorch 확장 기능을 제공하며 회선 및 배치 정규화와 같은 널리 사용되는 작업에 대한 지원을 포함합니다.

ONNX: Gaudi는 ML/DL 모델을 나타내는 개방형 표준인 ONNX(Open Neural Network Exchange) 형식도 지원합니다. ONNX 모델은 Gaudi로 가져와 고성능으로 실행할 수 있습니다.

Habana SynapseAI: Habana Labs는 SynapseAI라는 자체 소프트웨어 개발 키트도 제공합니다. 여기에는 ML/DL 개발자를 위한 고급 API 세트가 포함되어 있습니다. 이러한 API를 통해 개발자는 Gaudi에서 모델을 쉽게 생성, 교육 및 배포하고 NPU의 전체 기능을 활용할 수 있습니다.

전반적으로 Habana Labs는 개발자가 Gaudi NPU의 성능과 기능을 쉽게 활용할 수 있도록 설계된 다양한 소프트웨어 도구와 API를 제공합니다.

Q7. Habana Labs Gaudi는 어떤 OS에서 지원되나요?

A7. Habana Labs Gaudi NPU는 다음을 포함한 여러 운영 체제에서 지원됩니다.

Ubuntu: Habana Labs는 Ubuntu 18.04 및 20.04 LTS에서 Gaudi용 드라이버, 라이브러리 및 소프트웨어 패키지를 제공합니다. 이러한 패키지는 시스템의 패키지 소스에 추가할 수 있는 Habana Labs APT 저장소를 통해 사용할 수 있습니다.

RHEL(Red Hat Enterprise Linux): Habana Labs는 RHEL 8.4에서 Gaudi용 드라이버 및 소프트웨어 패키지를 제공합니다. 이러한 패키지는 시스템의 패키지 소스에 추가할 수 있는 Habana Labs YUM 저장소를 통해 사용할 수 있습니다.

CentOS: Gaudi는 RHEL과 동일한 패키지 및 리포지토리를 사용하여 CentOS 8.4에서도 지원됩니다.

SUSE Linux Enterprise Server(SLES): Habana Labs는 SLES 15 SP3에서 Gaudi용 드라이버 및 소프트웨어 패키지를 제공합니다. 이러한 패키지는 Habana Labs SUSE 리포지토리를 통해 사용할 수 있습니다.

Gaudi를 사용하려면 시스템이 지원되는 CPU, 메모리 및 마더보드를 포함하여 특정 하드웨어 요구 사항을 충족해야 합니다. Habana Labs는 웹 사이트에서 Gaudi와 호환되는 인증 시스템 목록을 제공합니다.

Microsoft .NET 7, 이제 IBM Power에서도 지원

 

.NET 7이 이제 Linux on Power (ppc64le)에서도 지원됩니다.  즉 ppc64le 아키텍처의 Power 서버에서는 C# 언어도 지원하게 되었습니다.  이로써 microservices app 개발에 사용되는 5개 프로그래밍 언어가 모두 ppc64le에서 지원됩니다.  

즉, 과거에는 Oracle 등 AIX에서 수행되는 기간계 시스템과 연계하여 C# 언어로 작성된 업무 프로그램을 사용하기 위해서는 Windows 또는 Linux를 설치한 x86 시스템이 필요했으나, 이제는 x86이 필요하지 않고 같은 Power 시스템에 설치된 Redhat 또는 Openshift container에서 C# 업무 프로그램을 운용할 수 있게 된 것입니다.  

2021년 Stack Overflow에서의 개발자 설문에 따르면 .NET framework은 전업 개발자들에게 있어서 가장 중요한 프레임웍 및 라이브러리입니다. 

관련 발표는 아래 URL에서 좀 더 자세히 보실 수 있습니다.

https://community.ibm.com/community/user/powerdeveloper/blogs/janani-janakiraman/2022/11/07/net7-support-linux-on-power

또한 .NET 7 ppc64le는 이미 고객 reference가 있습니다.  독일의 컴퓨터 설계 관련 기업인 SKM Informatik GmbH인데, 이 기업의 요청으로 .NET 7의 ppc64le 지원이 시작되었다고 합니다.

https://www.ibm.com/downloads/cas/29RYARBY

.NET 7은 github에 그 source code가 공개되니 직접 build 하셔도 됩니다만, .NET 7 for ppc64le는 Openshift container 이미지로 제공되고 또 RHEL 8.7 또는 RHEL 9.1에서 YUM repository를 통해서도 제공됩니다.  

.NET 7 관련된 패키지들은 yum 명령어를 통해 패키지로 아래 예와 같이 설치하실 수 있습니다.  

[cecuser@p1274-pvm1 ~]$ hostnamectl

   Static hostname: p1274-pvm1

         Icon name: computer-vm

           Chassis: vm

        Machine ID: e5e70adcd98c4b56b00cc49cbf093412

           Boot ID: 36e5448112b5432c91f40abe413cb05a

    Virtualization: powervm

  Operating System: Red Hat Enterprise Linux 8.7 (Ootpa)

       CPE OS Name: cpe:/o:redhat:enterprise_linux:8::baseos

            Kernel: Linux 4.18.0-372.9.1.el8.ppc64le

      Architecture: ppc64-le

[cecuser@p1274-pvm1 ~]$ yum list | grep dotnet

dotnet.ppc64le                                          7.0.100-1.el8_7                                             rhel-8-for-ppc64le-appstream-rpms

dotnet-apphost-pack-7.0.ppc64le                         7.0.0-1.el8_7                                               rhel-8-for-ppc64le-appstream-rpms

dotnet-host.ppc64le                                     7.0.0-1.el8_7                                               rhel-8-for-ppc64le-appstream-rpms

dotnet-hostfxr-7.0.ppc64le                              7.0.0-1.el8_7                                               rhel-8-for-ppc64le-appstream-rpms

dotnet-runtime-7.0.ppc64le                              7.0.0-1.el8_7                                               rhel-8-for-ppc64le-appstream-rpms

dotnet-sdk-7.0.ppc64le                                  7.0.100-1.el8_7                                             rhel-8-for-ppc64le-appstream-rpms

dotnet-sdk-7.0-source-built-artifacts.ppc64le           7.0.100-1.el8_7                                             codeready-builder-for-rhel-8-ppc64le-rpms

dotnet-targeting-pack-7.0.ppc64le                       7.0.0-1.el8_7                                               rhel-8-for-ppc64le-appstream-rpms

dotnet-templates-7.0.ppc64le                            7.0.100-1.el8_7                                             rhel-8-for-ppc64le-appstream-rpms

[cecuser@p1274-pvm1 ~]$ sudo yum install dotnet-sdk-7.0

Updating Subscription Management repositories.

Last metadata expiration check: 23:10:11 ago on Tue 06 Dec 2022 03:10:01 AM EST.

Dependencies resolved.

===================================================================================================

 Package                        Arch    Version            Repository                         Size

===================================================================================================

Installing:

 dotnet-sdk-7.0                 ppc64le 7.0.100-1.el8_7    rhel-8-for-ppc64le-appstream-rpms  53 M

Installing dependencies:

 aspnetcore-runtime-7.0         ppc64le 7.0.0-1.el8_7      rhel-8-for-ppc64le-appstream-rpms 2.8 M

 aspnetcore-targeting-pack-7.0  ppc64le 7.0.0-1.el8_7      rhel-8-for-ppc64le-appstream-rpms 1.6 M

 dotnet-apphost-pack-7.0        ppc64le 7.0.0-1.el8_7      rhel-8-for-ppc64le-appstream-rpms 100 k

 dotnet-host                    ppc64le 7.0.0-1.el8_7      rhel-8-for-ppc64le-appstream-rpms 190 k

 dotnet-hostfxr-7.0             ppc64le 7.0.0-1.el8_7      rhel-8-for-ppc64le-appstream-rpms 175 k

 dotnet-runtime-7.0             ppc64le 7.0.0-1.el8_7      rhel-8-for-ppc64le-appstream-rpms 7.8 M

 dotnet-targeting-pack-7.0      ppc64le 7.0.0-1.el8_7      rhel-8-for-ppc64le-appstream-rpms 2.9 M

 dotnet-templates-7.0           ppc64le 7.0.100-1.el8_7    rhel-8-for-ppc64le-appstream-rpms 3.1 M

 netstandard-targeting-pack-2.1 ppc64le 7.0.100-1.el8_7    rhel-8-for-ppc64le-appstream-rpms 1.5 M

Transaction Summary

===================================================================================================

Install  10 Packages

Total download size: 73 M

Installed size: 311 M

Is this ok [y/N]: y

...

Installed:

  aspnetcore-runtime-7.0-7.0.0-1.el8_7.ppc64le

  aspnetcore-targeting-pack-7.0-7.0.0-1.el8_7.ppc64le

  dotnet-apphost-pack-7.0-7.0.0-1.el8_7.ppc64le

  dotnet-host-7.0.0-1.el8_7.ppc64le

  dotnet-hostfxr-7.0-7.0.0-1.el8_7.ppc64le

  dotnet-runtime-7.0-7.0.0-1.el8_7.ppc64le

  dotnet-sdk-7.0-7.0.100-1.el8_7.ppc64le

  dotnet-targeting-pack-7.0-7.0.0-1.el8_7.ppc64le

  dotnet-templates-7.0-7.0.100-1.el8_7.ppc64le

  netstandard-targeting-pack-2.1-7.0.100-1.el8_7.ppc64le

Complete!

설치는 위와 같이 매우 간단합니다.  이제 "Hello, World!"를 프린트하는 샘플 프로그램을 돌려보도록 하겠습니다.

[cecuser@p1274-pvm1 ~]$ dotnet

Usage: dotnet [options]

Usage: dotnet [path-to-application]

Options:

  -h|--help         Display help.

  --info            Display .NET information.

  --list-sdks       Display the installed SDKs.

  --list-runtimes   Display the installed runtimes.

path-to-application:

  The path to an application .dll file to execute.

[cecuser@p1274-pvm1 ~]$ dotnet new console -o MyApp -f net7.0

Welcome to .NET 7.0!

---------------------

SDK Version: 7.0.100

----------------

Installed an ASP.NET Core HTTPS development certificate.

To trust the certificate run 'dotnet dev-certs https --trust' (Windows and macOS only).

Learn about HTTPS: https://aka.ms/dotnet-https

----------------

Write your first app: https://aka.ms/dotnet-hello-world

Find out what's new: https://aka.ms/dotnet-whats-new

Explore documentation: https://aka.ms/dotnet-docs

Report issues and find source on GitHub: https://github.com/dotnet/core

Use 'dotnet --help' to see available commands or visit: https://aka.ms/dotnet-cli

--------------------------------------------------------------------------------------

The template "Console App" was created successfully.

Processing post-creation actions...

Restoring /home/cecuser/MyApp/MyApp.csproj:

  Determining projects to restore...

  Restored /home/cecuser/MyApp/MyApp.csproj (in 200 ms).

Restore succeeded.

[cecuser@p1274-pvm1 ~]$ cd MyApp

[cecuser@p1274-pvm1 MyApp]$  ls -la

total 12

drwxrwxr-x.  3 cecuser cecuser   55 Dec  7 02:24 .

drwx------. 23 cecuser cecuser 4096 Dec  7 02:24 ..

-rw-rw-r--.  1 cecuser cecuser  239 Dec  7 02:24 MyApp.csproj

drwxrwxr-x.  2 cecuser cecuser  168 Dec  7 02:24 obj

-rw-rw-r--.  1 cecuser cecuser  103 Dec  7 02:24 Program.cs

[cecuser@p1274-pvm1 MyApp]$ cat Program.cs

// See https://aka.ms/new-console-template for more information

Console.WriteLine("Hello, World!");

[cecuser@p1274-pvm1 MyApp]$ dotnet run

Hello, World!

[cecuser@p1274-pvm1 MyApp]$ ls -ltr

total 8

-rw-rw-r--. 1 cecuser cecuser 239 Dec  7 02:24 MyApp.csproj

-rw-rw-r--. 1 cecuser cecuser 103 Dec  7 02:24 Program.cs

drwxrwxr-x. 3 cecuser cecuser 181 Dec  7 02:26 obj

drwxrwxr-x. 3 cecuser cecuser  19 Dec  7 02:26 bin

[cecuser@p1274-pvm1 MyApp]$ ls -ltr bin/Debug/net7.0

total 168

-rw-rw-r--. 1 cecuser cecuser  10828 Dec  7 02:26 MyApp.pdb

-rw-rw-r--. 1 cecuser cecuser   4608 Dec  7 02:26 MyApp.dll

-rwxr-xr-x. 1 cecuser cecuser 139488 Dec  7 02:26 MyApp

-rw-rw-r--. 1 cecuser cecuser    385 Dec  7 02:26 MyApp.deps.json

-rw-rw-r--. 1 cecuser cecuser    139 Dec  7 02:26 MyApp.runtimeconfig.json

[cecuser@p1274-pvm1 MyApp]$ ./bin/Debug/net7.0/MyApp

Hello, World!

다만 아래의 MS 홈페이지의 .NET download 사이트에서는 ppc64le 관련 패키지는 별도로 제공되지 않네요.

https://devblogs.microsoft.com/dotnet/announcing-dotnet-7/

Power 서버 LPAR에서 "Compatibility Mode"란 대체 무엇인가?

 Processor compatibility mode란 신규 processor에서도 오래된 버전의 OS를 지원하기 위해 사용되는 mode로서, Power 서버에서 logical partition (LPAR)를 설정할 때 정하는 것입니다.  

이걸 그냥 default로 설정하면 hypervisor가 해당 LPAR를 부팅할 때, 그 OS 버전에 알맞은 최적의 mode를 자동으로 선정합니다.

POWER10에서는 OS 버전에 따라 p8 mode부터 p10 mode까지 사용이 가능하며, mode에 따른 성능 차이는 대부분의 경우 미미합니다.  따라서, 크게 신경 쓰지 않고 그냥 default로 두시는 것을 권고드립니다.

Power10의 경우 지원되는 OS에는 AIX 7.1도 있지만, AIX 7.3 또는 AIX 7.2 TL5 이상이 권고됩니다.  AIX 7.1도 TL5 이상일 경우 지원은 가능하지만, 물리적 I/O (NIC, HBA)를 사용할 수 없고 VIOS를 통한 가상 I/O만 사용이 가능하기 때문입니다.

Power10에서 AIX 7.3 + Power10 mode (Native mode)를 사용할 경우 AIX 7.2 + Power9 mode에 비해 더 얻을 수 있는 이익은 다음과 같습니다만, 192개 이상의 CPU core를 사용하는 경우가 아닌 이상 그 성능 차이는 크지 않습니다.

1. LPAR 하나당 최대 1920개의 logical CPU (AIX 7.2의 경우 최대 1536개)

2. Power10의 MMA (Matrix Multiply Assist) 엔진 지원 (인공지능 inference 업무에 사용)

3. Power10에 최적화된 memcpy 성능

Power10에서 AIX 7.2 + Power9 mode를 사용할 경우 LPAR 하나당 logical CPU 개수가 최대 1536개 (192 * 8) 로 제한됩니다.  이는 p9 시절 최대 확장성이 12-core * 16-socket = 192 core (SMT8) 였기 때문입니다.

XIVE (eXternal Interrupt Virtualization Engine)란 network 가상화의 최적화를 위한 기술입니다.

MMA (Matrix Multiply Assist)란 Power10에 탑재된 행렬 연산 엔진이며, 이는 인공지능 inference 업무에 사용됩니다.

P10 optimized memcpy를 쓸 경우 성능이 어느 정도 향상되는지에 대한 명확한 수치는 발표된 바가 없습니다.

AIX에서 ping의 속도를 msec 이하 단위로 측정하는 방법

 AIX에서는 ping의 응답 시간을 msec로만 보여줍니다.

/ # ping 10.10.14.121

PING 10.10.14.121 (10.10.14.121): 56 data bytes

64 bytes from 10.10.14.121: icmp_seq=0 ttl=255 time=0 ms

64 bytes from 10.10.14.121: icmp_seq=1 ttl=255 time=0 ms

이를 msec 이하의 좀 더 세밀한 단위로 볼 수 있는 방법이 필요할 경우, 아래와 같이 tcpdump를 이용하시면 됩니다.

1) 먼저 창을 2개 띄우시고, 한쪽에서는 목적지 server로 ping을 수행합니다.

/ # ping 10.10.14.121

PING 10.10.14.121 (10.10.14.121): 56 data bytes

64 bytes from 10.10.14.121: icmp_seq=0 ttl=255 time=0 ms

64 bytes from 10.10.14.121: icmp_seq=1 ttl=255 time=0 ms

2) 이어서 2번째 창에서는 아래와 같이 tcpdump 명령을 en0 interface를 통해 저 목적지로 오가는  ICMP protocol에 대해서만 수행합니다.

/ # tcpdump -i en0 ip proto \\icmp and host 10.10.14.100

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on en0, link-type EN10MB (Ethernet), capture size 262144 bytes

18:56:34.807504 IP 10.10.14.100 > aix61: ICMP echo request, id 320, seq 35, length 64

18:56:34.807528 IP aix61 > 10.10.14.100: ICMP echo reply, id 320, seq 35, length 64

18:56:35.807606 IP 10.10.14.100 > aix61: ICMP echo request, id 320, seq 36, length 64

18:56:35.807633 IP aix61 > 10.10.14.100: ICMP echo reply, id 320, seq 36, length 64

이 경우 seq 35 packet의 경우 18:56:34.807504와 18:56:34.807528의 차이, 즉 0.024msec가 응답 시간입니다.

seq 36 packet은 18:56:35.807606와 18:56:35.807633의 차이, 즉 0.027msec가 응답 시간입니다.

** 이 값들은 같은 물리적 서버 위에 구성된 VM 간의 virtual ethernet의 속도이므로 실제 물리적 switch를 거치는 값에 비해 매우 빠른 값입니다.