Samba server met Gigabit nic toch traag

[Verwijderd]

Mijn probleem is de volgende als ik files kopieer naar mijn samba server dan zie ik dat elke paar seconde de snelheid geheel weg valt en daarna wel weer verder gaat maar.

Mijn netwerk ziet er als volgt uit:
router<---->SW<--[192.168.1.0 255.255.255.0 100mbit]-->PC's
dan weer vanaf de SW<--->Linux server [debian woody met 2 nic's 100 en 1000]
SERVER<--[192.168.2.0 255.255.255.0 1000mbit]-->Poweruser PC

mijn server routert dus tussen de twee netwerken.
Hardware in de server zit een Intel 1000mbit nic en in de power user pc een 3com 1000mbit verbonden met een crosscable (cat5e 2,5 meter lengte).

Server:
Proliant3000 dual 500Mhz 512mb ram
96GB Raid5 WU2
compac nic 100mbit (intel)
Intel nic 1000mbit

Power PC:
Asus P4C800 Deluxe 3,3Ghz 1Gb ram
onboard 3com gigabit nic

zie nu de volgende filetransfer van een groot bestand van de Power PC naar de server.

edit:
steeds weer valt de snelheid even weg!

De snelheden naar de server zijn zo rond de 30mb/s (atto) dit is op zich redelijk.
maar als ik dus een groot bestand van 3Gb kopieer naar de server dan kan ik niet met goed fatsoen een mp3tje luisteren vanaf dezelde server. Dat zou toch geen probleem moeten zijn.

Ik heb het volgende al geprobeerd:
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
en
socket options = IPTOS_LOWDELAY TCP_NODELAY
en
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=16384
read raw = yes
en in combinatie met
level2 oplocks = true

resultaat is steeds hetzelfde lagere snelheid en zelfde patroon zie plaatje steeds even stoppen.
Wel zie ik dat tijdens het kopieeren er aardig wat CPU kracht van de server wordt gevraagd. zo'n 90% terwijl mijn Power PC niet boven de 5% uitkomt.

hier is mijn smb.conf

code:

# Samba config file created using SWAT
# from 0.0.0.0 (0.0.0.0)
# Date: 2004/06/15 11:52:35

# Global parameters
[global]
    workgroup = ETHERNET
    server string = Server
    password server = 
    passwd program = /bin/passwd
    log file = /var/logs/samba/%m.log
    max log size = 100
    socket options = TCP_NODELAY IPTOS_LOWDELAY
    add user script = /usr/sbin/useradd -d /dev/null -g 100 -s /bin/false -M %u
    domain logons = Yes
    os level = 99
    preferred master = Yes
    domain master = Yes
    wins support = Yes
    ldap ssl = no
    invalid users = root
    admin users = @sysadmin
    printer admin = @sysadmin
    read only = No
    printing = cups

[homes]
    comment = Home Directories
    create mask = 0700
    directory mask = 0700

[printers]
    comment = All Printers
    path = /tmp
    create mask = 0700
    printable = Yes
    default devmode = Yes
    browseable = No

[hplj1100a]
    path = /tmp
    create mask = 0700
    guest ok = Yes
    printable = Yes
    use client driver = Yes

[netlogon]
    path = /home/netlogon
    write list = administrator
    guest ok = Yes
[shares01]
    comment = Public Shares 01
    path = /home/shares01/PublicShares

[shares02]
    comment = Public Shares 02
    path = /home/shares02/PublicShares

[ Voor 10% gewijzigd door Verwijderd op 15-06-2004 13:00 ]

[Verwijderd]

Ik zou om te beginnen kontroleren of de linespeed-settings kloppen. Stel deze bij voorkeur aan beide zijden vast in op 1000Mb/ full duplex, dan weet je zeker dat het daar niet aan ligt. Autonegotiate uitzetten, dan weet je zeker welke snelheid er gesproken wordt.

[ Voor 12% gewijzigd door Verwijderd op 15-06-2004 12:16 ]

[Verwijderd]

Verwijderd schreef op 15 juni 2004 @ 12:15:
Ik zou om te beginnen kontroleren of de linespeed-settings kloppen. Stel deze bij voorkeur aan beide zijden vast in op 1000Mb/ full duplex, dan weet je zeker dat het daar niet aan ligt. Autonegotiate uitzetten, dan weet je zeker welke snelheid er gesproken wordt.

Heb ik nu net vast gezet en getest maar dit geeft nog steeds het zelfde beeld.
Ik krijg ook netjes in het log op de debian server tezien connected 1000mbit full duplex. Ik moet zeggen dat de CPU load van de server toch iets lager ligt tussen de 40-60%

[Verwijderd]

Gaat het ook mis als je probeert te scp'en? Als je op Windows pscp (Putty scp) installeert (zie Putty website), dan kun je kijken of het aan Samba ligt, of aan de verbindingsinstellingen op lager niveau.

[Flying_Thunder]

Heb je dit alleen bij Samba of bv ook bij FTP?

[Verwijderd]

Heb je toevallig dma uitstaan op je schijven ? Had icm een msi bord ook een trage filetransfer, toen bleek dat dma uitstond. Aangezet, probleem opgelost

[Verwijderd]

Wat standaard dingen die je kunt proberen (en handig mocht je het nog gaan vragen op de Samba mailinglijst zelf, hint ;-)):

- Probeer eens een andere netwerkkabel (hogere kwaliteit)

- Je zegt dat hij elke paar seconden 'hangt'. Doe een TCPDUMP van de traffic van SAMBA (niet alleen TCP/IP dump, maar ook op protocol level van Samba).

- Gaat het andersom wel snel (dus met smbclient van de Windows 2003 machine naar de Linux bak).

- Gaat FTP'en wel snel ? (dan geen NIC/Kabel probleem)

En kun je niet beter CIFS gebruiken?

[ Voor 6% gewijzigd door Verwijderd op 15-06-2004 16:55 ]

[Barracuda]

toevallig hadden wij dit laatst ook op me werk, maar dan icm één netwerk kaart met meerdere IP adressen (en redhat)

de oplossting bij ons was;
in /etc/sysconfig/ifcfg-eth0
BOOTPROTO=none (standaard staat deze op static, na deze naar none veranderd te hebben was ons probleem verholpen)

PS. dit was niet ICM met samba maar gewoon over het algemeen

[ Voor 13% gewijzigd door Barracuda op 15-06-2004 18:55 ]

[FatalError]

zet ook eens SO_RCVBUF=16384 SO_SNDBUF=16384 bij socket options, dat doet in ieder geval geen kwaad
En installeer ook op beide pc's de laatste drivers.

[ Voor 21% gewijzigd door FatalError op 15-06-2004 19:09 ]

[Tomsworld]

Al eens geprobeerd met netcps en/of netio te testen ?

Dan test je je doorvoer zonder tussenkomst van harde schijven, dan weet je dat je kabels, switch, nics combo ok is.

[Tatsu]

hdparm -d /dev/hd[schijf] om te kijken of de desbetreffende hardeschijf of hardeschijven op UDMA staan, staat deze op 0, dan staat UDMA uit. Deze is dan te activeren door hdparm -d 1 /dev/hd[schijf].
Als dit nog niet het geval is.

[Verwijderd]

Verwijderd schreef op 15 juni 2004 @ 16:49:
Wat standaard dingen die je kunt proberen (en handig mocht je het nog gaan vragen op de Samba mailinglijst zelf, hint ;-)):

- Probeer eens een andere netwerkkabel (hogere kwaliteit)

- Je zegt dat hij elke paar seconden 'hangt'. Doe een TCPDUMP van de traffic van SAMBA (niet alleen TCP/IP dump, maar ook op protocol level van Samba).

- Gaat het andersom wel snel (dus met smbclient van de Windows 2003 machine naar de Linux bak).

- Gaat FTP'en wel snel ? (dan geen NIC/Kabel probleem)

En kun je niet beter CIFS gebruiken?

-Heb helaas op dit moment nog geen betere kwaliteit kabel dan cat5e.

-TCPDUMP ik ben niet erg bekend met dit commando kan wel een algemene dump maken maar daar staat zoveel in dat daar niet uit te komen is.

- Anders om gaat wel maar dan op 12,5% maar wel continu zonder dat hij steeds terug valt! (linux-->XP via smb)
PS ik heb in mijn netwerk geen windows 2003 machine staan. De verbinding waar het bij misgaat is tussen een windows XP (met laatste updates) en Debian Woody 3.0 (ook up to date) ik geloof alleen dat er nu een nieuwe driver uit is voor mijn gigabit nic. Ga zo checken of dit beter werkt!

- FTP wil geen grote files kopieeren dus ik via deze weg kan ik het nu even niet testen met FTP. Snap het niet geeft melding disk quota exeeded maar dat heb ik gecheckt en dat kan niet ik heb voor die ftp user geen limiet ingesteld!!

-CIFS hmm niet mee bekend...

[Verwijderd]

FatalError schreef op 15 juni 2004 @ 19:07:
zet ook eens SO_RCVBUF=16384 SO_SNDBUF=16384 bij socket options, dat doet in ieder geval geen kwaad
En installeer ook op beide pc's de laatste drivers.

Heb ik ingesteld maar geen effect!

[Verwijderd]

Tatsu schreef op 16 juni 2004 @ 02:15:
hdparm -d /dev/hd[schijf] om te kijken of de desbetreffende hardeschijf of hardeschijven op UDMA staan, staat deze op 0, dan staat UDMA uit. Deze is dan te activeren door hdparm -d 1 /dev/hd[schijf].
Als dit nog niet het geval is.

Ik heb SCSI schijven zou dit dan ook een probleem kunnen opleveren ze staan in raid 5. Ben er een beetje huiverig voor om dit comando zo maar even te gaan testen. Ik heb geen test bak met scsi schijven en gigabite nic...

Zou je me even kunnen terug posten of je hier ook een SCSI HD mee om zetten /dev/ida/c0d0p3 in mijn geval.

Het zou nl. heel goed kunnen dat de schijven niet helemaal optimaal functioneren en dat daardoor de verbinding niet goed werkt.

Heb net getest op mijn test bak of het commando daar wat weer geeft. Maar mijn Debian versie kent het hele commando niet!

[ Voor 8% gewijzigd door Verwijderd op 17-06-2004 15:59 ]

[Verwijderd]

Barracuda schreef op 15 juni 2004 @ 18:54:
toevallig hadden wij dit laatst ook op me werk, maar dan icm één netwerk kaart met meerdere IP adressen (en redhat)

de oplossting bij ons was;
in /etc/sysconfig/ifcfg-eth0
BOOTPROTO=none (standaard staat deze op static, na deze naar none veranderd te hebben was ons probleem verholpen)

PS. dit was niet ICM met samba maar gewoon over het algemeen

Dit gecheck maar Debian kent dit comando niet... OF ik kan het niet vinden..
dat zou ook nog kunnen

[Flying_Thunder]

Verwijderd schreef op 17 juni 2004 @ 15:40:
[...]
- FTP wil geen grote files kopieeren dus ik via deze weg kan ik het nu even niet testen met FTP. Snap het niet geeft melding disk quota exeeded maar dat heb ik gecheckt en dat kan niet ik heb voor die ftp user geen limiet ingesteld!!

Ehm als je er naar uploadt krijg je die melding? Dan download je toch een groot bestand vanaf je FTP? Of anders over HTTP ofzo

[Papillon]

Vertoont ie dit gedrag ook als je onder een command prompt werkt? (upload naar de server)

[VROEM!]

Verwijderd schreef op 17 juni 2004 @ 15:47:
[...]

Ik heb SCSI schijven zou dit dan ook een probleem kunnen opleveren ze staan in raid 5. Ben er een beetje huiverig voor om dit comando zo maar even te gaan testen. Ik heb geen test bak met scsi schijven en gigabite nic...

Zou je me even kunnen terug posten of je hier ook een SCSI HD mee om zetten /dev/ida/c0d0p3 in mijn geval.

Het zou nl. heel goed kunnen dat de schijven niet helemaal optimaal functioneren en dat daardoor de verbinding niet goed werkt.

Heb net getest op mijn test bak of het commando daar wat weer geeft. Maar mijn Debian versie kent het hele commando niet!

apt-get install hdparm is de oplossing. Voor veel andere commando's die niet werken gewoon apt-get install <commando> proberen, meestal heb je dan wel de juiste packages te pakken.

hdparm -d <device> kijkt alleen wat de huidige status van de schijf is. hdparm -d 1 zet dma aan, hdparm -d 0 zet dma uit. Hdparm -d is dus voor zover ik weet compleet veilig.
Ik weet niet zeker of je dit commando ineens op een array toe kunt passen. Ik verwacht eerder dat je het per schijf even moet doen.

Verwijderd schreef op 17 juni 2004 @ 15:49:
[...]

Dit gecheck maar Debian kent dit comando niet... OF ik kan het niet vinden..
dat zou ook nog kunnen

Ik zou hier eens kijken of je dit niet /etc/network/interfaces in moet voegen. De tip die je hier krijgt is een configuratie bestand aan te passen, niet om een commando in te voeren. Als ik het goed begrijp that is

Aan je antwoorden te zien ben je nog niet echt een debian expert. Misschien is het slim om ook een keer te studeren op de handleiding van http://panic.et.tudelft.nl

Veel distributies (suse, conectiva,redhat) hebben een /etc/sysconfig directory, debian gooit wat meer dingen direct onder /etc.
/etc/sysconfig/ifcfg-eth0 komt bij debian overeen met /etc/networking/interfaces, dan in dat bestandje het deel van eth0.

[ Voor 8% gewijzigd door VROEM! op 17-06-2004 18:17 ]

[VROEM!]

Oh voor ik het vergeet: Het _zou_ ook aan de windows zijde kunnen liggen. Kun je die PC samen met een andere Gbit machine een transfer laten doen? Hou zou een beetje kut zijn als je veel moeite stopt om linux te debuggen terwijl de fout aan de windows kant ligt.

[Verwijderd]

VROEM! schreef op 17 juni 2004 @ 18:13:
[...]


apt-get install hdparm is de oplossing. Voor veel andere commando's die niet werken gewoon apt-get install <commando> proberen, meestal heb je dan wel de juiste packages te pakken.

hdparm -d <device> kijkt alleen wat de huidige status van de schijf is. hdparm -d 1 zet dma aan, hdparm -d 0 zet dma uit. Hdparm -d is dus voor zover ik weet compleet veilig.
Ik weet niet zeker of je dit commando ineens op een array toe kunt passen. Ik verwacht eerder dat je het per schijf even moet doen.
[...]


Ik zou hier eens kijken of je dit niet /etc/network/interfaces in moet voegen. De tip die je hier krijgt is een configuratie bestand aan te passen, niet om een commando in te voeren. Als ik het goed begrijp that is

Aan je antwoorden te zien ben je nog niet echt een debian expert. Misschien is het slim om ook een keer te studeren op de handleiding van http://panic.et.tudelft.nl

Veel distributies (suse, conectiva,redhat) hebben een /etc/sysconfig directory, debian gooit wat meer dingen direct onder /etc.
/etc/sysconfig/ifcfg-eth0 komt bij debian overeen met /etc/networking/interfaces, dan in dat bestandje het deel van eth0.

Nou ben wellicht geen expert maar ik weet me doorgaans toch wel aardig te redden met Debian. Van dit soort specifieke problemen heb ik nog niet eerder bij de hand gehad.

Even nakijkend bij www.debian.org leerd dat dit comando alleen geschikt is voor IDE devices....... daar heb ik dus niet zo veel aan met mijn scisi schijven!

Package: hdparm (4.5-1.2)
Tune hard disk parameters for high performance.
get/set hard disk parameters for Linux IDE drives. Primary use is for enabling irq-unmasking and IDE multiplemode.

Heb hem wel geinstaleerd en test maar hdparm geeft zelf aan dat deze functie niet word ondersteund voor /dev/ida/c0d0p3 schijven!

[Verwijderd]

VROEM! schreef op 17 juni 2004 @ 22:26:
Oh voor ik het vergeet: Het _zou_ ook aan de windows zijde kunnen liggen. Kun je die PC samen met een andere Gbit machine een transfer laten doen? Hou zou een beetje kut zijn als je veel moeite stopt om linux te debuggen terwijl de fout aan de windows kant ligt.

Ik heb het nu net wel weten te testen met FTP!
Van Linux naar Power PC gaat goed constante snelheid van 12,5%
Upload van Power PC naar Linux gaat niet goed ook 12,5% maar steeds ook weer die terug val!!!

Nu is de schijf waar vandaan ik het probeer een 200Gb SATA die met atto tussende 40 en 60 mb/s haalt dus daar lijkt het me niet aan te kunnen liggen!
Iemmand nog een idee waar aan het zou kunnen liggen?

[Verwijderd]

Barracuda schreef op 15 juni 2004 @ 18:54:
toevallig hadden wij dit laatst ook op me werk, maar dan icm één netwerk kaart met meerdere IP adressen (en redhat)

de oplossting bij ons was;
in /etc/sysconfig/ifcfg-eth0
BOOTPROTO=none (standaard staat deze op static, na deze naar none veranderd te hebben was ons probleem verholpen)

PS. dit was niet ICM met samba maar gewoon over het algemeen

Verwijderd schreef op 17 juni 2004 @ 15:49:
[...]

Dit gecheck maar Debian kent dit comando niet... OF ik kan het niet vinden..
dat zou ook nog kunnen

Heb dit comando toegevoegd aan /etc/netwerk/interfaces onder de juiste adapter echter heeft dit geen effect op de preformance en lost dit mijn probleem niet op.

[Papillon]

Hmmm.. Ik zie dat je RAID 5 gebruikt op de server. Gebruik je ook toevallig ext3fs op je RAID volumes. Ik haal uit de thread niet of je software of hardware RAID5 hebt gebruikt. Er zijn vele redenen aan te duiden die deze perfomance ervaringen veroorzaken. Bijv. of een NIC op zelfde bus al PCI, of op CSA bus etc. De P4C800 Deluxe heeft zo'n 3COM 940 die dus de bus shared met PCI.

Het is sowieso al zo dat RAID5 stukken langzamer schrijft dan leest. Afhankelijk van het aantal schijven ligt de verhouding 4 op 1. Soms nog schever, tevens dien je te bedenken dat als je een journalling filesystem gebruikt, dat dat ook je (schrijf)performance niet ten goede komt. Zeker niet als die logs ook op de RAID5 volumes huizen hetgeen tot gevolg heeft dat er nog meer parity berekeningen moeten worden uitgevoerd.

Ik heb zelf ook een RAID5 set, echter van 4 IDE schijven. Momenteel ben ik aan het testen wat de impact is van het scheiden van journalling. Daarmee bedoel ik dat de journal logs niet op de RAID5 volume worden bijgehouden maar op een andere disk/volume.

[pierre-oord]

Papillon schreef op 19 juni 2004 @ 18:40:
Hmmm.. Ik zie dat je RAID 5 gebruikt op de server. Gebruik je ook toevallig ext3fs op je RAID volumes. Ik haal uit de thread niet of je software of hardware RAID5 hebt gebruikt. Er zijn vele redenen aan te duiden die deze perfomance ervaringen veroorzaken. Bijv. of een NIC op zelfde bus al PCI, of op CSA bus etc. De P4C800 Deluxe heeft zo'n 3COM 940 die dus de bus shared met PCI.

Het is sowieso al zo dat RAID5 stukken langzamer schrijft dan leest. Afhankelijk van het aantal schijven ligt de verhouding 4 op 1. Soms nog schever, tevens dien je te bedenken dat als je een journalling filesystem gebruikt, dat dat ook je (schrijf)performance niet ten goede komt. Zeker niet als die logs ook op de RAID5 volumes huizen hetgeen tot gevolg heeft dat er nog meer parity berekeningen moeten worden uitgevoerd.

Ik heb zelf ook een RAID5 set, echter van 4 IDE schijven. Momenteel ben ik aan het testen wat de impact is van het scheiden van journalling. Daarmee bedoel ik dat de journal logs niet op de RAID5 volume worden bijgehouden maar op een andere disk/volume.

Heb je dan nog wel wat aan raid5?

[Papillon]

pierre-oord schreef op 20 juni 2004 @ 06:38:
[...]


Heb je dan nog wel wat aan raid5?

Jazekers heb ik wat aan RAID5. Write acties heb ik gelukkig niet al te veel en de read performance van RAID5 is uitstekend. Maar de belangrijkste reden dat ik RAID5 gebruik is redundantie. Er mag bij mij een schijf uitvallen en ik behoud mijn data. De hinder die ik zou hebben om in een dergelijke geval de data terug te zetten (als ik bijv. RAID0 had gebruikt), we praten dan over 100'en GB's, telt bij mij meer dan de RAID5 "nadelen".

[VROEM!]

Waarom neem je niet raid 1 oid? Of evt 2 stripe sets in raid 0 die als stripes weer in raid 1 staan. Dan skip je in ieder geval die pariteitsberekeningen.

[Papillon]

Ho Ho ... Ik heb geen problemen met mijn RAID5. De thread starter heeft er problemen mee. Ik hoop dan ook dat bovenstaande bericht aan de threadstarter is gericht.

Ik kies bewust voor RAID5 vanwege prijs/performance/redundatie overwegingen. In mijn geval gaat het om een prive servertje. Dan is de overhead van RAID1 of RAID1+0 (of RAID0+1) mij te gortig. Dat zou betekenen dat ik per schijf een schijf moet "opofferen" voor de redundantie. Nu hoef ik slechts 1 schijf op te offeren. Dat vind ik voor prive gebruik acceptabel.

Het feit dat ik met de journalling (locaties) wil experimenteren heeft meer een wetenschappelijke achtergrond dan dat het echt nodig is. Ik wil graag weten welke effecten dat heeft op de (write-)performance. Wellicht dat ik deze kennis in mijn werk kan gebruiken.

[ Voor 6% gewijzigd door Papillon op 20-06-2004 11:20 ]

[Verwijderd]

Papillon schreef op 19 juni 2004 @ 18:40:
Hmmm.. Ik zie dat je RAID 5 gebruikt op de server. Gebruik je ook toevallig ext3fs op je RAID volumes. Ik haal uit de thread niet of je software of hardware RAID5 hebt gebruikt. Er zijn vele redenen aan te duiden die deze perfomance ervaringen veroorzaken. Bijv. of een NIC op zelfde bus al PCI, of op CSA bus etc. De P4C800 Deluxe heeft zo'n 3COM 940 die dus de bus shared met PCI.

Het is sowieso al zo dat RAID5 stukken langzamer schrijft dan leest. Afhankelijk van het aantal schijven ligt de verhouding 4 op 1. Soms nog schever, tevens dien je te bedenken dat als je een journalling filesystem gebruikt, dat dat ook je (schrijf)performance niet ten goede komt. Zeker niet als die logs ook op de RAID5 volumes huizen hetgeen tot gevolg heeft dat er nog meer parity berekeningen moeten worden uitgevoerd.

Ik heb zelf ook een RAID5 set, echter van 4 IDE schijven. Momenteel ben ik aan het testen wat de impact is van het scheiden van journalling. Daarmee bedoel ik dat de journal logs niet op de RAID5 volume worden bijgehouden maar op een andere disk/volume.

Ik gebruik ext2 op mijn RAID volumes.
Ik weet dat RAID 5 volumes een stuk langzaamer schijven van lezen maar dat zou toch niet de oorzaak van mijn probleem mogen zijn. Maar goed als dat wel zo mocht zijn wat kan ik er aan doen om het te verhelpen!?

[DaRealRenzel]

Je Gigabit NIC kan veel meer data doorvoeren dan je UW2 SCSI Raid Controller weg kan zetten. UW2 SCSI is 20 MBit/sec... Wat je hier ziet is dat je cache van je RAID Controller (SMART-2DH ? 16MB of 4MB) volgeschreven wordt met max capacity, waarna het systeem zelf als buffer gebruikt wordt, en dus IO Waits moet accepteren (disk not ready). Als de cache eenmaal geflushed is, gaat het weer wat sneller.....

Dus zo zie je maar, Gigabit is niet altijd sneller (of beter). In jouw geval heeft het dus geen effect of je nu een Gigabit of 100Mbit kaart gebruikt, je disks zijn te traag.

[Papillon]

U2W (Ultra 2 Wide) kan 80 MB(yte) per seconde wegzetten. Dat is snel genoeg om de PCI bus (zeker in combinatie met de Gb NIC) vol te trekken. Het verhaal met de cache is veel waarschijnlijker als oorzaak. Het kan inderdaad zo zijn dat de cache volgezet wordt en dan moet worden leeggehaald om weer goed verder te kunnen. Dat zou dan een schommelend throughput moeten geven. Dat is volgens mij ook hetgeen waar de threadstarter last van heeft.

Dat probleem zou dan op moeten treden bij bestanden die groter zijn dan de cachegrootte. Vraag is dan ook aan de threadstarter of dit probleem zich ook voordoet met bestanden van pak ehm beet 512 MB (uitgaande dat je cache vele orden kleiner is dan 512 MB)?

Mocht je dan het schommelende effect weg willen werken zul je de controller moeten vertellen dat ie write operaties gelijk wegschrijft en dan ook niet cached.

[ Voor 11% gewijzigd door Papillon op 21-06-2004 07:26 ]

[Verwijderd]

Misschien dat het hiermee te maken heeft?

[rml][ P4P800] onboard LAN TX ultratraag[/rml]

[deepbass909]

Ik ken hetzelfde probleem ook, maar dan een schaal lager. Ik gebruik een Dual Pentium Pro server, met een ServeRaid Controller van IBM (powerpc gestuurde SCSI Raid). Deze server heef t een 100mbit netwerk verbinding, maar deze wordt ook maar gedeeltelijk gebruikt. De schijven/controller/pci bus houden het simpelweg niet bij.

Het is een fabeltje om te denken dat als je een bepaalde netwerk standaard installeerd, en je alles volgens de regels doet, je ook die snelheid haalt. Als ik zijn hardware specs bekijk (cat5e is gigabit netwerkkabel), dan is alles in orde. Haalt hij die snelheid niet, dan ga ik dus kijken naar de lokale preformance. Als je realiseerd dat is tests een P4 2Ghz het al niet voor elkaar krijgt om genoeg data naar een gigabit netwerk kaart te krijgen (Pci bus is simpel weg te traag), hoe moet een PIII 500Mhz het dan in godsnaam voor elkaar krijgen???

Ik vrees dat de TS zich erbij neer moet leggen dat zijn hardware het niet aan kan.

[Verwijderd]

Sniff sniff
ik heb idd een smart 2DH controller 4mb cache. Had al zo'n vermoeden dat het welleens met mijn schijven en of controller te maken zou kunnen hebben. Maar dan denk je SCSI UW2 moet toch wel wat door voer capaciteit hebben. Maar nee dus!

Oja, dit probleem doet zich idd voor als ik grote bestanden beschrijf van meer dan pak hem beet 100 mb.

Ik ga nog eens kijken of ik de controller kan vertellen dat ik gelijk moet gaan schrijven en niet cachen... maar ja ik weet niet of die dat wel kan??? Het is al weer een oudtje

[Verwijderd]

Ik heb zelf ook vergelijkbare problemen als ik iets download van mijn win 2003 server naar mijn linux doos (momenteel Mepis maar ook ubuntu en ik dacht ook Suse 9.1).

Ik vraag mij alleen af als de problemen aan het opslag "systeem" ligt dan zou je de zelfde problemen toch verwachten wanneer je lokaal op de computer bestanden kopieert of zie ik dat fout???

[Verwijderd]

Ik heb het probleem bij mij opgelost door het vervangen van mijn hub die linux niet accepteerde als een 100baseTx-FD link partner maar dus alleen maar als 100baseTx-HD of 10baseT-HD
(FD is full en HD is half duplex)

Ik vindt het ook heel vreemd dat dit probleem verholpen wordt onder Linux door het vervangen van terwijl het netwerk onder windows goed loopt (waarschijnlijk full duplex).

[smokalot]

een hub is nu eenmaal altijd half duplex

(de populaire switching hubs niet trouwens)

[Verwijderd]

smokalot schreef op maandag 14 februari 2005 @ 12:25:
een hub is nu eenmaal altijd half duplex

(de populaire switching hubs niet trouwens)

'de populaire' switching hubs wel degelijk. Een switching hub is niets meer dan een hub met meerdere backplanes voor verschillende snelheden (10/100mbps). Je zou kunnen zeggen dat bv. een 10/100 switching hub in feite bestaat uit een 10mbit hub gekoppeld aan een 100mb hub.

Het blijven echter hubs, dus half duplex.

Pas als je een 'echte' switch koopt, is het full-duplex.

[Verwijderd]

hmm, dat wist ik niet (ict opleiding van het Zaadkine)
Dat wordt dus een switch aanschaffen.
Helaas heb ik nu wel het probleem dat wanneer ik een groot bestand over het netwerk van mijn linux doos naar mijn Windows 2003 DC stuur deze op de helft crashed. in het begin gaat het pompen rond de 30 mb per sec.
halverwegen (vermoedelijk wanneer het geheugen vol zit van de win 2003 DC) neemt de snelheid af naar ongeveer 4 MB/sec en vervolgens loopt ie na enkele minuten vast.(nog tijdens het over pompen)
De win 2003 DC doos is een Pentium 3 1 ghz met 512 MB geheugen aan boord en beschikt over een Sata schijf.
de netwerk kaart is een sweex gigabit met realtek chipset (weet momenteel niet welke)

Linux doos is, vida linux (gentoo stage 3) AMD 2200 768 met een 100Mb realtek (weet ook niet welke)
zou dit probleem veroorzaakt kunnen worden doordat de transfer mode toch verkeerd staat OID???

[smokalot]

Verwijderd schreef op maandag 14 februari 2005 @ 19:27:
[...]


'de populaire' switching hubs wel degelijk. Een switching hub is niets meer dan een hub met meerdere backplanes voor verschillende snelheden (10/100mbps). Je zou kunnen zeggen dat bv. een 10/100 switching hub in feite bestaat uit een 10mbit hub gekoppeld aan een 100mb hub.

Het blijven echter hubs, dus half duplex.

Pas als je een 'echte' switch koopt, is het full-duplex.

ik heb toch echt zo'n populaire "switch", die toch echt full duplex werkt:

code:

# mii-tool
eth0: negotiated 100baseTx-FD, link ok

Voor zover ik het begreep zijn het hubs, maar hebben ze een RX/TX buffer(tje), waardoor ze op full duplex kunnen, en je tegelijk 10mbit en 100mbit apparaten aan kunt sluiten. Kwa performance schiet je er niet veel mee op, maar het is wel prettig om niet overal terug te vallen op 10mbit zodra je er 1 aansluit.

[Parasietje]

Probeer te elimineren.

doe een cp --progress file1 /dev/null. Zo kan je zien hoe snel er van die schijf wordt gelezen mbv het bestandssysteem. Is het hier traag en in periodes, elimineer dan al problemen met samba/ftp. Probeer dan eens een raw read op de schijf (hdparm kan snelheden van schijven testen, en arrays ook denk ik... anders gewoon timen hoelang je met 'dd' erover doet om 50Mb raw te copiëren van je hd array naar /dev/null).

Denk dan pas in de richting van de netwerkkaart.