Ich brauch mal den Rat von Netzwerkspezialisten, ich suche den richtigen
Suchbegriff für mein Problem, ich weiß nicht wonach ich googeln soll.
Problem:
sowohl
1
PC(Win) ===GBit/s=== Fritz ===100MBit/s=== 100erSwitch ===100MBit/s=== PC(Linux)
als auch
1
PC(Win) ===GBit/s=== Fritz ===100MBit/s=== TV-Box(Android)
erlauben mit SMB nur mickrige 1.5MBytes/s Netto Transferrate,
mit SyncThing oder FTP oder ähnlichem jedoch bekomme ich annähernd die
zu erwarteten 11 MBytes/s.
Drossle ich jedoch in der Fritzbox-Konfiguration den Port an dem der
linke PC hängt auf 100 MBit/s so bekomme ich auch mit SMB wieder die
erwarteten beinahe 10 MByte/s zwischen allen Geräten.
Frage: Nach welchen Stichworten muss ich googlen um zu verstehen was da
vor sich geht, was das verursachen könnte?
Bernd K. schrieb:> PC(Win) ===GBit/s=== Fritz ===100MBit/s=== TV-Box(Android)
Ist also nach der Fritz auf 100 Gedrosselt. Somit Mascht das eine
Maximale Geschwindigkeit von 100Mbit.
100Mbit sind ~12MB'S
Allerdings schafft man selten das Optimum. 8MB's sind realistisch.
1,5 Allerdings etwas Lahm. Smb zwischen welchen Geräten?
Max Muster schrieb:> 100Mbit sind ~12MB'S> Allerdings schafft man selten das Optimum.
Ab SMBv2 sind Raten an der Kante des Netzwerks durchaus realistisch.
Dazu fehlen viele Informationen noch.
Was für Daten sind es (viele kleine oder große?), wie ist die Auslastung
vom Switch und den PCs, Firewall/Virenscanner ?
DNS/IPs/Routing alles richtig eingestellt?
Hast du VPN am laufen? mehere Subnetzwerke?
MTU Werte verändert?
Immer wieder verlinke ich folgende Seite gerne:
http://www.nwlab.net/guide2na/netzwerkanalyse-probleme-2.html
Neben der Bandbreite ist ganz entscheidend die Latenz - insbesondere bei
SMBv1 bei einer max. WindowSize von 64KByte.
Ich weiß nicht, wie oft ich die den Zusammenhang zwischen Latenz &
Performance erklärt habe, aber es war einige Male ...
ist die 1GB/s wirklich stabil?
Oder wir nac a bisserl Verkehr wieder speed negotiation gemacht aka
zeit vertrödelt?
sind Kabel + Stecker + Buchsen im 1GB/s Abschnitt wirklich gut und
fit? (sosolala taugt eben nicht f. GE)
Kein scharfer knick im 1GB/s Kabel?
Anderes Kabel schon mal probiert?
L/ocal A/rea N/otwork schrieb:> sind Kabel + Stecker + Buchsen im 1GB/s Abschnitt wirklich gut und> fit? (sosolala taugt eben nicht f. GE)>> Kein scharfer knick im 1GB/s Kabel?
Erstaunlicherweise kann ich mit SyncThing zig Gigabyte in beide
Richtungen syncen stundenlang und mit stabilen 11 MB/s (also 100M Bit
ausgelastet bis an die Kante).
Das Problem tritt nur mit SMB auf. Es tritt nicht auf mit anderen
Protokollen und auch die Verbindung vom/zum Internet (50MBit/s down)
geht stabil an allen angeschlossenen Geräten.
Ich würde gerne den betreffenden Port an der Fritzbox nicht auf
100MBit/s drosseln da noch ne USB-Platte in der Fritzbox steckt und die
ist etwas schneller als 100MBit/s.
Jumbo-Frames sind aus. Flow control am PC-NIC ist an (auch kein
Unterschied wenn ich es ausschalte).
Das Kabel kat keinen erkennbaren Schaden, das GBit-Segment ist auch nur
2 Meter lang, ich vermute keinen Schaden auf der physikalischen Schicht,
das muss entweder ein Protokoll-fsck-up sein (Microsoft?) oder zu kleine
Buffer im Switch? aber warum gehen andere Protokolle?
Mountain schrieb:> Wie sind die Ping Zeiten in beiden Fällen ?
vom rechten PC aus gepingt (jupiter ist der linke)
Momentan steht der linke link auf 1GBit/s
1
$ ping jupiter.fritz.box
2
PING jupiter.fritz.box (10.0.1.0) 56(84) bytes of data.
3
64 bytes from Jupiter.fritz.box (10.0.1.0): icmp_seq=1 ttl=128 time=0.288 ms
4
64 bytes from Jupiter.fritz.box (10.0.1.0): icmp_seq=2 ttl=128 time=0.166 ms
5
64 bytes from Jupiter.fritz.box (10.0.1.0): icmp_seq=3 ttl=128 time=0.275 ms
6
64 bytes from Jupiter.fritz.box (10.0.1.0): icmp_seq=4 ttl=128 time=0.251 ms
7
64 bytes from Jupiter.fritz.box (10.0.1.0): icmp_seq=5 ttl=128 time=0.200 ms
> Welche WindowSize wird ausgehandelt ?
Wo seh ich das?
Kai schrieb:> Dazu fehlen viele Informationen noch.> Was für Daten sind es (viele kleine oder große?), wie ist die Auslastung
Eine große Datei (mehrere Gigabyte)
> vom Switch und den PCs, Firewall/Virenscanner ?
Keine weitere Auslastung, alles idle.
> DNS/IPs/Routing alles richtig eingestellt?
Ja, selbstverständlich. Routing gibts nicht, ist alles ein einziges
Netz. IPs und DNS von der Fritzbox via DHCP, alles einwandfrei.
> Hast du VPN am laufen? mehere Subnetzwerke?
Nein. nein.
> MTU Werte verändert?
Nein, alles auf Standardeinstellungen so wie es bei Windows 7 (links)
und Ubuntu (rechts) eingestellt war.
Das Problem löst sich in Luft auf sobald ich an der Fritzbox den LAN1
(und nur den!) auf 100MBit/s drossle, das ist der an dem der linke PC
hängt.
Kein anderes Protokoll ist betroffen außer SMB.
Bitte mal auf der Windows Pc Seite sniffern ...
man muß sich das genau ansehen und die beiden Zustände vergleichen ...
wahrscheinlich geht das etwas schief und es treten retransmits auf ...
glaskugel aus ....
Bernd K. schrieb:> Es tritt also nur auf wenn Windows den Server spielt
Windows konnte SMB/CIFS noch nie richtig verarbeiten. Damit wirst du
also leben müssen.
SMBv1 oder SMBv2? Samba kann ab ca. V3.6 SMBv2, aber nicht unbedingt per
Voreinstellung. Eine bestehende Verbindungsdefinition in v1 bleibt bei
v1, muss also komplett entfernt und neu angelegt werden.
Ich tippe ganz stark darauf, dass auf der fritzbox die packete verloren
gehen weil sie mit >100mbits ankommen aber nur mit weniger als 100mbits
weitergeleitet werden.
Es kommt zu paketverlusten und zum warten vor dem neuversenden.
Vermutlich hat MS ein nettgemeintes feature implementiert, wenn beide
Geräte im selben subnetz sind wird von Anfang an mit der vollen NIC
Geschwindigkeit kommuniziert.
Mit den aufkommenden paketverlusten kommt dann das Programm nicht
zurecht.
c.m. schrieb:> vielleicht hat die fritzbox zu wenig puffer um ankommende 1gbs packete> zwischen zu speichern.
Ja, sowas in der Art vermute ich auch
>> probier mal nur zum spass Fritz ===100MBit/s===> |> PC(Win) ===100MBit/s=== 100erSwitch ===100MBit/s === PC(Linux)
Diese Konfiguration kenn ich nicht auf die Schnelle einrichten denn der
Link zum 100er-Switch geht ans andere Ende der Wohnung und der 100er
Switch samt Ubuntu-PC steht hinten im Arbeitszimmer.
Was ich testen konnte war den 1GBit/s-Link zwangsweise auf 100MBit/s zu
setzen, dann existieren im gesamten Netz nur noch 100MBit/s, dann tritt
kein Problem mehr auf.
Und ich vermute wenn ich den Switch im Arbeitszimmer gegen einen GBit
austausche (Kabel ist bereits Cat5e) dann können zumindest die beiden
PCs wieder vernünftig miteinander.
Aber es werden dann immer noch 100MBit/s-Geräte (und WLAN-Geräte) an der
Fritzbox hängen. Zuerst aufgefallen ist mir das übrigens als ich
feststellte daß meine Kodi-Box keine 1080p-Filme per SMB vom Windows-PC
streamen konnte (weder über WLAN noch über Kabel), sehr wohl aber
problemlos solche von der Fritz-USB-Platte).
Die Rechenleistung der Teilnehmer spielt auch eine große Rolle. Ein
moderner PC schafft bei mir 117MB/s an einem uralten GB-Switch unter
SAMBA und Windows, und 12MB bei Fast Ethernet. Mit einer Klapperkiste
bin ich über 20MB/s nicht rausgekommen. Ein Raspberry 2 schafft immerhin
27MB mit USB-"Netwerkkarte".
Abgesehen von möglichen Fehleinstellungen würde ich mal zur Gegenprobe
die Geräte mit einem anderen, langen Patchkabel miteineander verbinden.
Evtl. ist schon unterwegs was faul oder Paare falsch?
A. K. schrieb:> SMBv1 oder SMBv2? Samba kann ab ca. V3.6 SMBv2, aber nicht unbedingt per> Voreinstellung. Eine bestehende Verbindungsdefinition in v1 bleibt bei> v1, muss also komplett entfernt und neu angelegt werden.
Ich würde auch sagen, das man das unbedingt zuerst prüfen sollte.
SMBv2 und neuer kann Verbindungen deutlich besser auslasten.
Schon seltsam, daß gerade Windows mit dem Windows-eigenen Protokoll
solche Späne macht.
knipps mal den Arbeitsstationsdienst probeweise aus, (Das geschwätzige
"hallo in bin Jupiter, ein Windows-PC mit folgenden Shares... und wer
seit ihr?" hört dann (an der eth-act-LED sichtbar) auf).
alternativ sieh zu, das beide in der Arbeitsgruppe WORKGROUP sind.
(im Gegensatz zu den eigenen gesetzten Standards arbeitet Windows
inzwischen mit der eingestellten + der fixen WORKGROUP- Arbeitsgruppe.
du glaubst gar nicht wie geschwätzig der Kram wird.
Auch alle DNS-Dienste mal an der windose deaktivieren. (der ist client,
kein Server).
Und vor allem wichtig: die Broadcastadresse (und demzufolge auch die
Netzwerkmaske) muß bei allen korrekt sein.
Für eine Standard-fritzbox wäre das also
IP=192.168.178.x
Netmask=255.255.255.0
Broadcast=192.168.178.255
Ansonsten wären noch Dinge wie "Netbios over TCPIP = aktiv" oder
"Computername sollte == Hostname sein" zu nennen.
wenn du auf ~50% der FTP-Geschwindigkeit kommst, hast du dein Ziel
erreicht.
Hallo,
ich weiß nicht, ob ich völlig daneben liege, aber bei Windows ist
verzögertes Ack bei TCP generell an.
Ich hatte da mal ein ähnliches Problem, dabei fiel auf, daß einige
Protokolle diese Einstellung offenbar ignorieren und es abschalten. Bei
denen stimmte dann die Geschwindigkeit.
Kann man in der Registry abschalten, gibt es auch einen KB-Eintrag.
Vielleicht mal probieren.
Gruß aus Berlin
Michael
Hallo,
ich installiere mir immer eine LMHost-Datei auf der "Ubuntu (Linux)
Seite" und stelle zum Test die Windows Verschlüsslung auf 56Bit.
Klar mit einem WINS Dienst wäre das nicht nötig. Braucht man ja sonst
nur zum Routen.
Hast Du das mal getestet ?
Probier mal einen anderen, ggf. älteren Treiber, und spiel bisschen mit
den Optionen (Offloading disable). Sieht stark danach aus, dass der
Windows-Treiber ein Problem mit der Flow Control hat.
Hatte mal ein Asus-Board mit nem Atheros L1 on Board, da war's auch
spannend den richtigen, funktionierenden Treiber zu finden.
> Erzähl mehr.
Gern doch, hat uns Anfang 2014 einige nervige Monate beschert, weil das
Problem so seltsam ist, dass wir uns erstmal gar keinen Reim drauf
machen konnten.
Zuerst bemerktes Symptom: Einige Geräte, die über WLAN der 7390
dranhängen, kommen nicht oder nur sehr zäh ins Netz, und das trotz gutem
Pegel. Per tcpdump mitgespannt kommen die Pakete aus dem WLAN gar nicht
auf der LAN-Seite raus. FB-Reset hilft kurzzeitig (so 30min bis ein paar
Stunden). Wenn es aber mal ein Gerät trifft, ist es immer so, unabhängig
vom Typ (Mobiltelefon, Notebook, etc.) und auch nach WLAN Ab/Anmeldung.
D.h. es ist kein Problem eines bestimmten WLAN-Clients/Chips.
Die WLAN-Anmeldung an sich ist auch nie ein Problem, das "taube" Gerät
taucht auf der Geräte-Übersicht der 7390 auf.
Das Verhalten konnte mit 7 Stück 7390 in zwei Netzumgebungen
nachgestellt werden, also kein Montagsproblem. Aktuelle FW, auch
Beta-FW, Wechsel der WLAN-Kanäle, Konfigurationsresets etc. halfen
nichts.
Anfrage bei AVM, die wussten aber von nix.
Da die FBs in der Anwendung auch als DECT-Stationen benutzt werden,
haben wir "richtige" APs (TP-Link C7 ) gekauft, die der Einfachheit an
den FB-Switch angeschlossen und das FB-WLAN abgeschaltet.
Oh Wunder, immer noch dieselben Probleme ausser zur Web-GUI der C7...
Bestimmte Geräte (MACs?) kommen "nicht raus".
Da hats dann endlich Klick gemacht: Der Switch in der FB ist einfach
Schrott. Hat evtl. was mit der internen MAC-Tabelle und der Anzahl der
MACs im Netz zu tun, jedenfalls verwirft er ab einem gewissen Zeitpunkt
dann alle Pakete eines Geräts oder leitet sie an den falschen Port
weiter.
Jetzt hängen die FBs am Switch der C7 und damit geht das WLAN
problemlos.
Offensichtlich scheint das Problem nicht besonders bekannt zu sein.
Vermutlich tritt es bei Mini-Heimnetzen (Handy+PC+Notebook) aufgrund der
beschränkten MAC-Anzahl einfach nicht auf. Bei uns sind es halt
potentiell am Tag einige 100 verschiedene Geräte.
Allerdings gibt es durchaus andere Posts, die verdächtig nach "unserem"
Problem klingen:
http://www.teltarif.de/fritz-box-internet-zugang-probleme-smartphone/news/64808.html
Mit einer 7490 konnten wir den Effekt auch nicht mehr beobachten.
ja das Problem kenne ich auch, per WLAN angebundener Mediaplayer hat
Internetzugang und auch alle anderen Geräte im WLAN können darauf
zugreifen aber ins LAN ist keine Verbindung möglich. Ein Ping geht
meistens dann nix mehr. Man kann dann durchaus noch weitere WLAN Geräte
anmelden die problemlos gehen. Nach einem Neustart der FB geht dann das
vorher betroffene Gerät aber der Fehler tritt dann plötzlich bei einem
anderen auf.
Von AVM auch keine Hilfreiche Antwort erhalten.
Sascha
Ich hätte da noch einen Gedanken. Ausgangslage:
- Die Fritten filtern SMB nach draussen.
- LAN 1 lässt sich zum WAN-Port umkonfigurieren.
Da das Umkonfigurieren zwischen LAN und WAN wohl kaum durch echtes
Umschalten der Leitungen erfolgt, wird's via netfilter/iptables gemacht.
Wenn da ein Bug lauert...
@OP: Schon einen anderen LAN-Port probiert?
Ansonsten gebe ich 1N4148 recht, habe da auch so meine "spassigen"
Erinnerungen mit div. Atheros.
Thread beobachten
Seitenaufteilung abschalten