Forum: Offtopic LAN für Testzwecke definiert drosseln?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Frank E. (Firma: Q3) (qualidat)


Lesenswert?

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).

: Bearbeitet durch User
von Cyblord -. (cyblord)


Lesenswert?

Frank E. schrieb:

> Wozu sowas gut ist?

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.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Frank E. schrieb:
> Kennt jemand eine passende fertige Hard- oder Software-Lösung?

FreeBSD's netgraph kennt ein ng_pipe, mit dem man sowas machen kann 
(Bandbreitenlimitierung, Verzögerung, Paketverluste).

Ob man das aber auch auf layer 2 (bridging) zusammen gebastelt bekommt 
oder layer 3 (routing) dafür braucht, bin ich gerade überfragt.

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Frank E. schrieb:
> 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.

Gruss
WK

: Bearbeitet durch User
von Frank E. (Firma: Q3) (qualidat)


Lesenswert?

Cyblord -. schrieb:

> 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.

: Bearbeitet durch User
von Christian M. (christian_m280)


Lesenswert?

Zumindest bei Chrome kann man die Timestamps anzeigen lassen, irgendwo 
bei Entwicklertools.

Gruss Chregu

von Oliver S. (phetty)


Lesenswert?

Willst du ein Endgerät drosseln?
Dann einfach einen Smart-Switch mit "Rate Limit" nehmen und den 
entsprechenden Port begrenzen.

von Motopick (motopick)


Lesenswert?

Oliver S. schrieb:
> 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.

von Norbert (der_norbert)


Lesenswert?

Frank E. schrieb:
> 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

von Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)


Lesenswert?

Frank E. schrieb:
> es gibt sicher noch reichlich andere nützliche Anwendungen,

Hatte ich früher mal gemacht zum Ausprobieren mit Switches, die auch 
1MBit konnten und dazwischen einen Switch gehängt, der nur 1MBit konnte.

von (prx) A. K. (prx)


Angehängte Dateien:

Lesenswert?

Motopick schrieb:
> 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.

: Bearbeitet durch User
von Sebastian W. (wangnick)


Lesenswert?

Norbert schrieb:
> Das nennt sich traffic shaping.

Traffic Shaping kann soweit ich erinnere der Linux-Netzwerkstack 
off-the-shelf ...

LG, Sebastian

von (prx) A. K. (prx)


Lesenswert?

Sebastian W. schrieb:
> 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.

: Bearbeitet durch User
von Norbert (der_norbert)


Lesenswert?

Sebastian W. schrieb:
> Traffic Shaping kann soweit ich erinnere der Linux-Netzwerkstack
> off-the-shelf ...

Das stimmt, das kann er.
Und das kann er sogar verdammt gut.
Braucht ein wenig Zeit bis man die tc Tabellen gedengelt hat, aber dann…

Aber oben war ja auch nach einer fertigen HW-Lösung gefragt.

EDIT: War ich wohl etwas zu langsam… ;-)

: Bearbeitet durch User
von Motopick (motopick)


Lesenswert?

(prx) A. K. schrieb:
> Motopick schrieb:
>> 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. :)

von (prx) A. K. (prx)


Lesenswert?

Motopick schrieb:
> 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.

: Bearbeitet durch User
von Motopick (motopick)


Lesenswert?

(prx) A. K. schrieb:
> Motopick schrieb:
>> 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. :)

von Norbert (der_norbert)


Lesenswert?

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…

von (prx) A. K. (prx)


Lesenswert?

Motopick schrieb:
> Nichts kann man nicht bremsen.

Nicht das Nichts wird gebremst, sondern mit dem Nichts wird das 
verzögert, was nicht Nichts ist.

: Bearbeitet durch User
von Irgend W. (Firma: egal) (irgendwer)


Angehängte Dateien:

Lesenswert?

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.

von Alexander (alecxs)


Lesenswert?

nimm doch einfach den Web.de SmartSurfer

von Foobar (asdfasd)


Lesenswert?

Motopick schrieb:
> 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).

: Bearbeitet durch User
von Motopick (motopick)


Lesenswert?

Foobar schrieb:
> Motopick schrieb:
>> 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.

Beitrag #7644185 wurde vom Autor gelöscht.
von (prx) A. K. (prx)


Lesenswert?

Ich habe nicht den Eindruck, dass ihr euch widersprecht.

Foobar schrieb:
> Das Wegschmeißen von Frames ist das ganz normale Verhalten von IP,
> *wenn die Bandbreite nicht ausreicht*

Was eine Neuaushandlung im TCP triggert.

Motopick schrieb:
> Bei einer Droprate von 1/7

... 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.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Motopick schrieb:
> und auf ein ACK des/der Clients wartet,

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.

von (prx) A. K. (prx)


Lesenswert?

Jörg W. schrieb:
> also die Anzahl der vorab
> ohne empfangene Bestätigung versdendeten Pakete

Genau genommen ist es bei TCP die Gesamtgrösse der Daten.

@alle: Wen das interessiert:
https://accedian.com/blog/tcp-receive-window-everything-need-know/

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

(prx) A. K. schrieb:
> Genau genommen ist es bei TCP die Gesamtgrösse der Daten.

Wobei diese eben nicht fest ist, sondern dynamisch angeglichen, wenn 
jemand "auf der Strippe steht".

von G. K. (zumsel)


Lesenswert?

Frank E. schrieb:

> 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.

https://man7.org/linux/man-pages/man8/tc-netem.8.html
https://www.cs.unm.edu/~crandall/netsfall13/TCtutorial.pdf
https://www.lug-erding.de/vortrag/net-em.pdf

von Motopick (motopick)


Lesenswert?

(prx) A. K. schrieb:

> Motopick schrieb:
>> Bei einer Droprate von 1/7
>
> ... 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.

Jörg W. schrieb:
> Motopick schrieb:
>> und auf ein ACK des/der Clients wartet,
>
> Genau das macht TCP übrigens nicht, ...

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.

von G. K. (zumsel)


Lesenswert?

Motopick schrieb:
> 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?

von Motopick (motopick)


Lesenswert?

G. K. schrieb:

> 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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Motopick schrieb:
> 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.

von Martin S. (strubi)


Lesenswert?

Mit

WanSIM (sollte das hier sein WIMRE: https://github.com/fhendrikx/wansim)

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.

von Foobar (asdfasd)


Lesenswert?

Motopick schrieb:
> Ja, der Mythos der "trickreichen" Algorithmen.

https://en.wikipedia.org/wiki/TCP_congestion_control#Algorithms

> 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

von G. K. (zumsel)


Lesenswert?

Motopick schrieb:

> 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.

von Motopick (motopick)


Lesenswert?

Foobar schrieb:
> 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.

G. K. schrieb:
> Bullshit, große Buffer bringen das Flow-Control von TCP erst recht aus
> dem Tritt.

Was TCP recht schnell voellig aus dem Tritt bringt, sind sicher eher
fehlende Pakete.

von G. K. (zumsel)


Lesenswert?

Motopick schrieb:
> Was TCP recht schnell voellig aus dem Tritt bringt, sind sicher eher
> fehlende Pakete.

Offensichtlich hast du dich bisher recht wenig mit TCP beschäftigt sonst 
würdest du wissen was "fast retransmission" ist und wie das 
funktioniert.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Motopick schrieb:
>> Ich hoffe nicht, dass du versucht hast, IP über eine verschlüsselte
>> TCP-Verbindung zu tunneln ...
>
> Es war IPSEC.

IPSEC over TCP?

hust, hust …

Aber wir bewegen uns stark vom Thema weg.

von Motopick (motopick)


Lesenswert?

Jörg W. schrieb:
> Motopick schrieb:
>>> Ich hoffe nicht, dass du versucht hast, IP über eine verschlüsselte
>>> TCP-Verbindung zu tunneln ...
>>
>> Es war IPSEC.
>
> IPSEC over TCP?

Das geht wohl mittlerweile auch. .)
Aber nein, es war IPSEC.

> Aber wir bewegen uns stark vom Thema weg.
Themen kommen und gehen.

G. K. schrieb:

> 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.

von G. K. (zumsel)


Lesenswert?

Motopick schrieb:

> Wenn etwas nicht richtig funktionierte, hatte ich "Link Analyst"
> und "Netsense" at my fingertips.

Kann man das essen?

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.