Windows에서 초당 수백만 개의 데이터 그램을 처리 할 수 ​​있습니까?

Windows 에서 수십 또는 최대 200 개의 멀티 캐스트 그룹 (예 : MSI-X 및 RSS 사용)을 사용하여 작은 UDP 멀티 캐스트 데이터 그램 (대부분 100-400 바이트)을 높은 속도로 수신 하는 HPC 앱을 Windows에 구현할 수 있는지 조사 중입니다. 여러 코어로 확장), 패킷 당 일부 처리를 수행 한 다음 전송합니다. TCP를 통해 전송하면 벽에 부딪히지 않고 필요한만큼 (6.4Gb / sec) 올라갈 수 있었지만 높은 pps 속도로 데이터 그램을받는 것이 문제가되었습니다.

Windows 2012 R2에서 2 포트 10Gb 이더넷 NIC를 사용하는 고사양 NUMA 시스템에 대한 최근 테스트 에서 초 당 수십만 개의 UDP 데이터 그램 을 수신 할 수있었습니다 (즉, 데이터를 실제로 처리하지 않고도 2x12 코어를 사용하여 방정식에서 응용 프로그램의 처리 오버 헤드를 제거하여 얼마나 빨리 얻는 지 확인하고 테스트 된 12 개의 멀티 캐스트 그룹의 커널 부분이 하나의 NUMA 노드의 8 또는 10 코어에 분산 된 것처럼 보입니다 ( 최대 RSS 대기열 이 설정되었습니다) 16)-.net 앱을 사용하더라도 기본 앱은 더 빨라질 수 있습니다.

그러나 심지어 렌 Holgate는 단지 500kpps에서 UDP 패킷을 수신 관리 에 자신의 고성능 윈도우 RIO 시험 1024 바이트의 UDP 페이로드를 사용하여.

에서는 QLogic의 백서 설정된다 "다중 스레드 초소형 패킷 라우팅"(그래서, 수신 및 전송 모두를 포함 후속?)에 대한 제한 (테스트중인 OS가없는 한) 5.7Mpps를 . 에서 기사 에 리눅스 네트워킹 , 한계가 설정되어 2Mpps에 1Mpps 로고 코어 당 (소문에 더 많거나 적은 선형 적 확장), 또는 15Mpps 커널을 우회하는 특별한 솔루션.

예 : 넷맵

900Ghz 에서 실행되는 단일 코어로 10GigE 링크 에서 회선 속도 ( 14.88Mpps ) 로 트래픽을 생성 할 수 있습니다 . 이는 패킷 당 약 60-65 클럭 사이클에 해당하며 코어 및 클럭 주파수에 맞게 확장됩니다 (4 코어의 경우 450MHz 미만에서 회선 속도가 달성 됨). 수신 측에서도 비슷한 요금이 부과됩니다 .

그렇다면 앞 단락에서 설명한대로 특히 UDP 멀티 캐스트를 수신 할 수있는 Windows / Windows Server의 최신 버전은 무엇입니까?

편집 Linux에서 클라우드 플레어 블로그 게시물과 흥미로운 주석 섹션이 있습니다. 초당 백만 개의 패킷을받는 방법 과 해당 해커 뉴스 의견 페이지가 있습니다.

마이크로 소프트에 따르면, 자신의 실험실에서 테스트를 보였다 의 "초기 테스트에서 특정 서버에"고 RIO , 그들은 처리 할 수 있었다

• Windows Server 2008R2에서 손실없이 2Mpps , 즉 RIO 없음
• RIO를 사용하는 Windows Server 8 (시험판)에서 4Mpps

해당 비디오의 스크린 샷 (44:33) :

내 질문에 대한 대답 Is it possible to process millions of datagrams per second with Windows?은 예입니다 . 예 , Windows Server 2008R2에서 RIO 이전에도 나타났습니다.

그러나 공식 발표 자료, 특히 미공개 소프트웨어의 경우,이 프리젠 테이션에 제공된 희소 정보, 테스트에 대한 많은 질문 및 결과를 올바르게 해석하는 방법만으로 소금 한 덩어리로 찍어야했습니다. 가장 관련성이 높은 것 :

1. 송신 수치는? 전수? 아니면 라우팅 (예 : 수신 + 전송)?
2. 어떤 패킷 크기? pps 수치를 자랑하려고 할 때 일반적으로 수행되는 것처럼 아마도 가장 낮습니다.
3. 몇 개의 연결 (TCP 인 경우) / 패킷 스트림 (UDP 인 경우) ? -> 아마도 모든 코어를 사용할 수 있도록 워크로드를 분배하는 데 필요한만큼
4. 어떤 테스트 설정? 기계 및 NIC 사양 및 배선

첫 번째 단계는 중요합니다. 보내기 및 받기에는 다른 단계가 필요하고 성능에 상당한 차이가있을 수 있습니다. 다른 수치의 경우, 코어 당 최소 하나의 연결 / 패킷 스트림이 최대 사양의 머신에서 사용되어 최대 Mpps 수치를 얻는 가장 낮은 패킷 크기를 가정 할 수 있습니다.

편집 나는 방금 Linux에서 고성능 패킷 처리 에 대한 인텔 문서를 발견 했으며 그에 따르면 (Linux)

플랫폼은 초당 약 2M 트랜잭션의 트랜잭션 속도를 유지할 수 있습니다

표준 Linux 네트워킹 스택 사용 (2x8 코어가있는 물리적 호스트). 이 요청 / 응답 테스트의 트랜잭션에는 두 가지 모두가 포함됩니다.

1. UDP 패킷 수신
2. 해당 패킷의 후속 전달

(netperf의 netserver 사용). 테스트는 100 개의 트랜잭션을 병렬로 실행했습니다. 이 논문에는 관심있는 사람들을 위해 더 많은 세부 사항이 있습니다. Windows에서 비교할 내용이 있으면 좋겠습니다. 어쨌든, 해당 요청 / 응답 테스트에 가장 관련성이 높은 차트는 다음과 같습니다.

tl; dr

명확한 대답을하려면 더 많은 테스트가 필요한 것 같습니다. 그러나 상황에 따른 증거에 따르면 Linux는 초저 대기 시간 커뮤니티에서 실제로 독점적으로 사용되는 OS이며 일상적으로 Mpps 워크로드를 처리하는 OS입니다. 그렇다고 Windows에서는 불가능하다는 것을 의미하지는 않지만 Mpps 수를 달성 할 수는 있지만 Windows가 상당히 뒤쳐 질 것입니다. 그러나이를 위해서는 테스트가 필요하며, 예를 들어 CPU 수를 계산할 수있는 비용을 파악해야합니다.

NB 이것은 내가 받아 들일 대답이 아닙니다. 질문에 대한 답변에 관심이있는 모든 사람에게 우리가 어디에 서서 더 조사해야하는지에 대한 힌트를 제공하기위한 것입니다.

에 따라 구글 단지에서 명확히 윈도우 네트워크에서 더 많은 성과를 얻을 수 RIO 시험 (를하고 그 결과를 발표) 한 단 하나가 될 것으로 보인다 렌 Holgate, 자신의 블로그에 코멘트 그는 하나의 IP / 포트 콤보를 사용했다 UDP 패킷을 전송합니다.

즉, 그의 결과는 Linux 테스트에서 단일 코어 수치와 다소 비슷해야합니다 (8 개의 스레드를 사용하고 있지만 코드를 확인하지 않고 단일 UDP 패킷 스트림 만 처리 할 때 성능에 해로울 수 있습니다) 패킷을 과도하게 처리하면 실제로 사용되는 스레드가 거의 없다고 언급합니다. 그 말에도 불구하고 :

이전 API와 새 API 간의 상대적 성능을 비교하기 위해 최대 성능을 얻으려고 열심히 노력하지 않았으므로 테스트에서 철저하지 않았습니다.

그러나 "열심히 시도하는 것"이외 의 더 거친 RIO 세계를 위해 표준 IOCP의 (상대) 안락함을 포기하는 것은 무엇 입니까? 적어도 단일 UDP 패킷 스트림에 관한 한.

그가 의미하는 바는 RIO의 여러 테스트에서 다양한 디자인 접근법을 시도했을 때 NIC 설정을 미세 조정하여 마지막 성능을 짜 내지 않았다는 것입니다. 예를 들어, 수신 버퍼 크기 의 경우 UDP 수신 성능 및 패킷 손실 수치에 큰 긍정적 영향을 줄 수 있습니다.

그러나 그의 결과를 다른 Linux / Unix / BSD 테스트의 결과와 직접 비교하려고 할 때의 문제는 다음과 같습니다. 대부분의 테스트는 "초당 패킷 수"경계를 푸시 할 때 가능한 가장 작은 패킷 / 프레임 크기, 즉 이더넷을 사용합니다 64 바이트의 프레임. Len은 1024 바이트 패킷 (-> 1070 바이트 프레임)을 테스트했는데, 특히 No-Nagle UDP의 경우 훨씬 높은 "초당 비트 수"수치를 얻을 수 있지만 더 작은 패킷을 사용할 수있는 한 pps 경계를 밀지 못할 수 있습니다. . 따라서 이러한 수치를 그대로 비교하는 것은 불공평합니다.

내 퀘스트 결과를 Windows UDP 수신으로 요약하면 지금까지 성능이 나타납니다.

• 초저 대기 시간 및 / 또는 처리량이 많은 응용 프로그램을 개발하려고 할 때 실제로 Windows를 사용하는 사람은 없습니다. 요즘에는 Linux를 사용하고 있습니다.
• 실제로 실제 결과가있는 모든 성능 테스트 및 보고서 (예를 들어 단순한 제품 광고가 아님)는 Linux 또는 BSD에 있습니다 (Len은 개척자이자 최소한 하나의 참조 지점을 제공해 주셔서 감사합니다!)
• Windows의 UDP (표준 소켓)가 Linux보다 빠르거나 느립니까? 나는 아직 말할 수 없다, 내 자신의 테스트를 수행해야
• Windows에서 고성능 UDP (RIO vs netmap)가 Linux보다 빠르거나 느립니까? 리눅스는 쉽게 900MHz 대역, 윈도우에서 단일 코어 전체 10 기가비트의 라인 속도를 처리의에서 발표 최상의 경우 1024 큰 UDP 패킷 크기에 대한 43 % 또는 492kpps까지 갈 수있다, 작은 크기, 즉 BPS 수치는 아마 크게 될 것입니다 pps 수치는 아마도 높아질 것이지만 (인터럽트 처리 또는 다른 커널 공간 오버 헤드가 제한 요인이 아닌 한) 더 나쁩니다.

그들이 리눅스를 사용하는 이유에 관해서는, 월급이 레드몬드에서 나오지 않는 한 Windows와 같은 폐쇄 시스템에서는 netmap이나 RIO와 같은 커널 변경과 관련된 솔루션을 개발하는 것이 거의 불가능하기 때문입니다. 또는 Microsoft와 특별한 계약을 체결 한 경우. 이것이 RIO가 MS 제품인 이유입니다.

마지막으로, 내가 발견 한 것에 대한 몇 가지 극단적 인 예를 들어 보면 Linux에서 진행되고 있습니다.

이미 15 년 전에 일부 사람들 은 1GbE NIC에서 800mHz 펜티엄 III CPU, 133mHz 전면 버스 를 사용하여 680kpps를 수신했습니다 . 편집 : 그들은 표준 네트워크 스택의 대부분을 우회하는 커널 모드 라우터 인 Click 을 사용하고있었습니다 .

2013 년, 아르곤 디자인 관리 얻기 위해

35ns [nano seconds]의 낮은 지연 시간을 거래합니다

그들은 또한 주장

오늘날 거래를위한 기존 컴퓨팅 코드의 대다수는 x86 프로세서 아키텍처의 Linux 용으로 작성되었습니다.

Argon은 Arista 7124FX 스위치 를 사용합니다 (FPGA 이외에).

표준 Linux 커널 위에 구축되었습니다.

다른 구성과 시나리오를 "측정"해야합니다. 2 개의 회사에서 제공하는 2 개의 장비로 AFAIK를 수행 할 수 있습니다. IXIA 와 Spirent . 이들은 라인 속도로 트래픽을 펌핑 할 수있는 하드웨어 기반 트래픽 생성기를 제공합니다. 특정 시스템이 붕괴 될 수있는 속도를 감지 할 수있는 램프 테스트를 제공합니다. 장치는 비싸지 만 대여 할 수 있습니다.