6.4.0저는 Linux 커널과 패치를 사용하여 Linux 실시간 시스템을 사용자 정의하고 있습니다 patch-6.4.6-rt8. 런타임 시 make menuconfig실시간 성능을 향상하려면 어떤 구성을 꺼야 합니까? 시스템은 주로 로봇 팔 컨트롤러 역할을 합니다.
이때 시스템을 사용하여 cyclictest지연 효과를 테스트한 결과, 지터가 최소값 2, 최대값 39로 다소 높은 것으로 나타났습니다.
# cyclictest -t1 -p 80 -n -i 1000 -l 10000
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 0.27 0.07 0.02 1/122 627
T: 0 ( 577) P:80 I:1000 C: 10000 Min: 2 Act: 2 Avg: 2 Max: 39
#
답변1
일반적으로 말하면 그렇지 않습니다. 시스템의 실시간 특성은 시스템의 기능이 아니라 -rt 패치 세트 적용 여부와 적절한 실시간 작업이 필요한 소프트웨어를 설계하고 실행하는지 여부에 따라 결정됩니다. 지연 시간을 추가하는 rt 패치 커널에서 유일한 것은 인터럽트가 비활성화된 긴 중요 섹션이 있는 드라이버입니다. 그러나 대부분의 장치에서 이는 아마도 커널 드라이버가 실행 중일 때 작동하지 않으며 드라이버를 제거하면 비활성화됩니다. 사용 중인 하드웨어 구성 요소. 그래서 나는 그것이 선택 사항이라고 생각하지 않습니다.
귀하의 핸들이 "ABeginner"이므로 처음부터 자체 커널 구성을 구축하지 말고 대신 oldconfigLinux 배포판에서 -rt 커널을 사용하거나, 제공하는 경우 -rt 커널을 사용하십시오. 귀하의 배포판과 함께 제공됩니다.
이때 시스템은 cyclotest를 사용하여 지연 효과를 테스트한 결과 지터가 최소값 2, 최대값 39로 약간 높은 것으로 나타났습니다.
최신 x86_64 또는 aarch64 시스템의 범위 내에서 이 숫자는 좋아 보입니다. 당신은 "지터가 약간 높다"고 말했지만 실시간 신호 처리에 관련된 엔지니어로서 "약간 높다"는 것은 실제로는 문제가 되지 않습니다. 최대 지연은 작동하거나 작동하지 않습니다. 이것이 바로 실시간 시스템의 핵심입니다.
따라서 39 µs가 충분하다고 결론을 내리거나(실제로는 아마도 그럴 것입니다! 예를 들어 오디오 관련 항목의 경우 또는 기계 비상 정지 컨트롤러의 경우 충분하지 않을 수도 있음), 그렇지 않다고 결론을 내릴 것입니다. 하지만 그 이유는 무엇인지 물으실 것입니다. 정확도 테스트를 수행하려는 경우 nanosleep(예: 커널 공간에서 하드웨어 타이머 인터럽트를 처리하는 대신) 나는 이것이 실제로 조금 더 나아갈 것이라고 생각합니다. 라이브 애플리케이션 프로세스에 어떤 코어를 고정하는지 파악하는 것이 포함됩니다(그러한 프로세스가 있는 경우 다시 userland 를 측정하고 있으므로 nanosleepa가 있어야 합니다). 이는 이벤트 소스 및 이벤트 소스(단순한 타이머 이상이라고 가정)와 이벤트에서 작동하는 시스템 사이의 체인에 있는 것과 관련됩니다. 따라서 불행하게도 실시간 시스템 개선의 모든 어려움은 FreeRTOS와 같은 단순한 운영 체제와 마찬가지로 Linux에도 적용됩니다.