Windows에서 HPC 앱을 구현할 수 있는지 조사 중입니다.12개에서 최대 200개의 멀티캐스트 그룹을 사용하여 작은 UDP 멀티캐스트 데이터그램(주로 100-400바이트)을 빠른 속도로 수신합니다.(예: MSI-X 및 RSS를 사용하여 여러 코어로 확장할 수 있음) 패킷당 일부 처리를 수행한 다음 이를 보냅니다. TCP를 통해 전송하면서 벽에 부딪히지 않고 필요한 만큼(6.4Gb/초)까지 올라갈 수 있었지만 높은 pps 속도로 데이터그램을 수신하는 것이 문제로 나타났습니다.
안에최근 테스트Windows 2012 R2의 2포트 10Gb 이더넷 NIC가 있는 고성능 NUMA 시스템에서는 다음과 같은 작업만 수행할 수 있었습니다.초당 수십만 개의 UDP 데이터그램 수신(초기 드롭, 즉 데이터를 실제로 처리하지 않고 방정식에서 내 앱의 처리 오버헤드를 제거하여 속도가 얼마나 빨라지는지 확인하기 위해) 2x12 코어를 사용하고 테스트된 12개 멀티캐스트 그룹의 커널 부분은 8개 이상의 코어에 분산되는 것처럼 보였습니다. NUMA 노드 1개의 코어 10개(최대 RSS 대기열16으로 설정됨) - .net 앱을 사용하더라도 기본 앱이 더 빠르게 작동할 수 있어야 합니다.
하지만 심지어렌 홀게이트 500kpps의 UDP 패킷만 수신했습니다.~에그의 고성능 Windows RIO 테스트, 1024바이트의 UDP 페이로드를 사용합니다.
~ 안에QLogic 백서(테스트 중인 OS는 언급되지 않음) "멀티 스레드 초소형 패킷 라우팅"(수신 및 후속 전송을 모두 포함합니까?)에 대한 제한은 다음과 같이 설정됩니다.5.7Mpps. ~ 안에조항~에리눅스 네트워킹, 한도는 다음과 같이 설정됩니다.1Mpps ~ 2Mpps코어당(거의 선형적으로 확장된다고 보고됨) 또는 심지어15Mpps커널을 우회하는 특수 솔루션을 사용합니다.
예:넷맵
회선 속도로 트래픽을 생성할 수 있습니다(14.88Mpps) 900Mhz에서 실행되는 단일 코어가 있는 10GigE 링크. 이는 패킷당 약 60-65 클록 주기에 해당하며 코어 및 클록 주파수에 따라 잘 확장됩니다(4개 코어의 경우 회선 속도는 450MHz 미만에서 달성됨).수신 측에서도 비슷한 속도에 도달했습니다..
그렇다면 Windows/Windows Server(최신 버전), 특히 앞 단락에서 설명한 UDP 멀티캐스트 수신을 얼마나 멀리까지 할 수 있습니까?
편집하다Linux에서 이를 수행하는 방법에 대한 cloudflare 블로그 게시물과 흥미로운 의견 섹션이 있습니다.초당 백만개의 패킷을 수신하는 방법, 그리고 그에 상응하는해커 뉴스 댓글 페이지.
답변1
Microsoft에 따르면 자체 연구실에서 테스트를 진행했습니다.보여 주었다"초기 테스트의 특정 서버에서"리오, 그들은 처리할 수 있었다
- 손실 없이 2MppsWindows Server 2008R2, 즉 RIO가 없는 경우
- RIO를 사용하는 Windows Server 8(시험판)에서 4Mpps
해당 동영상의 스크린샷(44:33):
그럼 내 질문에 대한 대답은Is it possible to process millions of datagrams per second with Windows?다음과 같습니다:예, Windows Server 2008R2에서는 RIO 이전에도 있었던 것 같습니다.
그러나 공식 수치, 특히 아직 출시되지 않은 소프트웨어에 대한 이 프레젠테이션에 제공된 희소한 정보만으로 소금을 조금 넣어야 하는 것 외에도 테스트에 대한 많은 질문과 결과를 올바르게 해석하는 방법이 남아 있습니다. 가장 관련성이 높은 것은 다음과 같습니다.
- Sending 수치인가요? 전수?아니면 라우팅(예: 수신 + 보내기)용인가요?
- 패킷 크기는 어떻게 되나요?-> 자랑할 pps 수치를 얻으려고 할 때 일반적으로 수행되는 것처럼 가능한 가장 낮은 값일 것입니다.
- 연결 수(TCP인 경우)/패킷 스트림(UDP인 경우)? -> 아마도 존재하는 모든 코어를 사용할 수 있도록 작업 부하를 분산하는 데 필요한 만큼 많을 것입니다.
- 어떤 테스트 설정?기계 및 NIC 사양 및 배선
보내기와 받기에는 서로 다른 단계가 필요하고 상당한 성능 차이가 나타날 수 있으므로 첫 번째가 중요합니다. 다른 수치의 경우 코어당 최소 하나의 연결/패킷 스트림이 있는 가장 낮은 패킷 크기가 가능한 최대 Mpps 수치를 얻기 위해 고성능 시스템에서 사용되었다고 가정할 수 있습니다.
편집하다방금 인텔 문서를 우연히 발견했습니다.고성능 패킷 처리Linux에서는 (Linux)
플랫폼은 초당 약 200만 건의 트랜잭션 속도를 유지할 수 있습니다.
표준 Linux 네트워킹 스택을 사용합니다(2x8 코어가 있는 물리적 호스트에서). 이 요청/응답 테스트의 트랜잭션에는 두 가지가 모두 포함됩니다.
- UDP 패킷 수신
- 해당 패킷의 후속 전달
(netperf의 netserver 사용). 테스트에서는 100개의 트랜잭션을 병렬로 실행했습니다. 관심 있는 분들을 위해 이 논문에 더 많은 세부정보가 있습니다. Windows에서 비교할 수 있는 이와 같은 것이 있었으면 좋겠습니다... 어쨌든, 해당 요청/응답 테스트에 가장 관련성이 높은 차트는 다음과 같습니다.
답변2
tl;dr
확실한 답을 내리기 위해서는 더 많은 테스트가 필요할 것 같습니다. 그러나 정황 증거에 따르면 Linux는 Mpps 워크로드를 일상적으로 처리하는 초저지연 커뮤니티에서만 실질적으로 독점적으로 사용되는 OS입니다. 이는 Windows에서는 불가능하다는 의미는 아니지만 Mpps 수치를 달성하는 것이 가능하더라도 Windows는 아마도 상당히 뒤처질 것입니다. 그러나 이를 확인하려면 테스트가 필요합니다. 예를 들어 해당 수치를 달성할 수 있는 CPU 비용을 파악하려면 테스트가 필요합니다.
NB 이것은 제가 받아들이려는 답변이 아닙니다. 이는 질문에 대한 답변에 관심이 있는 모든 사람에게 우리의 입장과 추가 조사에 대한 힌트를 제공하기 위한 것입니다.
Google에 따르면 Windows 네트워킹에서 더 많은 성능을 얻기 위해 RIO를 테스트하고 결과를 게시한 유일한 사람인 것으로 보이는 Len Holgate는 방금 다음과 같이 밝혔습니다.그의 블로그에 댓글을 달다그는 UDP 패킷을 전송하기 위해 단일 IP/포트 콤보를 사용하고 있었습니다.
즉, 그의결과는 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 대 넷맵)가 Linux보다 빠르거나 느립니까? 리눅스용이하게Windows에서 900MHz의 단일 코어로 최대 10Gb 회선 속도를 처리합니다.게시된 최고의 사례1024의 큰 UDP 패킷 크기에 대해 최대 43% 또는 492kpps까지 올라갈 수 있습니다. 즉, 작은 크기의 bps 수치는 훨씬 더 나쁠 수 있지만 pps 수치는 아마도 상승할 것입니다(인터럽트 처리나 다른 커널 공간 오버헤드가 제한되지 않는 한). 요인).
Linux를 사용하는 이유는 성능을 한계까지 끌어올릴 때 필요한 netmap 또는 RIO와 같은 커널 변경과 관련된 솔루션을 개발하는 것이 Redmond에서 급여가 나오지 않는 한 Windows와 같은 폐쇄형 시스템에서는 거의 불가능하기 때문일 것입니다. 또는 Microsoft와 특별한 계약을 맺었습니다. 이것이 바로 RIO가 MS 제품인 이유입니다.
마지막으로, 제가 발견한 것의 몇 가지 극단적인 예를 들자면 Linux 분야에서 현재 그리고 현재 진행되고 있습니다.
이미 15년 전에는 일부 사람들이 680kpps를 받고 있었습니다.800mHz Pentium III CPU, 133mHz 전면 버스1GbE NIC에서. 편집하다: 그들은 사용하고 있었다딸깍 하는 소리, 표준 네트워크 스택의 대부분을 우회하는 커널 모드 라우터, 즉 "속임수"입니다.
2013년 아르곤 디자인관리하다얻기 위해
35ns[나노초]만큼 낮은 거래 지연 시간을 선택하세요.
그런데 그들은 또한 그렇게 주장합니다
그리고 아르곤은아리스타 7124FX 스위치, (FPGA 외에) OS가 있음
표준 Linux 커널 위에 구축되었습니다.