[netwerkperformance] Snel maar met horten en stote

[Q]

Hallo,

Het volgende valt mij op: ik heb 2 redelijk snelle computers. PC A = win2k en PC B = linux met samba.

Als ik een file van 300 mb over mijn 100 mbit netwerk copieer van A naar B dan gaat dat redelijk snel (7 mb/s) maar met horten en stoten. Als het snel gaat zie ik de hd van pc B niet werken, op het moment dat ik schrijfactie zie dan gaat mijn troughput bruut naar beneden voor een paar seconden. Dus Snel..................langzaam...Snel...........lanzaam..etc.

Ik heb met hdparm mijn hd van PC B al even getuned (eerst was de performance nog slechter) , maar dit probleem blijft. Iemand een idee wat dit kan zijn?

[Verwijderd]

Wat voor netwerkkaarten heb je en hoe is de CPU belasting als ie langzaam wordt. SMB heeft overhead maar dat zou niet tot horten en stoten leiden.

[Q]

3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
00:11.0: 3Com PCI 3c905 Boomerang 100baseTx at 0xdc80. Vers LK1.1.16
***INVALID CHECKSUM 003e***


Hmm. Dat invalid checksum, zou dat het kunnen zijn? mij lijkt van niet omdat opzich de performance redelijk is. smbd lijkt wel flink wat cpu power te gebruiken tot soms 50-60 %, even begluurd via top... volgens mij ligt het aan hoe linux met data omgaat? ?

[UPDATE}

Het betreft hier alleen schrijf-acties die met horten en stoten gaan. Lezen gaat continue 7 mb/s zonder problemen. Schrijven gaat: 6 mb/s (hd lampje uit, blijkbaar caching) vervolgens cache wegschrijven en zo'n 100 kb/s - 1 mb/s voor een paar seconden. Wat gaat er mis? Heb reiserfs geprobeerd, en ook ext3, maar maakte niets uit.

[Verwijderd]

heb je ook de optie

socket options =

in je smb.conf staan.

Wat heb je daar als waarde neergezet? Als je deze waarde te hoog instelt of te laag dan wil je preformance van schrijf of leesacties wel eens heel hard dalen.

[Verwijderd]

Ik neem aan dat 32bits en DMA aan staan bij je harde schijf. Dus daar zou het dan niet aan liggen. Staan die niet aan is dat het eerste waar je naar zou moeten kijken.

Die checksum zegt me niks maar ik denk niet dat dat de oorzaak van je probleem zou zijn. Het treedt met name op wanneer je wilt gaan schrijven naar je hd.

Welke kernel en heb je ook al eens gekeken naar een aantal kernelpatches zoals de preemptive kernel patches van Robert Love? En zo zijn er nog een aantal meer patches die wellicht de performance wat zouden kunnen opkrikken.

[deadinspace]

lama

[Q]

Gebruik een kant en klare kernel. Zonder preemtive spul. Denk ook niet dat dit het zal zijn. Het is iets waardoor linux de data vanuit het netwerk niet meteen netjes in een continue tempo naar de hd doorsluist, maar opkropt, en dan naar de hd uitspuugt, die dan ff op topsnelheid moet werken en tijdelijk dus het netwerk belemmerd.

Samba: dit vond ik in de smb.conf: is hier iets aan te bespeuren?

socket options = IPTOS_LOWDELAY TCP_NODELAY SO_SNDBUF=4096 SO_RCVBUF=4096

[Verwijderd]

Op maandag 15 juli 2002 00:10 schreef deadinspace het volgende:
lama

Techposts aan het scoren?

[Q]

ik pomp nu ffies een file met ftp over, zelfde probleem. Het ligt dus ook niet aan samba. Linux moet gewoon meteen gaan schrijven en niet gaan hamsteren en dan op de hd kwakken. Wat kan ik hier aan doen? !? Het gaat hier dus om een schrijfactie.

[deadinspace]

Op maandag 15 juli 2002 00:15 schreef janjanjansen het volgende:
Techposts aan het scoren?

Sssst!

Ik stelde een vraag zonder eerst te refreshen... Jij had die vraag dus net ervoor al gesteld.[quote]
[b]Op maandag 15 juli 2002 00:20 schreef

het volgende:[/b]
ik pomp nu ffies een file met ftp over, zelfde probleem. Het ligt dus ook niet aan samba. Linux moet gewoon meteen gaan schrijven en niet gaan hamsteren en dan op de hd kwakken. Wat kan ik hier aan doen? !? Het gaat hier dus om een schrijfactie.

En diezelfde vraag heb jij dus nog niet beantwoord Staat DMA op je HD aan?

[Q]

Op maandag 15 juli 2002 00:35 schreef deadinspace het volgende:

En diezelfde vraag heb jij dus nog niet beantwoord Staat DMA op je HD aan?

Jep. Net vandaag de wondere wereld van hdparm ontdekt.

Timing buffer-cache reads: 128 MB in 1.51 seconds = 84.77 MB/sec
Timing buffered disk reads: 64 MB in 2.90 seconds = 22.07 MB/sec

[Verwijderd]

Net even getest via een samba share op de pc van mijn vriendin met een iso van 650 MB. De verschijnselen die jij beschrijft treden hier niet op.

Je hdparm waardes zijn niet extreem hoog, om niet te zeggen laag. Waar hebben we het hier over qua systeem?
/edit: ff wat vergelijkingmateriaal:

code:

bash-2.05a# hdparm -tT /dev/hde

/dev/hde:
 Timing buffer-cache reads:   128 MB in  0.76 seconds =168.42 MB/sec
 Timing buffered disk reads:  64 MB in  1.92 seconds = 33.33 MB/sec
bash-2.05a# hdparm /dev/hde

/dev/hde:
 multcount    = 16 (on)
 IO_support   =  1 (32-bit)
 unmaskirq    =  0 (off)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 readahead    =  8 (on)
 geometry     = 2498/255/63, sectors = 40132503, start = 0

[Q]

Betreft een pentium II 300 mhz met een ibm hd 32 gig van 2 jaar oud. (of al weer 3?) het betreft een dell optiplex gxa om precies te zijn. Ge upgrade dus met deze hd en er zit 160 mb geheugen in.

/dev/hda:
multcount = 16 (on)
I/O support = 3 (32-bit w/sync)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 4160/255/63, sectors = 66835440, start = 0
busstate = 1 (on)

Ben inmiddels ffies een nieuwe kernel speciaal voor dit systeem aan het bakken...

http://support.jp.dell.com/docs/systems/dfuj/Specs.htm

Janjanjansen: ik vind die prestaties van jouw vriendin's pc eigenlijk best wel pittig, wat voor systeem is dat? --> update ik lees t net hieronder.

[Verwijderd]

In dat geval lijken de prestaties wel goed en heb je denk ik gewoon last van cache legen op je disk.

Ik heb getest op 2 512 MB p3-1000 systemen en de benchmarks zijn van een seagate 7200 rpm disk, 3c905C en intel Pro 10/100 kaart.
/edit : ik zie nu je post, die write sync, gooit die geen roet in het eten bij I/O support ?
/edit2: typen is moeilijk

[RG]

Op maandag 15 juli 2002 00:10 schreef deadinspace het volgende:
lama

kameel

[Q]

write sync is ook niet t probleem. Ik denk dat ik maar ffies de resultaten van de nieuwe kernel moet afwachten. Vraag me echter af of t gaat helpen.

update: nieuwe kernel helpt niet dus. Ik draai debian, valt daar nog iets over te zeggen?

[Verwijderd]

Welk filesystem gebruik je op de partitie waar de data terecht komt.

Als je Ext3 gebruikt klopt het precies met wat je zegt. Die spaart de data een paar seconden op en flush dan de data naar disk en werkt de meta-data en file-data in de journal bij. Dat hoort dus zo.
Dat heeft dus geen bal met je kernel te maken. Zo werkt Ext3 nu eenmaal.

(nogmaals, mijn verhaal is alleen geldig voor ext3)

[LollieStick]

hmm.. we zijn al even verder maar ok. dit heb ik bij socket options staan:

code:

socket options = TCP_NODELAY

meer niet en ik heb geen enkel probleem met een goedkoop k*t kaartje (geen realtek want die is beter )

[Q]

De hd is in 3 partities gedeeld: 1 van ongeveer 4 gig met debian dr op. vervolgens nog een kleine partitie van een paar honderd mb voor swap en als laatste ook nog een gigantische partitie van ongeveer 28 gig waar ik data wil opslaan, los van de partitie van het OS.

Ik zie ook met ext2 het patroon van hamsteren en dan opeens alles wegschrijven. Ik snap er niets van. zou het kunnen uitmaken dat de bootpartitie, waar debian op staat ext3 geformatteerd is?

[Q]

Op maandag 15 juli 2002 01:39 schreef LinuxUser het volgende:
hmm.. we zijn al even verder maar ok. dit heb ik bij socket options staan:

code:

socket options = TCP_NODELAY

meer niet en ik heb geen enkel probleem met een goedkoop k*t kaartje (geen realtek want die is beter )

Hmm, ik zie nu een iets verbeterde doorvoer, van 6 mb/s naar 7 mb/s maar nogsteeds dat probleem van het datahamsteren.


=====
update:

Op een oude pentium 1 met een 4 gig schijf en debian, zie ik nu precies het zelfde probleem. 5 mb/s doorvoer met af en toe hiaten naar 100 kb/s of nul en dan zie je het HD lampje branden.

Als bron van het 300 mb grote bestand gebruik ik een athlon 600 mhz met 40 gig schijf (ibm) en windows 2k. Lijkt mij het probleem toch niet?!

Met ftp en het bestand verzenden tussen twee linux machines geeft ook het zelfde resultaat.

[Verwijderd]

zou het kunnen uitmaken dat de bootpartitie, waar debian op staat ext3 geformatteerd is?

Nee, als dit niet de partitie waar de data op weggeschreven wordt niet.

[deadinspace]

Welke kernel draai je eigenlijk?

[Q]

2.4.18 (apt-get install kernel-source-2.4.18)

[Q]

Okee,

Met een 2.2 kernel is het probleem over. Het betreft dus een probleem met de 2.4 kernel.

Dat verklaart ook waarom ik dit probleem ook heb met een andere machine die een 2.4 kernel heeft.

Vraag is: welke instelling in de 2.4 kernel veroorzaakt dit gesodemieter??!?!


Iemand een idee waar ik bij een linux forum ofzo of een kernel forum terecht kan??

[Verwijderd]

Je zou kunnen wachten op kernel 2.4.19. Hier hebben ze het ide spul flink onder handen genomen, en dan tot die tijd een 2.2 kernel houden.

Ik heb ook een vergelijkbare config als jij draaien. En ik heb ook lange tijd met kernel 2.4.18 gedraaid (nu weer 2.2.21), maar de problemen die jij noemt zijn mij vreemd.

[Q]

Hmm goed idee. Er is geen grote urgentie om persee 2.4 te gebruiken. Ik wilde het alleen oplossen. Ik ga gewoon ff op 2.4.19 wachten en dan met een andere bak testen.

Hmm. Die support standaard geen journaling filesystem, en dat bevalt mij totaal niet. Ik haat fsck. Ik wil wat meer veiligheid en dus ext3 / reiserfs. Dus dan toch maar 2.4. Ik zou bijna zelf in die kernel src willen klooien, maar met mijn kennis is dat het zelfde als een timmerman die een openhart operatie moet gaan uitvoeren.

Is een 2.5 kernel versie misschien een oplossing?!

[_JGC_]

Wat wel een oplossing zou kunnen zijn:
Linux kernel 2.4.19-rcnogwat met XFS

[Q]

Dat klopt, ik heb het probleem bij #kernelnewbies voorgelegd en die zeggen:

<riel> nan03: VM bug in 2.4
<nan03> Sorry, VM?
<sarnold> nan03: virtual memory system.

Dus het ligt niet aan mij. Maar inderdaad, 2.19 zou het dus moeten verhelpen. XFS, is dat al 'veilig' genoeg? Een vriend van me had een debian installatie gedaan met XFS maar dat ging niet zo best. Na een tijdje filecorruptie.

[_JGC_]

ik draai op dit moment 2.4.18 die ik met apt-get gehaald heb, heb em gepatched met xfs-1.1 van SGI en draai nu alweer bijna een maand XFS op zowel mn desktop als op mn server.
Op de server was echt noodzakelijk: ding was zo sloom als ik weet niet wat en 's nachts werd ik gewoon gek van die 5s commit interval (maakt niet uit of er geschreven wordt of niet, elke 5s een tik van die SCSI schijf )

Tot nu toe nog maar 1 probleem gehad met mn server: ik had aan mn kernel zitten kloten om een andere SCSI controller te gebruiken, en toen wou ie niet meer booten omdat er iets fout was gegaan met lilo ( LI LI LI etc...), probeer dan maar eens iets weer goed te krijgen zonder XFS bootdisk (nadeel heeft ReiserFS ook, ext3 heeft dat nadeel dus niet)

Edit: gebruik niet die XFS bootCD van Debian, maar gebruik gewoon de standaardfloppen. Als je je basesystem klaar hebt, kan je naderhand gewoon volgens de XFS site werken om je root fs op XFS over te zetten. XFS BootCD van Debian geeft hier nogal wat OOPSjes

[Q]

Op maandag 15 juli 2002 19:22 schreef _JGC_ het volgende:
...en 's nachts werd ik gewoon gek van die 5s commit interval (maakt niet uit of er geschreven wordt of niet, elke 5s een tik van die SCSI schijf )

Aha. Dus DAT is wat ik wil: ik heb een gateway met 3 gig schijf die dus ook iedere 5 seconden ofzo zijn hd accest terwijl dat helemaal niet nodig is: 99% van zn tijd heb ie geen hd nodig, dus zou apm oid wel prettig zijn. Door deze interval kan dit dus niet. XFS zou dat moeten oplossen?!

[quote]
Tot nu toe nog maar 1 probleem gehad met mn server: ik had aan mn kernel zitten kloten om een andere SCSI controller te gebruiken, en toen wou ie niet meer booten omdat er iets fout was gegaan met lilo ( LI LI LI etc...), probeer dan maar eens iets weer goed te krijgen zonder XFS bootdisk (nadeel heeft ReiserFS ook, ext3 heeft dat nadeel dus niet)
[quote]

Gebruik je deze image?:

http://people.debian.org/~blade/XFS-Install/download/

update: oh, ik lees dus dat je die vooral niet moet gebruiken?! Wanneer krijg je dan oopsen?

Miscshien ook maar eens met xfs aan de slag in een later stadium om te kijken of dit hd acces gedoe kan ophouden, zodat ik die hd met een gerust hart na 5 minuten kan stilleggen. Op die manier kan ik ook wel een pc aanlaten op mijn kamer zonder die vervelende whine van de hd.

[Apache]

[quote]
[b]Op maandag 15 juli 2002 18:52 schreef

het volgende:[/b]
Dat klopt, ik heb het probleem bij #kernelnewbies voorgelegd en die zeggen:
[..]

Dus het ligt niet aan mij. Maar inderdaad, 2.19 zou het dus moeten verhelpen. XFS, is dat al 'veilig' genoeg? Een vriend van me had een debian installatie gedaan met XFS maar dat ging niet zo best. Na een tijdje filecorruptie.

riel = Rick van Riel?

[Q]

Geen idee?!

[Verwijderd]

[quote]
[b]Op maandag 15 juli 2002 15:01 schreef

het volgende:[/b]
Hmm goed idee. Er is geen grote urgentie om persee 2.4 te gebruiken. Ik wilde het alleen oplossen. Ik ga gewoon ff op 2.4.19 wachten en dan met een andere bak testen.

Hmm. Die support standaard geen journaling filesystem, en dat bevalt mij totaal niet. Ik haat fsck. Ik wil wat meer veiligheid en dus ext3 / reiserfs. Dus dan toch maar 2.4. Ik zou bijna zelf in die kernel src willen klooien, maar met mijn kennis is dat het zelfde als een timmerman die een openhart operatie moet gaan uitvoeren.

Is een 2.5 kernel versie misschien een oplossing?!

Ik snap die hype rond journaling filesystems niet zo goed. Het beschermd je niet tegen data verlies. Als je systeem ploseling down gaat, dan zorgt het alleen dat je geen fsck hoeft te draaien. Maar een fsck op mijn server (60 gig aan harddisks) duurt nog geen 5 minuten.

Ik draai nog gewoon kernel 2.2.21 met ext2. ext3 bescherm met toch niet tegen data verlies, me systeem is alleen weer wat sneller up.

Kernel 2.5 draaien is vragen om meer van dit soort onverklaarbare dingen.

[Verwijderd]

In een van mijn eerdere posts gaf ik al aan dat je zou kunnen denken aan kernelpatches zoals de preemptive kernelpatch van Robert Love.
Ik zou wachten met 2.4.19-rc* aangezien hier nogal wat IDE wijzigingen in zitten en dat tot onnodige problemen kan leiden.
XFS bevalt mij goed, ik heb mijn machine al op XFS sinds Slackware 8.1 en dat lijkt gewoon goed te werken. Het lijkt gewoon wat soepeler te werken dan bijvoorbeeld ext3 en reiserfs. Die twee laatste hadden nog wel eens de neiging bij een grote schrijfopdracht je systeem even 'vast' te zetten.

Er is een Slackware XFS bootdisk te downloaden die wel goed werkt met de installatie van Slackware (op 2 machines geen problemen gehad).

[deadinspace]

Op maandag 15 juli 2002 23:56 schreef eenprobleempje het volgende:
Ik snap die hype rond journaling filesystems niet zo goed. Het beschermd je niet tegen data verlies. Als je systeem ploseling down gaat, dan zorgt het alleen dat je geen fsck hoeft te draaien. Maar een fsck op mijn server (60 gig aan harddisks) duurt nog geen 5 minuten.

ext3 probeert wel degelijk om data te beschermen tegen inconsistencies (bovenop het beschermen van de metadata). Vooral bij de data=journal mode heeft je data een betere kans dan bij veel andere filesystems.

Kernel 2.5 draaien is vragen om meer van dit soort onverklaarbare dingen.

I second that.

[Q]

Ik blijf van 2.5 af en wacht op 2.4.19.

Journaling is geen hype. Zelfs al journal je alleen de metadata en niet de data, dan ben je al een heel stap verder dan ext2, omdat met ext2 je filesystem in het erste geval stuk kan gaan en dat gaat met een journaling fs niet meer lukken zover ik weet. (misschien moet je dan gaan gooien met je pc ) (okee, of de code is nog 'vers)

Ik mocht 1 keer op een heel ongelegen moment mijn gateway overnieuw opzetten vanwege de kunstjes die ext2 je kan flikken, toen werd mij ext3 of reiserfs aangeraden. Ik heb me dr in verdiept en ik denk dat we kunnen stellen dat ext2 gewoon zo snel mogelijk verboden moet worden en dat we over gaan naar iets 'beters'.

-----
Merkwaardig: draai net een kernel compilatie en ik jas er tevens even een gloednieuwe ghost naar die bak toe (die in dit hele verhaal de hoofdrol speeld) en wat valt me op?! nogsteeds fikse doorvoer en continue!? pas na zo'n 20-30 seconden valter een gat. Grappig, zeker omdat de hd veel gebruikt wordt door gcc en make schijft ie z'n data sneller weg ofzo?! Ik hoop dat die nieuwe 2.4 kernel er snel aan komt

[Verwijderd]

Ik gebruik hiero RH 7.2 met XFS ( boot cd bij SGI gedownload), en moet zeggen dat de performance heel goed zijn.
Mijn hdd haalde met ext3 2.6 MB/s maar het XFS haal ik wel 6,6 MB/s.
En dat nog op mijn test Notebook Armada 7400 PII 266MHZ en 4 Gig hdd, en 196MB ram.

[Q]

Snakeeye: weet je zeker dat dit niet te maken heeft met hdparm?

Vraag:

http://people.debian.org/~blade/XFS-Install/download/

Heeft iemand recente ervaringen met deze versie van de debian xfs bootcd?