Für Testzwecke wäre es vorteilhaft, eine technische Möglichkeit zu besitzen, mit der man die effektive Geschwindigkeit einer LAN-Verbindung nahezu beliebig oder wenigstens in definierten Stufen drosseln könnte.
FÜr die einzelnen Ethernet-Frames liegt die Mindestgeschwindigkeit ja wohl bei 10 MBit, sonst funktioniert die Netzwerkkarte nicht mehr. Aber die Frames als Ganzes müsste man puffern und mit quasi beliebig großen Pausen dazwischen, weiterleiten können ...
Kennt jemand eine passende fertige Hard- oder Software-Lösung? Ansonsten fiehle mir nur ein MC-Projekt mit mind. 2 LAN-Ports und passender Software "dazwischen" ein.
Wozu sowas gut ist? Beobachtet z.B. mal das Laden mancher Webseiten, wenn die Bedingungen (unabsichlich) schlecht sind! Dann wird erstmal offensichtlich, wie oft in sinnlosester Weise die ganze Seite oder Teile davon neu geladen werden oder beobachtet mal (im Firefox links unten), was da alles für ein Mist gezogen wird - alles Dinge, die bei ordentlich Speed überhaupt nicht auffallen ... usw.
Das ist nur ein Beispiel, was mir spontan einfällt, es gibt sicher noch reichlich andere nützliche Anwendungen, insbesondere die strukturelle Optimierung eigener Webanwendungen, z.B. MC-GUIs auf Webbasis ... (ähnlich Tasmota).
Danke. Genau diese Frage hat sich mir stark aufgedrängt.
Beobachtet z.B. mal das Laden mancher Webseiten,
wenn die Bedingungen (unabsichlich) schlecht sind! Dann wird erstmal
offensichtlich, wie oft in sinnlosester Weise die ganze Seite oder Teile
davon neu geladen werden oder beobachtet mal (im Firefox links unten),
was da alles für ein Mist gezogen wird - alles Dinge, die bei ordentlich
Speed überhaupt nicht auffallen ... usw.
Ich sehe da keinen Zusammenhang zu deiner Anfrage. Wenn du wissen willst was und wann genau vom Browser angefordert wird, dann nimmst du Wireshark.
Was soll eine Drosselung bzw. das Zurückhalten vom Frames hier bringen?
Das Verhalten ändert sich, entgegen deiner Behauptung, NICHT wenn du Frames absichtlich verzögerst.
Das ist nur ein Beispiel, was mir spontan einfällt, es gibt sicher noch
reichlich andere nützliche Anwendungen,
Absolut nicht. Die Idee ist Humbug.
Ein realistischer und praktisch relevanter Test wäre ein Netzlasttest.
Damit testest man das Verhalten eines Netzwerkgerätes, wenn das Netz mit Traffic zugestopft ist. Es gibt für einige Bereiche sog. Netzlastklassen.
Dazu findest du genug Tools.
Kenn jemand eine passende fertige Lösung? Ansonsten fiehle mir nur ein
MC-Projekt mit mind. 2 LAN-Ports und passender Software "dazwischen"
ein.
Gibts sicher wie Sand am Meer. Vor zig Jahren hatte ich mal entfernt mit Wanem zu tun, das war eine kleine Linuxdistri mit der dann Netzwerkverbindungen mit bestimmten Parametern (Durchsatz, Paketverluste ...) nachgestellt werden konnten.
Im Kernel sind auch schon entsprechende Mechanismen eingebaut, die kann man afaik mit dem Kommando "tc", Unterabteilung "netem" konfigurieren.
Was soll eine Drosselung bzw. das Zurückhalten vom Frames hier bringen?
Das Verhalten ändert sich, entgegen deiner Behauptung, NICHT wenn du
Frames absichtlich verzögerst.
Die Reihenfolge sicher nicht, aber man kann es visuell beobachten und bewerten ... "erleben". Ein Wireshark-Mitschnitt zeigt mir nur Inhalt und Parameter der Frames als Liste, evtl. einen Timestamp. Den Seitenaufbau-Prozess im Browser kann ich jedoch bei hoher Geschwindigkeit nicht beobachten.
Das ist ungefähr der gleiche Grund, warum man (in manchen Fällen) lieber ein Diagramm oder gar eine Animation auschaut, anstatt Tabellen mit endlosen Zahlenreihen ...
Man kann es glauben oder nicht: Ich habe unter solchen Bedingungen schon herausbekommen, dass z.B. Codeblöcke in Javascript in der (vermeintlich) falschen Reihenfolge ausgeführt wurden, nur weil die Engine im Browser der Ansicht war, "optimieren" zu müssen. Kommt sicher nicht häufig vor, gibts aber.
Willst du ein Endgerät drosseln?
Dann einfach einen Smart-Switch mit "Rate Limit" nehmen und den
entsprechenden Port begrenzen.
Das begrenzt die Bandbreite nur mittelbar, und auf eine ganz
schlecht berechenbare Art. Begrenzt wird die Anzahl der Pakete.
Wenn man nichts "droppen" oder "delayen" will, schaltet man einfach
z.B. zwei Cisco Router ueber jeweils ein DCE- bzw. DTE-Kabel zusammen.
Auf der DCE-Seite kann man dann ganz bequem, die Taktrate auf dem
Interface einstellen. Und damit die Uebertragungsbandbreite.
Die Moeglichkeiten des IOS zur Bandbreitesteuerung hat man dann
ausserdem noch zur Verfuegung.
Kennt jemand eine passende fertige Hard- oder Software-Lösung? Ansonsten
fiehle mir nur ein MC-Projekt mit mind. 2 LAN-Ports und passender
Software "dazwischen" ein.
Das nennt sich traffic shaping.
Als fertiges Gerät gab's da mal einen ›TrafficShaper‹.
Der konnte noch tausend andere Dinge aber eben auch einfach nur das
Traffic Shaping kann soweit ich erinnere der Linux-Netzwerkstack
off-the-shelf ...
Kann er, und das funktioniert sehr gut. Muss man sich allerdings erst einmal reinfuchsen, oder eine gute Quelle zum abschreiben finden. Und muss dabei natürlich auf der Rechnung haben, dass diese Art Shaping nur ausgehenden Traffic begrenzt.
Das begrenzt die Bandbreite nur mittelbar, und auf eine ganz
schlecht berechenbare Art. Begrenzt wird die Anzahl der Pakete.
Sicher? Hier der Cisco SG250-08.
Der einfache "Rate Limiter" wirkt auf die Paketrate per Zeiteinheit.
Was ihm ja auch seinen Namen eingebracht hat.
Aber man kann ja alles aufbohren. :)
Der einfache "Rate Limiter" wirkt auf die Paketrate per Zeiteinheit.
Was ihm ja auch seinen Namen eingebracht hat.
Eine "Rate" kommt auch in Bitrate vor. :)
Dass die Bits im Frame nicht langsamer als die Interface-Rate sein können, liegt auf der Hand. Kontinuierlich gedrosseltes Ethernet gibts nicht ausserhalb der Interface-Raten.
Also kann nur zwischen Frames gebremst werden. Aber was spricht dagegen, dass er auf die transportierten Bits pro Zeit reagiert, statt auf die Frames pro Zeit? Zählen tut er die Bits sowieso, denn das muss er für die Statistik.
Der einfache "Rate Limiter" wirkt auf die Paketrate per Zeiteinheit.
Was ihm ja auch seinen Namen eingebracht hat.
Eine "Rate" kommt auch in Bitrate vor. :)
Dass die Bits im Frame nicht langsamer als die Interface-Rate sein
können, liegt auf der Hand. Kontinuierlich gedrosseltes Ethernet gibts
nicht ausserhalb der Interface-Raten.
Richtig.
Also kann nur zwischen Frames gebremst werden. Aber was spricht dagegen,
dass er auf die transportierten Bits pro Zeit reagiert, statt auf die
Frames pro Zeit? Zählen tut er die Bits sowieso, denn das muss er für
die Statistik.
Zwischen den Frames ist "Nichts". Nichts kann man nicht bremsen.
Der gesteigerte Aufwand. Auch wenn er Bits zaehlt, muss er das
irgendwann in eine Framerate umrechnen. Und verwerfen darf er die
Frames ja auch nicht. Er muss sie also queuen, und zum genehmen
Zeitpunkt senden.
Fuer vieles reicht Rate limiting aber. Denke z.B. mal an DNS-Anfragen.
Da will keiner die Anzahl der Bits wissen. :)
Bei TCP Streams kann man zB. die ACKs des Transfer-Windows verzögern und so die Rate der eingehenden Pakete (etwas verzögert zwar) durchaus limitieren.
Ausgehende Pakete ja sowieso…
Das ganze in eine virtuelle Umgebung verlagern. z.B. VMware kann bei den Einstellungen für die virtuelle LAN-Karte zwischen Host und Client recht detailliert eingestellt werden und ist nicht an die "üblichen Stufen" der Hardware gebunden.
Und verwerfen darf er die Frames ja auch nicht. Er muss sie also
queuen, und zum genehmen Zeitpunkt senden.
Das Wegschmeißen von Frames ist das ganz normale Verhalten von IP, wenn die Bandbreite nicht ausreicht - und das passiert ständig (z.B. Wechsel von Ethernet nach DSL/ISDN/Analogmodem). TCP weiß das und hat einen trickreichen Algorithmus, die Bandbreite der kompletten Verbindung (über mehrere Hops mit jeweils unterschiedlichen Bandbreiten hinweg) festzustellen und sich darauf anzupassen.
Btw, Puffer in Netzwerkkomponenten willst du möglichst klein halten (Stichwort: Buffer Bloat).
Und verwerfen darf er die Frames ja auch nicht. Er muss sie also
queuen, und zum genehmen Zeitpunkt senden.
Das Wegschmeißen von Frames ist das ganz normale Verhalten von IP, wenn
die Bandbreite nicht ausreicht - und das passiert ständig
Wird das Informatikern so beigebracht?
Ist es nicht eher so, dass TCP fuer fast jeden F.rz einen Handshake
mit einem "ACK" vom Gegenueber braucht? Damit stellt sich die
Geschwindigkeit natuerlich eher von "alleine" auf das Medium ein.
... TCP weiß das und hat einen
trickreichen Algorithmus, die Bandbreite der kompletten Verbindung (über
mehrere Hops mit jeweils unterschiedlichen Bandbreiten hinweg)
festzustellen und sich darauf anzupassen.
Ja, der Mythos der "trickreichen" Algorithmen.
2 Beispiele aus der Praxis:
Ein Host in China ueber IPSEC getunnelt erreichbar.
Paketverlustrate im Tunnel ca. 10 %. Auf der chinesischen Gegenseite
ca. ein 10 Mbit-Anschluss.
Die 10 % Verlustrate sorgen dafuer, dass man in einer SSH-Sitzung
ca. 1 Lochkarte/Terminalzeilenbreite per Minute uebertragen bekommt.
Das sollte doch nicht passieren wenn laufend sowieso Pakete
"gedroppt" werden, oder?
Fuer Untersuchungen an einer Software, die per UDP-Multicast ihre
Payload uebertraegt, und auf ein ACK des/der Clients wartet, habe
ich mir vor droellfzik Jahren mal fuer den Linuxkernel ein
Bridgemodul gebaut, bei dem die Droprate einstellbar war.
Das habe ich dann auch mal fuer einen Test von SSH gegriffen.
Bei einer Droprate von 1/7 kommt entweder ueberhaupt keine
Verbindung zustande, oder sie bricht unmittelbar wieder ab.
Auch das sollte nicht passieren wenn TCP so resistent dagegen waere.
Btw, Puffer in Netzwerkkomponenten willst du möglichst klein halten
(Stichwort: Buffer Bloat).
Jaja.
Daher nochmal:
Das Wegschmeißen von Frames ist das ganz normale Verhalten von IP
Ist es eben nicht.
Kann man selbst uebrigens mit einem Schlaufon mit einem zu knapp
bemessenen Volumen in der "Drossel" bequem ausprobieren.
Die droppen naemlich fuer ihre "Drossel" wirklich. Das Resultat
ist fuer den Kunden natuerlich voellig unbefriedigend.
Siehe dazu meine Beispiele oben.
Fuer den seltenen Fall, schalte ich dann auf eine GSM/GPRS-Verbindung
um. Das verbessert den Durchsatz merklich, und aergert den Betrieber,
weil ich dann im Prinzip mehr von seinen Ressourcen fuer weniger
Leistung verbrauche.
... die bei nun automatisch angepasstem TCP nicht mehr auftreten sollte. Sofern die Droprate mit der Transfercharakteristik der Daten zu tun hat, und nicht mit einer miesen Leitung.
Bleibt die Leitung auch dann konsequent bei dieser Droprate, weil Scheiss Leitung, oder weil mehrere beteiligte Netzbetreiber sich gerade in der Wolle haben (diesen Eindruck hatte ich schon), wirds hässlich. Damit kann TCP nicht gut umgehen. Ist aber eine andere Baustelle.
Genau das macht TCP übrigens nicht, und selbst Kermit konnte das schon besser. Bei Kermit war aber das "Fenster", also die Anzahl der vorab ohne empfangene Bestätigung versdendeten Pakete fix, bei TCP ist sie variabel, damit sich das eben an die reale Geschwindigkeit des gesamten Kanals anpassen kann.
Kennt jemand eine passende fertige Hard- oder Software-Lösung? Ansonsten
fiehle mir nur ein MC-Projekt mit mind. 2 LAN-Ports und passender
Software "dazwischen" ein.
... die bei nun automatisch angepasstem TCP nicht mehr auftreten sollte.
Sofern die Droprate mit der Transfercharakteristik der Daten zu tun hat,
und nicht mit einer miesen Leitung.
Welche und was fuer eine "Transfercharakteristik"?
Was soll TCP denn daran automatisch anpassen?
Natuerlich ist die "Leitung" bzw. deren Aequivalent in Form z.B.
eines IPSEC/Crypttunnels gemeint. Oder ein gestoertes WLAN.
... wirds hässlich.
Damit kann TCP nicht gut umgehen.
Genauso sieht es dann in der Praxis aus. Siehe mein Beispiel oben.
Es ging, so steht es auch von mir geschrieben, um eine IP/UDP
Multicastanwendung. Die mehrere Clients gleichzeitig bedienen kann.
Und bei der der Client den Empfang bestaetigen muss.
Dieses Bestaetigungspaket wurde vom Client aber nur genau einmal
gesendet. Fiel das dem "packet loss" zum Opfer, "stand" das ganze
Verfahren. Was bei der Routinenutzung dieser Anwendung oefter
und sehr stoerend war. Es handelt sich um den Norton Ghostserver. :)
Von TCP war nicht die Rede.
Es ging, so steht es auch von mir geschrieben, um eine IP/UDP
Multicastanwendung. Die mehrere Clients gleichzeitig bedienen kann.
Und bei der der Client den Empfang bestaetigen muss.
Dieses Bestaetigungspaket wurde vom Client aber nur genau einmal
gesendet. Fiel das dem "packet loss" zum Opfer, "stand" das ganze
Verfahren. Was bei der Routinenutzung dieser Anwendung oefter
und sehr stoerend war. Es handelt sich um den Norton Ghostserver. :)
Von TCP war nicht die Rede.
Eine kommerzielle Enterprise Anwendung soll für irgendwas maßstäblich sein?
Eine kommerzielle Enterprise Anwendung soll für irgendwas maßstäblich
sein?
Sie kann zumindest als schlechtes Beispiel dienen.
Es haette den Kohl nicht fetter gemacht, wuerden die Clients ihre
ACKs mehrfach senden.
Mit "zeitgemaessen" Switchen wuerde das Problem wohl heute auch
nicht mehr so auftreten. Damals waren die "Switchfabrics" auf das
unbedingt noetigste abgespeckt. Heute haette man kein Problen
einer Switchfabric auch noch einige GB Speicher/Buffer zu spendieren.
Es ging, so steht es auch von mir geschrieben, um eine IP/UDP
Multicastanwendung.
Ist mir schon klar. Nur eben offensichtlich auch noch eine sehr schlecht implementierte, die selbst fundamentale Erkenntnisse aus der Frühzeit der Datenkommunikation ignorierte.
und einer halbstarken PC-Kiste, die zwei Netzwerkkarten hat, kann man sich mit Linux sowas stricken. Inkl. Fehlerinjektion und Pipapo. Unterliegt halt den Linux-Latenzen.
Aufwendiger geht es mit einem ECP5 Versa-Kit, wenn man ganz detaillierte Paketsachen in Echtzeit machen muss.
Welche und was fuer eine "Transfercharakteristik"?
Die Bandbreite.
Btw, was für eine Bandbreite hat eine Verbindung, die konstant jedes 7. Paket wegschmeißt, selbst wenn sie nur mit 50Bd reinkommen?
Was soll TCP denn daran automatisch anpassen?
Die Senderate.
Btw, auf aktuellen Systemen ist TCP für hohe Daten- und geringe Fehlerrate getuned. Fehlerkorrektur ist oft auf dem Link-Layer besser zu behandeln und findet entspr immer häufiger da statt. Bei TCP wird Paket-loss hauptsächlich als Congestion eingestuft.
Natuerlich ist die "Leitung" bzw. deren Aequivalent in Form z.B.
eines IPSEC/Crypttunnels gemeint.
Ich hoffe nicht, dass du versucht hast, IP über eine verschlüsselte TCP-Verbindung zu tunneln ...
Damals waren die "Switchfabrics" auf das unbedingt noetigste
abgespeckt. Heute haette man kein Problen einer Switchfabric
auch noch einige GB Speicher/Buffer zu spendieren.
Das haben einige bereits versucht und sind damit auf die Nase gefallen. Ist ungefähr so intelligent, als würde man nur einmal im Jahr mit nem LKW einkaufen.
https://en.wikipedia.org/wiki/Bufferbloat
Mit "zeitgemaessen" Switchen wuerde das Problem wohl heute auch
nicht mehr so auftreten. Damals waren die "Switchfabrics" auf das
unbedingt noetigste abgespeckt. Heute haette man kein Problen
einer Switchfabric auch noch einige GB Speicher/Buffer zu spendieren.
Bullshit, große Buffer bringen das Flow-Control von TCP erst recht aus dem Tritt.
Ich hoffe nicht, dass du versucht hast, IP über eine verschlüsselte
TCP-Verbindung zu tunneln ...
Es war IPSEC.
Damals waren die "Switchfabrics" auf das unbedingt noetigste
abgespeckt. Heute haette man kein Problen einer Switchfabric
auch noch einige GB Speicher/Buffer zu spendieren.
Das haben einige bereits versucht und sind damit auf die Nase gefallen.
Ist ungefähr so intelligent, als würde man nur einmal im Jahr mit nem
LKW einkaufen.
https://en.wikipedia.org/wiki/Bufferbloat
Ja. Ein Switch braeuchte normalerweise keine grossen Buffer fuer
sein Geschaeft. Wenn er Traffic aber z.B. in der Bandbreite
begrenzen soll, ist es sicher besser, im begrenzten Mass Pakete
fuer eine spaetere Aussendung zu speichern, als sie einfach zu
verwerfen, um eine konfigurierte Packetrate oder
Uebertragungsbandbreite im Mittel zu erfuellen. Das was halt
eine Queue so tut.
Offensichtlich hast du dich bisher recht wenig mit TCP beschäftigt sonst
würdest du wissen was "fast retransmission" ist und wie das
funktioniert.
Wenn etwas nicht richtig funktionierte, hatte ich "Link Analyst"
und "Netsense" at my fingertips. Damit konnte man nichts uebersehen.
Und natuerlich noch einen respektive mehrere Schnueffis nebst
Remotesonden.
