Podobný test jsem shodou okolností dělal na začátku letošního roku.
Měl jsem 10 ks. Intel X520, připravoval jsem je na instalaci, tzn. testoval jsem různé platformy, kompatibilitu s transceivery a u všech aktualizoval firmware (primárně byla potřeba kvůli podpisům EFI, které některé stroje už standardně vyžadují).
Byly to kousky koupené po Covidu, kdy nebyly rozumně dodatelné jiné karty.
Testoval jsem to tak, že jsem měl dvě HP stanice, jednu relativně aktuální Z4 s Xeonem W7, druhou starou "laboratorní" Z420 s Haswell Xeonem (takže žádný extra rychlík), kam jsem dával karty.
Na obou strojích jsem rozběhl živou Clonezillu (s Debian jádrem) a testoval taky s iperf3. V tomhle prostředí to i s jedním TCP spojením v podstatě bez jakékoliv další konfigurace dávalo 8-10 Gbit, když jsem přehodil na 9k jumbo framy, tak jsem to stabilně dokázal saturovat.
Dává docela smysl si ozkoušet i posílání zpátky (client->server) s přepínačem -R, případně tomu trochu naložit s --bidir.
S Windows 11 (na tom výkonnějším stroji) na jedné straně to už bylo horší. Směr Win->Linux byl v pohodě, ale obráceně jsem končil řádově na 3-4 Gbit, resp. 6 Gbit s jumbo framy.
Po různém ladění a zkoušení výměny jedné síťovky za Mellanox X6, jsem seznal, že je to spíš vlastnost toho jak Windows 11 při zpracování rozhazuje interrupt handlery a následné DPC na jádra CPU a efektivitou toho stacku. Jsou tam nějaká dílčí nastavení toho mechanismu RSS (receive side scaling) - např. na která jádra to scheduluje souvislosti s NUMA nody, ale s Windows 11 na té konfiguraci s W7 Xeonem to nedávalo moc smysl měnit.. vycházelo to víceméně stejně. Samozřejmě nevylučuji, že na nějakém sytému s víc NUMA nody, několika síťovkami, případně větším množství spojení to ladění profilů (Enable-NetAdapterRss a Set-NetAdapterRss v PowerShellu) může dávat smysl, třeba i kvůli celkové zátěži.
Taky samozřejmě nevylučuji, že třeba na Ryzenu s více CCXy, to nějakou roli hrát může a třeba ruční zapinování na konkrétní jádra se může projevit.
Jediné, co to pak opravdu zabralo, a přiblížilo to 10 Gbit bylo navázat iperfem víc spojení přes -P (parallel), pak si to rozházel na příchozí Windows straně na víc jader a opravdu se zvýšila propustnost.
Protože jsem také trochu podezíral Widnows build iperf3, který je pořád tak trochu neofiko s cygwinem, tak jsem zkoušel přesně to, co je zmíněno v předchozím příspěvku. Na Linux straně jsem udělal Samba share nad tmpfs, stroj měl dost RAM, a připojil se tam z Windows klienta (SMB 3.0). Chodilo to výrazně líp než samotný iperf s jedním spojením. Pokud ta aplikace, co četla nebo zapisovala, dokázala naplnit frontu I/O operací (vyšší QD) - tzn. třeba Crystal Disk Mark nebo fio, tak jsem byl s 9k framy víceméně na 8-10 Gbit. Což jsem seznal jako uspokojující pro to, co jsem potřeboval.
Jinak jsem podobně ještě testoval i 25GbE Mellanoxy a novější Intel E810. Tam je to víceméně stejný příběh i v 25GbE režimu, Linux je out-of-box výrazně lepší.
Obě karty také může mít v 10GbE režimu znatelně menší vytížení CPU, zvlášť v UDP spojeních. Což by i dávalo smysl, offloaduje se toho ve výchozím stavu víc než u starší X520.
U X520 bylo ještě jedno nastavení, které něco házelo na Windows (u mě) - Interrupt Modulation, kdy při nastavení high místo adaptive tam byly měřitelně menší fluktuace propustnosti a žralo to trochu míň CPU (což bylo počítám na vrub latenci, ale to mě u tohohle až tak nepálilo).
Takže, pardon za delší příspěvěk. Ale podle toho, co jsem si zkoušel, tak je mi divné že i v prostředí Linux <-> Linux a s 9k framy tu 10Gbit linku nesaturujete. Možná je tam opravdu nějaký bottleneck na PCIe sběrnici, jak píše p. Ryšánek.
Možná má TrueNAS, jako appliance, nějaké výchozí nastavení, co tomu brání.. nicméně, jestli jste zkoušel Ubuntu <-> Ubuntu, tak byste tohle měl vyloučit. Tohle bych se osobně snažil vyřešit jako první.
Špatná SFPčka se mi moc nezdají, reálně jsem moc nezažil, že pokud to chytí link a běží to na obou stranách ve správném režimu, aby to omezovalo rychlost. Ano, viděl jsem samozřejmě nekompatibilní moduly (třeba ty x520 jsou vtipné, s nějakým OEM modulem jsem měl normálně pád driveru a backtrace v kernelu, resp. "zmizení" rozhraní ve Windows), ale jakmile to bylo "Intel kompatibilní", tak to běželo bez problémů. A jasně, taky jsem zažil situaci, že SR duplex optiku někdo omylem přejel židlí
Ale pak to úplně vypadávalo a bylo tam strašné množství ztracených paketů. Což se samozřejmě dá ověřit třeba přes ethtool -S <interface>.
15 Odpovědí
2483 Zhlédnutí