1. Home
  2. Electronics (German)
  3. Mein DSL
  4. Page 6

Mein DSL

Es wäre dessenungeachtet erfreulich, wenn solche Thesen mal mit Fakten, also RFC Texten und Primärquellen, unterlegt wären.

Das hatten wir vor einigen Monaten mal durchgerechnet. Im übrigen hat das nichts mit Asymmetrie zu tun. Es ist wohlfeil zu sagen, daß TCP nicht läuft, wenn ich irgendwo auf dem Pfad Überlast habe.

Das ist in etwa so neu wie daß bei Dir Wasser ins Klo läuft, wenn Du an der Spülung ziehst.

Laß das Traffic Shaping sein, wir hatten das unlängst überschlagen, Marc und ich haben die Usenetgemeinde lange genug genervt, irgendwo ab einem Datenratenverhältnis von 70:1 kannst Du langsam anfangen, Dir Sorgen zu machen. Die üblichen 16:1 oder 32:1 interessieren keinen.

Oder inschenschörmäßig gesagt: Das ist jenseits von gut und böse.

die sich hier leider nicht der Wirklichkeit anpasst. Aber man kann halt nicht immer Sieger sein ;-)

Reply to
Detlef Bosau
Loading thread data ...

Ach Du heilige Scheixxe! Dätkläff Bo Eyh Sau ist aus meinem Filter ausgebrochen.

zurück in das Verlies. Und nimm den HK auch mit. Danke.

Nun wird dse wohl den Bach runtergehen bzw. völlig unlesbar werden :(

Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang

--
Wolfgang Allinger, anerkannter Trollallergiker :) reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p
(lt. alter usenet Weisheit)
Reply to
Wolfgang Allinger

Eben. Es wird einer h=F6heren Abstraktionsebene von einer tieferen eine Einheitlichkeit vorgegaukelt, die tats=E4chlich nicht gegeben ist. Hier i= m lokalen Netzwerk mache ich genau das mit meinen Partitionen X: und Y:, die tats=E4chlich af einem anderen Rechner liegen. M.W. (aber bisher von mir nicht genutzt) kann Windows dasselbe auch =FCbe= r FTP.

Axel

Reply to
Axel Berger

Am 16.08.2012 23:10, schrieb Holger:

Und genauso sieht's aus mit curlftps.

Reply to
Hartmut Kraus

Mit der Wahrheit kann man niemanden beleidigen (hatten wir schon). Du solltest die Zeit nutzen, statt sie sinnlos zu verdiskutieren.

Reply to
Hartmut Kraus

Dümmere Ausreden fallen dir hoffentlich nicht mehr ein.

Reply to
Hartmut Kraus

Am 17.08.2012 00:15, schrieb Detlef Bosau:

Bevor du jetzt noch "Einsteigerliteratur" zum Thema "Der Unterschied zwischen Realität und Wirklichkeit" empfiehlst, mein Vorschlag zur Güte: Gebt mir Bescheid, sollte wider Erwarten innerhalb einer endlichen Zeit aus dieser "Diskussion" hier was praktisch Nutzbares 'rausgekommen sein.

Reply to
Hartmut Kraus

Was auch wiederum Unsinn ist und man Gegenteiliges problemlos in den entsprechenden RFCs nachlesen kann. TCP enthält auch diverse andere Annahmen über die zugrundeliegende Übertragungstechnik:

  1. hohe Latenz ist überlastungsbedingt (Annahme: Übertragungsweg ist low-latency)
  2. größere Paketverluste sind überlastungsbedingt (Annahme: Übertragungsweg ist annähernd (!) verlustfrei, kabelgebunden)

TCP reagiert auf die Fälle 1 und 2 mit Drosselung der Senderate und expontiellem Backoff, was bei ADSLs mit Interleaving Path und bei Funkübertragungen (Umgebung mit höheren Paketverlusten) in die Hose geht.

IEEE 802.11 (WLAN) enthält deshalb eine extra in Hardware gegossene zusätzliche Fehlerkorrektur, um TCP eine kabelgebundene Umgebung vorzutäuschen, während man bei 802.3 (Ethernet) problemlos ohne sowas hinkommt.

Für Umgebungen mit hohen Latenzen mußte der TCP-Protokollstack überarbeiten werden, indem Unterstützung für Window Scaling (RFC 1323) und Explicit Congestion Notication (RFC ECN, RFC 3168) hinzugefügt wurde.

Das alles wäre völlig unnötig gewesen, wäre TCP übertragungsweg- agnostisch konzipiert worden. In irgendwelchen Elfenbeintürmen lehren Leute zwar das (gescheiterte) OSI-Modell, an das sich die TCP/IP- Protokollsuite aber nicht hält, was Leute an zu diversen populären Irrtümern verleitet.

Joseph

Reply to
Joseph Terner

Weswegen sich TCP sehr konservativ bei Ausnutzung von "Bandbreite" verhält.

Was daran liegt, daß der sendende TCP auf der Seite, wo "reichlich Luft" ist, glaubt eine Congestion erkennen zu können. Die ja auch vorliegt, nur eben in eine Richtung.

TCP funktioniert übrigens mit leichten Asymmetrien bis etwa zum Verhältnis 2:1, nur halt nicht mit der VoD-Technik, die 16:1 anbietet.

Ja, es gibt Workarounds. Ändert nichts an der Grundaussage.

Joseph

Reply to
Joseph Terner

T=FCr zu! Von au=DFen!

Reply to
Guido Grohmann

Das mag sich vielleicht sogar messen lassen, deckt sich aber nicht mit meiner subjektiven Beobachtung. Ich habe hier 1500/192 und kann w=E4hrend=

eines ungedrosselten Uploads Sachen wie Newsgrouplesen, Browsen und Downloads ziemlich vergessen. Drossele ich den Upload auf rund 90 %, halte mir also nur 20 kbps frei, ist subjektiv keine Einschr=E4nkung mehr=

feststellbar.

Axel

Reply to
Axel Berger

Wolfgang Allinger schrieb:

War nur eine Frage der Zeit. Trolle wie Bosau und Kraus haben noch ihr=20 Umfeld, und wenn das hier auch noch aufschl=E4gt, ist dse endg=FCltig tot= =2E=20 Schade. Wird man wohl grunds=E4tzlich auf microcontroller.net umsteigen=20 m=FCssen. J=F6rg mit seinem Kugelgrill fand ich hingegen richtig nett, ab= er=20 Bosau und Konsorten sind eine v=F6llig andere Liga. Die werden schon noch= =20 daf=FCr sorgen, da=DF hier die Leute mit Ahnung nichts mehr schreiben, we= il=20 das ja auch eine Frage der Menschenw=FCrde ist.

Holger

Reply to
Holger

Axel Berger :

Der Grund liegt an den Queues (Warteschlangen) im ADSL-Router. Bei 90% Upload sind in der Uplink-Queue so gut wie keine Pakete drin - d.h. die wichtigen TCP-Ack-Pakete (die der Download braucht) kommen fast ungehindert durch. Bei "Traffik auf Anschlag" im Uplink sammeln sich mehrere Pakete in der Queue an und ACK-Pakete (die sich standardmässig auch hinten mit anstellen) brauchen länger bis sie rausgehen - was dann zur Drosselung des Downloads führt. Wenn man da nur eine Sache im Router ändert (TCP-ACK Pakete dürfen sich vordrängeln) hat man das Problem etwas entschärft (auch gern als QoS oder Traffikshaping verallgemeinert).

M.

Reply to
Matthias Weingart

"Holger" schrieb im Newsbeitrag news:k0ko3s$1fm$ snipped-for-privacy@speranza.aioe.org...

Hi, immer wieder beruhigend zu sehen, wie sich scheinbar gebildete Leute vor Rindviechern verneigen. Das ist Zivilisation, wenn der Eber vor der Türe grunzt, entdecken die Eingeborenen ihre Hasenohren..

Können wir wirklich nicht ein paar (weitere) Deppen ignorieren? Aber dann Zeitungen mit Mickeysoft-Werbung drin abonnieren, jawoll!

--
 mfg,
gUnther
Reply to
gUnther nanonüm

Erstens weiß ich nicht, was Du unter "praktisch nutzbar" verstehst, zweitens bin ich doch nicht Deine Sekretärin.

Das ist im übrigen niemand hier.

Du kannst hier gerne lesen und schauen, ob Dich was interessiert. Aber es wäre vielleicht angemessen, nicht irgendwelchen Unsinn in die Welt zu blasen. Im übrigen schau mal auf die Uhrzeit. Wer Nachtschicht hat, ist um diese Zeit im Geschäft. Wer tagsüber im Geschäft ist, ist um diese Zeit im Bett. Falls also Dein Problem ist, daß Du kein Geschäft hast und das mal abstellen solltest, weiß ich nicht, ob Trollerei Dein Problem löst.

Reply to
Detlef Bosau

Das einzige, was an Deinem Satz stimmt, sind die Anführungszeichen, denn TCP hat mit "Bandbreite" überhaupt nichts zu tun, und wenn hier gleich Horst Nietowski noch 80 mal mit dem Fuß aufstampft, dieser Fehlgebrauch des Wortes sei völlig richtig.

Im übrigen ist Deine Aussage in der von Dir getätigen Form sinnfrei.

Welches Verhalten von TCP kritisierst Du konkret? Wie könnte man es verbessern?

Kannst Du bitte mal konkret sagen, was Du damit meinst?

Ich hatte mich gestern bereits dazu geäußert.

Natürlich funktioniert TCP auch mit 16:1 ganz hervorragend. Und statt so etwas einfach zu behaupten, kannst Du solche Aussagen bitte mal mit Primärliteratur oder konkreter Argumentation begründen. Zur Zeit lese ich von Dir keins von beidem.

Die Grundaussage ist falsch, insofern brauchen wir keine Würgarounds. (Übrigens brauchen wir auch kein "Traffic Shaping", es hilft nichts, die ganze Tante Gurgel hier runterzubeten.)

>
Reply to
Detlef Bosau

Das hat nichts mit Asymmetrie zu tun.

Das ist bei symmetrischen Anbidungen ganz genauso.

Reply to
Detlef Bosau

Nein.

Punkt.

Der Grund dafür, daß eine zue Tür keine aufe Tür ist, liegt darin, daß eine zue Tür zu ist und nicht auf, sonst wäre das eine aufe Tür.

Wenn ich konkurrierenden Datenverkehr habe und dieser auf Datenfluß in beiden Richtungen angewiesen ist, und das ist bei TCP nun einmal so und auch nicht zu ändern, werde ich den mit Störverkehr immer beeinträchtigen können.

Warum man nun Video on Demand mit TCP macht, entbirgt sich mir nicht, geeignetere Technologien existieren, nicht nur über TCP/IP, seit über 30 Jahren.

Beim digitalen Satellitenfernsehen macht man das Streaming im Downlink auch nicht von Bestätigungen per Brieftaube abhängig.

Reply to
Detlef Bosau

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.