[GBIT NETWERK] Ontzettend trage snelheden

[codemann]

Ik heb hier al een tijdje problemen mee, maar aangezien de tijd me ontbrak heb ik het nooit kunnen bekijken. Tot ik gisteren eens besloot er werk van te maken en het eens uitvoerig te gaan testen.
Ik zal de situatie eerst even kort schetsen, meer details volgen onder de uitleg : ik heb een Linksys gigabit switch (Linksys SD2008) met een fileserver (Debian) en een desktop PC (Windows XP).

Op de fileserver zijn zowel FTP (glftpd) als Samba (v3.0.24) actief. In mijn Windows heb ik de mappen die ik snel toegankelijk wil hebben gemapped naar een bepaalde drive, en voor extern ook aan mijn data te kunnen heb ik FTP voorzien. Beide machines bevatten een Intel Pro/1000 GT NIC.
In de fileserver zit een 80GB HDD om te booten en 4x 200GB in LVM2 voor de data (zie specs onderaan voor meer details).

Maar het gaat dus echt ongelooflijk langzaam, over FTP bijvoorbeeld had ik een stabiele 11mb/s, over Windows (Samba dus) schommelt het tussen de 5mb/s en 15mb/s (gekeken via Total Commander).

Dus ik begin gisteren met mijn eerst en vooral al een volledig nieuwe kernel te compilen (2.6.20.4) zodat ik mooi de laatste versie van de drivers heb en ik upgrade samba zoals je kan lezen.
Maar de resultaten blijven zeer slecht!

Even wat tests :

# hdparm -tT /dev/hda

/dev/hda:
Timing cached reads: 1836 MB in 2.00 seconds = 917.87 MB/sec
Timing buffered disk reads: 78 MB in 3.04 seconds = 25.62 MB/sec

iperf, server op linux, client op windows :

iperf -c <ip server> -w 64k
[ 4] local 192.168.1.104 port 5001 connected with 192.168.1.125 port 2531
[ 4] 0.0-10.0 sec 113 MBytes 94.7 Mbits/sec

iperf -c <ip server> -w 128k
[ 5] local 192.168.1.104 port 5001 connected with 192.168.1.125 port 2533
[ 5] 0.0-10.3 sec 113 MBytes 92.5 Mbits/sec

iperf -c <ip server> -w 256k
[ 4] local 192.168.1.104 port 5001 connected with 192.168.1.125 port 2534
[ 4] 0.0-10.2 sec 113 MBytes 92.7 Mbits/sec

iperf -c <ip server> -w 512k
[ 5] local 192.168.1.104 port 5001 connected with 192.168.1.125 port 2536
[ 5] 0.0-10.3 sec 114 MBytes 92.5 Mbits/sec

iperf -c <ip server> -w 1m
[ 4] local 192.168.1.104 port 5001 connected with 192.168.1.125 port 2538
[ 4] 0.0-10.3 sec 114 MBytes 92.8 Mbits/sec

iperf -c <ip server> -w 2m
[ 5] local 192.168.1.104 port 5001 connected with 192.168.1.125 port 2539
[ 5] 0.0-10.4 sec 115 MBytes 93.0 Mbits/sec

Dit lijkt me toch wel onder het niveau als ik het vergelijk met wat ik zoal lees.

Ik heb alles al zitten lezen en mijn samba bijvoorbeeld al wat zitten tweaken, ipv6 voorlopig maar even uit te kernel gekegeld, ... Alles wat me zinnig leek uit andere threads hier of ergens anders wel geprobeerd, maar ik kom niet verder. Iemand een suggestie? Ik zou hier echt wel uit willen geraken...
Ik ga zowiezo een RAID5 controller kopen en overschakelen naar 4x 500GB in RAID5, maar de prestaties zouden met deze hardware toch ook al beter moeten zijn...

Ik geef jullie nog even de specs van de PC's mee, als er kernel configs ofzo nodig zijn, vraag gerust.

Fileserver :

Behuizing: AOpen ATX Desktop HQ95
Voeding: Standaard
Moederbord: Abit IS7
Videokaart: NVidia Hercules (passief gekoeld) - nVidia Corporation NV11 [GeForce2 MX/MX 400]
NIC: Intel Pro/1000 GT - Intel Corporation 82541PI Gigabit Ethernet Controller (rev 05)
Controller Kaart: Promise SATAII 150 TX4 - Promise Technology, Inc. PDC20518/PDC40518 (SATAII 150 TX4)
Harde Schijf: Western Digital 80GB WDC WD800JB-00CRA1 + 4x 200GB
DVD Lezer: LG DVD-ROM HL-DT-STDVD-ROM GDR8162B

Desktop:

Behuizing: NoName ATX Midi Tower
Voeding: Zalman ZM400B-APS 400W Voeding
Moederbord: Abit IC7-G :
- Passieve NorthBridge koeling Zalman ZM-NB47J
- CPU koeling Zalman CNPS7000-ALCU
- 2x Corsair TWINX CMX512-3200LL - XMS3200 512MB - 400MHz
Videokaart: MSI NX6800GT - TD256
NIC: Intel Pro/1000 GT
Draadloze NIC: Belkin F5D7001 Wireless LAN PCI Adapter
Harde Schijf: Seagate Barracuda 7200.10 - 250GB
DVD Schrijver: AOpen DSW1812P
DVD Lezer: LG DVD-ROM HL-DT-STDVD-ROM GDR8164B

[Verwijderd]

Je disks doen maar 25MB/s dus dat lijkt me sowieso al een bottleneck, maargoed je haalt nog lager dan dat via netwerk. Dat laatste lijkt me meer voor de networking-fora maargoed.

Je geeft echter geen info over CPU utilization; als je cpu tegen 100% aan zit is het logisch dat je niet hoger kunt. Welke MTU gebruik je bijvoorbeeld? Geef eens een "ifconfig" output en zeg even welke categorie bekabeling je gebruikt voor desktop en server.

[ Voor 13% gewijzigd door Verwijderd op 05-04-2007 20:54 ]

[codemann]

Mijn excuses! Ik zag inderdaad te laat dat het de verkeerde plaats was, zeker met zo'n titel.

Tijdens de tests die ik beschrijf in de beginthread blijft mijn CPU laag, maar ik test even wat meer :

FTP Windows -> Linux
- Snelheid : 10-11MB/s, met drops tot 5MB/s
- Windows CPU : ong. 35% (FlashFXP.exe)
- Linux CPU : ong. 35% (glftpd)

FTP Linux -> Windows
- Snelheid : 10-11MB/s, met drops tot 5MB/s
- Windows CPU : ong. 45% (FlashFXP.exe)
- Linux CPU : ong. 35% (glftpd)

Samba Windows -> Linux (getest met Total Commander)
- Snelheid : schommelt zwaar tussen 6000kbytes/s en 8000kbytes/s met een zeldzame piek tot 11000kbytes/s
- Windows CPU : niks op te merken
- Linux CPU : nog geen 5% (smbd)

Samba Linux -> Windows (getest met Total Commander)
- Snelheid : 9500kbytes/s met drops tot 6000kbytes/s
- Windows CPU : niks op te merken
- Linux CPU : nog geen 5% (smbd)

En tenslotte :

eth0 Link encap:Ethernet HWaddr 00:0E:0C:D0:00:5E
inet addr:192.168.1.104 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3719166 errors:0 dropped:0 overruns:0 frame:0
TX packets:3492676 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:4039099033 (3.7 GiB) TX bytes:3039385287 (2.8 GiB)
Base address:0x9000 Memory:fb020000-fb040000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

[Verwijderd]

Je zegt b.v.:

- Linux CPU : ong. 35% (glftpd)

Ik heb liever dat je tijdens het testen "top" openhoudt en kijkt naar hoeveel % free je CPU is. Interrupts etc. wordt dan allemaal meegerekend. user CPU usage is namelijk niet het enige. In tegendeel.

Verder:
- ik zie niet op welke media snelheid je NIC is verbonden, is dat 100BaseT of 1000BaseT full duplex?
- ik zie dat je MTU 1500 gebruikt, dat levert natuurlijk niet optimale performance op; lees je eens in over jumbo frames (MTU 9000)
- je zou ook kunnen kijken naar TCP send/receive buffer instellingen, alsmede samba buffer instellingen in smb.conf
- gebruik je interrupt mode of device polling?

[ Voor 44% gewijzigd door Verwijderd op 05-04-2007 21:52 ]

[dôh]

Gebruik je SSL data transfer?!

Zo ja, zet die eens uit en gebruik alleen SSL listing..

Scheelt een hoop CPU time!

[Verwijderd]

dôh schreef op donderdag 05 april 2007 @ 21:51:
Gebruik je SSL data transfer?!

Zo ja, zet die eens uit en gebruik alleen SSL listing..

Scheelt een hoop CPU time!

Ik denk niet dat Windows filesharing (SMB/CIFS) SSL ondersteunt.

[dôh]

Verwijderd schreef op donderdag 05 april 2007 @ 21:52:
[...]

Ik denk niet dat Windows filesharing (SMB/CIFS) SSL ondersteunt.

Nee... maar hij gebruikt ook glftpd, en die doet dat wel!

[gjs]

Ben je er zeker van dat beide machines op gigabit geconnect zijn ?
Aan Iperf te zien heb je maar 100mbit.
Hoe zit het met je bekabeling ? Gebruik je wel cat5e of cat6 ?
Heb je al eens getest met een crosskabel tussen pc en server ?
Wellicht een duplex probleem ?

[ Voor 6% gewijzigd door gjs op 05-04-2007 22:14 ]

[Fauna]

Zou het niet gewoon een bottleneck in de PCI bus kunnen zijn? De server heeft namelijk maar een 'normaal' desktopbord met PCI 32bits/33MHz. Als je daar een I/O kaart en een gigabit netwerkkaart aan hangt is het natuurlijk vragen om problemen. Maar dan zou de limiet eerder rond de 20-30MB/s moeten liggen i.p.v. 10.

TS: heb je al geprobeerd met een andere client PC?

[codemann]

- Linux CPU : ong. 35% (glftpd)

Ik heb liever dat je tijdens het testen "top" openhoudt en kijkt naar hoeveel % free je CPU is. Interrupts etc. wordt dan allemaal meegerekend. user CPU usage is namelijk niet het enige. In tegendeel.

Gebruik je SSL data transfer?!

Zo ja, zet die eens uit en gebruik alleen SSL listing..

Scheelt een hoop CPU time!

Er stond inderdaad SSL nog op in mijn FlashFXP, dit had ik ooit zo ingesteld om eens te testen. Staat nu af en ik zie dan dat glftpd nog maar tot maximaal 15-20% komt, maar de snelheid blijft maximaal 10MB/s.
Ik bekeek trouwens "top" en glftpd is het enige wat CPU verbruikt, voor de rest heb je kjournald, kswapd, pdflush, ... die af en toe omhoog komen, maar dat is nog niet eens 1%.

Ik moet wel zeggen dat als ik wil verbinden via FlashFXP ik het volgende krijg :
[R] Connecting to fileserver -> DNS=fileserver IP=192.168.1.104 PORT=21
[R] Connected to fileserver
En dat hij dan enkele secondes niks doet... en daarna logt hij razendsnel in. Dat ga ik zelf ook nog eens bekijken, maar dat was vroeger in ieder geval niet.

En de rest van top zegt (een paar copy & pastes) :

top - 22:25:23 up 2:45, 2 users, load average: 0.40, 0.21, 0.08
Tasks: 61 total, 3 running, 58 sleeping, 0 stopped, 0 zombie
Cpu(s): 7.3%us, 8.3%sy, 0.0%ni, 40.4%id, 37.1%wa, 1.7%hi, 5.3%si, 0.0%st
Mem: 516676k total, 510768k used, 5908k free, 1824k buffers
Swap: 1542200k total, 2056k used, 1540144k free, 466508k cached

top - 22:26:14 up 2:46, 2 users, load average: 0.45, 0.25, 0.10
Tasks: 61 total, 3 running, 58 sleeping, 0 stopped, 0 zombie
Cpu(s): 7.0%us, 6.3%sy, 0.0%ni, 60.7%id, 22.0%wa, 1.0%hi, 3.0%si, 0.0%st
Mem: 516676k total, 510852k used, 5824k free, 1712k buffers
Swap: 1542200k total, 2056k used, 1540144k free, 466532k cached

top - 22:26:32 up 2:47, 2 users, load average: 0.43, 0.25, 0.10
Tasks: 61 total, 3 running, 58 sleeping, 0 stopped, 0 zombie
Cpu(s): 8.0%us, 9.3%sy, 0.0%ni, 24.0%id, 54.0%wa, 0.3%hi, 4.3%si, 0.0%st
Mem: 516676k total, 510764k used, 5912k free, 1720k buffers
Swap: 1542200k total, 2056k used, 1540144k free, 466896k cached

- ik zie dat je MTU 1500 gebruikt, dat levert natuurlijk niet optimale performance op; lees je eens in over jumbo frames (MTU 9000)

Dat ga ik onmiddellijk nadat ik op "verstuur bericht" op geklikt eens opzoeken

- je zou ook kunnen kijken naar TCP send/receive buffer instellingen, alsmede samba buffer instellingen in smb.conf

Dat was deel van de SMB optimalisatie die ik al eens had geprobeerd :

[global]
workgroup = LAN
server string = fileserver
hosts allow = 192.168.1.100 192.168.1.101 192.168.1.102 192.168.1.125
log file = /var/log/samba/%m.log
max log size = 50
security = share
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192

[Share]
comment = Share
path = /glftpd/site
force user = codemann
force group = codemann
read only = No
guest ok = Yes

- gebruik je interrupt mode of device polling?

Hier praat je even Chinees tegen me, ik ga eens zien wat Google zegt dat het betekent

Ben je er zeker van dat beide machines op gigabit geconnect zijn ?
Aan Iperf te zien heb je maar 100mbit.
Hoe zit het met je bekabeling ? Gebruik je wel cat5e of cat6 ?
Heb je al eens getest met een crosskabel tussen pc en server ?
Wellicht een duplex probleem ?

Gigabit connectie hardware :
- ze hebben allebei een Intel Pro/1000
- er zit enkel een gigabit switch tussen
- kabel is cat5e

Gigabit connectie software :
- Windows zegt 1gbit
- Linux (mii-tool) zegt : "eth0: negotiated 100baseTx-FD flow-control, link ok"
Dat ga ik zelf ook nog even verder onderzoeken...


Alvast bedankt voor de reacties, ik ga die paar dingen al eens opzoeken en testen.

[codemann]

update :

mii-tool is dus enkel voor 10/100mbit, snel weer weg gedaan

ethtool geinstalleerd, daar gaf hij 100mbit aan en dus het volgende geprobeerd :
ethtool -s eth0 speed 1000 duplex full autoneg off

met als resultaat een PuTTY die weg was en uiteindelijk op de console kregen we dit :

Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 1000baseT/Full
Advertised auto-negotiation: Yes
Speed: Unknown! (65535)
Duplex: Unknown! (255)
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: umbg
Wake-on: g
Current message level: 0x00000007 (7)
Link detected: no

Terug gaan fixen aan de console en nu staat er terug :

Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: umbg
Wake-on: g
Current message level: 0x00000007 (7)
Link detected: yes

*zucht*

Ook even gecontroleerd of de driver zeker juist was, en dat is hij ook :

Intel(R) PRO/1000 Network Driver - version 7.3.15-k2-NAPI
Copyright (c) 1999-2006 Intel Corporation.
e1000: 0000:02:04.0: e1000_probe: (PCI:33MHz:32-bit) 00:0e:0c:d0:00:5e
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection

[ Voor 8% gewijzigd door codemann op 05-04-2007 23:03 ]

[Verwijderd]

- Linux (mii-tool) zegt : "eth0: negotiated 100baseTx-FD flow-control, link ok"

Dus op Linux draait je NIC vrolijk in 100BaseT mode met dus maximaal 100Megabit link.

edit: dat had je dus al door.

Je kunt wel 'forceren' op 1000BaseT maar het hoort via auto-negotiation te werken. Controleer de bekabeling van je linux PC, check of dat echt Cat5e is, en zo ja hoe lang. Is de kabel misschien opgerold? Vervang de kabel eens door een uitstekende kwaliteit van maximaal 10 meter lang en try again.

Anders kan het een driver probleem zijn, probeer de intel site eens die hebben binary drivers voor Linux/BSD voor hun Pro/1000 NICs.

[ Voor 62% gewijzigd door Verwijderd op 05-04-2007 23:22 ]

[codemann]

Verwijderd schreef op donderdag 05 april 2007 @ 23:18:
[...]


Dus op Linux draait je NIC vrolijk in 100BaseT mode met dus maximaal 100Megabit link.

edit: dat had je dus al door.

Je kunt wel 'forceren' op 1000BaseT maar het hoort via auto-negotiation te werken. Controleer de bekabeling van je linux PC, check of dat echt Cat5e is, en zo ja hoe lang. Is de kabel misschien opgerold? Vervang de kabel eens door een uitstekende kwaliteit van maximaal 10 meter lang en try again.

Anders kan het een driver probleem zijn, probeer de intel site eens die hebben binary drivers voor Linux/BSD voor hun Pro/1000 NICs.

Ja ik las ook net dat autonegotiation aan moest... Opnieuw geprobeerd, weer die ******** putty kwijt, weer naar beneden wandelen (ik ga nog een goeie conditie krijgen) en weer terug op 100mbit gegooid.

Kabel heb ik gisteren nog gecontroleerd, staat cat5e op, maar ik ga hem voor de zekerheid eens vervangen. De switch staat beneden, dus eigenlijk is dat juist het korte deel. Richting deze Windows PC is het lange deel juist.

[mvanderkruk]

Verwijderd schreef op donderdag 05 april 2007 @ 23:18:
Dus op Linux draait je NIC vrolijk in 100BaseT mode met dus maximaal 100Megabit link.

Je kunt wel 'forceren' op 1000BaseT maar het hoort via auto-negotiation te werken. Controleer de bekabeling van je linux PC, check of dat echt Cat5e is, en zo ja hoe lang. Is de kabel misschien opgerold? Vervang de kabel eens door een uitstekende kwaliteit van maximaal 10 meter lang en try again.

Check je kabel eens, dit lijkt mij een typisch kabelprobleem... voor gigabit zijn alle 8 aders benodigd...
De standaard linux driver voor de Intel Pro1000 werkte bij zonder problemen.. snelheid tot 50Mbyte/sec
(Toen hield de disk in mijn werkstation het niet meer bij)

Autonegetiation heb ik ook wat problemen mee gehad, maar het rmmod-den van de driver gevolgd door een modprobe loste ook dat probleem op.

[codemann]

mvanderkruk schreef op donderdag 05 april 2007 @ 23:32:
[...]


Check je kabel eens, dit lijkt mij een typisch kabelprobleem... voor gigabit zijn alle 8 aders benodigd...
De standaard linux driver voor de Intel Pro1000 werkte bij zonder problemen.. snelheid tot 50Mbyte/sec
(Toen hield de disk in mijn werkstation het niet meer bij)

Autonegetiation heb ik ook wat problemen mee gehad, maar het rmmod-den van de driver gevolgd door een modprobe loste ook dat probleem op.

Ik heb juist met 2 andere kabels getest, met allebei kwam de link up en ging hij onmiddellijk weer terug down, en dat bleef zich herhalen...
De originele kabel terug geprobeerd en daar blijft hij bij down. Ik ga eens zien of ik nog gekke kameraden heb die op dit uur nog wakker zijn en een cat5e kabeltje hebben liggen, dit is gewoon te gek voor woorden

[codemann]

Gelukkig hebben we kameraden die in een computerwinkel werken! Nieuwe Cat5e kabel en hij geeft 1000mbit aan!

Even getest met FTP : Transferred 1 file totaling 2,51 GB in 2 minutes 19 seconds (18,98 MB/s)

Wat nog steeds erg traag is eigenlijk... De verbinding is de hele tijd rond de 25mb/s, maar hij dropt op het laatste zelfs tot 3-4mb/s bij momenten... Maar voor vandaag is het goed geweest, er is weer wat vooruitgang geboekt

Juist even gekeken, laptop heeft 1000mbit. Morgen eens nog een nieuw kabeltje halen en onder eens op de switch insteken. Ben benieuwd wat dat gaat geven qua snelheid... To be continued!

[ Voor 17% gewijzigd door codemann op 06-04-2007 00:35 ]

[Verwijderd]

Nouja als je schijven maar 25MB/s doen dan is dat logisch, en die drops naar 3-4MB/s kan een indicatie zijn dat de schijf door het OS gebruikt wordt voor andere dingen. Je netwerk is nu wellicht geen bottleneck meer maar je hardeschijf. Test eens met iperf apart je netwerkbandbreedte en kijk eens of je je HDD snelheid kunt verbeteren.

[codemann]

Verwijderd schreef op vrijdag 06 april 2007 @ 00:56:
Nouja als je schijven maar 25MB/s doen dan is dat logisch, en die drops naar 3-4MB/s kan een indicatie zijn dat de schijf door het OS gebruikt wordt voor andere dingen. Je netwerk is nu wellicht geen bottleneck meer maar je hardeschijf. Test eens met iperf apart je netwerkbandbreedte en kijk eens of je je HDD snelheid kunt verbeteren.

De schijf die daar getest wordt is de bootschijf. Ik heb juist nog wat zitten lezen en ik lees dat er sdparm en blktool bestaan, die ga ik vanavond eens op mijn SATA schijven proberen. hdparm geeft namelijk foutmeldingen als ik met mijn SATA schijven test, dus ik weet niet of die resultaten waarde hebben dan... Ik zal dan iperf ook eens opnieuw testen. To be continued in ieder geval

[Verwijderd]

Schijfperformance kun je als volgt testen:

# lezen
dd if=/mountpoint/bigfile of=/dev/null bs=1m

# schrijven
dd if=/dev/zero of=/mountpoint/new-bigfile bs=1m count=1024

Bij de schrijfactie wordt "new-bigfile" aangemaakt, zorg dus niet dat dat bestand bestaat anders wordt het overschrijven. Met mountpoint bedoel ik NIET iets wat met /dev begint, maar iets met /mnt/sataschijf1/ ofzoiets.

[codemann]

Verwijderd schreef op vrijdag 06 april 2007 @ 13:07:
Schijfperformance kun je als volgt testen:

# lezen
dd if=/mountpoint/bigfile of=/dev/null bs=1m

# schrijven
dd if=/dev/zero of=/mountpoint/new-bigfile bs=1m count=1024

Bij de schrijfactie wordt "new-bigfile" aangemaakt, zorg dus niet dat dat bestand bestaat anders wordt het overschrijven. Met mountpoint bedoel ik NIET iets wat met /dev begint, maar iets met /mnt/sataschijf1/ ofzoiets.

Zo snel als ik thuis kom gaan we dat eens testen. /mnt/mijnpornocollectie/ in mijn geval
Argh was de werkdag maar al gedaan, ik wil spelen met mijn netwerk!

[BalusC]

Opslagmedia & I/O Controllers » Netwerken

codemann schreef op vrijdag 06 april 2007 @ 13:29:
Zo snel als ik thuis kom gaan we dat eens testen. /mnt/mijnpornocollectie/ in mijn geval

Dat vindt zij misschien niet zo interessant

[Kabouterplop01]

En nu de Jumbos nog aan zetten

[codemann]

Even een paar extra tests gedaan. Mijn Laptop (vrij nieuwe Asus) heeft een gigabit NIC, dus deze even met een nieuwe kabel uit de winkel getest rechtstreeks op de switch beneden. En dezelfde tests ook gedaan met de Desktop PC.
De tests gebeurden altijd vanaf de Laptop of de Desktop PC.

Server -> Laptop (FTP)
Transferred 1 file totaling 2,31 GB in 1 minute 37 seconds (24,38 MB/s)
Transferred 1 file totaling 2,31 GB in 1 minute 29 seconds (26,39 MB/s)
Transferred 1 file totaling 2,31 GB in 1 minute 31 seconds (25,86 MB/s)

- geen (of maximaal 1-2%) cpu belasting door glftpd

Server -> Desktop PC (FTP)
Transferred 1 file totaling 2,31 GB in 1 minute 8 seconds (34,83 MB/s)
Transferred 1 file totaling 2,31 GB in 1 minute 17 seconds (30,80 MB/s)
Transferred 1 file totaling 2,31 GB in 1 minute 3 seconds (37,44 MB/s)
Transferred 1 file totaling 2,31 GB in 1 minute 15 seconds (31,32 MB/s)
Transferred 1 file totaling 2,31 GB in 58,77 seconds (40,36 MB/s)

- geen (of maximaal 1-2%) cpu belasting door glftpd
- zakt soms tot 15-20mb/s, dan wordt er weer gepiekt tot 45mb/s
- resultaten zijn ook met 10mb/s verschil tussen hoogste en laagste

In allebei de gevallen blijven de snelheden relatief stabiel, het grote verschil zit hem in de piek.
Bij de laptop was dit 30mb/s, bij de PC is dit tot 45mb/s gegaan.
Ik merkte dat meestal bij de PC in het begin de snelheid lager lag, maar op het einde was de snelheid stabiel rond de 45mb/s. Alsof hij even de juiste snelheid moest vinden... Kan dit iets met de latency te maken hebben?


Laptop -> Server (FTP)
Transferred 1 file totaling 2,31 GB in 2 minutes 7 seconds (19,00 MB/s)
Transferred 1 file totaling 2,31 GB in 2 minutes 6 seconds (19,08 MB/s)
Transferred 1 file totaling 2,31 GB in 1 minute 59 seconds (20,37 MB/s)

- cpu (glftpd) meestal tussen de 25-30%, 1x gezien dat de transfer snelheid voor een tijdje continu 30-35mb/s was, en toen was de cpu ook 40-45%

Desktop PC -> Server (FTP)
Transferred 1 file totaling 2,31 GB in 1 minute 33 seconds (26,32 MB/s)
Transferred 1 file totaling 2,31 GB in 1 minute 30 seconds (27,58 MB/s)
Transferred 1 file totaling 2,31 GB in 1 minute 33 seconds (26,30 MB/s)

- cpu belasting is hier vrij stabiel rond de 40-45%


Conclusie :

De kabel tussen mijn Desktop PC en de gigabit switch lijkt me wel ok te zijn, ik kan toch pieken tot 45mb/s.
Er is een duidelijk verschil tussen de laptop en de desktop pc, ik vermoed dus dat de laptop toch ergens zijn begrenzingen heeft, en het is trouwens een onboard gigabit NIC.

Alle tests zijn trouwens gedaan met Jumbo Frames aan op de fileserver.

[ Voor 5% gewijzigd door codemann op 06-04-2007 22:23 ]

[Romke]

20 tot 30 MB/s is een zeer redelijke snelheid voor gbit

Mijn AMD64 serverbitch haalt dat ook ongeveer als ik em op gbit zet, ook een linuxbakje met ubuntu-amd64-server.

[Verwijderd]

Stel je hebt compu A en B en we willen data transproteren van A naar B (via file & printer sharing).

Maakt het voor de snelheid nog verschil of je deze data "vanuit A naar B duwt" (je bedient A) of dat je de data "vanaf B uit A trekt" (je bedient ?

[ Voor 10% gewijzigd door Verwijderd op 07-04-2007 01:10 ]

[codemann]

Verwijderd schreef op zaterdag 07 april 2007 @ 01:08:
Stel je hebt compu A en B en we willen data transproteren van A naar B (via file & printer sharing).

Maakt het voor de snelheid nog verschil of je deze data "vanuit A naar B duwt" (je bedient A) of dat je de data "vanaf B uit A trekt" (je bedient ?

Mijn ervaring is dat downloaden (lezen) een pak sneller gaat dan uploaden (schrijven).

[codemann]

Kameraad van mij is de hele avond hier geweest met een server van hem, we hebben uitgebreid zitten testen...

Conclusie is zoals eerder al aangegeven dat ik inderdaad 40-50MB/s haal als ik via FTP download van de fileserver, en als ik upload dan kom ik rond de 30MB/s.
Als we vanaf verschillende PC's werkten, dan was het altijd gemiddeld rond de 50MB/s samen, en daarbij maakte het niet uit of het download + download of download + upload was.

Ook hebben we zowel de Linksys DSW2006 als de professionele Level1 SGW-1655 als een gewone Level1 getest, en geen van de 3 komt aan zijn limiet, allemaal versturen ze de data even vlotjes. Ik kan de Linksys overkopen van die kameraad, ik denk dat ik die ook ga nemen aangezien die toch net wat betere specs schijnt te hebben.

Ik heb dan even mijn PCI overclocked gehad om te testen, maar dit bleek niet zo een goed idee Alleen downloaden of uploaden maakte geen snelheidswinst en toen we samen aan het downloaden waren ging het opeens tot 60-70MB/s, maar toen kreeg ik opeens een héél zware load op mijn sata schijven! Maar snel teruggezet dus.

Ook was het zo dat ik in het begin deze snelheden niet echt stabiel haalden, maar uiteindelijk bleek dit te zijn omdat ik aan het testen was vanaf de bootschijf van de Desktop PC. Even een extra schijf aangehangen op een apart IDE kanaal en getest van en naar deze schijf en toen waren de snelheden heel stabiel.

Nog enkele vragen :
1. Is het normaal dat die upload langzamer is dan de download?
2. Is het normaal dat via mijn samba shares het aanzienlijk trager is? 30MB/s down en 15MB/s up. Valt daar nog iets aan te optimaliseren? Momenteel heb ik dit al toegevoegd : socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192


Ik was ook aan het denken om een Hardware RAID5 oplossing te zoeken, maar aangezien ik met PCI zit en niet een van de nieuwere versies (PCI-X of PCIe), ga ik hier qua performantie geen winst mee kunnen boeken.
Is Software RAID5 (LVM2 ondersteunt het zag ik in mijn kernel) even betrouwbaar als Hardware RAID5? Ik heb eens heel snel gekeken en ik zag een Highpoint voor rond de €125 die RAID5 ondersteunt en in een andere thread werd me een Promise aangeboden voor €125. Dit vind ik qua prijs doenbaar, maar wat zou voor mij het voordeel van een Hardware RAID5 kunnen zijn over een Software RAID5? Betrouwbaarheid?

Het was weer een leerrijke avond, moe maar voldaan ga ik nu eens mijn bedje opzoeken!

[ Voor 21% gewijzigd door codemann op 07-04-2007 13:14 ]

[codemann]

Een kleine *bump*

Kan iemand me nog verder helpen met mijn laatste vraagjes? Dan ben ik echt overal uit...

[ Voor 15% gewijzigd door codemann op 07-04-2007 13:15 ]