Vraag & Antwoord

OS Linux

[SuSE Linux 9.3] eth1394 netwerk

16 antwoorden
  • Omdat een eth1394 netwerk sneller is dan een ethernet netwerk, heb ik dit geprobeerd. PC1: Athlon XP 1700+ met 512 MB RAM. PC2: Dual Pentium III 1000 Mhz met 512 MB RAM. Ik heb de beide eth1394 geconfigureerd met een statisch IP adres. Deze zijn aangesloten via een in de winkel gekochte kant en klare eth1394 kabel van ongeveer 3 meter lang. Als ik vanaf PC2 inlog in SuSE Linux 9.3 op PC1 via [code:1:e0aa75f45e] fish://<IP adres eth1394 van PC1> [/code:1:e0aa75f45e] en een bestand van circa 638 MB probeer te kopiëren van PC1 naar PC2 dan begint het kopiëren wel, maar wordt na enige tijd onderbroken. Er is dan slechts een klein deel van dat bestand gekopieerd. Bovendien was de kopieer snelheid te laag. Op het moment dat het kopiëren is onderbroken, is PC1 niet meer te pingen. Op PC1 is echter alles nog in orde. Dus lijkt het erop dat de eth1394 driver op PC2 is gecrashed. Maar ik weet dit niet zeker. Op PC2 is overigens wel voldoende schijf ruimte voor dat bestand van 638 MB. Het merkwaardige is dat als ik PC2 opstart in Slackware 10.1 (getest met SMP kernel 2.6.10 en 2.6.11.8) terwijl PC1 nog steeds in SuSE Linux 9.3 is, dat het kopiëren van die circa 638 MB bestand naar PC2 dan wel lukt. En wel met de juiste snelheid. Deze snelheid circa 7 Mbytes/sec komt ongeveer overeen met die in Windows XP. Als ik daarentegen in SuSE Linux 9.3 vanuit PC1 via fish inlog op de IP adres eth1394 van PC2 eveneens opgestart met SuSE Linux 9.3, dan kan ik die circa 638 MB bestand wel kopiëren vanaf PC2 naar PC1. Maar nog wel te langzaam. Circa 3.5 Mbytes/sec. Wat zou de verklaring kunnen zijn dat SuSE Linux 9.3 (SMP) minder goed lijkt te werken met een firewire netwerk dan Slackware 10.1?
  • misschien totaal niet relevant, maar ik heb wel eens gehoord dat het commando [i:ec237aebec]sync[/i:ec237aebec] er voor zorgt dat de door de kernel gebufferde gegevens geforceerd worden weggedrukt over de verbinding, waardoor het allemaal was sneller gaat. Max
  • [quote:30e386206c="maximilaan"]misschien totaal niet relevant, maar ik heb wel eens gehoord dat het commando [i:30e386206c]sync[/i:30e386206c] er voor zorgt dat de door de kernel gebufferde gegevens geforceerd worden weggedrukt over de verbinding, waardoor het allemaal was sneller gaat.[/quote:30e386206c] sync schrijft buffers weg die aan het filesystem gerelateerd zijn.
  • Klopt, en dat schijnt ook te werken met gemounte filesystems op afstand over en netwerk Ik zie overigens dat jolo gebruik maakt van fish. Dat kan ook de bottleneck zijn, probeer het eens met ssh zelf... Max
  • [quote:516b649b09="maximilaan"]Klopt, en dat schijnt ook te werken met gemounte filesystems op afstand over en netwerk Ik zie overigens dat jolo gebruik maakt van fish. Dat kan ook de bottleneck zijn, probeer het eens met ssh zelf... [/quote:516b649b09] Ik ken KDE niet echt, maar verbindingen met fish zijn afaik niet echt gemount. Daarnaast zijn de meeste network filesystems waarschijnlijk synchroon gemount, gezien de onbetrouwbaarheid van netwerkverbindingen.
  • [quote:4d6001f050="maximilaan"]Ik zie overigens dat jolo gebruik maakt van fish. Dat kan ook de bottleneck zijn, probeer het eens met ssh zelf...[/quote:4d6001f050] Dat ik fish gebruik in Konqueror is vooral omdat deze extra info geeft, zoals de kopieer snelheid. Ik heb het inmiddels met ssh geprobeerd. [code:1:4d6001f050] ssh <IP adres eth1394 van PC1> [/code:1:4d6001f050] en [code:1:4d6001f050] jolo@linux:~/Downloads> cp -av valhalla-i386-disc1.nrg /home/jolo/ `valhalla-i386-disc1.nrg' -> `/home/jolo/valhalla-i386-disc1.nrg' [/code:1:4d6001f050] na ongeveer 1 minuut 25 / 1 minuut 30 kreeg ik de Linux prompt weer terug. Het leek even mislukt te zijn. Want in Konqueror die open stond, en direct nadat ik de kopieer opdracht had gegeven, het te kopiëren bestand toonde, gaf nadat het kopiëren was voltooid, niet de volledige grootte aan. Nadat ik die map in Konqueror nogmaals liet herladen, toonde deze wel de juiste grootte. Dus kopiëren via ssh werkt dus wel op de juiste snelheid. Wellicht is fish inderdaad minder betrouwbaar. Maar dat verklaart nog niet waarom fish dan wel goed werkte in Slackware 10.1.
  • [quote:3b1f85524b="danieldk"] Ik ken KDE niet echt, maar verbindingen met fish zijn afaik niet echt gemount. [/quote:3b1f85524b] Klopt, fish is een wrapper rond SSH Ik was dus even abuis :) [quote:3b1f85524b] Daarnaast zijn de meeste network filesystems waarschijnlijk synchroon gemount, gezien de onbetrouwbaarheid van netwerkverbindingen.[/quote:3b1f85524b] Niet helemaal waar, er blijken genoeg bedrijven te zijn die het niet synchroon mounten (onwetendheid misschien? Gevolg in kde is dat de verzending op een of andere reden steeds langzamer verloopt.. Rinse
  • [quote:9ef213ef33="jolo"]Dat ik fish gebruik in Konqueror is vooral omdat deze extra info geeft, zoals de kopieer snelheid. Ik heb het inmiddels met ssh geprobeerd. [code:1:9ef213ef33] ssh <IP adres eth1394 van PC1> [/code:1:9ef213ef33] en [code:1:9ef213ef33] jolo@linux:~/Downloads> cp -av valhalla-i386-disc1.nrg /home/jolo/ `valhalla-i386-disc1.nrg' -> `/home/jolo/valhalla-i386-disc1.nrg' [/code:1:9ef213ef33] [/quote:9ef213ef33] Het lijkt erop dat ik deze test niet meer kan herhalen. Toen ik in die test inlogde via ssh, toonde df de partities van pc2, zodat ik bestanden vanaf pc1 naar pc2 kon kopiëren. Nu toont df na het inloggen op pc2, de partities van pc2. Het zou moeten kunnen met [url=http://www.osplatform.nl/techniek/ssh/scp_man.html]SCP.[/url] Maar dit heb ik de vorige keer niet gebruikt. Verder schijnt SuSE 9.3 problemen te hebben met twee netwerkkaarten. In dit geval dus een 3com netwerkkaart en die eth1394 netwerkkaart. Als het goed werkt wordt deze op pc1, dan is de output van /sbin/ifconfig [code:1:9ef213ef33] eth0 Link encap:UNSPEC HWaddr 00-00-4C-01-07-00-00-2F-00-00-00-00-00-00-00-00 inet addr:192.168.0.200 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:232 errors:0 dropped:0 overruns:0 frame:0 TX packets:187 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:24792 (24.2 Kb) TX bytes:27112 (26.4 Kb) eth1 Link encap:Ethernet HWaddr 00:0A:5E:22:7C:06 inet addr:192.168.1.12 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::20a:5eff:fe22:7c06/64 Scope:Link UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1 RX packets:36 errors:0 dropped:0 overruns:0 frame:0 TX packets:36 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4267 (4.1 Kb) TX bytes:3479 (3.3 Kb) Interrupt:9 Base address:0xb800 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:106 errors:0 dropped:0 overruns:0 frame:0 TX packets:106 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:6675 (6.5 Kb) TX bytes:6675 (6.5 Kb) [/code:1:9ef213ef33] en in de map /etc/sysconfig/network staat [code:1:9ef213ef33] config dhcp ifcfg-eth0 ifcfg-eth-id-00:0a:5e:22:7c:06 ifcfg-lo ifcfg.template if-down.d ifroute-lo if-up.d providers scripts wireless[/code:1:9ef213ef33] Maar de volgende dag na die test die 3com netwerkkaart die werd weergegeven als eth1, toen weergegeven als eth0. De eth1394 was weg. De eth1394 module werd nog wel geladen, maar kreeg geen ip-adres meer. Het wijzigen van ifcfg-eth0 in ifcfg-eth1 hielp niet. Want toen werd de 3com kaart weer eth1. De 3com netwerkaart configuratie staat eigenlijk in die ifcfg-eth-id-00:0a:5e:22:7c:06. Om de een of andere reden kregen de dag daarna weer wel beide netwerkkaarten een ip-adres.
  • Het lijkt erop dat inmiddels eth1394 wel weer dagelijks goed lijkt te werken in SuSE Linux 9.3 op PC1. Hoe weet ik niet. Want ik heb verder niets veranderd in de eth1394 configuratie. Ik heb nu dus kopiëren van bestanden tussen PC1 en PC2 kunnen testen via commando SCP. Vanuit PC2 een bestand kopiëren van PC1 naar PC2 [code:1:7ca3eeb68c]jolo@linux:~> scp jolo@192.168.0.200:linux-2.6.11.10.tar.bz2 /home/jolo Password: linux-2.6.11.10.tar.bz2 100% 35MB 8.7MB/s 00:04 jolo@linux:~> [/code:1:7ca3eeb68c] Vanuit PC2 een bestand kopiëren van PC2 naar PC1 [code:1:7ca3eeb68c] jolo@linux:~/Downloads/yos> scp yos-i686-2.1.0-4.iso jolo@192.168.0.200:/home/jolo Password: yos-i686-2.1.0-4.iso 100% 693MB 3.4MB/s 03:25 [/code:1:7ca3eeb68c] Zo te zien werkt dit wel. Alleen wordt nu weer wel de snelheid lager bij grotere bestanden. En nogmaals vanuit PC2 een bestand kopiëren van PC1 naar PC2 [code:1:7ca3eeb68c] jolo@linux:~> scp jolo@192.168.0.200:yos-i686-2.1.0-4.iso /home/jolo Password: yos-i686-2.1.0-4.iso 95% 660MB 0.0KB/s - stalled - [/code:1:7ca3eeb68c] En toen ging er dus toch nog iets mis. Op dat moment is PC1 niet meer te pingen [code:1:7ca3eeb68c] ping 192.168.0.200 PING 192.168.0.200 (192.168.0.200) 56(84) bytes of data. From 192.168.0.100 icmp_seq=1 Destination Host Unreachable From 192.168.0.100 icmp_seq=2 Destination Host Unreachable From 192.168.0.100 icmp_seq=3 Destination Host Unreachable From 192.168.0.100 icmp_seq=5 Destination Host Unreachable From 192.168.0.100 icmp_seq=6 Destination Host Unreachable From 192.168.0.100 icmp_seq=7 Destination Host Unreachable --- 192.168.0.200 ping statistics --- 10 packets transmitted, 0 received, +6 errors, 100% packet loss, time 9000ms[/code:1:7ca3eeb68c] En PC1 is niet down. Die draait nog gewoon. Heeft iemand nog suggesties?
  • Ik ben weer verder gegaan met testen. Maar eerst nog even dit. Ik zie nu pas dat er een foutje in mijn opening post staat. :oops: [quote:1fd995f702="jolo"] Als ik daarentegen in SuSE Linux 9.3 vanuit PC1 via fish inlog op de IP adres [b:1fd995f702] eth1394 [/b:1fd995f702] van PC2 eveneens opgestart met SuSE Linux 9.3, dan kan ik die circa 638 MB bestand wel kopiëren vanaf PC2 naar PC1. Maar nog wel te langzaam. Circa 3.5 Mbytes/sec. [/quote:1fd995f702] Daar had moeten staan: Als ik daarentegen in SuSE Linux 9.3 vanuit PC1 via fish inlog op de IP adres [b:1fd995f702] 3Com netwerkkaart [/b:1fd995f702] van PC2 eveneens opgestart met SuSE Linux 9.3, dan kan ik die circa 638 MB bestand wel kopiëren vanaf PC2 naar PC1. Maar nog wel te langzaam. Circa 3.5 Mbytes/sec. Daar heb ik mee verder getest. Dus PC1 en PC2 in SuSE 9.3. Maar nu met het SCP commando [code:1:1fd995f702] jolo@linux:~> scp jolo@192.168.1.12:valhalla-i386-disc1.nrg /home/jolo Password: valhalla-i386-disc1.nrg 100% 638MB 4.3MB/s 02:27 [/code:1:1fd995f702] Dan wordt wel het volledige bestand gekopieerd. Maar wat je niet kunt zien aan deze output, is dat de kopieer snelheid begint met 10MB/s. Nadat 100 a 200 MB is gekopieerd, begint de kopieer snelheid te zakken naar 4.3MB/s. Ditzelfde bestand van 638 MB kopiëren van PC1 naar PC2 beide in Windows XP via het Firewire netwerk duurt ongeveer 1 minuut. En via de 3Com netwerkkaart ongeveer 1 minuut en 7 seconden. SuSE 9.3 doet er met die 2 minuten en 27 seconden er toch minstens 2 maal zolang over. In een [url=http://forum.computertotaal.nl/phpBB/viewtopic.php?t=142819&highlight=netwerk+linux]discussie in sub-forum OS Windows[/url] beweerde iemand, dat het kopiëren via een netwerk in Linux sneller zou gaan dan in Windows. Maar dat zal ongetwijfeld wel in een andere Linux distributie zijn geweest dan SuSE. Het volgende is ook nog belangrijk: het crashen van de netwerk verbinding gebeurt dan wel alleen in een SuSE 9.3 > SuSE 9.3 eth1394 netwerk, bij het kopiëren van grote bestanden. Maar de afnemende kopieer snelheid bij het kopiëren van grote bestanden, gebeurd ook bij het kopiëren van datzelfde 638 MB bestand van een NTFS partitie naar de ReiserFS 3.6 partitie in SuSE 9.3 op PC1. Deze begint met een snelheid van 25 MB/sec en eindigt met snelheid van ongeveer 5 MB/sec. Het kopiëren van dat 638 MB bestand duurt dan ongeveer 1 minuut en 45 seconden. Het kopiëren van een 35 MB bestand duurt dan ongeveer 2 seconden.
  • Ik heb intussen nog wat kunnen testen. Het mijn gewoonte bij het installeren van een nieuwe versie van SuSE, dat ik ook nog over de vorige versie blijf beschikken. Dus SuSE 9.2 staat ook nog op beide pc's. Ik heb in SuSE 9.2 twee dingen getest. Het kopiëren van die 638 MB bestand van een NTFS partitie naar de ReiserFS 3.6 partitie. Dat duurde circa 45 seconden. En de netwerk test met de 3Com netwerkkaarten tussen PC1 SuSE 9.2 > PC2 SuSE 9.2. [code:1:6f1ad20987] jolo@linux:~> scp jolo@192.168.1.12:valhalla-i386-disc1.nrg /home/jolo Password: valhalla-i386-disc1.nrg 100% 638MB 7.5MB/s 01:25 [/code:1:6f1ad20987] Het lijkt erop dat de nieuwe SuSE 9.3 dus trager is geworden dan SuSE 9.2 bij het kopiëren van grote bestanden. Waarom weet ik nog niet. Alleen de test met de eth1394 in SuSE 9.2 heb ik niet kunnen uitvoeren. Deze is mislukt. Ofschoon beide eth1394 wel een statisch IP kregen, (zelfde als in SuSe 9.3) en deze wel naar de eigen IP adres konden pingen, kon er niet worden gepingt tussen PC1 en PC2 of andersom.
  • Die snelheid die je noemt in je eerste post (7mb/s) die "goed" zou moeten zijn, is nogsteeds langzamer dan de +/- 9Mb/s die gehaald word op mijn 3com ethernet kaartjes, dus waar is firewire dan sneller in? enfin, heb je je hdparm settings al geprobeerd na te kijken, als je harde schijf de data niet weg kan schrijven op minstens de netwerk snelheid, word de snelheid op den duur langzamer bij grotere bestanden, door het vollopen van buffers, en kan zelfs helemaal stoppen, zoals jij geloof ik ziet gebeuren.
  • [quote:a3213718a5="Tekkie"]Die snelheid die je noemt in je eerste post (7mb/s) die "goed" zou moeten zijn, is nogsteeds langzamer dan de +/- 9Mb/s die gehaald word op mijn 3com ethernet kaartjes, dus waar is firewire dan sneller in? [/quote:a3213718a5] Ik had verwacht dat firewire 2 maal sneller zou zijn dan een gewone netwerkkaart. Maar is in die test onder Windows XP slechts 10 % sneller dan die 3Com netwerkkaart. Ik had die eth1394 en 3Com netwerkkaart test ook nog wel in Slackware 10.1 op beide pc's willen doen met SSH en SCP. Maar dan volgt de melding [code:1:a3213718a5] jolo@linux:~$ ssh 192.168.1.12 ssh: connect to host 192.168.1.12 port 22: Connection refused [/code:1:a3213718a5] In beide Slackware 10.1 op PC1 en PC2 staat in /etc/hosts.deny [code:1:a3213718a5] ALL: ALL [/code:1:a3213718a5] en in /etc/hosts.allow [code:1:a3213718a5] ALL : 127.0.0.1 # ALL: ALL: DENY sshd: ALL: ALLOW sshd2: ALL: ALLOW[/code:1:a3213718a5] Ik heb dus vanuit Slackware 10.1 via SSH en SCP alleen toegang tot SuSE 9.3 in 1 richting. [quote:a3213718a5="Tekkie"] enfin, heb je je hdparm settings al geprobeerd na te kijken,[/quote:a3213718a5] In SuSE 9.3 staat dma al standaard aan. Op PC1 met een 200 GB WDC harde schijf in SuSE 9.3 [code:1:a3213718a5] linux:/home/jolo # hdparm -t /dev/hda /dev/hda: Timing buffered disk reads: 84 MB in 3.04 seconds = 27.63 MB/sec linux:/home/jolo # [/code:1:a3213718a5] Op PC2 met 2 WDC harde schijven van 80 GB in SuSE 9.3 [code:1:a3213718a5] /dev/hda: Timing buffered disk reads: 140 MB in 3.01 seconds = 46.46 MB/sec linux:/home/jolo # hdparm -t /dev/hdc /dev/hdc: Timing buffered disk reads: 124 MB in 3.00 seconds = 41.33 MB/sec linux:/home/jolo # hdparm -t /dev/hdc [/code:1:a3213718a5] In Slackware 10.1 zijn de hdparm -t /dev/hdX resultaten op beide pc's hetzelfde als in SuSE 9.3.
  • Probeer het eens met een bestand dat kleiner is dan je heoveelheid RAM in beide machines, dan weet je zeker dat'ie alles in RAM kan houden en heb je niks met disks te maken. Ik weet niet zeker of Linux er ook voor kiest om in zo'n geval alles in het RAM te houden, of toch naar de harddisk gaat schrijven...
  • [quote:c088845bd0="lckarssen"]Probeer het eens met een bestand dat kleiner is dan je heoveelheid RAM in beide machines, dan weet je zeker dat'ie alles in RAM kan houden en heb je niks met disks te maken. Ik weet niet zeker of Linux er ook voor kiest om in zo'n geval alles in het RAM te houden, of toch naar de harddisk gaat schrijven...[/quote:c088845bd0] Waarom zou GNU/Linux bij kleinere bestanden niks naar de harde schijf schijven? Dit is een test van een 180 MB bestand gekopieerd via de 3Com netwerkkaarten in SuSE 9.3 > SuSE 9.3 [code:1:c088845bd0] jolo@linux:~> scp jolo@192.168.1.12:ubcd32-full.iso /home/jolo Password: ubcd32-full.iso 100% 180MB 10.0MB/s 00:18[/code:1:c088845bd0] 209 MB bestand [code:1:c088845bd0] jolo@linux:~> scp jolo@192.168.1.12:Mandriva-Linux-2005-Limited-Edition-Extra-Drivers.i586.iso /home/jolo Password: Mandriva-Linux-2005-Limited-Edition-Extra-Drivers.i586.iso 100% 209MB 5.7MB/s 00:37 [/code:1:c088845bd0] En deze 180 MB bestand gekopieerd via eth1394 in SuSE 9.3 > SuSE 9.3 [code:1:c088845bd0]jolo@linux:~> scp jolo@192.168.0.200:ubcd32-full.iso /home/jolo Password: ubcd32-full.iso 14% 26MB 1.3MB/s - stalled -K[/code:1:c088845bd0] PC1 en PC2 hebben beide 512 MB RAM.
  • Jammer dat het geen verschil maakt. Ik dacht dat bij een bestand dat kleiner was dan je hoeveelheid RAM disk latencies geen rol spelen, omdat hij dan niet op de disk hoeft te schrijven, maar alles in RAM kan zetten en daarna rustig op schijf. Het ging mij erom om de schijf als mogelijke oorzaak uit te sluiten (hoewel je hdparm resultaten aangeven dat ze in principe snel genoeg zijn). Ik zie dat ik ook nog wat te doen heb: [code:1:6fa32fe7a8] lennart@barabas:/tmp$ scp KNOPPIX_V3.8.1-2005-04-08-EN.iso jerom:/tmp lennart@jerom's password: KNOPPIX_V3.8.1-2005-04-08-EN.iso 100% 686MB 6.1MB/s 01:52 [/code:1:6fa32fe7a8] Dit is een directe verbinding tussen twee gigabit netwerkkaartjes (1x Realtek r8169, 1x National Instruments ns83820)...

Beantwoord deze vraag

Weet jij het antwoord op deze vraag? Registreer of meld je aan met je account

Dit is een gearchiveerde pagina. Antwoorden is niet meer mogelijk.