10 Gbit Broadcom BCM57840 lassú

Hálózati eszközök

Érdekes jelenséggel találkoztam. Adott két szerver mind kettőben egy-egy Broadcom BCM57840 10 Gbites ethernet kártya. Direktben összekötve a kettőt kb 500 Mbit (hol több, hol kevesebb egy kicsit, de kb az 1 Gbit fele) átvitelt tudok kihozni (ipperf) ha leveszem a sebességet 1 Gbitre akkor is kb ennyi. Az érdekes az, hogy egy másik (Intel) egy gigabites kártyával összekötve hozza a kb 1Gbit/s értéket.
A kábel Cat6-os 2 méter.
Az ethtool szerint a kártyák szépen megegyeztek a 10Gbites full duplex (félduplexet nem is támaogatja) sebességben.
Kernel: 4.4.0-108
Tapasztalt valaki hasonlót vagy van ötletetek?

  • 2010 megtekintés

( bandy | 2018. 01. 22., h – 17:23 )

Milyen CPU és mennyi RAM csücsül a szerverekben?

( blackluck v | 2018. 01. 22., h – 18:21 )

Induljunk a kalyhatol.

Gondolom ahol 1Gbit/s meg 500Mbit-et irtal az byte akart lenni a 10Gbit-es kartya eseten.

Milyen iperf parameterekkel mersz, tcp/udp, 1 vagy tobb szalon, mekkora window size-al?

Nincsenek interface-en nagy/novekvo mertekben eldobott csomagok, hibak (ifconfig dropped, netstat -s)?

Halokartya driver/firmware mennyire friss, valoban azt hasznalja (ethtool -i eth0)?

Halokartya parameterekbol default-ban mik vannak bekapcsolva (ethtool -k eth0), mekkora ring buffer size-t tud a kartya es mi van beallitva (ethtool -g eth0)?

Meres kozben nem-e terhel ki 1 magot interruptokkal, el vannak-e osztva interruptok tobb magra (cat /proc/interrupts , egyaltalan alapbol tobb queue-t kapcsol-e be a broadcom kartya vagy kulon kell megadni a modulnak)?

Mondjuk 2 meteren elegnek kell lenni cat6-nak is, de esetleg probaltad masik kabellel?

(Ertelem szeruen eth0 helyett megfelelo interface-t behelyettesiteni.)

Azt írja:

> Az érdekes az, hogy egy másik (Intel) egy gigabites kártyával összekötve hozza a kb 1Gbit/s értéket.

Ebből számomra az derül ki, hogy ahol 1Gbit/s-et és 500Mbit/s-t ír, ott valóban arra gondolt, nem elírásról van szó.

Értelmezésem szerint a két kártya egymással összekötve 1000Base-T és 10GBase-T módban egyaránt ~500Mbit/s hasznos adatátvitelre képes, és pont az adja a dolog érdekességét, hogyha az egyik végére berak egy "sima" gigás (1000Base-T) kártyát, akkor lőn, megvan a gigabit.

Innentől az iperf paraméterek nagyjából lényegtelenek.

Ez szerintem:
- vagy hardware issue lesz (alaplap/PCIe slot nem szereti az adott kártyát, stb.)
- vagy valami beállítási probléma (MSI/IRQ/...)
- vagy retek a driver

Hogy a túloldalt GbE kártyára cserélve mitől lesz "jó" a BCM is hirtelen, az passz. Csodaszép dolog a hardver világa.

Amire én elsőre kiváncsi lennék:

1.) Alaplap és/vagy szerver típusa
2.) lspci -vv
3.) /proc/interrupts

Biztos nem a csak fizikai csatlakozóban x8-as foglalatok egyikébe tetted?

"3 PCI-E 3.0 x8, 1 PCI-E 3.0 x4 (in x8),1 PCI-E 3.0 x16, 1 PCI-E 2.0 x4 (in x8)"
--

"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."

Köszönöm az ötleteket, nagy részén már túl vagyok, viszont másnak is azok az ötletei, mint nekem és ez biztató.

Az infók:

>Gondolom ahol 1Gbit/s meg 500Mbit-et irtal az byte akart lenni a 10Gbit-es kartya eseten.
Sajnos nem íram el 500Mbit a mért érték, azaz kb a gigabit fele.

>Milyen iperf parameterekkel mersz, tcp/udp, 1 vagy tobb szalon, mekkora window size-al?
Az iperf paraméterekkel sokat kísérleteztem, tcp window méret több szál két irány, udp ...
Gyakorlatilag semi különbség nincs - a hardware-re vagy alacsony szintű driverre gyanakszom, mert több szál esetén szépen eloszlik ez a sávszélesség a szálak között, de a végösszeg nem változik.
Egyetlen éerdekes és megmagyarázhatatlan jelenség van az, hogy a sebesség gyakran aszimetriks, azaz a iperf -d-vel mindkét irányba mérek a két irány között 30-50% sebesség különbség lehet.

>Nincsenek interface-en nagy/novekvo mertekben eldobott csomagok, hibak (ifconfig dropped, netstat -s)?
Az interface-en a drop, error, overrun, collision mind nulla.

>Halokartya driver/firmware mennyire friss, valoban azt hasznalja (ethtool -i eth0)?
A firmware nem tudom mennyire új ezt mondja:
ethtool -i eth10f
driver: bnx2x
version: 1.712.30-0
firmware-version: bc 7.13.0 phy 1.22
expansion-rom-version:
bus-info: 0000:01:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes

>Halokartya parameterekbol default-ban mik vannak bekapcsolva (ethtool -k eth0), mekkora ring buffer size-t tud a kartya es mi van beallitva (ethtool -g eth0)?
A rx ring buffer kevesebb volt a maximumnál, de maxra állítva sem változik semmi.
Beállításból van annyi, mint égen a csillag a jelenlegi itt: https://pastebin.com/fuMbQ1Zv

>Meres kozben nem-e terhel ki 1 magot interruptokkal, el vannak-e osztva interruptok tobb magra (cat /proc/interrupts , egyaltalan alapbol tobb queue-t kapcsol-e be a broadcom kartya vagy kulon kell megadni a modulnak)?
A mérés közben a processzor terhelés gyakorlatilag nulla. Az egyes interruptok szét vannak osztva a magok között a /proc/interrups szerint kb egyenletesen.

>Mondjuk 2 meteren elegnek kell lenni cat6-nak is, de esetleg probaltad masik kabellel?
Próbáltam több kábellel is kínomban cat5-tel is, hátha attól rosszabb lesz, de semmi változás.
Nem hiszem, hogy kábel gond lenne, mert akkor lenne hiba az interface-en.

Leginkább valam driver gondot sejtek a háttérben, vagy egyszerűen rossz ez a két új kártya.

Performance tuning for Linux részt nézd végig szerintem:
http://h50146.www5.hpe.com/products/software/oe/Linux/mainstream/suppor…

--

"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."

"Az iperf paraméterekkel sokat kísérleteztem, tcp window méret több szál két irány, udp ..."

Ha csak 1 iranyban mersz akkor is 500Mbps tempo jo ki, fugg attol melyik iranyba mersz?
Mert akkor konnyen lehet valami pcie savszel keves megis, dmesg-ben vagy lspci -vv -vel keress ra milyen sebesseggel allt ossze a pcie kartya.

( arpi_esp v | 2018. 01. 22., h – 19:57 )

jumbo framek nelkul necces lesz 10g sebesseget kihasznalni. a bit/s egy dolog, de a pps (packet/sec) egy masik, es altalaban ilyen sebessegeknel mar az utobbi a szuk keresztmetszet (mit bir a cpu/os/ram illetve az irq)
az se mindegy az offloading parameterek hogy vannak belove, mit csinal a kartya es mit a cpu.

> jumbo framek nelkul necces lesz 10g sebesseget kihasznalni

Más történet egy switch/router, ahol csillió interfészen zúdulnak tonnaszámra a packetek, ott erősen érdekes lehet a pps.

Két gép esetében, ami egymással közvetlenül össze van kötve, nagyjából tökmindegy. Én teszteléshez megfogtam két ősöreg (7+ éves) ProLiant DL380 G7-et, beletettem két, manapság használtan 10e Ft alatt beszerezhető Mellanox 10GbE kártyát, összekötöttem egy DAC kábellel és minden különösebb tuning és erőlködés nélkül, sima 1500-as MTU-val azonnal stabil 9,6-9,8 Gbit/sec-et mértem iperf-fel. Csak TCP4SUM volt offloadolva, de azt is kikapcsoltam, semmi izgalom, röhögve megcsinálja. Felraktuk 9000-re az MTU-t, azon túl, hogy valós workload mellett kb. felére esett a csomagok száma (az átlagos csomagméret 3000 byte körül van) semmi szóra érdemes változás nem történt.

( iattilagy | 2018. 01. 22., h – 21:50 )

Első körben ilyenkor dmesg, az elég sok hasznos infót szokott tartalmazni. Pl., hogy milyen módban működik a kártya.

( freeoli v | 2018. 01. 23., k – 06:39 )

Az VMQ nekem mar okozott hasonlot, de mas kornyezetben. Valami nem stimmel vele a broadcom kartyakon.