7390: Netzwerkgeschwindigkeit zur Enigma-Box viel zu gering

[sipgateuser]

Ich habe mir einen ZyXEL GS-108S v2 als Switch besorgt, da die FB 7390 zu wenig Ports hat, und mir das Übertragen großer Files mit dem 100MBit-Switch zu langsam war. Iirgendwo hakt es aber noch. Die Diagnose sagt, dass alle 4 Ethernet im Powermodus sind, dh 1Gbit Ethernet ist überall aktiviert. Ein scp auf meinem Linux-PC zeigt 6.2MB/s an, das ist eine schlechte 100Mbit-Verbindung.

Woran kann es haken? Der ZyXEL-Switch sollte doch eine 1 Gbit-Leitung automatisch erkennen. Ich wüsste nicht, wie man beim Zyxel was konfiguriert.

Gibt es in der Fritzbox 7390 (FRITZ!OS 06.20, also aktuell) irgendwas mit dem man den Transfer kontrollieren kann?

eth1      Link encap:Ethernet  Hardware Adresse 68:...
          inet Adresse:192....  Bcast:192.168.178.255  Maske:255.255.255.0
          inet6-Adresse: fe80:.../64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX-Pakete:471807 Fehler:0 Verloren:1033 Überläufe:0 Fenster:0
          TX-Pakete:1805061 Fehler:0 Verloren:0 Überläufe:0 Träger:0
          Kollisionen:0 Sendewarteschlangenlänge:1000

 

[MuP]

Welchen Aufdruck tragen die verwendeten LAN-Kabel ?

 

[PeterPawn]

Ein scp auf meinem Linux-PC zeigt 6.2MB/s an, das ist eine schlechte 100Mbit-Verbindung.

Noch mal für mein Verständnis ... bei dem "scp" ist die FRITZ!Box nicht nur als Switch involviert (selbst da hätte sie ein bißchen "zu rechnen"), sondern sie ist gleichzeitig Quelle oder Ziel des Kopiervorgangs?

Wenn ich das oben richtig verstanden habe, wirst Du wohl nur aus dem RAM der FRITZ!Box höhere Durchsatzraten erzielen können (und auch das nicht, wenn da erst noch eine Verschlüsselung stattfinden muß wie beim "scp"). Alles andere dürfte durch USB2 bzw. die lahme Flash-Anbindung (der wird seitenweise eingeblendet, wenn ich den Code richtig interpretiere) ausgebremst werden und da sind dann die 6.2 MByte/s (ich nehme mal an, das sind Byte) schon ein akzeptabler Wert angesichts der Hardware.

Ansonsten mal mit "nc" und "/dev/zero" oder ähnlichem die reine Ethernet-Übertragungsrate messen ... die sollte es schon über die 100 MBit/s-Latte schaffen, wobei das aber auch eher kein GBit/s werden wird, dafür ist der Vx180 zu lahm und die Bridge an den LAN-Anschlüssen ist wohl "nur" noch in Software realisiert (muß ja i.d.R. auch noch ins WLAN funktionieren).

Alternativ läßt sich auf der Support-Seite ein iperf-Server aktivieren, aber nicht wundern über die Werte. Der TCP-Durchsatz einer 7390 ist eben grottig, der Prozessor ist immerhin über 7 Jahre alt. Beim UDP-Durchsatz macht sich wohl ein geringerer Rechenbedarf positiv bemerkbar. Warum aber der TCP-Durchsatz tatsächlich so grottenschlecht ist (das betreffende Kernelmodul für den iperf-Server ist - glaube ich jedenfalls - sogar in den OSS-Quellen von AVM enthalten), kann man auch nur raten, denn der Handshake findet ja nur einmal statt. Es muß also irgendwas anders laufen bei der "packet inspection" für TCP-Pakete.

 

[sipgateuser]

Welchen Aufdruck tragen die verwendeten LAN-Kabel ?

Mindestens Cat 6, tw. Cat 7, der längste Teil ist Cat 6

Noch mal für mein Verständnis ... bei dem "scp" ist die FRITZ!Box nicht nur als Switch involviert (selbst da hätte sie ein bißchen "zu rechnen"), sondern sie ist gleichzeitig Quelle oder Ziel des Kopiervorgangs?

Ist etwas komplizierter.

Der PC hat 2 NICs. Realtek onboard und Intel 82574L PCIe-Karte. Von der Intel-Karte geht es zur Fritzbox. Von der Fritzbox geht es weiter zum Zyxel-Switch, von dort zu einem Patchpanel, dann geht es weiter zu einer Ethernet-Dose und von dort weiter zum ein VU+ Linux-Sat-Receiver mit dem der PC Dateien austauschen soll.

Ansonsten mal mit "nc" und "/dev/zero" oder ähnlichem die reine Ethernet-Übertragungsrate messen

Bitte konkreter.

Es muß also irgendwas anders laufen bei der "packet inspection" für TCP-Pakete

Da fällt mir was ein, die Zyxel hat so ein "Pseudo-QoS", vielleicht sind die Kabel nicht optimal angesteckt. Vgl. http://www.zyxel.com/de/de/products_services/gs_108s_v2.shtml?t=p bzw. die Anschlüsse bei http://www.zyxel.com/uploads/images/app_gs_108s_v2_700.gif

 

[PeterPawn]

Ok, dann ist die FRITZ!Box also "nur" Switch in Deinem Netzwerk. Theoretisch können die LAN-Ports bei der 7390 tatsächlich fast auf Hardware-Ebene zu einem Switch zusammengefaßt werden, die konkrete Konfiguration bei "lanmode_bridge" kennt m.W. aber nur AVM.

Wenn der VU+ ein "irgendwas 2" ist (BCM74xx), könnte der vielleicht etwas mehr liefern ... eines der älteren Modelle mit BCM73xx ist bei SSH auch mit den 6.2 MByte/s schon überfordert, das Chipset ist eben nicht für Verschlüsselung ausgelegt.

Wenn Du etwas von 6.2 MByte/s schreibst, von wo nach wo hast Du das denn nun gemessen?

Zu "nc" findest Du meterweise Dokumentation in den Regalen des Internet ... und /dev/zero dient nur dazu, fast verzögerungsfrei einen Strom von binären Nullen als Eingabe für eine Übertragung zu liefern.

Wenn die FRITZ!Box "nur" Switch ist, hat sie etwas weniger zu tun, ist aber immer noch involviert und - wenn der Switch-Chip nicht entsprechend konfiguriert ist - arbeitet als "software-based switch" (kann man sich mit brctl ansehen). Die konkrete Switch-Konfiguration ist aber vom Modell abhängig, bei der 7390 könnten LAN2/LAN3 tatsächlich "in Hardware" gebrückt werden bei entsprechenden Werten in den Konfigurationsregistern. Einzelheiten dazu finden sich in den Kernel-Quellen von AVM in "avm_cpmac.c".

Ist die FRITZ!Box Teil der Verbindung, hat sie entsprechend mehr zu tun und der Durchsatz sinkt.

Ich würde jedenfalls bei einem GBit-LAN nicht auf die Idee kommen, weitere (GBit-fähige) Geräte per Kabel über die FRITZ!Box anzubinden. Dann lieber noch 20 EUR ausgeben und einen weiteren 5-Port-Switch am Aufstellort der FRITZ!Box dazwischen hängen, wenn die Verkabelung es so erforderlich machen sollte.

 

[sipgateuser]

Vielleicht mal ein anderer Wert: Wenn ich vom PC über die Fritzbox zu einem anderen PC mit scp eine Datei übertrage, dann erreiche ich ca. 38MB/s bei einer 1GB-Datei. Da hängt also kein Zyxel-Switch in der Verbindung, aber das Patch-Panel. Ich kann mir jetzt überlegen die Ethernet-Kabel anders anzustecken, ist aber kompliziert, weil auf die Schnelle nicht erkennbar ist, welches Kabel wohin gehört und das sind 20 Kabel die zugeordnet werden müssen.

Wenn der VU+ ein "irgendwas 2" ist (BCM74xx)

Auf der Herstellerseite findet man nur "1000/100/10 MBit kompatibles Interface" und dmesg verrät "bcmgenet bcmgenet.0 eth0: link up, 1000 Mbps, full duplex"

Wenn Du etwas von 6.2 MByte/s schreibst, von wo nach wo hast Du das denn nun gemessen?

Das zeigt scp an. Ich habe da noch ein Plugin bei XFCE, das zeigt mir auch den Transfer an.

Zu "nc" findest Du meterweise Dokumentation in den Regalen des Internet

Schon klar und http://dell9.ma.utexas.edu/cgi-bin/man-cgi?nc+1 habe ich gelesen, kommen mit den dafür sinnvollen Optionen aber trtozdem nicht klar, aber vielleicht ist das gar nicht so wichtig, mein Bauchgefühl sagt mir, da passt was bei den Prioritäten des Zyxel-Switch nicht. Ich werde mal versuche eine Verbindung ohne Zyxel aufzubauen, muss dafür nur die richten Kabeln finden.

Ich würde jedenfalls bei einem GBit-LAN nicht auf die Idee kommen, weitere (GBit-fähige) Geräte per Kabel über die FRITZ!Box anzubinden. Dann lieber noch 20 EUR ausgeben und einen weiteren 5-Port-Switch am Aufstellort der FRITZ!Box dazwischen hängen, wenn die Verkabelung es so erforderlich machen sollte.

Daran soll es nicht scheitern, ich habe sogar noch mal den gleichen Zyxel-Switch neu für einen anderen Zweck unbenutzt rumliegen. Ziel müsste es also sein, die Fritzbox nicht als Switch fungieren zu lassen, oder? Ich müsste also alle Kabel die an der FB hängen und die schnellen Datentransfer von PC zu PC brauchen, nicht an die FB stecken, sondern an den Zyxel und 1 Kabel führt von der Zyxel zur Fritzbox?

Vielleicht kann mir wer sagen, ob das mit den QoS-Ports zu tun haben könnte. Die LEDs dazu leuchten grün, eine gelb, da hängt ein Gigaset A510 daran. An welche Ports des Zyxel soll ich was anschließen? Also welcher Zyxel-Port an welchen FB-Port?

 

[thtomate12]

Die Fb sollte an einen Low- oder Med-Prio-Port, bei der FB egal, außer bei der WAN-Benutzung (dann kein LAN1, obviously), oder Gast-LAN (4).

 

[PeterPawn]

Das portbasierte QoS des Zyxel kenne ich nicht, ich käme aber auch nicht auf die Idee, so etwas zu wollen (was macht man denn, wenn man 3 "Echtzeit"-Ports braucht?). So einfach das für Ahnungslose sein mag, wenn man das Kabel in den richtigen Port steckt, so unflexibel (und fehleranfällig, weil eben jede Kommunikation zwischen zwei Teilnehmern läuft) ist das am Ende. Aber das war ja auch nicht die Frage. Trotzdem begreife ich nicht, was ein portbasiertes QoS bringen soll, wenn die höher priorisierten Ports immer nur genau als ein einzelnes Paar existieren. Hier fehlt mir irgendwie die Phantasie für den "use case" ...

Zur Frage:
Wenn Du "an der FRITZ!Box vorbei" netzwerken willst, geht tatsächlich noch genau ein einziges Kabel vom Switch zur FRITZ!Box. Wenn Du dann noch einen "richtigen" GBit-Switch nimmst (ich glaube aber nicht daran, daß das QoS Schuld ist, solange da nicht parallel höher priorisierte Übertragungen stattfinden, denn dann wäre das QoS ja auch bei nicht ausgelasteten Verbindungen eine echte Bremse) und alles andere, was auch direkt miteinander "reden" soll, dort anschließt, ist die FRITZ!Box nur noch mit den Daten beschäftigt, die tatsächlich für sie selbst (oder mit ihr verbundene WLAN-Clients) oder für das WAN bestimmt sind.

An welchem Port die FRITZ!Box am Ende landet, hängt eben auch davon ab, was da auf der WLAN-Seite noch so läuft. Wenn da mit einem Tablet Videos von der VU+ über's WLAN gesehen werden sollen, muß natürlich auch die FRITZ!Box an einem "realtime"-Port hängen, ansonsten greift das QoS für das WLAN nicht mehr (und drosselt u.U. das Video herunter, wenn da eine Bandbreitenreservierung dabei ist und kein dynamisches Management).

Das wäre dann ein schönes Beispiel für die Unflexibilität eines portbasierten Managements. Es gibt sicherlich Szenarien, wo das Sinn macht ... z.B. ein Backup-Server an so einem Port oder auch ein LAN-fähiger Drucker. Spätestens wenn das dort angeschlossene Gerät einen Mix aus verschiedenen Diensten und auch Dienstgüten bietet/braucht (oder sogar wieder ein Router ist), wird das aber schnell unübersichtlich und die Tendenz der Nutzer, einfach mal ein Kabel in einen freien Port zu stecken, kann dann auch schnell zu unerwarteten Ergebnissen führen (Ende OT).

BTW: Ich kann immer noch nicht klar erkennen, von wo nach wo Du bei den gemessenen 6.2 MByte/s denn nun die Daten übertragen hast und welche Geräte/Kabel dabei beteiligt waren/sind. Ob das am Ende eine Anzeige von "scp" oder ein Desktop-Plugin ist, was Dir diese Anzeige liefert, ist dabei vollkommen egal ... mir ging es nur darum, daß auch eine GBit-fähige Verkabelung andere Nadelöhre haben kann und das können beteiligte Geräte sein. Mein VU+ Ultimo mit 2x400 MHz-BCM7413 kommt bei SSH-Verschlüsselung auf dem Receiver auch nicht aus dem Knick und Blockartefakte sind bei paralleler Aufnahme fast zwangsläufig, daher greife ich dort eben nur mit NFS zu und lasse alles andere, was etwas mehr Rechenarbeit erfordert, auf anderen Geräten machen. Der MIPS-Kern des BCM7413 ist nun mal für AES256-Verschlüsselungen nicht die richtige Plattform ... das aber nur als Beispiel, daß ein GBit-Netzwerkanschluß (mein Ultimo hat sogar nur einen FE-Anschluß) noch nicht heißt, daß die Daten auch tatsächlich auf diesem Niveau fließen.

 

[sipgateuser]

Ich verstehe jetzt eins nicht, oben wurde nachvollziehbar versichert, dass es besser ist als Switch den Zyxel und nicht die FB zu verwenden. Daher habe ich nun testweise 2 PCs an den Zyxel-Switch gehängt. Den einen PC, der die Datei sendet an Priority high und den der empfängt an Priority medium. Die FB habe ich vom Strom getrennt, sodass ich keinen Denkfehler habe und da doch was über die FB läuft. Die Testdatei wird mit 22.3MB/s übertragen.

Sendender PC:
eth1 Link encap:Ethernet Hardware Adresse 68:
inet Adresse:192.168.178.100 Bcast:192.168.178.255 Maske:255.255.255.0
inet6-Adresse: fe80:
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
RX-Pakete:1242563 Fehler:0 Verloren:5696 Überläufe:0 Fenster:0
TX-Pakete:10144419 Fehler:0 Verloren:0 Überläufe:0 Träger:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX-Bytes:125290794 (125.2 MB) TX-Bytes:14673687415 (14.6 GB)
Interrupt:44 Speicher:fe5c0000-fe5e0000


Empfangender PC:
eth0 Link encap:Ethernet Hardware Adresse 10:
inet Adresse:192.168.178.70 Bcast:192.168.178.255 Maske:255.255.255.0
inet6-Adresse: fe80:
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
RX-Pakete:6794057 Fehler:0 Verloren:2001 Überläufe:0 Fenster:0
TX-Pakete:480595 Fehler:0 Verloren:0 Überläufe:0 Träger:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX-Bytes:9900127375 (9.9 GB) TX-Bytes:34549500 (34.5 MB)


Wenn ich es nicht gepostet hätte, dass ich vorher 38MB/s erreiche, würde ich es nicht glauben. Ich habe jetzt den Zyxel ausgeschaltet und erreiche über die FB ebenfalls 22.3MB/s, wenn ich die Kabel an der FB anstecke.

Sendender PC:
TX-Pakete:12298272 Fehler:0 Verloren:0 Überläufe:0 Träger:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX-Bytes:137831386 (137.8 MB) TX-Bytes:17815093070 (17.8 GB)

Empfangender PC:
RX-Pakete:8947289 Fehler:0 Verloren:2140 Überläufe:0 Fenster:0
TX-Pakete:636835 Fehler:0 Verloren:0 Überläufe:0 Träger:0
Kollisionen:0 Sendewarteschlangenlänge:1000

 

[HabNeFritzbox]

Im FB Interface steht doch GBit oder 100Mbit in Netzwerkübersicht.

Am Switch hat man oft ne grüne LED für GBit und Orange für 100Mbit, sofern der auch GBit kann, was ja beim Zyxel zutrifft.

Und wieso wird nur SCP Probiert? Besten Ergebnisse bekomme ich am NAS oder zwischen Windows Rechner eher über CIFS , da sind über 100MB/s schon normal.

 

[sipgateuser]

Unsere Antworten haben sich überschnitten.

Das portbasierte QoS des Zyxel kenne ich nicht, ich käme aber auch nicht auf die Idee, so etwas zu wollen

Das haben ja bereits die Einsteigerswitch. Jetzt beim Test läuft da gar nichts mit hohem Transfer, alle 15 Min. werden Mails geholt, sind aber auch nicht viele, die jetzt ankommen.

Wenn Du "an der FRITZ!Box vorbei" netzwerken willst, geht tatsächlich noch genau ein einziges Kabel vom Switch zur FRITZ!Box

Siehe oben, das hat nichts gebracht. WLAN ist bei der FB deaktiviert und über die anderen WLAN-Geräte (TP-Link) läuft zur Zeit nichts. Ach ja, das habe ich noch vergessen zu erwähnen, der 2. PC hängt an einem TP-Link 1040 und dieser war bei den Tests entweder an der FB oder am Zyxel angesteckt.

BTW: Ich kann immer noch nicht klar erkennen, von wo nach wo Du bei den gemessenen 6.2 MByte/s denn nun die Daten übertragen hast

Vielleicht sollte man das erst einmal zurückstellen, sodass die Verbindung wieder schneller wird, die schon schneller war? Vielleicht war das Zufall, aber so ein großer Unterschied? Ich hatte ein schlechtes Ethernetkabel mit abgebrochener Klemme, das vorher die 38MB/s brachte, durch ein nagelneues Cat7-Kabel getauscht

welche Geräte/Kabel dabei beteiligt waren/sind

Kann ich jetzt nicht mehr 100% sicher sagen, wie was angesteckt war, vermutlich war es so:

PC - FB - Zyxel - Patchpanel - Ethernetdose - Satreceiver

Ich verwende scp nur desweigen weil es schön die Transferrate anzeigt und ich sehe das als relativen Wert.

Beim 2. PC ist der Weg so:

PC - FB - TP-Link TL-WR1043ND - PC oder
PC - Zyxel - TP-Link - PC

Am TP-Link TL-WR1043ND ist WLAN aktiv, da läuft aber bei den Tests nichts und an der FB ist WLAN deaktiviert.

Es geht mir auch nicht darum Aufnahmen live auf den PC zu übertragen, ich will nur fertige Aufnahmen am Duo2 mit rsync zum PC übertragen.

 

[sipgateuser]

m FB Interface steht doch GBit oder 100Mbit in Netzwerkübersicht.

Siehe Anhang

Mir geht es um rsync zwischen Sat-Box und Linux-PC.

 

[HabNeFritzbox]

Also nochmal... was steht in der Heimnetzliste bei Verbindung? Auch Gbit?

 

[sipgateuser]

Sorry, ich hatte das falsche Bild hochgeladen, in #12 sieht man, dass alle Ports auf 1GBit gestellt sind und das findet sich auch im Heimnetzwerk: LAN 2 mit 1 Gbit/s Das ist das LAN mit dem ich jetzt teste, die ursprüngliche Verbindung lasse ich bis auf weiteres ruhen, jetzt will ich wissen, warum die Verbindung zu einem 2. PC langsamer wurde.

 

[HabNeFritzbox]

Auf dem Bild sieht man nur, dass GBit eingestellt hast, nicht mit was Gerät sich verbindet, was ja entscheidend ist.

Wenn dort in Liste für Geräte an LAN 2 und 3 auch GBit steht, ist ja gut.

Evt. drosselt der Switch runter wegen ganzen Eco kram?

 

[sipgateuser]

Ja, im Heinetzwerk steht überall 1Gbit/s

 

[PeterPawn]

Ich verwende scp nur desweigen weil es schön die Transferrate anzeigt und ich sehe das als relativen Wert.

Das ist aber definitiv falsch. Da bei scp auch immer noch eine Verschlüsselung stattfindet, spielt dann die Prozessorleistung der beiden Endpunkte auch immer noch eine entscheidende Rolle. Wenn dabei ein Prozessor an seine Grenzen kommt (was bei der VU ganz fix geht), verfälscht das alles.

Sieh Dir doch einfach mal "iperf" an, wenn Du einen Geschwindigkeitstest machen willst ... damit testen jedenfalls die Leute, die das beruflich machen (bei Tests für Zeitschriften o.ä.), wenn es rein um die Netzwerk-Geschwindigkeit geht.

Und nur noch als Info, weil Du rsync erwähnt hast: Wenn Du nicht ständig irgendwelche Abbrüche hast und von der differentiellen Übertragung beim rsync profitieren willst, ist rsync auch bei einer Duo2 nicht unbedingt die beste Wahl. Die Installation eines NFS-Servers auf einer Vu+ ist simpel und wenn Du ohnehin Linux verwendest, ist auch die Client-Seite schon geklärt. Da fällt dann die ganze Verschlüsselung weg ... probier' es mal und Du wirst (wahrscheinlich) staunen, wie schnell das Kopieren von ts-Dateien von einer Vu+ sein kann.

Wenn Du jetzt schon bei nicht ausgelastetem Netzwerk und dem Anschluß eines Gerätes an einem "medium"-Anschluß eine sinkende Geschwindigkeit konstatierst, teste doch einfach mal mit zwei Teilnehmern an den "high"-Ports. Wenn das dann wieder volle Geschwindigkeit (im Rahmen der Möglichkeiten der Clients) ist, dann bremst das portbasierte QoS eben immer. Was man dann davon halten sollte, habe ich ja schon geschrieben.

 

[sipgateuser]

Ich habe mittlerweile die VU+ mit einem 1,5m langen Cat7-Kabel direkt an die FB angeschlossen, scp meint 6.4MB/s

Tasks:  77 total,   2 running,  75 sleeping,   0 stopped,   0 zombie
Cpu(s): 42.8%us, 15.6%sy,  0.0%ni, 37.0%id,  0.4%wa,  0.0%hi,  4.2%si,  0.0%st
Mem:   1240596k total,  1016792k used,   223804k free,     6976k buffers
Swap:        0k total,        0k used,        0k free,   896432k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
 1059 root      20   0  3064 1104  880 R   93  0.1   3:00.00 dropbear           
 1062 root      20   0  2724  732  632 S   15  0.1   0:23.39 scp

Für Iperf brauche ich ja Client und Server, für die VU+ gibt es keine opkg-Installationsdatei.

 

[PeterPawn]

Für Iperf brauche ich ja Client und Server, für die VU+ gibt es keine opkg-Installationsdatei.

Wir reden aneinander vorbei.

Wenn Du für die Vu+ Duo2 ein "iperf"-Paket brauchst, geht es ja doch wieder um die Geschwindigkeit des Receivers und nicht um die des Netzwerks und der beteiligten Netzwerk-Komponenten. Wenn Du das Netzwerk messen willst, nimm zwei potente Clients und teste mit denen.

Wenn Du wissen willst, wie schnell der Receiver sein kann, dann spiele nicht mit den Netzwerk-Komponenten, sondern optimiere die bei der Übertragung verwendete Software.

Das sind einfach zwei verschiedene Paar Schuhe ... Du läßt ja auch kein Bobby-Car auf der Kart-Bahn mitfahren.

 

[sipgateuser]

Hmmh, ich verstehe noch nicht so recht, was ich tun kann, IMHO hängt ja alles miteinandere zusammen. Zu Zeiten eines Celeron 400 oder so, habe ich bei scp keinen Geschwindigkeitsunterschied wegen der Verschlüsselung gemerkt. Jetzt verwende ich einen 1300MHz-Prozessor am Sat-Receiver, klar eine andere Architektur.

root@vuduo2:~# cat /proc/cpuinfo 
system type		: BCM7425B2 STB platform
machine			: Unknown
processor		: 0
cpu model		: Brcm4380 Broadcom BMIPS5000 V1.1  FPU V0.1
BogoMIPS		: 864.25
cpu MHz			: 1305.096
wait instruction	: yes
microsecond timers	: yes
tlb_entries		: 64
extra interrupt vector	: yes
hardware watchpoint	: no
isa			: mips1 mips2 mips32r1
ASEs implemented	:
shadow register sets	: 1
kscratch registers	: 0
core			: 0
VCED exceptions		: not available
VCEI exceptions		: not available

processor		: 1
cpu model		: Brcm4380 Broadcom BMIPS5000 V1.1  FPU V0.1
BogoMIPS		: 655.36
cpu MHz			: 1305.096
wait instruction	: yes
microsecond timers	: yes
tlb_entries		: 64
extra interrupt vector	: yes
hardware watchpoint	: no
isa			: mips1 mips2 mips32r1
ASEs implemented	:
shadow register sets	: 1
kscratch registers	: 0
core			: 0
VCED exceptions		: not available
VCEI exceptions		: not available

Ein NFS-Server auf der Sat-Box ist auch so eine Sache, da gibt es ein Problem beim Mounten, der Server muss zuerst hochgefahren sein und das ist nicht gewährleistet.

Ich probiere gerade ein rsync ohne ssh und da erhalten ich etwas über 8MiB. Soll die Verschlüsselung 2MiB kosten, dann macht das das Kraut auch nicht fett. Gerade hängt der PC direkt am Zyxel und die Sat-Box auch und es läuft ein rsync.

Tasks:  77 total,   2 running,  75 sleeping,   0 stopped,   0 zombie
Cpu(s): 53.3%us, 13.6%sy,  0.0%ni, 30.6%id,  0.2%wa,  0.0%hi,  2.4%si,  0.0%st
Mem:   1240596k total,  1204700k used,    35896k free,     6444k buffers
Swap:        0k total,        0k used,        0k free,  1099588k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
 2272 root      20   0  3120 1180  880 R   99  0.1   6:37.56 dropbear           
 2275 root      20   0  3220 1072  624 S   31  0.1   2:03.94 rsync

Ok, ganz langweilig ist der Sat-Box nicht bei ca. 50% CPU, aber da ist noch Reserve.

Von der Satbox:

cat /proc/net/dev
Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
    lo:    1728       3    0    0    0     0          0         0     1728       3    0    0    0     0       0          0
 wlan0:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
  eth0: 3272886661 3390138    0 1060    0     0          0     42020 3971689711 6169172    0    0    0     0       0          0

Also, wenn ich das richtig sehe, dann gibt es da 6169172 Errors, die könnten aber vom Umstecken kommen, während ein rsync lief. Sorry.