Niet tevreden over snelheid netwerk

[TommyGun]

Inleiding

Het zou kunnen dat jullie dit bekend in de oren klinkt, maar dit staat los van het probleem dat ik heel wat maanden geleden met mijn netwerk heb gehad. Inmiddels is al veel apparatuur vervangen. Echter dacht ik toch maar even een topic te openen.

Het probleem

Ik maak gebruik van Chello Extreme, en trek ook de volle snelheid op mijn server. (2.2 MB's). Ook op de andere systemen is de snelheid vanaf het internet uitstekend. Echter het netwerk is niet zo snel als ik het graag zou willen. En daar gaat dit topic dus ook over.

File (300 mb) van werkstation naar server = 2100 kb's
File (300 mb) van server naar werkstation = 1500 kb's

File (300 mb) van laptop naar server = 1400 kb's
File (300 mb) van server naar laptop = 2200 kb's

Vreemde resultaten vindt ik, de laptop is sneller met downloaden, en m'n werkstation is sneller met versturen. Deze snelheden zijn overigens zeer stabiel en altijd constant.

Apparatuur

Chello modem -> Server -> Switch / Router -> Werkstations / Laptop. (Overal cat5e bekabeling).

De server is een Dell PowerEdge 6450, 4x Intel P3 Xeon 700Mhz 2MB Cache CPU, 8x 512 ECC SD RAM geheugen, 4x 37 GB 10.000 RPM in een RAID 5 opstelling. Dit aan een goede SCSI hardware RAID controller (64 bits).

In deze server (draaiend op ClarkConnect 3.2, CentOS Linux) zitten 2 64bit netwerkkaarten die beiden 1000 MBps kunnen hebben. Dan heb ik nog een onboard NIC die 32bit is en 100 MBps kan trekken. De 32bit kaart is eth1, en de 2 64bit kaarten zijn eth2 en eth0.

Zie TommyGun in "Niet tevreden over snelheid netwerk"

Op eth1 komt het internet vanuit de modem binnen, waarna eth2 een switch aanstuurt, en eth0 een WLAN router. De switch is een simpele Edimax 4 ports // TommyGun in "Niet tevreden over snelheid netwerk" // en de WLAN router is een Sitecom met MIMO-XR. (Weet het exacte type zo niet).

In m'n laptop (Windows XP Home) zit een S-ATA schijf van 4200 (meen ik) RPM, en in m'n werkstation (Windows XP Pro) zitten meerdere schijven waaronder een S-ATA schijf, een aantal IDE schijven en een USB disk. (Deze zijn allemaal 7200 RPM). Met al deze schijven haal ik ongeveer dezelfde snelheden.

NIC instellingen

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: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/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: d
Current message level: 0x00000007 (7)
Link detected: yes

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

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

Eth0 zit in de reeks 192.168.4.x en eth2 in 192.168.3.x. Mijn werkstation heeft dus het vaste adres 192.168.3.2 en de server zelf is 192.168.3.1. De WLAN router heeft het adres 192.168.4.5 en geeft automatisch een nieuwe in diezelfde reeks aan de laptop.

Benchmarks

Op aanraden wou ik netperf even testen, maar dit krijg ik niet werkend. O.a vanwege het feit dat ClarkConnect goed is in de basis omgeving, maar daarbuiten is het een ramp. (Vooral voor iemand zoals mij, die nog niet zo heel lang met Linux werkt). Vervolgens maar even NetIO getest:

Server commando:

./linux-i386 netio -s

NETIO - Network Throughput Benchmark, Version 1.26
(C) 1997-2005 Kai Uwe Rommel

TCP server listening.
UDP server listening.
TCP connection established ...

Werkstation commando 1:

win32-i386 -t 192.168.3.1

NETIO - Network Throughput Benchmark, Version 1.23
(C) 1997-2003 Kai Uwe Rommel

TCP connection established.
Packet size 1k bytes: 11333 KByte/s Tx, 11178 KByte/s Rx.
Packet size 2k bytes: 11320 KByte/s Tx, 11558 KByte/s Rx.
Packet size 4k bytes: 10062 KByte/s Tx, 11567 KByte/s Rx.
Packet size 8k bytes: 11550 KByte/s Tx, 11561 KByte/s Rx.
Packet size 16k bytes: 11541 KByte/s Tx, 11548 KByte/s Rx.
Packet size 32k bytes: 11576 KByte/s Tx, 11559 KByte/s Rx.
Done.

Antwoord server op commando 1:

Receiving from client, packet size 1k ...
Sending to client, packet size 1k ...
Receiving from client, packet size 2k ...
Sending to client, packet size 2k ...
Receiving from client, packet size 4k ...
Sending to client, packet size 4k ...
Receiving from client, packet size 8k ...
Sending to client, packet size 8k ...
Receiving from client, packet size 16k ...
Sending to client, packet size 16k ...
Receiving from client, packet size 32k ...
Sending to client, packet size 32k ...
Done.
TCP server listening.

Werkstation commando 2:

win32-i386 -u -b 2k 192.168.3.1

NETIO - Network Throughput Benchmark, Version 1.23
(C) 1997-2003 Kai Uwe Rommel

UDP connection established.
Packet size 2k bytes: 9952 KByte/s (0%) Tx, 7429 KByte/s (85%) Rx.
Done.

Antwoord server op commando 2:

UDP connection established ...
Receiving from client, packet size 2k ...
Sending to client, packet size 2k ...
Done.
UDP server listening.

Werkstation commando 3:

win32-i386 -u -b 10k 192.168.3.1

NETIO - Network Throughput Benchmark, Version 1.23
(C) 1997-2003 Kai Uwe Rommel

UDP connection established.
Packet size 10k bytes: 11710 KByte/s (0%) Tx, 618 KByte/s (99%) Rx.
Done.

Antwoord server op commando 3:

UDP connection established ...
Receiving from client, packet size 10k ...
Sending to client, packet size 10k ...
Done.
UDP server listening.

Als laatste nog even hdparm op de server los gelaten:

hdparm -tT /dev/sda

/dev/sda:
Timing cached reads: 860 MB in 2.00 seconds = 429.64 MB/sec
Timing buffered disk reads: 158 MB in 3.02 seconds = 52.26 MB/sec

Slot

Iemand die misschien suggesties, tips of in het beste geval oplossingen kan geven? Het draait verder allemaal rete stabiel, maar iets sneller mag toch wel. Als er iemand een log wil zien, dan kan ik die wel posten. Maar ik zelf zie geen vreemde dingen in bijv dmesg, messages, system, syswatch etc.

Edit; even een Protocol Statistics log bijgevoegd van enkele weken; link

En phpSysInfo: link

Alvast bedankt!

[TommyGun]

Helaas, niemand die ook meer enig idee heeft?

[TommyGun]

Goed, de switch is vervangen door een Netgear FS105. Echter zijn de speeds nog exact hetzelfde. De switch geeft aan dat de poorten op FDX draaien, en ik zie ook geen collision ledjes opblinken (op de switch zelf dus) tijdens het overpompen van redelijk veel data.

Eth2;

code:

Mar 14 17:52:41 gateway kernel: e100: eth2: e100_watchdog: link down
Mar 14 17:53:47 gateway kernel: e100: eth2: e100_watchdog: link up, 100Mbps, full-duplex
Mar 14 17:53:49 gateway kernel: e100: eth2: e100_watchdog: link down
Mar 14 17:53:51 gateway kernel: e100: eth2: e100_watchdog: link up, 100Mbps, full-duplex

Iemand nog suggesties?

[ Voor 37% gewijzigd door TommyGun op 14-03-2007 18:19 ]

[Guru Evi]

1)Zijn alle netwerkkaarten op 1000MBps ingesteld? Indien niet mogelijk, probeer alle 100MBps apparaten eruit te halen. Je switch is 10/100MBps, dus meer dan dat kun je niet verwachten. 1500kbyte/s =~ 12MBit/s, vind ik toch redelijk op een 100MBps netwerk voor een enkele transfer over verschillende layers.

2) Welk protocol gebruik je en wat is de CPU load tijdens de transfer. SMB is trager dan FTP bijvoorbeeld.

3) Je haalt bijna 100Mbps overal met NetIO vind ik toch redelijk tussen 2 punten. Als je verschillende clients een file laat downloaden tegelijkertijd, hoeveel haalt je server dan? Vind je daardoor misschien een bottleneck?

4) Je netwerkkaarten, zijn ze allemaal goed ingesteld? Heb je de TCP instellingen in je kernel geoptimaliseerd? Jumbo-pakketten gebruikt? Tegenwoordig zijn de out-of-the-box instellingen nog steeds voor 100Mbps of lager, dus 1Gbps zou wel een beetje tweaken nodig zijn.

5) Probeer eens IPv6 ipv IPv4

[ Voor 14% gewijzigd door Guru Evi op 14-03-2007 18:28 ]

[JHMvP]

1. Hmmm...je geeft aan de de NIC's in je server allemaal 1000Mb/s aankunnen maar je lijstje geeft aan dat alleen ETH0 dit kan. En uitgerekend deze snelste poort knup je aan het WiFi ding... Kun je de snelste poort niet es gebruiken voor je switch en dus voor je LAN?

2. Je switch is niet bepaald het meest profi ding wat er bestaat. Kun je niet ergens even een 1000Mb/s switchje lenen?

3. Doorvoersnelheden worden ook bepaald door de netwerkkaarten. Zijn dit onboard-NICjes? Meer info over NIC's graag!

4. Hebben de NIC's in je server, allen een eigen IRQ etc?

[TommyGun]

Guru Evi schreef op woensdag 14 maart 2007 @ 18:24:
1)Zijn alle netwerkkaarten op 1000MBps ingesteld? Indien niet mogelijk, probeer alle 100MBps apparaten eruit te halen. Je switch is 10/100MBps, dus meer dan dat kun je niet verwachten. 1500kbyte/s =~ 12MBit/s, vind ik toch redelijk op een 100MBps netwerk voor een enkele transfer over verschillende layers.

Edit; zie TommyGun in "Niet tevreden over snelheid netwerk"

2) Welk protocol gebruik je en wat is de CPU load tijdens de transfer. SMB is trager dan FTP bijvoorbeeld.

Wat bedoel je precies met welke protocol? Op moment van transferen via WinSCP is de load als volgt; (SSH is waarschijnlijk WinSCP, aangezien die er anders nooit tussen staat. Maar er is genoeg power over dus.)

3) Je haalt bijna 100Mbps overal met NetIO vind ik toch redelijk tussen 2 punten. Als je verschillende clients een file laat downloaden tegelijkertijd, hoeveel haalt je server dan? Vind je daardoor misschien een bottleneck?

Hmm ja naast mijzelf is de enige andere client de PC van mijn zusje. Testen zal dus ietwat lastig worden, of ik moet er een andere PC bij gooien.

4) Je netwerkkaarten, zijn ze allemaal goed ingesteld? Heb je de TCP instellingen in je kernel geoptimaliseerd? Jumbo-pakketten gebruikt? Tegenwoordig zijn de out-of-the-box instellingen nog steeds voor 100Mbps of lager, dus 1Gbps zou wel een beetje tweaken nodig zijn.

Zie antwoord op vraag 1, met een toevoeging; de kernel en TCP instellingen zijn verder gewoon standaard, ik heb niks zelf gebuild of getweakt aan de kernel of wat dan ook, aangezien ik een Linux beginner ben. (Dus waag me daar niet echt aan).

5) Probeer eens IPv6 ipv IPv4, die is iewat beter voor hoge snelheden.

Ik ben wel bekend met het fenomeen IPv4 en IPv6 maar niet hoe ik dit zou kunnen aanpassen.

Bedankt voor je bericht.

[ Voor 19% gewijzigd door TommyGun op 14-03-2007 19:07 ]

[TommyGun]

JHMvP schreef op woensdag 14 maart 2007 @ 18:27:
1. Hmmm...je geeft aan de de NIC's in je server allemaal 1000Mb/s aankunnen maar je lijstje geeft aan dat alleen ETH0 dit kan. En uitgerekend deze snelste poort knup je aan het WiFi ding... Kun je de snelste poort niet es gebruiken voor je switch en dus voor je LAN?

Edit; zie TommyGun in "Niet tevreden over snelheid netwerk"

2. Je switch is niet bepaald het meest profi ding wat er bestaat. Kun je niet ergens even een 1000Mb/s switchje lenen?

Ik heb net een andere, zie 3e post in dit topic.

Edit; zie ook TommyGun in "Niet tevreden over snelheid netwerk"

3. Doorvoersnelheden worden ook bepaald door de netwerkkaarten. Zijn dit onboard-NICjes? Meer info over NIC's graag!

NIC in mijn werkstation is idd onboard, maar de CPU load is ook maar 20 / 30 procent als ik volop aan het pompen ben met data.

Edit; zie TommyGun in "Niet tevreden over snelheid netwerk"

4. Hebben de NIC's in je server, allen een eigen IRQ etc?

Durf ik niet te zeggen, ben daar verder niet mee bezig geweest in de BIOS.

[ Voor 47% gewijzigd door TommyGun op 14-03-2007 19:06 ]

[Orion84]

Guru Evi schreef op woensdag 14 maart 2007 @ 18:24:
1)Zijn alle netwerkkaarten op 1000MBps ingesteld? Indien niet mogelijk, probeer alle 100MBps apparaten eruit te halen. Je switch is 10/100MBps, dus meer dan dat kun je niet verwachten. 1500kbyte/s =~ 12MBit/s, vind ik toch redelijk op een 100MBps netwerk voor een enkele transfer over verschillende layers.

Een beetje verwarrend geschreven met al die verschillende notaties. Dacht heel even dat je 1500kbyte/s omrekende naar 12MByte/s. Meestal wordt volgens mij namelijk die hoofdletter B gebruikt voor bytes en een kleine b voor bits? Maargoed, dan nog is 12Mbps natuurlijk veel te weinig voor een 100Mbps netwerk in mijn ogen? Ik heb hier veel mindere hardware staan en haal met gemak 8MByte/s over 100mbit via SMB protocol, wat dus 4 keer zo snel is.

2) Welk protocol gebruik je en wat is de CPU load tijdens de transfer. SMB is trager dan FTP bijvoorbeeld.

Ook SMB zou veel meer moeten halen als deze snelheden. CPU load enzo monitoren is dus wel eens een goed idee.

3) Je haalt bijna 100Mbps overal met NetIO vind ik toch redelijk tussen 2 punten. Als je verschillende clients een file laat downloaden tegelijkertijd, hoeveel haalt je server dan? Vind je daardoor misschien een bottleneck?

Met NetIO gaat het inderdaad wel goed, dus je netwerk(hardware) an sich is het probleem niet direct. Dus of de lees/schrijfsnelheid van je disken is in de praktijk nogal belabberd (testtooltjes kunnen daar een vertekend beeld geven), of er zit ergens anders nog een bottleneck die alleen zichtbaar is bij bepaalde protocollen, bijvoorbeeld dus CPU ofzo bij SMB.

4) Je netwerkkaarten, zijn ze allemaal goed ingesteld? Heb je de TCP instellingen in je kernel geoptimaliseerd? Jumbo-pakketten gebruikt? Tegenwoordig zijn de out-of-the-box instellingen nog steeds voor 100Mbps of lager, dus 1Gbps zou wel een beetje tweaken nodig zijn.

5) Probeer eens IPv6 ipv IPv4

Lijkt me stug dat het daaraan ligt, dan zou het met netIO ook brak moeten zijn lijkt me?

[TommyGun]

Oke ik heb 2 fouten gemaakt. Even op een rijtje;

eth1 = waar het internet binnen komt. Dit blijkt mijn ooit gekochte Intel® PRO/100 S Server Adapter te zijn. Dus dat is een 100 MBps kaart.

eth2 = de NIC waarop de switch zit aangesloten. Dit is een onboard NIC, en blijkt tevens 100 MBps te zijn! Mobo specs geeft het volgende; Onboard Intel Pro/100+ (82559). Ik dacht dus dat deze 1000 MBps was.

eth0 = de NIC waaraan de WLAN router hangt, en is dus de enige 1000 MBps NIC. Dit is een Intel A51562-008 (64bit PCI 66Mhz, E-G021-01-3932CB). Van deze kaart heb ik nog een 2e examplaar liggen, waarvan ik dacht dat die in de server zat (als eth1), maar dat blijkt dus die Intel te zijn.

(Waarschijnlijk zit die Intel erin omdat die geconfigd is met Chello, aangezien je met Chello niet zomaar een andere NIC kunt gebruiken. Je moet dan namelijk weer stappen in *Windows* doorlopen voor het registreren van een MAC en weet ik 't allemaal.)

Beste zou dus zijn, in mijn ogen, om die onboard NIC te disablen, en de 2e 1000 MBps NIC in de server te plaatsen. Deze zou ik dan aan de switch kunnen binden, die ik dan ook zou moeten vervangen door een 1000 MBps switch. Helaas is mijn ervaring met CC dat deze alles door elkaar gooit als je een NIC weghaalt of erbij plaatst. Dan kan eth0 zomaar eth2 zijn en ga zo maar door. Daar heb ik al veel stress mee gehad.....

Heb mijn vorige posts en de start post aangepast, zodat er geen verwarring ontstaat

[ Voor 3% gewijzigd door TommyGun op 14-03-2007 19:08 ]

[JHMvP]

Betreft nieuwe switch; óók Netgear is niet bepaald de meest profi switch die je zou kunnen gebruiken...

Anyway, ik begrijp eigenlijk helemaal de zin niet van die drie NIC's in je server. Het is toch maar een héél klein netwerkje? Of is het meer als experiment bedoeld?

Waarom niet;
- onboard 100Mbps NIC gebruiken om aan je internet-router te knopen
- die 1000Mbps NIC in de server laten zitten, daar een (redelijke) switch achter zetten en daarachter weer de WiFi-router en de bedrade PC's
- die derde NIC eruit

Persoonlijk zou ik het denk ik gewoon met één 1000Mbps NICje in de server doen, maar ik weet niet in hoeverre zo'n Chello-modem een goede firewall bezit.

[Romke]

Chello modem = modem
Geen firewall dus.

Adsl modems zijn vaak routers en modem in 1, dus daar kun je van een firewall spreken.
Ik zie inderdaad ook het nut van die 3e netwerkkaart niet, als je dat dan al voor wifi wil gebruiken, pak dan een goeie wlan kaart en stel die als AP in

Met goed bedoel ik dus Senao (goeie linux support), of Linksys, Cisco oid.
Ook spul met een Ralink chipset werkt goed met linux.

[ Voor 18% gewijzigd door Romke op 15-03-2007 10:41 ]

[Orion84]

JHMvP schreef op donderdag 15 maart 2007 @ 10:25:
Betreft nieuwe switch; óók Netgear is niet bepaald de meest profi switch die je zou kunnen gebruiken...

Via NetIO haalt ie prima 100Mbps, dus aan z'n switch ligt het niet echt lijkt me. En Netgear is misschien geen professioneel merk, maar echt geen rotzooi. Sowieso is er met de meeste switches niet al te veel mis qua throughput. Hoogstens qua bestendigheid tegen grote netwerken (te kleine mac tabellen enzo) en andere exotische dingen waar je thuis weinig last van hebt.

Anyway, ik begrijp eigenlijk helemaal de zin niet van die drie NIC's in je server. Het is toch maar een héél klein netwerkje? Of is het meer als experiment bedoeld?

Waarom niet;
- onboard 100Mbps NIC gebruiken om aan je internet-router te knopen
- die 1000Mbps NIC in de server laten zitten, daar een (redelijke) switch achter zetten en daarachter weer de WiFi-router en de bedrade PC's
- die derde NIC eruit

Op de manier waarop hij het nu heeft kan hij WLAN en LAN veel stricter gescheiden houden. Geen idee of ie dat op dit moment ook doet, maar met de nog altijd enigzins twijfelachtige beveiligingskwaliteit van WiFi is dit opzich nog niet zo'n verkeerd idee, om WLAN in een apart subnet te zetten, evt. met een extra firewall etc.

Persoonlijk zou ik het denk ik gewoon met één 1000Mbps NICje in de server doen, maar ik weet niet in hoeverre zo'n Chello-modem een goede firewall bezit.

Chello modem heeft helemaal geen firewall of routing ofzo. Modem/Routers zoals bij ADSL zie je (nog) niet bij kabelinternet

[TommyGun]

Orion84 schreef op donderdag 15 maart 2007 @ 10:42:
[...]
Via NetIO haalt ie prima 100Mbps, dus aan z'n switch ligt het niet echt lijkt me. En Netgear is misschien geen professioneel merk, maar echt geen rotzooi. Sowieso is er met de meeste switches niet al te veel mis qua throughput. Hoogstens qua bestendigheid tegen grote netwerken (te kleine mac tabellen enzo) en andere exotische dingen waar je thuis weinig last van hebt.

Zoals ik eerder aangaf (TommyGun in "Niet tevreden over snelheid netwerk") had ik wat foutjes gemaakt, maar toch bijf ik het vreemd vinden.... want de speeds die ik haal zijn mijn inziens aan de lage kant, ook al draait het dan op 100MBps. NetIO is inderdaad gewoon prima, maar met data overpompen (WinSCP) gaat het nou niet echt bepaald snel. (Zie snelheden in de start post).

[...]
Op de manier waarop hij het nu heeft kan hij WLAN en LAN veel stricter gescheiden houden. Geen idee of ie dat op dit moment ook doet, maar met de nog altijd enigzins twijfelachtige beveiligingskwaliteit van WiFi is dit opzich nog niet zo'n verkeerd idee, om WLAN in een apart subnet te zetten, evt. met een extra firewall etc.

Exact, ik hou dingen graag gescheiden, is netter en overzichtelijker.

Chello modem heeft helemaal geen firewall of routing ofzo. Modem/Routers zoals bij ADSL zie je (nog) niet bij kabelinternet

Chello modem is een Chello modem, inderdaad geen firewall, routing of wat dan ook. Dus echt overkill is dit niet Server heeft namelijk andere doelen dan alleen het netwerk delen, dus die had ik zoiezo een nodig. Ik heb geen goede ervaringen met routers (Sweex, E-Tech, Edimax en ook een bugged Linksys) als het gaat om zeer veel connecties, die mijn server met gemak trekt.

Kleine toevoeging

1 gb bestand die ik download vanaf mijn server (TorrentFlux) geeft het volgende;



Klimt niet verder op, blijft schommelen rond de 2200 / 2500 kb's

[ Voor 8% gewijzigd door TommyGun op 15-03-2007 15:46 ]

[JHMvP]

Lijstje met suggesties;

• Controleer of je SCSI-kaart in de server op full-speed draait. Als je bijvoorbeeld een SCSI-I tapedrive of oude CD-Rom speler hebt aangesloten of slecht hebt geterminated, kan de hele bus naar 3,3MB/s zakken
• Controleer in je server of SCSI-kaart, IDE-controller en NIC's unieke IRQ's hebben
• Controleer of *alle* harddisks op UMDA66 draaien (plus 80-aderige IDE-kabel en MS patches)
• Controleer of *alle* systemen de meest recente chipset-drivers hebben
• Controleer of *alle* NIC's de meest recente drivers hebben
• Controleer of *alle* virusscanners en P2P-progs uit staan
• Controleer of *alle* NIC's op autosensing staan
• Controleer of TCPIP je *enige* protocol is

Zet alleen je server aan en één PC, test opnieuw, ook met *meerdere* grote ftp-transfers tegelijk.

Wordt het niet beter, dan ga ik er van uit dat de kwaliteit van je bekabeling de bottleneck is...je zou dan even kunnen testen met een crosscable tussen server en PC. Als je dan nog steeds meent dat je bekabeling goed is, dan zou je eens een filetransfer van RAM-disk naar RAM-disk kunnen proberen...gaat dat dan sneller, dan is één of meerdere schijven je bottleneck.

[ Voor 26% gewijzigd door JHMvP op 16-03-2007 10:15 ]

[lier]

Je kan bij wijze van test ook nog Atto benchmark draaien op de netwerkschijven. Als je netwerkschijven hebt aangemaakt op je clients, dan kan je deze ook selecteren in Atto.

[TommyGun]

JHMvP schreef op vrijdag 16 maart 2007 @ 09:37:
Lijstje met suggesties;
[list]
• Controleer of je SCSI-kaart in de server op full-speed draait. Als je bijvoorbeeld een SCSI-I tapedrive of oude CD-Rom speler hebt aangesloten of slecht hebt geterminated, kan de hele bus naar 3,3MB/s zakken

Geen tapedrive, wel een CD-ROM speler.

Stukje uit dmesg;

code:

SCSI subsystem initialized
ACPI: PCI interrupt 0000:00:05.0[A] -> GSI 17 (level, low) -> IRQ 177
ACPI: PCI interrupt 0000:00:05.1[B] -> GSI 18 (level, low) -> IRQ 185

scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36
        <Adaptec aic7899 Ultra160 SCSI adapter>
        aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs

scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36
        <Adaptec aic7899 Ultra160 SCSI adapter>
        aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs

megaraid cmm: 2.20.2.6 (Release Date: Mon Mar 7 00:01:03 EST 2005)
megaraid: 2.20.4.6 (Release Date: Mon Mar 07 12:27:22 EST 2005)
megaraid: probe new device 0x101e:0x1960:0x1028:0x0493: bus 14:slot 0:func 0
ACPI: PCI interrupt 0000:0e:00.0[A] -> GSI 19 (level, low) -> IRQ 225

megaraid: fw version:[199A] bios version:[3.35]
scsi2 : LSI Logic MegaRAID driver
scsi[2]: scanning scsi channel 0 [Phy 0] for non-raid devices
  Vendor: DELL      Model: 1x4 U2W SCSI BP   Rev: 1.30
  Type:   Processor                          ANSI SCSI revision: 02
scsi[2]: scanning scsi channel 1 [Phy 1] for non-raid devices
scsi[2]: scanning scsi channel 2 [virtual] for logical drives
  Vendor: MegaRAID  Model: LD 0 RAID5  104G  Rev: 199A
  Type:   Direct-Access                      ANSI SCSI revision: 02
SCSI device sda: 213073920 512-byte hdwr sectors (109094 MB)
sda: asking for cache data failed
sda: assuming drive cache: write through
 sda: sda1 sda2 sda3
Attached scsi disk sda at scsi2, channel 2, id 0, lun 0

• Controleer in je server of SCSI-kaart, IDE-controller en NIC's unieke IRQ's hebben

Hm dit moet ik zeker in de BIOS checken?

• Controleer of *alle* harddisks op UMDA66 draaien (plus 80-aderige IDE-kabel en MS patches)

Euh MS patches op een Linux systeem? Of bedoel je daar iets anders mee? En het zijn SCSI disks.

• Controleer of *alle* systemen de meest recente chipset-drivers hebben

Mijn werkstation iig wel, maar dat mobo is al even oud (P4P800 Deluxe) dus laatste chipset is van 2004 volgens mij. Laptop is nog niet zo oud, maandje of 6, dus dat zal ook wel goed zijn. Lijkt me iig sterk dat het daar aan ligt.

• Controleer of *alle* NIC's de meest recente drivers hebben

Zelfde verhaal hier, mijn werkstation heeft een onboard NIC (3Com Gigabit LOM 3C940) dus ook hiervan zijn de drivers al een tikkeltje oud. Werkstation van m'n zusje gebruikt gewoon de Windows drivers voor zover ik weet, ik ga daar ook niks aan wijzigen, wil ze zelf niet en ik heb daar geen tijd / zin in.

(Ze draait toch alleen MSN dus zoiezo weinig netwerk verkeer van haar).

• Controleer of *alle* virusscanners en P2P-progs uit staan

M'n zusje gebruikt wel eens LimeWire, maar als die PC uit staat zijn de speeds nog altijd hetzelfde. Ik zelf gebruik geen P2P progs. Beide werkstations draaien overigens wel McAfee 8 nog iets. (Zo ook mijn laptop. Gelieve daar geen discussie over, heb al zoveel AV progs gehad en deze vind ik nog altijd het beste).

• Controleer of *alle* NIC's op autosensing staan

Op de server iig wel, zie topic start. Zo ook op mijn werkstation.

• Controleer of TCPIP je *enige* protocol is
[/list]

Hoe bedoel je dit?

Zet alleen je server aan en één PC, test opnieuw, ook met *meerdere* grote ftp-transfers tegelijk.

Zo gaat het hier vrijwel altijd. Zoals ik al zei, het werkstation van m'n zusje staat niet zo vaak aan, en verder ben ik de enige met computer stuff, dus dat hoef ik niet te testen.

Wordt het niet beter, dan ga ik er van uit dat de kwaliteit van je bekabeling de bottleneck is...je zou dan even kunnen testen met een crosscable tussen server en PC. Als je dan nog steeds meent dat je bekabeling goed is, dan zou je eens een filetransfer van RAM-disk naar RAM-disk kunnen proberen...gaat dat dan sneller, dan is één of meerdere schijven je bottleneck.

Lijkt me ook sterk. WLAN router zit op een originele kabel met de server, en de switch zit ook weer op een andere originele kabel met de server verbonden. De kabel tussen switch en mijn werkstation is een van goeie kwaliteit, en zelfs met een andere kabel blijft dit hetzelfde.

Bedankt voor je post

[TommyGun]

Kleine bump?

[ls470]

TommyGun schreef op zondag 25 maart 2007 @ 04:07:
Kleine bump?

Nog een suggestie da'k hier niet heb gezien: probeer zo veel mogelijk alles afzonderlijk te testen...

Log in op je server, copieer een grote file naar /dev/null en kijk hoe lang dat duurt.

Copieer daarna (eventueel een andere omdat ie niet in de cache zou zitten) via scp (en daarna eventueel via gewone ftp om te zien of het verschil geeft) een grote file naar /dev/null om te zien of het aan het gebruikte protocol ligt dat de boel zo traag gaat.

Als beide tests snel genoeg gaan weet je dus al dat't niet aan de schijf en CPU verbruik (tenzij misschien van de netwerkkaart) van de server ligt.

Sluit daarna de laptop via een gekruiste kabel (die nog niet eerder in de opstelling gebruikt is; bv. een nieuwe kabel of een kabel van een vriend waarvan je weet dat die in orde is (de kabel, niet de vriend)) aan op de server. Probeer dan de grote file te downloaden (scp en ftp).
Als dat traag gaat kun je eventueel een 'omgekeerde' test doen: download guildftpd, installeer die op de laptop en download via ftp een grote file van op de server. (controleer ondertussen het CPU gebruik).
Als dat nog traag gaat zou'k denken dat er iets mis is met de netwerkkaarten en/of met de laptop (dat laatste kun je testen door geen server te gebruiken, met de laptop naar de desktop te gaan en die guildftpd die er al op staat te gebruiken om de snelheid te testen)
Als je problemen met de netwerkkaart/kabel verdenkt kun je proberen te pingen met verschillende pakketgroottes; als grote pakketjes veel meer loss hebben dan kleine ligt't waarschijnlijk aan de hardware...

PS. Zeker op oudere hardware (die 700MHz machine) is het zeer belangrijk welke software je gebruikt voor de communicatie. Toen ik enkele jaartjes terug mijn 'nieuwe' bak kocht (A XP 2400+) heb ik snelheden liggen testen over een 100Mbit netwerkje tussen mijn nieuwe en mijn oude (Celeron 333) bak (oude bak met realtek kaartje, nieuwe netwerk in de nforce2 southbridge). Bij ftp transfer haalde ik amper 1MB/sec tot maximaal 6MB/sec afhankelijk van de software die op beide (vooral op de tragere, maar ook op de snellere) computers gebruikt werd. In windows netwerkomgeving kwam ik amper boven 1.5MB/sec op die machines.

[ Voor 15% gewijzigd door ls470 op 25-03-2007 13:57 ]

[TommyGun]

@ hierboven;

Dat /dev/null verhaal ga ik eerst even doen. Ben op dit moment een file van 5 GB aan het overpompen naar de server, en dit geeft als load zo'n 50 procent. (Command = sshd.) Dan staat er nog eentje bij van sftp-server en die geeft zo'n 7 procent load aan. Beide zijn dus voor WinSCP neem ik aan. (Die ik gebruik voor het overpompen van data).

Zal zometeen ook eens met FlashFXP naar m'n server pompen en weer terug, kijken wat dat opleverd. Over dat /dev/null, ik kan gewoon cp filenaam /dev/null doen? Of krijg ik dan geen output te zien?

Laptop / netwerk gedeelte zal ik eens een keer 's nachts doen, gewoon de kabel naar de switch eruit en direct de laptop daarop. Even tcp/ip instellingen goed zetten en testen maar. Bedankt voor je post in ieder geval.

[ Voor 8% gewijzigd door TommyGun op 25-03-2007 16:33 ]

[DukeBox]

Ik las toevallig dat je transfers met winscp (ssh) doet, winscp is gewoon traag... op de snelste servers die wij hebben haal ik over gbit vaak ook niet meer dan 5000KByte/s.
Aangezien netio proma resultaten levert moet het wel protocol gerelateerd zijn of een beperkng in het verwerken van IO na de NIC.

[TommyGun]

DukeBox schreef op zondag 25 maart 2007 @ 16:49:
Ik las toevallig dat je transfers met winscp (ssh) doet, winscp is gewoon traag... op de snelste servers die wij hebben haal ik over gbit vaak ook niet meer dan 5000KByte/s.
Aangezien netio proma resultaten levert moet het wel protocol gerelateerd zijn of een beperkng in het verwerken van IO na de NIC.

Via http gaat het sneller ja; http://www.gamergun.com/files/1/video_ts_download_tf.PNG

Zal zometeen, nogmaals, eens FlashFXP proberen. Die 5 gb file duurt nog een kwartier

[DukeBox]

b.t.w. die intel pro (+/s)'s zijn prima.. ik trek er de volle 100Mbit mee, dus als je switch maar 100mbit is heeft het weinig nut die te vervangen. Daarnaast, jouw oplossing met een apparte nic voor wireless geeft alleen maar meer bandbreedte van/naar je server, zo'n gek idee vind ik dat niet.

[TommyGun]

Dit is onvoorstelbaar;

http://www.gamergun.com/files/1/flashfxp1.PNG
http://www.gamergun.com/files/1/flashfxp2.PNG

Blijft ongeveer op de snelheid van de 2e afbeelding. Ga nu even op m'n laptop pompen, dit was m'n werkstation. Edit; laptop blijft rond de 2600 kb's, wel redelijk voor wireless lijkt me?

Server load op dit moment; tusen de 8 en 12 procent voor proftpd. Veel minder dus dan met WinSCP. Kan ik hieruit concluderen dat mijn netwerk gewoon in orde is, maar WinSCP een poep programma?

Edit 2; toch wou ik dat /dev/null verhaaltje nog even proberen, maar welk commando gebruik ik daarvoor?

code:

[root@gateway WWW]# cp 2007-03-25-WWW.tar.gz /dev/null
cp: overwrite `/dev/null'? n
[root@gateway WWW]#

[ Voor 107% gewijzigd door TommyGun op 25-03-2007 17:31 ]

[DukeBox]

Jup.. zoals ik al zei (schreef)..

[TommyGun]

DukeBox schreef op zondag 25 maart 2007 @ 17:31:
Jup.. zoals ik al zei (schreef)..

Oké dan.

Ik ben over gestapt naar WinSCP omdat deze veel fijner is met meerdere files copyen, met FlashFXP duurt het gewoon veel langer om een dir vol met kleine files over te pompen. Hoewel ze niet echt te vergelijken zijn, totaal verschillend protocol.

Maar dan weet ik genoeg lijkt me. WinSCP voor de dirretjes met filetjes en FlashFXP voor de grote files

Bedankt DukeBox

[DukeBox]

Ik zou voor de 'simpele' dingetjes toch ff samba aansteken. In de praktijk erg makkelijk omdat je er geen client voor nodig hebt e.d.

[TommyGun]

DukeBox schreef op zondag 25 maart 2007 @ 17:35:
Ik zou voor de 'simpele' dingetjes toch ff samba aansteken. In de praktijk erg makkelijk omdat je er geen client voor nodig hebt e.d.

Samba heb ik inderdaad draaien, maar alleen voor een printer op dit moment. Maar goed dat is dus gewoon even bekijken hoe en wat. Het is iig een mogelijkheid en ik weet dat dat werkt, echter werk ik liever met iets zoals WinSCP, kan ik meteen files editen / chmodden eventueel.

[ Voor 12% gewijzigd door TommyGun op 25-03-2007 17:40 ]

[DukeBox]

je kunt daarvoor er een ssh shell naast draaien maar idd, scp is dan makkelijker.

[TommyGun]

DukeBox schreef op zondag 25 maart 2007 @ 17:44:
je kunt daarvoor er een ssh shell naast draaien maar idd, scp is dan makkelijker.

Ja WinSCP is net iets simpeler dan via een SSH shell Maar bedankt voor je tips.

[ls470]

TommyGun schreef op zondag 25 maart 2007 @ 17:23:
Dit is onvoorstelbaar;

http://www.gamergun.com/files/1/flashfxp1.PNG
http://www.gamergun.com/files/1/flashfxp2.PNG


Edit 2; toch wou ik dat /dev/null verhaaltje nog even proberen, maar welk commando gebruik ik daarvoor?

cat blabla.txt > /dev/null werkt zeker... (en nee, die zegt niets, dus je moet timen hoe lang het duurt) maar blijkbaar is je probleem toch al opgelost :-)

scp en sftp zijn secure protocollen: alle data die doorgestuurd wordt moet gecrypteerd worden waardoor dit veel meer processorbelasting veroorzaakt dan gewone ftp (en dus waarschijnlijk een straffere computer nodig is, zeker als de server-software zo gescreven is dat er per connectie maar 1 CPU gebruikt wordt)

[DukeBox]

ls470 schreef op zondag 25 maart 2007 @ 18:09:
alle data die doorgestuurd wordt moet gecrypteerd worden waardoor dit veel meer processorbelasting veroorzaakt

Dat is wel zo, maar zelfs al wordt de cpu maar voor 5% gebruikt, wil scp gewoon niet sneller.
Ook met hele 'straffe' computers..