Có thể xử lý hàng triệu datagram mỗi giây với Windows không?

Tôi đang điều tra xem liệu tôi có thể triển khai ứng dụng HPC trên Windows để nhận các datagram đa tuyến UDP nhỏ (chủ yếu là 100-400 byte) với tốc độ cao hay không, sử dụng hàng tá hoặc tối đa 200 nhóm phát đa hướng (tức là sử dụng MSI-X và RSS chia tỷ lệ thành nhiều lõi), thực hiện một số xử lý cho mỗi gói và sau đó gửi nó ra. Gửi qua TCP Tôi đã cố gắng tăng lên đến mức tôi cần (6.4Gb / giây) mà không va vào tường, nhưng việc nhận datagram với tốc độ pps cao hóa ra là một vấn đề.

Trong một thử nghiệm gần đây trên máy NUMA thông số kỹ thuật cao với một ethernet ethernet 10 cổng 10 cổng trên Windows 2012 R2, tôi chỉ có thể nhận được hàng trăm ngàn datagram UDP mỗi giây (giảm sớm, tức là không thực sự xử lý dữ liệu, để loại bỏ chi phí xử lý của ứng dụng của tôi khỏi phương trình để xem tốc độ của nó nhanh như thế nào) bằng cách sử dụng lõi 2x12 và phần nhân của 12 nhóm phát đa hướng được kiểm tra dường như được phân phối trên 8 hoặc 10 lõi của một nút NUMA ( hàng đợi tối đa RSS đã được đặt đến 16) - mặc dù có ứng dụng .net, vì vậy các ứng dụng gốc sẽ có thể đi nhanh hơn.

Nhưng ngay cả Len Holgate cũng chỉ có thể nhận được các gói UDP với tốc độ 500kpps trong các thử nghiệm Windows RIO hiệu suất cao của mình , sử dụng tải trọng UDP là 1024 byte.

Trong whitepaper của QLogic (Hệ điều hành đang được thử nghiệm không được đề cập), các giới hạn cho "định tuyến gói siêu nhỏ đa luồng" (để bao gồm cả nhận và gửi sau?) Được đặt ở mức 5,7Mpps . Trong các bài viết về mạng Linux , các giới hạn được đặt ở mức 1Mpps đến 2Mpps trên mỗi lõi (được báo cáo tăng tỷ lệ tuyến tính nhiều hơn hoặc ít hơn), hoặc thậm chí 15Mpps với các giải pháp đặc biệt bỏ qua kernel.

Ví dụ: sơ đồ mạng

có thể tạo lưu lượng ở tốc độ đường truyền ( 14,88Mpps ) trên liên kết 10GigE chỉ với một lõi duy nhất chạy ở tốc độ 900Mhz. Điều này tương đương với khoảng 60-65 chu kỳ xung nhịp cho mỗi gói và có tỷ lệ tốt với lõi và tần số xung nhịp (với 4 lõi, tốc độ đường truyền đạt được ở mức dưới 450 MHz). Tỷ lệ tương tự đạt được ở phía nhận .

Vậy tôi có thể đi bao xa (các phiên bản mới nhất) của Windows / Windows Server, đặc biệt là nhận đa tuyến UDP như được mô tả trong đoạn đầu?

Chỉnh sửa Có một bài đăng trên blog trên nền tảng đám mây - và một phần bình luận thú vị - về cách thực hiện trên Linux: Cách nhận một triệu gói mỗi giây và có trang bình luận tin tức về tin tặc tương ứng .

Theo Microsoft, các thử nghiệm trong phòng thí nghiệm của họ cho thấy rằng "trên một máy chủ cụ thể trong thử nghiệm sớm" của RIO , họ có thể xử lý

• 2Mpps không bị mất trong Windows Server 2008R2, tức là không có RIO
• 4Mpps trên (phát hành trước) Windows Server 8 bằng RIO

Ảnh chụp màn hình từ video đó (44:33):

Vì vậy, câu trả lời cho câu hỏi của tôi Is it possible to process millions of datagrams per second with Windows?sẽ là: Có , và rõ ràng là ngay cả trước RIO, trong Windows Server 2008R2.

Nhưng ngoài các số liệu chính thức, đặc biệt là trên phần mềm chưa được phát hành, phải dùng một nhúm muối, chỉ có thông tin thưa thớt được đưa ra trong bài trình bày này, vẫn còn nhiều câu hỏi về bài kiểm tra, và do đó làm thế nào để diễn giải đúng kết quả. Những cái có liên quan nhất là:

1. Là số liệu cho Gửi? Tiếp nhận? Hoặc có thể cho Định tuyến (tức là Nhận + Gửi)?
2. Kích thước gói nào? -> Có lẽ là thấp nhất có thể, như thường được thực hiện khi cố gắng lấy số liệu pps để khoe khoang
3. Có bao nhiêu kết nối (nếu TCP) / luồng gói (nếu UDP) ? -> Có thể cần nhiều phân phối khối lượng công việc để có thể sử dụng tất cả các lõi có mặt
4. Thiết lập thử nghiệm gì? Thông số kỹ thuật của máy và hệ thống dây điện

Điều đầu tiên rất quan trọng, bởi vì Gửi và Nhận yêu cầu các bước khác nhau và có thể cho thấy sự khác biệt đáng kể về hiệu suất. Đối với các số liệu khác, có lẽ chúng ta có thể giả sử rằng kích thước gói thấp nhất, với ít nhất một luồng kết nối / gói trên mỗi lõi đang được sử dụng trên một máy có thông số kỹ thuật cao để có được số liệu Mpps tối đa có thể.

Chỉnh sửa Tôi chỉ tình cờ tìm thấy một tài liệu của Intel về Xử lý gói hiệu suất cao trên Linux và theo đó, (Linux)

nền tảng có thể duy trì tốc độ giao dịch khoảng 2 triệu giao dịch mỗi giây

sử dụng ngăn xếp mạng Linux tiêu chuẩn (trên máy chủ vật lý có lõi 2x8). Một giao dịch trong kiểm tra yêu cầu / trả lời này bao gồm cả hai

1. nhận gói UDP
2. chuyển tiếp tiếp theo của gói đó

(sử dụng máy chủ của netperf). Các thử nghiệm đã chạy song song 100 giao dịch. Có nhiều chi tiết hơn trong bài báo, cho những người quan tâm. Tôi ước rằng chúng tôi có một cái gì đó như thế này để Windows so sánh ... Dù sao, đây là biểu đồ phù hợp nhất cho bài kiểm tra yêu cầu / trả lời đó:

tl; dr

Để đưa ra một câu trả lời chắc chắn, nhiều bài kiểm tra dường như cần thiết. Nhưng bằng chứng hoàn cảnh cho thấy Linux là HĐH được sử dụng thực tế trong cộng đồng độ trễ cực thấp, cũng thường xuyên xử lý khối lượng công việc Mpps. Điều đó không có nghĩa là không thể với Windows, nhưng Windows có thể sẽ bị tụt lại phía sau khá nhiều, mặc dù có thể đạt được số Mpps. Nhưng điều đó cần kiểm tra để được xác định, và ví dụ để tìm ra cái gì (CPU) chi phí cho những con số đó có thể đạt được.

NB Đây không phải là một câu trả lời tôi dự định chấp nhận. Nó được dự định để cung cấp cho bất cứ ai quan tâm đến một câu trả lời cho câu hỏi một số gợi ý về nơi chúng tôi đứng và nơi để điều tra thêm.

Len Holgate, người theo google dường như là người duy nhất đã thử nghiệm RIO để có được hiệu suất cao hơn từ mạng Windows (và công bố kết quả), chỉ cần làm rõ trong một nhận xét trên blog của mình rằng anh ta đang sử dụng một kết hợp IP / Cổng duy nhất để gửi các gói UDP.

Nói cách khác, kết quả của anh ta có thể tương đương với các số liệu lõi đơn trong các thử nghiệm trên Linux (mặc dù anh ta đang sử dụng 8 luồng - mà chưa kiểm tra mã của anh ta, có vẻ có hại cho hiệu suất khi xử lý chỉ một luồng gói UDP duy nhất và không thực hiện bất kỳ xử lý nặng nào của các gói và anh ta chỉ đề cập đến một vài luồng thực sự được sử dụng, điều này sẽ có ý nghĩa). Đó là mặc dù anh ta nói:

Tôi đã không cố gắng hết sức để có được hiệu suất tối đa chỉ để so sánh hiệu suất tương đối giữa các API cũ và API mới và vì vậy tôi đã không kiểm tra kỹ lưỡng.

Nhưng điều gì đang từ bỏ vùng thoải mái (tương đối) của IOCP tiêu chuẩn cho thế giới RIO thô ráp hơn ngoài "cố gắng hết sức"? Ít nhất là liên quan đến một luồng gói UDP.

Tôi đoán ý của anh ấy - như anh ấy đã thử các cách tiếp cận thiết kế khác nhau trong một số thử nghiệm của RIO - là anh ấy đã không tinh chỉnh các cài đặt NIC để giảm bớt hiệu suất cuối cùng. Trong đó, ví dụ, trong trường hợp Kích thước bộ đệm nhận có thể có tác động tích cực rất lớn đến UDP nhận hiệu suất và số liệu mất gói.

Tuy nhiên, vấn đề khi cố gắng so sánh trực tiếp kết quả của mình với các thử nghiệm Linux / Unix / BSD khác là: Hầu hết các thử nghiệm, khi cố gắng đẩy ranh giới "gói mỗi giây", sử dụng kích thước gói / khung nhỏ nhất có thể, tức là Ethernet khung 64 byte. Len đã kiểm tra các gói 1024 byte (-> khung 1070 byte), điều này (đặc biệt đối với UDP No-Nagle) có thể giúp bạn có được số liệu "bit trên giây" cao hơn nhiều, nhưng không thể đẩy ranh giới pps xa hơn với các gói nhỏ hơn . Vì vậy, sẽ không công bằng khi so sánh những con số này.

Tóm tắt kết quả của nhiệm vụ của tôi vào Windows UDP nhận được hiệu suất cho đến nay:

• Không ai thực sự sử dụng Windows khi cố gắng phát triển các ứng dụng có độ trễ cực thấp và / hoặc các ứng dụng có thông lượng cao, ngày nay họ đang sử dụng Linux
• Thực tế tất cả các bài kiểm tra và báo cáo hiệu suất với kết quả thực tế (tức là không chỉ quảng cáo sản phẩm) ngày nay đều có trên Linux hoặc BSD (cảm ơn Len vì đã là người tiên phong và cho chúng tôi ít nhất một điểm tham khảo!)
• Là UDP (ổ cắm tiêu chuẩn) trên Windows nhanh hơn / chậm hơn so với trên Linux? Tôi chưa thể nói, sẽ phải tự kiểm tra
• Là UDP hiệu suất cao (RIO so với netmap) trên Windows nhanh hơn / chậm hơn so với trên Linux? Linux dễ dàng xử lý tốc độ dòng 10Gb đầy đủ với một lõi đơn ở mức 900 MHz, Windows, trong trường hợp tốt nhất được công bố có thể tăng tới 43% hoặc 492kpps cho kích thước gói UDP lớn 1024, tức là số liệu bps cho kích thước nhỏ hơn có thể sẽ đáng kể tệ hơn, mặc dù số liệu pps có thể sẽ tăng (trừ khi xử lý ngắt hoặc một số chi phí không gian nhân khác là yếu tố giới hạn).

Về lý do tại sao họ sử dụng linux, đó phải là vì việc phát triển các giải pháp liên quan đến thay đổi kernel như netmap hoặc RIO - cần thiết khi đẩy hiệu suất đến giới hạn - gần như không thể với một hệ thống khép kín như Windows, trừ khi tiền lương của bạn xuất hiện từ Redmond, hoặc bạn có một số hợp đồng đặc biệt với Microsoft. Đó là lý do tại sao RIO là một sản phẩm MS.

Cuối cùng, chỉ đưa ra một vài ví dụ cực đoan về những gì tôi đã khám phá được và đang diễn ra trên đất Linux:

Cách đây 15 năm, một số người đã nhận được 680kpps sử dụng CPU Pentium III 800 mHz, bus phía trước 133 mHz trên NIC 1GbE. Chỉnh sửa : Họ đang sử dụng Click , một bộ định tuyến chế độ hạt nhân bỏ qua phần lớn ngăn xếp mạng tiêu chuẩn, tức là họ "bị lừa".

Vào năm 2013, Argon Design đã có được

đánh dấu vào độ trễ giao dịch thấp tới 35ns [nano giây]

Btw họ cũng tuyên bố rằng

Phần lớn mã máy tính hiện có để giao dịch ngày nay được viết cho Linux trên các kiến ​​trúc bộ xử lý x86.

và Argon sử dụng công tắc Arista 7124FX , rằng (ngoài một GPU ) có HĐH

được xây dựng dựa trên nhân Linux tiêu chuẩn.

Bạn chắc chắn sẽ cần "đo" các cấu hình và kịch bản khác nhau. Điều này có thể được thực hiện AFAIK với hai thiết bị được cung cấp bởi 2 công ty. IXIA và Spirent . Họ cung cấp các bộ tạo lưu lượng dựa trên phần cứng có thể bơm lưu lượng ở tốc độ đường truyền. Họ cung cấp thử nghiệm đường dốc nơi bạn có thể phát hiện tốc độ mà hệ thống cụ thể của bạn có thể sụp đổ. Các thiết bị đắt tiền nhưng bạn có thể thuê chúng.