Gigabit Ethernet LAN running slow

Optimera tcp stacken och aktivera jumbo frames samt ha bra nätverkskort är mer eller mindre ett krav. Sen spelar det roll vilka protokoll man använder.

Själv får jag 30MB/s med windows utdelningar från min linux till xp burk och 60MB/s med FTP, har då igång jumbo frames och tweakat tcp.

Har inbyggt intel kort i linuxburken och ett pci kort i min desktop samt en 3com gbit switch som klarar jumbo frames.

PanzarPaw, du är välkommen att redovisa resultat ifrån Iperf när du kör Iperf mellan de enheter du uppger i e-postmeddelandet.

Lust att dela med dig inställningar för iperf, får ingen vidare speed med det original.

Kollade lite med wireshark och såg att jumbo frames inte alls används, de är 1460 bytes stora när jag kör FTP. Antar dock att det beror på att en dator i nätet inte har jumbo frames, annars är det aktiverat och satt på 9014 på båda burkarna.

Jumbo Frames är bra för att det blir så satans många paket annars. 100MB delat på 1500 byte-paket blir nästan 70,000 paket/sek som ska över nätverket. Med 9000B-paket så blir det ju "bara" en sjättedel så många.

Ang. TCP-stacken så skulle jag tro att en av de viktigare optimeringarna är att öka window size, så att man slipper skicka tusentals relativt onödiga ACK-paket per sekund. Frågan är dock om inte alla moderna OS klarar detta automatiskt? OS X Leopard och Linux är väl åtminstone bra på att sköta windowing automatiskt.

Vi kan iofs gå ett steg längre och plocka bort Windows samt 64-bitars OS ur ekvationen och köra en Ubuntu Live CD(dvs den rör ej installationen som finns på dina hårddiskar, körs ifrån skiva samt minne) i 32-bitars läge.

Kör iperf -c IP-adress till iperfserver hos klienten.
Kör iperf -s hos servern.

Kör sedan gärna hos servern och klienten med växeln u några gånger.
Lägg efter ett par gånger även till --window 1500 hos både servern och klienten. Om dina kort samt switch har stöd för jumboramar så kan du öka --window till 4k några gånger, 9k några gånger och 16k. Du märker rätt så fort vilken största ramstorlek som nätverksenheter hos dig klarar med.

Posta sedan värden ifrån samtliga tester. Då har man lättare att se ett snitt och var det skiter sig.

Har lekt lite med iperf nu iaf, kommer dock inte över 600Mbit vad jag än gör, tycker man borde få lite mer då det sitter intel kort på båda sidorna och de samt switchen klarar jumbo frames.

Är detta även med växeln u eller det är 600 Mbit när du kör u och en del lägre utan u?

u växeln slår nämligen över till UDP läge och då ska det gå fortare än i TCP läge(iallafall rent teoretiskt eftersom upptäckta fel och tacksåmycket(ACK) skickas ej till motparten).

Om du tvingar på större ramstorlekar, kontrollera även att enheterna(om du kör Intel så står det under Jumbo Frames) är aktiverade i exakt samma läge, dvs om switchen orkar lira med t.ex 16128 bytes så skall bägge kort ställas i detta läge och iperf --window höjas upp till 16k bytes.

T.ex om två kort är ställda i 4k läge och switchen klarar ej av någon form av jumboramar så upptäcker du rätt så kvickt att något konstigt är på gång(så prova inte detta på distans via någon fjärrprogramvara mot en burk som inte är hemma hos dig, annars kommer du ej åt burken via vanlig fjärrstyrning som använder sig utav datorns nätverkskort för att bli fjärrstyrd).

Ett förtydligande: bara för att man ber iperf köra större paketstorlek så innebär det ej att nätverkskortet kommer skicka detta stora paket utan vidare. Kortets ramstorlek måste vara ställt i minst den storlek som paketet har, annars kommer kortet ändå att hacka upp ett 4k paket i flera 1500 bytes paket och då faller hela idén med att skicka ett stort paket istället för många små(= mer jobb == tar längre tid == lägre testresultat).

Switchen är en 3com och ska klara 8-9k stora jumboframes iaf, nätverskortet på xp burken går det att ställa in upp till 16k. Just när är det 4088 på båda sidorna.

Provade med udp men gick inge vidare.

Lekte med iställningar med tcp också men paketen blir varken mindre eller större än 1460 bytes, kollade med wireshark. Har dock en dator i nätet som inte klarar jumbo frames, kan det vara därför?

Jag kan tyvärr inte hjälpa dig konkret, men kan bara ge utav min egen erfarenhet.

Ett par Intel PRO/1000 MT PCI-X kort hemma och två 3Com 3C996B PCI-X.

Däremot så är switcharna 3Com OfficeConnect modeller utan stöd för jumboramar. Windows fildelning(SMB) slutade med en gång när ett kort ändrades till 9k och inget bättre resultat när det andra kortet ändrades till 9k. FTP via FileZilla gick halvknasigt(körde inte Ethereal/Wireshark vid testtillfället). Ställde om Jumbo Frames till disabled och då fungerade allt som det gjort tidigare.

Däremot så tycker jag inte att bara för att en enhet i nätverket saknar påslaget stöd för jumboramar så skall det påverka trafiken mellan två andra enheter som har fungerande stöd för jumboramar(kanske om man kör med hubb, men knappt det ens).

Lite underligt att UDP gick inget vidare.

ASBR: samtliga enheter måste iallafall vara medvetna om att hantera jumboramar(iallafall om där finns risk för samtrafik, t.ex massutskick, plus vilken storlek), och jag själv saknar konfigurerbara switchar samt har sett icke konfigurerbara switchar där stödet finns per automatik så fort switchen slåss på. Däremot så verkar det vara så att man måste uttryckligen slå på det i sina aktiva nätverksenheter(räknar en dum switch som passiv ), som t.ex NAS:ar, vanliga nätverkskort i vanliga datorer m.m.

Får t.ex en enhet ett paket på 4k när den förväntar sig max 1500 byte(och den känner inte till något alls om vad jumboramar är) så blir nog den stackaren förvirrad och ledsen samt undrar vad som är på gång, och i värsta fall så går enheten och ställer sig i ett hörn och startar om sig(om programmeraren ej lagt in övertrasseringskontroll och bufferten spiller över till ett område som det ej var tänkt och processorn stannar upp och vakthunden startar om prylen, programmerarnas sista-utväg-instruktion).

Normalt så har man 1492(tror det är ADSL som har det) eller 1500 på WAN sidan om vi pratar NAT. Riktiga routrar vet ej vad LAN eller WAN är. Dessa jobbar med med andra beteckningar som t.ex IF0, IF1 osv.

Vad som sker med ethernetpaket på inkommande sidan både hos routrar och bredbandsdelare är att dessa routar ej ethernetpaket, så om t.ex ett 9k ethernetpaket kommer in på LAN så går aldrig detta paket ut vidare på WAN sidan eller till ett annat IF. Routern eller bredbandsdelaren tar livet av ethernetpaketet och plockar enbart utav IP-paketet därifrån. Därefter är det frågan om det är en NAT lösning eller en riktig router. En riktig router drar enbart ev en TTL ifrån paketet och normalt sätt(om gränssnittet är ethernetbaserat) skapar ett nytt ethernetpaket med samma IP-last dock med ett TTL lägre än tidigare.

En NAT lösning som alla privatpersoner med privatabonnemang och mindre firmor har, den går dessutom in i paketet och kollar lite mer samt "ljuger" till en annan avsändaradress och är det en Packet Filter baserad NAT lösning så "ljuger" den direkt till en helt annan avsändarport(IP-tables "ljuger" till först till en annan port när två avsändare eller fler på LAN sidan använder samma avsändarport, då får avsändare nr två i turordning en slumpad port).

Däremot om du ansluter ditt jumbokonfigurerade nätverkskort direkt till t.ex stadsnätets switch i fastighetens källare så är det mer eller mindre denna switch som ansvarar för vad den skall göra med okända paket. Alla seriösa enheter hanterar felaktigheter på korrekt sätt, men som vi många vet så är det en del av oss som fått starta om våra enheter för att dessa hängt sig(och då tänker jag ej på överhettning) och det är helt enkelt pga allt för taskig programmering.

Förhoppningsvis så sitter ej dessa enheter i något stadsnät :D.

Det är helsikes svårt att komma upp i riktiga gigabit-hastigheter, och det beror på ytterst många faktorer.

- Filsystemet
- Mjukvaran klient/server (Windows fildelning suger, så är det bara)
- TCP window size
- Ethernet (MTU) frame-storlek
- Kvalite på NIC/drivrutiner
- Kvalite/skick på kablar
- Kvalite på Switch

Jag har lyckats mäta (med Iperf) upp en 400Mbps (~50MB/s) utan Jumbo-frames mellan två Windows 2003 maskiner med Intel-kort och HP-swtich. Windows fildelningen hamna på runt 20-25MB/s (>200Mbps) på sin höjd.