[완료->미해결]arm에서 epoll ET +PF_PACKET의 90%캡쳐율 문제
[ PC ] ---- 110byte, 960packet/s ---> [ ARM ]
ARM보드의 스펙은 한백전자의 SM2로
Intel Xscale PXA270, 520Mhz, RAM 128M
리눅스는 2.6.12가 설치 되어 있는 상태입니다.
Ethernet frame이 960Hz로 N개의 노드에서 ARM보드에 전송하고 있으며
ARM보드에서는 PF_PACKET소켓을 이용하여 패킷을 잡고 있습니다.
ET모드로 epoll로 소켓을 감시하고 패킷이 있으면 소켓에서 데이터를 읽는 쓰레드를 깨우는 식으로 구현해 놓았습니다.
그런데 아무리해도 약90%정도의 패킷만을 잡아 내고 있습니다.
LT모드에서는 85%정도의 캡쳐율을 보이며
노드가 1개일 때는 약 850개 전후
2개일때 1700개 전후
10개일때 8000개 전후
이런식의 캡쳐율을 보이고 있습니다.
PCAP을 이용해서 리눅스에서 모든 패킷을 잡는게 어렵다고 하는데.. PCAP도 PF_PACKET소켓을 사용하고 있지요?
커널패치를 통해서 PF_RING이라는 소켓을 사용할 수 있도록 하면 된다고 해서 PF_PACKET에 관련된 논문들을 읽고 있는데..
이런 일이 발생하는 원인을 알고싶습니다.
제 생각으로는 PF_PACKET이 하나의 소켓을 이용해서 모든 패킷을 잡으려니 병목이 일어나는 거 같은데요...
그리고 pthread_cond를 이용해서 읽기 쓰레드가 대기 하고 있는데 쓰레드를 깨우는데 걸리는 지연 때문에 패킷을 몇개 못잡는건지 ㅡㅜ
작은크기, 많은 양, 정확한 타이밍을 요구하는 패킷들을 처리하는 시스템에서는 커널을 수정하는 방법밖에는 답이 없을까요?
...
보고 계신 논문(?)을 잘~ 읽어보시면 궁금하신 부분에 대한, 많은 실험결과(?)가 나올텐데요.
5~6년전에 서베이한 것이라, 좀 가물가물하긴한데요.
패킷의 손실(loss)는 대체로 네트워크 인터페이스와 커널사이에서 일어납니다. 커널과 유저사이에서도 일어날 수 있지만, 전자보다는 못하고, 따라서, NIC-Kernel, 이 부분의 개선이 필수적이라는 얘기지요.
pcap buffer size(kernel) , Interrupt vs. polling, NAPI등과 메인 보드의 Bus Speed도 고려 대상입니다.
네트워크와 메모리(버퍼)의 관계는 말할 필요없고, 네트워크장비등처럼 빈번한(주업무가) IO를 행하는 장비에서 인터럽트는 오히려 독이 되기도 한다는 사실과(폴링이 오히려 낫다!), NIC에서 메인보드로 전송되는 보드의 버스 스피드도 주 고려대상입니다.(대상장비의 물리적 한계치를 검토하시라는 얘기입니다)
이러한 문제를 해결해보고자 실험하고, 만들고해서, 산물이 나왔지요. 이러한 소프트웨어적인 접근의 산물로 PF_RING과 보다 최근(2-3년전이던가요?) DMA_RING등을 검토할 수 있을 것입니다.
아울러, 비용이 문제긴 하지만, NPU, FPGA 및 Dag, Combo6등 전용 패킷 캡쳐카드등 하드웨어의 도움을 받는 것도 방법입니다.
------------------ P.S. --------------
지식은 오픈해서 검증받아야 산지식이된다고 동네 아저씨가 그러더라.
------------------ P.S. --------------
지식은 오픈해서 검증받아야 산지식이된다고 동네 아저씨가 그러더라.
허접한 질문에 답변 감사합니다.
논문들 찾아 놓고 다 읽지 않은 상태에서 우문을 해버렸네요..
논문들을 보니 어느정도 답이 나와있더군요;;
답변 감사드립니다.
프로그래머 다운 프로그래머가 되고 싶습니다. 많은 지도 편달 부탁드립니다^^
완료된줄 알았으나.. 아니었습니다.
위 프로젝트는 끝났으나 문제가 발생하여 리플을 올립니다.
PF_RING에... 상당히 큰 문제가 있었습니다. 이 글을 쓸때의 PF_RING버전이 데드락이었나? 죽어버리는 버그가 있었습니다. 커널 모듈인데 말이죠...
그로인해서 저는 2주동안 괜한 삽질을 한것이었고.... 제대로 했는데 오동작하여 뭔가 이상하다고 생각했었는데....역시나.....
PF_RING이 정상작동하고 제대로 테스트를 할수 있었습니다. 그 결과 epoll과 비교 하였을때 위 환경에서는 PF_RING과 epoll의 차이가 없었습니다. 오히려 PF_RING은 불안정한 운영을 보여주었습니다.
중요한것은 그게 아니고...
인텔 펜티엄 3 400Mhz CPU
80G HDD, 7200RPM
128 SD RAM
BX chip MS6116 mainboard
Realtek 8139D NIC
위 사양의
windows XP
Cent OS 5.2 (kernel 2.6.18)
Fedora 4 (kernel 2.6.11)
OS 에서 100%의 캡쳐율을 보이고 30노드(초당 960 * 30의 패킷수)에서 knee가 나타납니다. 초기 약 5%의 로스에서 로스율은 증가 합니다. 앞의 경우에는 로스율이 일정하지요
ARM보드의 스펙으로도 충분히 960Hz의 패킷을 받을수 있을 것이라 예상했는데 일정하게 10%정도의 로스가 발생하는게 계속해서 이해가 되지 않았습니다.
MIPS는 ARM의 경우가 역시 더 높습니다. 다른 연산(대칭, 비대칭 암호화,복호화)에서는 ARM이 3배 정도 더 나은 결과를 보여주었습니다.
혹시 NIC의 문제일까 해서 구글링을 해봐도 특별히 나오는건 없습니다...
그런데 커널에서(PF_RING의 커널모듈) 수신한 패킷을 디버그 모드로 다 찍어보면 역시 위의 님께서 말씀해주신 바와 같이 커널자체에 패킷이 들어오지 않았습니다.
이제 한백전자에 결과와 코드들을 다 보내서 더 물어봐야 할거 같은데 프로젝트도 끝나고(성과없음;;) 원래 해야 하는 일을 해야 하기에 시간이 안나네요.. 원인을 찾으면 다시 보완을 해야겠습니다.
혹시나 원인이 짐작가시는 분은 댓글좀 달아주세요 ㅜㅜ
프로그래머 다운 프로그래머가 되고 싶습니다. 많은 지도 편달 부탁드립니다^^
프로그래머 다운 프로그래머가 되고 싶습니다. 많은 지도 편달 부탁드립니다^^
댓글 달기