Windows 1MB/s, Linux 30MB/s? - JEGELVE

Hálózatok általános

Sziasztok!

Ma belefutottam egy elég érdekes problémába (igazából ma derítettem ki, hogy ez a helyzet, a windows már régóta lassú).
Szóval: van egy windowsos szerverem (1. gép), gigabiten. Ezen fut virtuális gépen egy debian, bridged módú hálózattal. Az adott gépről a szerverteremben lévő másik gépre (legyen a 2. gép) a kapcsolat nagyjából 1-4MB/s között mozog, ha a windowst érem el. Máshova, pl. más szerverterembe a már gyorsabb, képes 20-30MB/s-el menni. Viszont a 1. gépen futó virtuális linuxról a 2. gépre képes a 30 MB/s-re. A 2. gépről az 1. gép windowsára szintén gyors a kapcsolat.
Tud valaki valami tippet adni, hogy merre induljak el, mert erre én még rákeresni sem tudok.
Elvileg a hoszt ugyan úgy a windows nic-driverét használja, így szerintem nem a hálókártya a ludas, viszont nemtudom mi lehet.

Szerk (újra nekifutva):
Az 1. gépen (ami "lassú") Windows Server 2003 R2 32bit van, VMWare Server 2 a virtualizáló szoftver, Debian Lenny guest-tel.
A 2. gépen szintén Windows Server 2003 R2 32bit van.
A két gép egy szerverteremben van, valamint ugyan azokkal az alapbeállításokkal rendelkeznek.

A 3. gép Windows Server 2008 R2 64 bit. Ez máshol van szintén gigabiten.

Ábra

HTTP-n és FTP-n is hasonló értékeket kapok.

A hálózatot nem én üzemeltetem, így erre nincs rálátásom.

  • 3170 megtekintés

( ppenta | 2010. 08. 07., szo – 10:30 )

Kicsit érthetetlen. És az információ tartalma, annyi, hogy valamilyen gépek, valamilyen hálón néha "gyorsak" néha nem. Kicsit konkrétabban kellene...

1. gép win/virtual linux verziók?
2. gép win vagy linux? verziók?
3. szerveterem win vagy linux? verziók?

Mi az, hogy elérem? Fájl megosztás? Samba verzió? Samba confot akkor nyomhatnál...

Egyébként önmagában sem a win, sem a linux nem "lassú" sőt. Az más kérdés, hogy fájlmegosztás szintjén akadhatnak gondok a két oprendszer között főleg Vistától felfelé (vista, 2008, w7). De ezek is orvosolhatók jó konfigurálással.

A hálózat az megint más tészta. Külön kezelendő.

Hozzáteszem, hogy "gigás" hálón 90Megabájt/s a normális már elfogadható stabil érték. Ennyit viszont egyenlőre nem fogsz tudni átvinni win és linux között. 30-40M/s az reális.

Az 1. gépen (ami "lassú") Windows Server 2003 R2 32bit van, VMWare Server 2 a virtualizáló szoftver, Debian Lenny guest-tel.
A 2. gépen szintén Windows Server 2003 R2 32bit van.
A két gép egy szerverteremben van, valamint ugyan azokkal az alapbeállításokkal rendelkeznek.

A 3. gép Windows Server 2008 R2 64 bit. Ez máshol van szintén gigabiten.

HTTP-n és FTP-n is hasonló értékeket kapok.

Ábra

A hálózatot nem én üzemeltetem, így erre nincs rálátásom.

( pepo v | 2010. 08. 08., v – 09:31 )

Ilyesmibe régen futottam bele: a windowsos gépen tedd a hálókártyát automatikus-ból 100/100 fullduplexre. (Az eszközkezelőn belül lehet a videokártya tulajdonságainál elkövetni.)

( XMI | 2010. 08. 08., v – 14:14 )

Arra is vigyázz, hogy bridged módban a vmware server/workstation meglepően lassú tud lenni. Valójában nem szoftveres switch van benne (mint az ESX Servernél), hanem csak szoftveres hub, így a fizikai hálózaton bejövő csomagokat címzettől függetlenül az összes virtuális gép is megkapja és a kiküldött csomagok is mindenhova mennek. Ráadásul szerintem sután van megcsinálva, mert nem puffereli a csomagokat (áttúrtam a forráskódját, onnan tudom).

Nem ritka, hogy NAT módba átrakva 2-3x ugrik az áteresztőképesség és valamelyest jobb lesz a latency is. Ha teheted szerintem próbáld ki, hátha ez is közrejátszik nálad.
---
Internet Memetikai Tanszék

Natot inkább hanyagolnám, szeretném külön IP-n hagyni a gépet. (és valami miatt nem ment nat mögött a levelezés kívülről, publikus IP-re rakva minden konfig nélkül ment) Valamint elég a 30MB/s egy webszervernek:) Viszont így továbbra sem értem, a linux miért sokkal gyorsabb ugyan azon a kábelen. (natolva nem néztem a sebességét)

A full duplex beállítást még megnézem (bár valószínűleg csak holnap)

( athila v | 2010. 08. 27., p – 16:45 )

UDP-vel próbáltad már?
iperf-et javaslom, azzal lehet UDP-vel is mérni.
Illetve TCP-nél add meg mérésnél a window size-t, mondjuk 128k-t.

Mértem iperf-et, párféle módban, ott sem rózsás a helyzet. TCP 1 szálon bármekkora Windows size-al 10mbit körül jött ki mindig, 10-20 szálon szumma 50-60mbit. UDP gyalázat, 1 szálon, 10 szálon szumma 1mbit körüli értékek. Alacsony- és magas porttartományban is. Ezt egyszer már eljátszottam az operátor előtt is, azzal a különbséggel, hogy akkor TCP-n nem is indult el a teszt, elfailelt. Úgyhogy az lett az eredmény, hogy sorry, nemtudom mitől lehet.

Szerk: lefuttattam a linuxon is az iperfet, és kissé meglepődtem: TCP-n 240MBit körüli értékek voltak, ez nekem teljesen rendben van, viszont UDP-n 1 MBit ment át.

( athila v | 2010. 08. 29., v – 17:39 )

iperf-es UDP-s tesztnél meg kell adni a bandwidth értéket (a kliensnél, -b 100000000 pl a 100 mbithez), alapesetben csak 1 mbit-et tol bele a csőbe. kíváncsi vagyok, mit fog produkálni a win.

Köszi, így is lemértem.
UPD-n így 93-100MBit között jött ki, 1,7-2,3% közötti packet lossal.
TCP-n -b kapcsoló használatával szinén hasonló értékek jöttek ki, elképzelhető, hogy a windowsos verzióban TCP-n is használja a '-b'-t?

Linuxon úgy tűnik szintén van értelme a -b kapcsolónak: UDP-n 650-, TCP-n 500 MBit körül ment (itt -b nélkül 300-350 között volt)

Kezdem nemérteni az ftp, http, samba lassúságának okát.

( athila v | 2010. 08. 31., k – 18:07 )

A windowsos TCP stack implementálása egy rakás kaki, ezért mérsz ilyeneket.
Ha egy LAN-on vannak a wines gépek, akkor jó lesz a sebességük egymás között, de amint egy
route-olt hálózaton átmennek az IP csomagok, onnantól kezdve összeszarja magát. Minél messzebb van a két gép és minél több hop van közöttük, annál rosszabb lesz.
Elviekben lehet a registry-ben a TCP-t finomhangolni, de nekem nem sikerült elérni vele semmit.

Az iperfnek meg linux alatt is meg kell adni a bandwidthet UDP tesztnél, hiszen onnan fogja tudni,
mennyi csomagot generáljon, amit beletol a csőbe. TCP-nél nem kell a -b sztem, ott maga a TCP szabályozza, mennyi menjen és mennyi jöhet.