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
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
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.
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
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
Zumindest bei Chrome kann man die Timestamps anzeigen lassen, irgendwo bei Entwicklertools. Gruss Chregu
Willst du ein Endgerät drosseln? Dann einfach einen Smart-Switch mit "Rate Limit" nehmen und den entsprechenden Port begrenzen.
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.
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
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.
Angehängte Dateien:
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
Norbert schrieb: > Das nennt sich traffic shaping. Traffic Shaping kann soweit ich erinnere der Linux-Netzwerkstack off-the-shelf ... LG, Sebastian
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
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
(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. :)
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
(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. :)
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…
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
Angehängte Dateien:
-
vm_ware_lan.jpg
66 KB
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.
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
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.
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
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.
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
(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".
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
(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.
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?
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.
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.
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.
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
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.
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.
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.
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.
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.
Motopick schrieb: > Wenn etwas nicht richtig funktionierte, hatte ich "Link Analyst" > und "Netsense" at my fingertips. Kann man das essen?
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.