Gigabit LAN sebessége

Hálózatok általános

Építgettem otthon egy kis hálózatot tesztcélokra.
Mindkét gép Opteronos, de még az 1xx-es korszakból (SUN Java Workstation w1100z (A) és SUN Ultra 20 (B))
A-ban egy PCI-X 133 slotban egy Intel dual portos gigabit PCI-X 133-as kártya van, B-ben pedig két PCI-e 1x Intel gigabites adapter.
A két-két interfészt közvetlenül összekötöttem bondoltam/trönköltem/etherchannel-eztem (802.3ad) (kinek melyik), bekapcsoltam a jumbo-frame támogatást és tesztképpen scp-vel másolgattam át nagy fájlokat (A->B).
A CPU terhelés nem volt jelentős, 10% körüli volt, az A-beli RAID-1 kötet olvasásra 90, írásra 60 MB/s körüli értékeket tud, ezt a sebességet a B-gép is tudja. (Most vettem bele egy nagyon gyors vinyót, azzal még nem próbáltam. Nyilván ez is jelentősen befolyásolhatja az eredményeket.)
A jumbo-frame támogatás bekapcsolása előtt 36 MB/s-kel lehetett scp-zni, utána 46 MB/s lett a sebesség.
Ez egy ilyen elrendezésben normális, vagy lehetne sokkal jobb is?
Ezt azért kérdezem, mert nagyon nincs viszonyítási alapom, hogy ez most jónak, elfogadhatónak, vagy nagyon rossznak számít.
Azt persze észrevettem, hogy ez a "gigabit" elméleti maximumának (128 MB/s) kicsivel több csupán mint a harmada.

  • 3945 megtekintés

( veyron007 | 2010. 06. 01., k – 09:50 )

Az elméleti sebességet nem tudod elérni viszont 100 MB/s simán elérhető szerintem. Én egy 10/100-as hálózat sebességének közel 95%-át tudtam elérni.
Milyen HD-k vannak a RAD1 kötetetben?

3ware 9500S-4LP kártyán van két 400 GB-os Samsung HD403LJ diszk.
A diszkek külön külön 80MB/s körüli értékeket produkál (hdparm -t), RAID-1 tömbben pedig, - a 3ware drivert megfelelően paraméterezve - 94 MB/s körül.
A célgépben pedig - a teszt végzésekor - egy Seagate 320GB-os ST3320620AS vinyó volt, az a vinyó is tud olyan 62 MB/s-olvasásra (hdparm -t szintén).
A B gépbe került most egy jó gyors (120 MB/s - szokásos hdparm -t) Samsung HD502HJ vinyó, így majd azzal is kipróbálom, hogy mennyire befolyásolja ez a sebességet.
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.

Slackware Linux 12.1 | 2.6.26.7-janos

( Dwokfur v | 2010. 06. 01., k – 11:00 )

Szerk: most nézem, hogy wowbagger vagy - bocs, ha triviális dolgokat magyarázok...

A TCP/IP-nek van egy overhead-je, ami miatt sohasem lesz annyi, amennyit a bitek alapján számolna az ember. A leggyorsabb az ftp szerintem. Semmiképpen sem ssh-val tesztelném a sebességet.

Még valami: sajnos hiába bond-olsz két interface-t, de egy kapcsolat átvitele akkor is csak az egyik csatoló maximuma lesz. A bondolás előnye egyszerre több kapcsolatnál jöhet elő.

46Mb/s szerintem nem rossz. Örülnék neki a munkahelyen.

Meg azt is figyelembe kell venni, hogy a diszk rendszer elbírja-e a sustained 100MB/s-t a teszthez.

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

( blackluck v | 2010. 06. 01., k – 09:52 )

Futtass iperf-et inkabb ha azt akarod megtudni mit bir effektive a kapcsolat. (tcp window size-al jatszhatsz)
Plusz nem arthat ha kernel parametereket is novelsz hozza
http://fasterdata.es.net/TCP-tuning/linux.html

--
Don't Panic if you see me laughing,
that's not a bug, just a feature.

Sokáig használtam ezt a szoftvert de, az IPerf is tud csalóka lenni (de viszonyításnak nem rossz), mi viszont sima 200 megabites optikai betáp vonalat nem tudtunk vele tesztelni, mert össze vissza mutogatta az értékeket (120-180 megabit). 4 szálú FTP letöltéssel viszont simán 194MB. Bár tény, hogy ez internet teszt volt, nem pedig helyi hálózat (nekünk volt közben jó pár média konverter, switch, border gw router, stb...)

Ez valoszinu azert volt mert TCP vel mertel. Egyszalu TCP nem feltetlenul mutat jofajta ertekeket. Plane akkor ha interneten mesz keresztul es valahol elhagyodnak a csomagok vagy valahonnan tavolrol toltesz le. UDP-vel a masik fel altal reportolt sebessegnek viszont pontosnak kellene lennie.

De ez ugye attol fugg, hogy hogy definialod a 200megabitet (van olyan alkalmazas amivel ennyit tudsz atvinni vagy egy TCP alkalamazas fog ennyit brini).

( Imo | 2010. 06. 01., k – 10:28 )

Nem kell bedőlni olyasminek, hogy csak ftp-n, meg egyszerű protokollokkal lehet kihasználni a gbitet.

Itt egy default installos(!) SMB másolás két win között, mezei gigabiten, mezei pc-n, intel hálókártyákkal, trunking nélkül. (a szerver ráadásul virtualizált)

video

Most mértem egyet azért:

szerver: sun x4150 8x10kRPM SAS lemez, hardware RAID6-ban, FreeBSD, geli, zfs.
(dd if=/dev/aacd0 of=/dev/null bs=1M : 491994458 bytes/sec;
dd if=/storage/public/nagyfile.iso of=/dev/null bs=1M : 306447249 bytes/sec)
kliens: imac, OSX 10.6
másolás smb -n:
dd if=/Volumes/public_smb/nagyfile2.iso of=/dev/null bs=1M : 28503340 bytes/sec
másolás afp-n (netatalk a szerveren):
dd if=/Volumes/public_afp/nagyfile3.iso of=/dev/null bs=1M : 98675120 bytes/sec

ugyan ez van két imac között is.

szerveren smb.conf releváns beállításai:
socket options = TCP_NODELAY SO_KEEPALIVE SO_RCVBUF=9216 SO_SNDBUF=9216

Szóval nem szar, csak egy kicsit, ha a teljesítményét nézzük. :)

Wow! :)
Kipróbáltam:

dd if=/Volumes/public_smb/nagyfile.iso of=/dev/null bs=1M : 8329524344 bytes transferred in 99.597756 secs (83631647 bytes/sec)

Viszont egy note: az smbd az egyik magot 67%-on eszi, míg ha afp-t használok, az afpd olyan 15-18%-ot eszik csak (és ugye az 98 ezer valamennyi byte/sec-kel másolt)
note2:
Ha így másolok, hogy dd if=/..... of=/dev/null bs=8192, akkor a samba 17-21 MB/sec között ingadozik, míg az afp így is tud 90-91 MB/sec-et.
És ugye azért nem minden programnak lehet megadni, hogy 1Mb buffert használjon...

Na de köszi a tippet! :)

( gabrielakos v | 2010. 06. 01., k – 11:26 )

Diszkről diszkre nem rossz az.
Ezek a gépek amúgy elég gyengék, főleg ssh-val másoláshoz.
Amit itt javasoltak iperf, nem rossz ötlet, vagy a /dev/zero-t lehet a /dev/null -ba másolni, ha másolni akarsz mindenképpen.

--
Gábriel Ákos

( wowbagger v | 2010. 06. 02., sze – 02:29 )

Köszönöm az ötleteket/észrevételeket. A következő pár napban majd utánanézek a dolgoknak, és megnézem, hogy pontosan hol tudnék finomítani a dolgokon.
Azután majd jelentkezem, hogy mire jutottam.
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.

Slackware Linux 12.1 | 2.6.26.7-janos

az a gond, hogy az scp-vel nekem még sosem sikerült kipadlózni a drótot, most, olvasván a posztodat, merült fel bennem a gyanú, hogy a titkosítás miatt romlik az rtt-je a kapcsolatnak. Lehet, hogy ezért, lehet, hogy nem.

Nekem két gép között apacsról wget-be több párhuzamos dróton, külön-külön ip címpárokkal 2.5GBps volt eddig a rekord. Ez gyakorlatilag block cache-ből devnullba másolás volt.

Jaj urak, ez annyira ismert dolog.

High Performance SSH/SCP - HPN-SSH patchset kell neked!

SCP and the underlying SSH2 protocol implementation in OpenSSH is network performance limited by statically defined internal flow control buffers. These buffers often end up acting as a bottleneck for network throughput of SCP, especially on long and high bandwith network links. Modifying the ssh code to allow the buffers to be defined at run time eliminates this bottleneck. We have created a patch that will remove the bottlenecks in OpenSSH and is fully interoperable with other servers and clients. In addition HPN clients will be able to download faster from non HPN servers, and HPN servers will be able to receive uploads faster from non HPN clients. However, the host receiving the data must have a properly tuned TCP/IP stack

( asch v | 2010. 06. 03., cs – 19:12 )

Nekem Saját alkalmazásból sikerült 540MBps-t elérni, és stabilan tartani. Az egyik oldalon program generálta az adatot, a másik oldalon pedig egy az egyben írtam fájlba. Ja, és Java volt a program mindkét oldalon java.nio-val ha ez esetleg számítana.

A szűk keresztmetszet a diszk volt, kb ez volt a max, amivel még ment a fájl írás. A hálózaton két alaplapi Ethernet kommunikált egy fancy-n kinéző és nagyon hangos 24 portos gigabites switch-csen át. Ezzel most ki vagytok segítve :-).

Fájlba is írta (67,5 Mbyte/sec), szerintem annyira nem vészes.

Tudnál nézni egy hdparm -tT /dev/XXX-d?
Kíváncsi vagyok, hogy mennyire lassúak ezek a vinyók.


/dev/hda:
Timing cached reads: 1138 MB in 2.00 seconds = 568.94 MB/sec
Timing buffered disk reads: 244 MB in 3.03 seconds = 80.65 MB/sec


$ sudo hdparm -tT /dev/sda

/dev/sda:
Timing cached reads: 4284 MB in 2.00 seconds = 2142.15 MB/sec
Timing buffered disk reads: 278 MB in 3.01 seconds = 92.28 MB/sec

$ sudo hdparm -tTd /dev/sda

/dev/sda:
HDIO_GET_DMA failed: Inappropriate ioctl for device
Timing cached reads: 4658 MB in 2.00 seconds = 2329.18 MB/sec
Timing buffered disk reads: 278 MB in 3.01 seconds = 92.28 MB/sec

Az a fail akármi kicsit gyanús, de most van nagyobb bajom is.

bevallom, számomra nem derült ki, hogy asch ezt egy sun gépen mérte volna. továbbá az Sda az vagy valamilyen speckó scsi driver, vagy speckó sata driver, vagy általános libata. az első két esetben driver kérdése, milyen parancsokat támogatnak. libata esetében viszont nem kérdés, mivel a libata nem támogatja a hdio parancsokat. ezenkívül lényegtelen, milyen interface van a lemezen, ha libata-n keresztül használja a kernel, akkor scsi parancsokkal használja, amit a libata fordít a megfelelőre, ilyen szampontból az ata lemez is scsi a rendszer számára. én így tudom.

( 3xtati | 2010. 06. 09., sze – 09:18 )

signup
____________________
Ha igen akkor miért nem...
Linux 2.6.30-gentoo-r4 i686 Intel(R) Core(TM)2 Duo CPU E6550 @ 2.33GHz GenuineIntel GNU/Linux