CodingBox Q&A Ask question
Log in Sign up

Mesh MCX516A-CCAT trên DAC 100G: lshw báo 40Gbit/s còn một luồng iperf3 chỉ đạt tối đa 21 Gbit/s

Asked Active Viewed 49 AI translation from English
2

Bọn mình chạy một cluster ba node với các node đấu cáp trực tiếp với nhau qua DAC 100G, không có switch nào trên đường truyền, và các interface được đưa vào một broadcast bond để traffic replication có fabric riêng của nó. Trước khi đặt tải thật lên đó, mình muốn có một baseline, và các con số lại không khớp với nhau.

  • 3x Mellanox ConnectX-5 EN, MCX516A-CCAT, hai cổng QSFP28
  • Một DAC 100G giữa mỗi cặp node
  • Host AMD EPYC, Proxmox trên cả ba

ethtool thì hoàn toàn hài lòng:

# ethtool ens1
Settings for ens1:
        Supported link modes:   100000baseCR4/Full
        Advertised link modes:  100000baseCR4/Full
        Speed: 100000Mb/s
        Duplex: Full
        Link detected: yes

lshw thì không:

# lshw -class network
  *-network
       description: Ethernet interface
       vendor: Mellanox Technologies
       capacity: 40Gbit/s

Và iperf3 giữa hai trong số các node nằm ở khoảng 21 Gbit/s, chẳng gần với con số nào trong hai con số kia cả.

Đã làm:

  • chuyển cáp sang cổng thứ hai trên cả hai card, không đổi
  • đổi sang một DAC khác cùng loại, không đổi
  • link giữ up suốt thời gian, không có lỗi nào tăng trên counter

Vậy công cụ nào trong hai công cụ đang nói dối mình, và mình nên truy theo cáp, card, hay driver?

Show original (English) Also available in: English العربية Deutsch Español Français हिन्दी Bahasa Indonesia Italiano 日本語 한국어 Nederlands Polski Português Русский Türkçe Tiếng Việt 简体中文
connectx-5 DAC iperf pcie QSFP28
United Kingdom coaxpilot98 GB

Comments 5

Accepted answer

Không có gì bạn đăng lên chỉ về phía DAC cả. Có hai chuyện không liên quan đến nhau đang xảy ra ở đây.

Thứ nhất, chuyện không khớp nhau. lshw -class network in ra một con số capability mà nó tự tính lấy, và trên các card này nó sẽ vô tư nói capacity: 40Gbit/s về một link đã lên ở 100G. Tốc độ đã negotiate mới là thứ ethtool báo cáo, và của bạn nói Speed: 100000Mb/s với 100000baseCR4/Full được advertise. Phần đó ổn rồi, chẳng có gì phải sửa.

Thứ hai, chuyện throughput. Kiểm tra khe cắm trước khi đụng vào bất cứ thứ gì khác:

# lspci -vv
        LnkCap: ... Speed 8GT/s ...
        LnkSta: ... Speed 2.5GT/s ... (downgraded)

Nếu LnkSta train ở 2.5GT/s trong khi LnkCap nói 8GT/s, bạn đang bị giới hạn thấp hơn hẳn so với khả năng thực, và đổi cáp bao nhiêu lần cũng chẳng giúp được gì. Cắm lại card và đảm bảo nó nằm trong một khe thực sự được đi dây đủ full width.

Rồi ngừng đo bằng một luồng duy nhất:

# iperf3 -P 8 -c <peer>

Khoảng 21 Gbit/s là mức mà một core sẽ cho bạn trên loại host này, nên riêng con số đó chẳng nói lên được bao nhiêu. Theo dõi CPU trong lúc chạy và xem cả idle state đang làm gì nữa: các core rơi vào C-state sâu giữa các đợt burst sẽ tốn thật sự băng thông ở tốc độ này.

3 Taiwanlinkeng56TW Show original (English) AI translation

Trước khi bạn đặt mua bất cứ thứ gì để thay thế, đăng dòng LnkSta từ lspci -vv cho card đó và dòng lệnh iperf3 chính xác bạn đã dùng. Một luồng ở 100G đo một CPU core duy nhất, không phải đo link, và nhiều người đã tốn cả ngày trời vì chuyện này. Và xác nhận luôn là cổng thứ hai thực sự đang mang leg còn lại của mesh trong lúc bạn test, chứ không phải đang nằm không: một khe nuôi hai cổng 100G đang sống là một ngân sách khác hẳn so với một cổng. Mình sẽ gác lshw sang một bên lúc này, nó không phải công cụ cho câu hỏi này.

3 United Arab Emirateslambdahawk88AE Show original (English) AI translation

Một chỉnh sửa về phần C-state: nếu host là EPYC, mấy công tắc intel_idle được dán vào mọi thread kiểu này chẳng có tác dụng gì với bạn đâu, driver đó hoàn toàn không nằm trên đường đi ở AMD. Cái đòn bẩy có tác dụng với mình là processor.max_cstate=2 trên kernel command line. Cùng ý tưởng, khác platform. Phần còn lại của bài đó vẫn đúng, đặc biệt là chuyện không đọc tốc độ đã negotiate từ lshw.

2 SpainoptictechES Show original (English) AI translation

Một lỗi hơi khác, cùng họ phần cứng, đáng để loại trừ khi khe cắm đã ổn: một mesh trực tiếp giữa các cổng QSFP28 ConnectX-5 rất dễ bị sai ở layer 3. Mình từng có ba node trên MCX516A-CCA_Ax, firmware 16.35.4030 với driver DOCA 2.8.0, đấu bằng DAC đồng MCP1600-C003E30L 3 m. Mọi link đều báo active ở 100 Gbps và không một ping nào đi qua được. Cả sáu interface trong mesh đều có địa chỉ từ cùng một subnet 10.5.5.x mà không có switch nào trên đường truyền, nên kernel không có cách nào quyết định đích đến cho trước thuộc về cổng vật lý nào. Mỗi cặp node một subnet riêng, 10.5.5.x, 10.5.6.x và 10.5.7.x, và nó bắt đầu hoạt động. Đáng để chạy ip a và ip route trên cả ba box trước khi ai đó đổ lỗi cho dây đồng.

1 Ukrainerxnode71UA Show original (English) AI translation

Cả hai điểm đều đúng. lspci -vv cho thấy card train ở 2.5GT/s so với LnkCap là 8GT/s, nên đó là nghi phạm số một. Mình chuyển card sang khe khác trên cả ba box, LnkSta giờ lên ở 8GT/s, và với iperf3 -P 8 cùng cặp node đó vượt qua ngay con số đo bằng một luồng.

Mình cũng từ bỏ broadcast bond và xây lại mesh trên Open vSwitch với RSTP. Với iperf trải trên ba luồng CPU và cả hai cổng, giờ mình đo được khoảng 95 Gbit/s, đủ gần với line rate cho những gì cluster này làm. lshw vẫn khăng khăng 40Gbit/s và mình đã ngừng để ý tới nó.

1 United Kingdomcoaxpilot98GB Show original (English) AI translation
Log in to comment. Log in