kiki's world: 8월 2019

기억용.....보관용...

https://m.blog.naver.com/PostView.nhn?blogId=alice_k106&logNo=221170259817&proxyReferer=https%3A%2F%2Fwww.google.com%2F

3. RT 벤치마크 사용하기

3.1 cyclictest 설치

RT 벤치마크는 참 여러가지 종류가 있다. 가장 많이 쓰이는 벤치마크는 cyclictest10 라는 프로그램인 듯 하여 본 포스트에서는 cyclictest를 사용할 것이다. 그러나 벤치마크가 cyclictest만 있는것도 아니니, 흥미가 있는 사람은 레퍼런스에 있는 벤치마크를 알아보기 바란다. 물론 난 전부 다 써보진 않았다111213. 그 중에는 한국인이 만든 벤치마크도 있다!14 (이분은 지금 삼성에서 일하고 계신 듯 하다. 심지어 내가 살고있는 곳 바로 옆에 살고계신다.. 영통...)

어쨌든, cyclictest 벤치마크를 내려받아 사용해보자. 참 쉽게 사용할 수 있다.

git clone git://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git

cd rt-tests

git checkout stable/v1.0

make all

make install

Colored by Color Scripter

3.2 cyclictest 실행 및 결과 분석

cyclictest는 수만번, 수십만번의 벤치마크 루프를 돌면서 성능을 측정한다. 자세한 내용까지 들여다 보지는 않았지만, 쓰레드가 잠잤다가(sleep) 일어났을 때(wake)의 시간 차를 측정해 보여주는 걸로 추측된다. 그리고 그 도중, 시간 차가 일정 threshold를 넘으면 overflow로 간주해 결과로써 표시해주는 것 같다.

곧바로 벤치마크를 실행해보자.

./cyclictest -l100000 -m -n -a0 -t1 -p99 -i400 -h400

-l 옵션은 루프의 회수, -t 옵션은 실행될 쓰레드의 개수, -p는 쓰레드의 우선순위(RT 기준) 을 나타낸다. cyclictest 프로세스는 -t 옵션에 명시된 개수만큼의 LWP(Light Weight Process)를 생성하며, 이 쓰레드(프로세스?) 는 SCHED_FIFO로 139의 Priority를 갖는다.15

결과는 아래와 같으며, 각각 차례대로 (1) RT 패치가 되지 않은 라즈비안, (2) emild RT 라즈비안, (3) 일반 커널에 RT를 패치한 경우이다.

Max Latency는 수십만번의 벤치마크 루프 중 가장 Latency가 컸을 때를 의미하고, Min Latency는 가장 짧았던 Latency, Avg는 평균을 의미한다. Total은 총 루프 회수를 뜻하니... 위에서는 1000000번의 루프를 수행한 것이다.16 Histogram Overflow at cycle number는 몇 번째 쓰레드에서 Overflow가 났는지를 뜻하며, 많으면 많을수록 성능이 안좋은 것이다. (따라서 첫 번째 실행 결과가 가장 Worst 하다)

	Max Latency (us)	Min Latency (us)	Avg Latency (us)
일반 커널	514	14	20
emlid RT 라즈비안 커널	67	10	12
일반 커널 RT 패치	91	11	18

꽤 흥미로운 결과가 나왔다. 일반 커널의 Max Latency는 500을 뛰어넘었지만 emild RT 라즈비안은 67에 불과하고, 일반 커널에 RT를 패치한 경우는 91가 나왔다. emild RT 라즈비안 커널이 다른 두 개에 비해서 벤치마크 성능이 월등히 높게 나온다. 일반 커널보다 Latency가 낮은건 이해하겠는데 일반 커널 RT 패치보다 성능이 좋다(......) 직접 벤치마크를 해봤다면 알겠지만, 실행 중 출력에서 나오는 Latency 값도 emild는 10~12를 오가는 반면 일반커널 RT 패치는 15~18을 넘나든다.

왜 두 개의 성능이 다른지는 아직도 잘 이해하지 못하겠다. emild가 소스코드를 특별히 수정한게 있나보다.. 하고 추측만 할 뿐이다.

3.3 시스템 부하를 인위적으로 가해 벤치마크 수행하기

사실 Real-time이라는 건 시스템 부하가 없는 상황에서는 크게 의미가 없다고 볼 수 있다. 왜냐하면 CPU가 Idle 한 상태에서는 무엇을 처리해도 빨리빨리 수행할 것이고, 이러한 상황에서는 RT 리눅스가 의도하는 바인 Pre-emptive의 효과는 크게 두드러지지 않을 것이기 때문이다. 따라서 각 테스트 케이스에서 RT 벤치마크 결과의 차이점을 뚜렷하게 확인하기 위해서는 시스템에 의도적인 부하를 가해야 할 필요가 있다.

부하를 인위적으로 주는 방법은 여러가지가 있겠지만, 내가 이 포스트를 작성하며 사용한 방법은 크게 2가지이다. 첫 번째는 hackbench 라는 툴을 사용해 시스템에 부하를 주는 것이고17, 다른 하나는 cyclictest의 쓰레드 개수를 늘리는 것이다. 이거 말고도 위에서 한국인이 만들었다는 Worst Case Latency Scenario 라는것도 있지만 여기서는 굳이 다루지 않기로 했다.

먼저 hackbench에 대해서 설명하자면, hackbench 는 cyclictest github에 포함되어 있기 때문에 cyclictest를 사용했다면 동 디렉터리 내에 hackbench 파일이 존재할 것이다. hackbench는 두 개의 쓰레드를 생성하고, 서로가 메시지를 엄청나게 많이 주고받음으로써 부하를 일으킨다고 한다. 사용 방법은 매우 쉽다.

hackbench -l 1000000

-l 옵션은 부하 시도 횟수... 로 추측된다. 위 명령어를 실행하면 곧바로 시스템 부하가 시작되며, hackbench를 실행한 상태로 cyclictest를 실행하면 된다.

다른 하나는 cyclictest의 쓰레드 개수를 늘리는 것이다. 직관적으로 생각해 볼 때, 벤치마크가 동시에 여러 개가 실행되면 벤치마크의 성능은 더욱 나빠질 것이다. 따라서 여러 개의 cyclictest를 구동하는 것은 매우 간단하면서도 효과적인 부하 발생 방법이라고 볼 수 있다. 그렇지만 터미널을 여러개 켜고 cyclictest 명령어를 각각 입력할 필요는 없고... cyclictest에서 -t 옵션에 쓰레드의 개수를 지정해주면 된다. 일반적으로 CPU의 개수만큼 쓰레드를 생성해 테스트한다. 또한, -a 옵션을 통해 CPU Affinity를 고정해 주는 것이 일반적이다.18

root@rt-linux-rpi-4:/home/pi/rt-tests ./cyclictest -l100000 -m -n -a -t4 -p99 -i400 -h400

# /dev/cpu_dma_latency set to 0us

policy: fifo: loadavg: 0.04 0.05 0.00 1/166 1042

T: 0 ( 1039) P:99 I:400 C: 13914 Min: 11 Act: 17 Avg: 13 Max: 75

T: 1 ( 1040) P:99 I:400 C: 13808 Min: 11 Act: 18 Avg: 13 Max: 61

T: 2 ( 1041) P:99 I:400 C: 13704 Min: 11 Act: 17 Avg: 13 Max: 58

T: 3 ( 1042) P:99 I:400 C: 13598 Min: 11 Act: 30 Avg: 13 Max: 44

어쨌든, RT 패치된 커널에서 부하를 가한 뒤 cyclictest를 실행하면 CPU가 자주 뻗어 죽어버리므로 재부팅해야 한다는 단점이 있다.

주의해서 사용하도록 하자.

끝.

1. 라즈베리파이 3를 쓰지 않은 이유는 아래에서 설명할 emild의 RT 라즈비안이 라즈베리파이 3를 지원하지 않기 때문이다. 라즈베리파이 3에서 사용하는 방법은 https://autostatic.com/2017/06/27/rpi-3-and-the-real-time-kernel/ 를 참고.
2. github 주소 : https://github.com/emlid/linux-rt-rpi
3. emild 사이트 주소 : https://emlid.com/raspberry-pi-real-time-kernel/
4. 혹시 모르니
CONFIG_PREEMPT_RT_FULL: Kernel Features → Preemption Model (Fully Preemptible Kernel (RT)) → Fully Preemptible Kernel (RT)
Enable HIGH_RES_TIMERS: General setup → Timers subsystem → High Resolution Timer Support (Actually, this should already be enabled in the standard configuration.)
를 설정한다.
5. RT 라즈비안 설치 방법 잘 설명해 놓음 : http://www.frank-durr.de/?p=203
6. 똑같은 내용이지만, 잘 설명해 놓음 : http://artteknika.hatenablog.com/entry/2016/08/23/142820
7. 라즈비안 RT 패치 공식 문서 : https://www.raspberrypi.org/documentation/linux/kernel/patching.md
8. 리눅스 재단(Linux Foundation) RT 패치 공식 문서 :
https://wiki.linuxfoundation.org/realtime/documentation/howto/applications/preemptrt_setup
9. RT Patch Config 확인방법, 개념 및 다양한 내용 :
https://raspberrypi.stackexchange.com/questions/8970/default-kernel-preemption-vs-real-time-patch
10. https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cyclictest
11. https://www.osadl.org/Latency-generator.latency-generator.0.html
12. https://www.osadl.org/Driver-to-Program-Signal-Tester.driver-to-program-signal-tester.0.html
13. https://wiki.archlinux.org/index.php/Realtime_kernel
14. https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/worstcaselatency
15. 궁금하면 cyclictest 를 실행한 뒤 ps -cLe | grep cyclictest 를 사용해보자.
16. Cyclictest 결과 분석 및 예제 소스코드 한국어 포스트. 매우 잘 써놨음 : https://blog.naver.com/indy9052/120123664718
17. https://man.cx/hackbench(8)
18. Cyclictest 옵션 설명 및 결과 분석하기 :
https://events.static.linuxfound.org/sites/events/files/slides/cyclictest.pdf

kiki's world

2019년 8월 9일 금요일

ROS2 관련 자료

cmake / MakeFiles 관련 study

2019년 8월 8일 목요일

ROS2 명령어 등 정리

2019년 8월 4일 일요일

[프로그래밍]-[버전관리] git

linux preempt_rt 성능 테스트

프로필