나는 Zynq 7000 보드에서 리눅스의 자일링스 배포판으로 일하고있다. 여기에는 두 개의 ARM 프로세서, 일부 L2 캐시, DRAM 인터페이스 및 많은 양의 FPGA 패브릭이 있습니다. 어플라이언스는 FPGA에서 처리중인 데이터를 수집 한 다음 기가비트 네트워크를 통해 다른 시스템으로 보냅니다.Zynq 7000에 임베디드 리눅스, 거의 모든 UDP 패킷을 버림
이 어플라이언스에서 지원해야하는 서비스 중 하나는 UDP 데이터 그램을 사용하는 SNMP이며 SNMP는 TCP를 지원하지만 클라이언트가이를 강제로 사용할 수는 없습니다.
내가 아는 것은이 시스템이 거의 모든 SNMP 요청을 잃어 버리고 있다는 것입니다.
네트워크 나 CPU에 과부하가 걸리지 않습니다. 데이터 속도는 특별히 높지는 않으며 CPU는 대개 약 30 % 부하 정도입니다. 또한 SNMP 용 SNMP ++ 및 Agent ++ 라이브러리를 사용하고 있으므로 해당 시스템을 제어 할 수 있으므로 시스템 데몬이 손상되지는 않습니다. 그러나 처리 및 네트워크 작업을 중지하면 SNMP 요청이 손실되지 않습니다. SNMP는 자체 스레드에서 처리되고 있으며 희귀하고 확산 된 요청을 유지하여 한 번에 둘 이상의 요청을 버퍼링해서는 안됩니다. CPU 부하가 적 으면 요청을 처리하기 위해 수신 프로세스로 문맥 전환하는 데 문제가 없어야합니다.
CPU 또는 이더넷 대역폭 문제가 아니기 때문에 문제는 Linux 커널에 있다고 생각하면됩니다. 낮은 네트워크로드에도 불구하고, 제한된 네트워크 스택 버퍼가 과도하게 채워지고있는 것 같아 UDP 데이터 그램을 삭제하는 이유입니다.
인터넷 검색을 통해 netstat을 사용하여 손실 된 패킷을보고하는 방법에 대한 예제를 찾았지만 "-s"옵션이 없기 때문에이 시스템에서는 작동하지 않습니다. 어떻게 이러한 패킷 방울을 모니터링 할 수 있습니까? 어떻게 원인을 진단 할 수 있습니까? 이 손실을 최소화하기 위해 어떻게 커널 매개 변수를 조정할 수 있습니까?
감사합니다.
요청이 끝날 때 SNMP 응답이 손실 될 수도 있지만 이는 CPU와 메모리가 많은 Linux를 실행하는 일반 x86 시스템 일뿐입니다. –
문제를 두 갈래로 나누고 패킷의 도착 위치와 손실 위치를 확인할 수 있다면 좋을 것입니다. wireshark와 같은 도구를 사용하여 요청이 Zynq 보드에 전달되는지 확인할 수 있습니다. UDP 패킷이 커널에서 사용 가능한지 확인하기 위해'tcpdump'를 추천 할 것입니다. 보드의 플래시를 통해 다른 linux 유틸리티를 설치할 수 있습니다. 또한 UDP는 전달을 보장하지 않습니다 (SNMP에 자체 재시도 논리 온톨 탑이 있는지 확실하지 않습니다). – Phil
좋아요, 저는 개인적으로 wireshark를 사용한 적이 없지만 제 동료들이 가지고 있습니다. SNMP의 경우 시간 제한이 있습니다. 제 경우에는 상태 변수를 변경하고 설정하지 않는 것을 찾으려고하므로 10 번 재 시도하는 스레드를 생성합니다. 종종 10 번 시도가 모두 손실되어 고통 스럽습니다. –