Jump to content

Dbox2 mit 10Mbit Vollduplex?


Worschter

Empfohlene Beiträge

  • Antworten 56
  • Created
  • Letzte Antwort

Top Posters In This Topic

Hallo,

danke erst mal für das Image. Ich habe bis eben getestet, getestet und noch mal getestet.

Aber leider wurden die Ergebnisse nicht besser.

Hier einfach mal was ich getan habe.

 

1. Standartimage, Box normal, Switch normal (10 hdx), mit TELNET auf Box und dann im gemounteten Verzeichnis mit cp test test2 eine ca 55MB (59547852 Byte) Datei umkopiert.

Somit wird gelesen und geschrieben zur gleichen Zeit.

Dauer: 2 min 18 Sekunden (24762 Collisonen)

Diese Zeit sollte jeder mit einen guten Switch erreichen. Mit einen einfachen Switch (Netgear, D-Link, Linkpro) hatte ich da was um die 12 min. Also scheinen mein Switche (BayStack 350, HP ProCurve 3550, Linkpro Gigabit) das ja alles richtig zu machen.

 

2. Das FDX-Image auf Box (2xI-500) gebügelt, Switch und Box noch auf hdx gelassen

Dauer 6 min 14 Sekunden

Also macht der Kernel da ja irgendwas anders.

 

3. Das FDX-Image, Switch fest auf 10 FDX, Box Pin 21 auf Masse und dann

Dauer 8 min 35 Sekunden

so hab ich das nicht erwartet.

 

Frust.. ich hab dann noch mal die Tests mit FTP auf die Box getestet. Dabei kam folgendes raus.

Standartimage und hdx beim kopieren von einen Image in /tmp: zur Box 813 kByte/sec, von Box 720 kByte/sec.

FDX-Image und Box und Switch auf FDX: zur Box 33 kByte/sec :angry: , von Box 962 kByte/sec :angry:

Also beim lesen hats was gebracht, aber das schreiben zur box hat sich so verlangsamt das es Insgesamt langsamer wird. Irgendwie will der Kernel das mit dem FDX moch nicht so Richtig.

Wärend allen Tests mit FDX war Idle (bei top) nie unter 70 %, als scheint es kein Rechenleistungsproblem zu sein.

Link zu diesem Kommentar
Auf anderen Seiten teilen

OK OK ... das kann sein. Ich habe auf dem Switch (BayStack) auch noch ein Monitorport laufen. Das kann den Unterschied 64M 2:11 zu 55M 2:18 schon aus machen. Desweiteren habe ich auch noch einen extra switsch (Giga) vor dem NFS-Server, um immer die selbe Verbindung zum Server zu haben, somit doppele Latency :angry:

Link zu diesem Kommentar
Auf anderen Seiten teilen

okee, damit kenn ich mich nun net so aus :angry:

 

beim 2ten Versuch waren es exakt 2Min 6 Sekunden für 64MB.

 

Spielt vielleicht noch ne Rolle, daß ich optimale Einstellungen hab bei mir was rsize und wsize angeht

 

mal was andres, wo Du Dich ja anscheinend so gut auskennst, weisst Du warum man bei WIN2000

kein höheres wsize als 8192 einstellen kann bzw. wo man da drehen müsste daß es geht?

Mit 2003 gehen 32768 was ungemeine Geschwindigkeitssteigerung bringt.

 

 

EDIT: autsch, ich hatte das nun auch nocch falsch verstanden, sorry!

ich dachte die 6 Minuten wären mit Standard Image und normalem Switch. Okee,

das ist natürlich dann weitaus verständlicher.

Link zu diesem Kommentar
Auf anderen Seiten teilen

leider hab ich im Moment keinen w2k rechner da. Ist mir garnicht aufgefallen das es bei w2k nicht höher geht. Ich werde aber morgen mal eine Virtuelle Maschiene mit w2k server installieren, und mal schauen was ich finde. Geht bestimmt wieder mit irgend einen reg-key.

Was ist denn dein NFS-Server. WIN oder Linux ?

HAst du Box - Switch - NFS-Server ? oder Box -Switch- Switch- NFS-Server

Link zu diesem Kommentar
Auf anderen Seiten teilen

Ach so

 

EDIT: autsch, ich hatte das nun auch nocch falsch verstanden, sorry!

ich dachte die 6 Minuten wären mit Standard Image und normalem Switch. Okee,

das ist natürlich dann weitaus verständlicher.

 

nee nee . der Versuch Nummer 2 war nur zum test ob jetzt fehler auf tauchen, weil der switch und der chip der box ja noch die collisonserkennung haber, der kernel aber nicht

 

 

 

PS. ist euch mal aufgefallen, das die Uhr im Board eine Stunde nach geht.. ?

bearbeitet von vitacola1
Link zu diesem Kommentar
Auf anderen Seiten teilen

ah ja. soweit ich sehe hab ihr versucht mit einer größeren Window-SIZE die collisonen zu vermeiden, die von den Antwortpacketen verurscht werden. Bei 8192 Bytes wäre das im Ethernet 8192 durch MTU ( 1492 bei Windows XP nicht 1500) abzüglich Overheat, alle vier bis fünf Packete nur eine Bestätigung. Jetzt wollt ihr noch versuchen das auf mehr packete zu beschränken. Ich gebe nur zu bedenken, das wenn ein packet verlohren geht das ganze "Window" wiederholt werden muß.

.. ob da zeit für ist?

bearbeitet von vitacola1
Link zu diesem Kommentar
Auf anderen Seiten teilen

ah ja. soweit ich sehe hab ihr versucht mit einer größeren Window-SIZE die collisonen zu vermeiden, die von den Antwortpacketen verurscht werden. Bei 8192 Bytes wäre das im Ethernet 8192 durch MTU ( 1492 bei Windows XP nicht 1500) abzüglich Overheat, alle vier bis fünf Packete nur eine Bestätigung. Jetzt wollt ihr noch versuchen das auf mehr packete zu beschränken. Ich gebe nur zu bedenken, das wenn ein packet verlohren geht das ganze "Window" wiederholt werden muß.

.. ob da zeit für ist?

 

:angry:

 

nun, wir haben da das bewährte Try and Error Prinzip angewendet und einfach die verschiedenen Werte durchgetestet

 

Und es liessen sich eils erhebliche Steigerungen erreichen. Aber nur bis zu nem bestimmten grad und

auch Hardwareabhängig.

Bei mir geht es am Besten mit nem wsize von 16384, drüber nimmt die Datenrate wieder ab.

Da triffts dann wohl zu dass zu viel wiederholt wird.

 

Aber so gut kenne ich mich da eh nicht aus :angry:

Link zu diesem Kommentar
Auf anderen Seiten teilen

da wäre das mit dem Fullduplex ja eine feine Sache, wenn die Antwortpackete keine Collison mehr verursachen würden.

 

jedes bisl zählt beim Streamen. Ist halt ungeschickt, wenn man dazu spezielle Hardware braucht.

 

Das Umlöten würde ich mir ja noch antuen, aber einen teuren Switch kaufen, das

ist´s fast net Wert, wenn man da bald dann ne Dreambox für bekommen würde.

 

Obwohl, da müsst man dann wieder Enigma nutz, :angry:

Link zu diesem Kommentar
Auf anderen Seiten teilen

Das..

TCPWindowSize

 

 

This value determines the maximum amount of data (in bytes) that can be outstanding on the network at any given time. It can be set to any value from 1 to 65,535 bytes by using the following registry entry:

 

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip \Parameters\TcpWindowSize (REG_DWORD)

 

The default for a gigabit interface is set to approximately 65,535 (rounded down to the nearest multiple of full TCP packets), 16,384 for a 100 Mbps link, and 8,192 for all interfaces of lower speeds (for example, modems), again rounded down. Ideally, this value should be set to the product of end-to-end network bandwidth (in bytes/s) and the round-trip delay (in seconds), also referred to as the bandwidth-delay product. This value should be set according to the amount of TCP data expected to be received by the computer.

 

 

hab ich hier gefunden

 

http://www.microsoft.com/technet/interopmi...fu/perfnfs.mspxMy Webpage

Link zu diesem Kommentar
Auf anderen Seiten teilen

hm

 

ans solchen Parametern haben wir auch schonmal gedreht, frei nach dem Motto

"und sie wussten nicht was sie tun" :angry:

 

ich hab nun im Moment auch kein Win2000 mehr laufen zum Testen,

Aber das krigen wir bestimmt irgendwie getestet.

Danke für die Mühe :angry:

 

 

und erstmal gute Nacht :angry:

 

Morgen ist auch noch ein Tag...

Link zu diesem Kommentar
Auf anderen Seiten teilen

Was kost eigentlich so ein Switch wenn man mal fragen darf smile.gif

 

Also der Hp ProCurve ca 800, der BayStck ist schon älter bekommt man aber bei ebay bestimmt schon günstig.

 

Aber der 8 Port Gigabit Switch von Linkpro hat mich 104 Nettp bei ERGOS gekostet.

Der ist echt super auch mit der box im 10 MBit modus

 

Ich wünsche dir auch eine gute Nacht !!!!

bearbeitet von vitacola1
Link zu diesem Kommentar
Auf anderen Seiten teilen

Moin :angry:

 

hm, das sind schon Preise für Hobbyisten. Ich denke das macht für mich dann auch wenig Sinn,

denn die Images sollen ja nach Möglichkeit auch mit normaler Hardware fünktionieren

Ist beim Testen schon wichtig, daß ich da "Standardkomponenten" nehm.

Manchmal schon bisl ärgerlich :angry:

 

Hab grad nmal nach dem Regkey geschaut, der existiert z.B. auf dem WIN2003

garnicht. Wenn dem auf 2000 auch so ist, dann haben wir wohl eher nicht daran

versucht. Naja, wenn ich meine neue Festplatte hab, dann werd ich mal eh ein neues System

aufsetzen müssen und kann gleich bisl Testen, wird wohl im Laufe der Woche sein.

 

 

Aber mal zurück zum Thema.

Ich hab jetzt nochmal bisl in den Sourcen rumgestöbert, aber ich glaube ohne weitere

Anleitung wird´s da schwierig für mich da überhaupt was rauszulesen.

Mir fehlts halt bisl an den Kenntnissen, auch allgemein zu dem Thema.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Moin :angry:

 

'nAbend. :angry:

 

Hab grad nmal nach dem Regkey geschaut, der existiert z.B. auf dem WIN2003

garnicht. Wenn dem auf 2000 auch so ist, dann haben wir wohl eher nicht daran

versucht.

 

Existiert schon bei Win2000, vielleicht nicht als Standard, damals mein skyDSL hat diesbezüglich irgendwelche Anpassungen an der Registry automatisch vorgenommen.

 

TcpWindowSize steht bei mir 18600 drin. Dürfte auf Direkt Streaming von der dBox sowieso nichts zu melden haben, da das ja über UDP läuft. Hab jedenfalls schon mal mit dem Wert experimentiert, das juckt die rsize-/wsize-Geschichte einen Feuchten, mehr als die 8096 für wsize geht nicht, bei der Geschwindigkeit war auch nichts zu merken.

Link zu diesem Kommentar
Auf anderen Seiten teilen

das ja über UDP läuft. Hab jedenfalls schon mal mit dem Wert experimentiert, das juckt die rsize-/wsize-Geschichte einen Feuchten, mehr als die 8096 für wsize geht nicht, bei der Geschwindigkeit war auch nichts zu merken.

 

sag das bloss nicht meinem Rechner, sonst setzt der den Wert wieder zurück und ich bekomme

schwierigkeiten beim Streamen,. :angry:

Bei mir hast das auf jeden Fal was gebracht.

Aber das kann man sich ja hier

http://www.keywelt-board.com/index.php?showtopic=47601

genauer ansehen, da stehen so gut alle meine wichtigen Testergebnisse drin.

Link zu diesem Kommentar
Auf anderen Seiten teilen

ha ... hab noch was gefunden.

Bei NFS V2 geht nur 4096 oder 8192 Read- und Write-Size, da weis ich nicht worauf sich die man-page jetzt bezieht . Erst ab v3 kann man höher gehen.

Kann der sfu nicht nur v2?

Ich suche jetzt nur noch die Option um ihn zum mount mit v3 zu bringen.

 

Siehe "man mount"

 

       Especially useful options include

      rsize=8192,wsize=8192
             This will make your nfs connection faster than with the default buffer size of 4096. (NFSv2 does not work with
             larger values of rsize and wsize.)

 

bei "man nfs" bekommt man

 

 

     rsize=n        The number of bytes NFS uses when reading files from an NFS server.  The default value is dependent on the kernel, currently 1024  bytes.   (How-
                     ever, throughput is improved greatly by asking for rsize=8192.)

      wsize=n        The number of bytes NFS uses when writing files to an NFS server.  The default value is dependent on the kernel, currently 1024 bytes.  (However,
                     throughput is improved greatly by asking for wsize=8192.)          

Link zu diesem Kommentar
Auf anderen Seiten teilen

Ups..

bei mir ist mit Linux ist schon v3.

Da werde ich doch mal den Test laufen lassen.

 

/var # mount
/dev/root on / type squashfs (ro)
none on /dev type devfs (rw)
proc on /proc type proc (rw)
tmpfs on /tmp type ramfs (rw)
/dev/mtdblock/2 on /var type jffs2 (rw)
172.21.250.2:/server/Film on /mnt/filme type nfs (rw,v3,rsize=8192,wsize=8192,soft,udp,nolock,addr=172.21.250.2)
/var #                                                                                                                

 

Das Ergebnis

/tmp # ./ntest

udp, sync
8192+0 records in
8192+0 records out
real    1m 44.62s
user    0m 0.24s
sys     0m 23.81s
4923
8192+0 records in
8192+0 records out
real    1m 15.75s
user    0m 0.20s
sys     0m 7.44s
6826
172.21.250.2:/server/Film on /mnt/filme type nfs (rw,sync,v3,rsize=32768,wsize=32768,soft,udp,nolock,addr=172.21.250.2)

udp, async
8192+0 records in
8192+0 records out
real    1m 2.31s
user    0m 0.25s
sys     0m 12.01s
8126
8192+0 records in
8192+0 records out
real    1m 17.39s
user    0m 0.25s
sys     0m 7.20s
6649
172.21.250.2:/server/Film on /mnt/filme type nfs (rw,v3,rsize=32768,wsize=32768,soft,udp,nolock,addr=172.21.250.2)

tcp, sync
8192+0 records in
8192+0 records out
real    1m 45.34s
user    0m 0.22s
sys     0m 27.83s
4830
8192+0 records in
8192+0 records out
real    1m 17.21s
user    0m 0.29s
sys     0m 12.57s
6649
172.21.250.2:/server/Film on /mnt/filme type nfs (rw,sync,v3,rsize=32768,wsize=32768,soft,tcp,nolock,addr=172.21.250.2)

tcp, async
8192+0 records in
8192+0 records out
real    1m 30.17s
user    0m 0.27s
sys     0m 9.79s
5688
8192+0 records in
8192+0 records out
real    1m 17.36s
user    0m 0.19s
sys     0m 11.10s
6649
172.21.250.2:/server/Film on /mnt/filme type nfs (rw,v3,rsize=32768,wsize=32768,soft,tcp,nolock,addr=172.21.250.2)

 

jetz teste ich das noch mal mit 8192

bearbeitet von vitacola1
Link zu diesem Kommentar
Auf anderen Seiten teilen

  • Wer ist Online   0 Benutzer

    • Keine registrierten Benutzer online.

×
×
  • Neu erstellen...