Fastpath reduziert die Geschwindigkeit?!

[Kenny]

Hi,
ich habe gerade mein Profil auf dein "nicht-fastpath-profil" umstellen lassen und bemerkt, dass der Speed zunimmt (vorallem im Upload, ca 200 kbit/s).
Kann sich jemand erklären, warum mein Fastpath mich so ausbremst???




Greetz Kenny


edit: Die Sache hat sich erledigt, meine Leitung hat wohl ein paar Probleme. Muss ich eben ohne Fastpath zoggn (FEC-Coding-Rate steigt ziemlich start an bei aktivierung von Fastpath)

[/dev/null]

Imho liegt das daran, das die Pakete dann mit Fehlerkorrektur (interleaved) verschickt werden. Dadurch verringert sich die Anzahl der Fehlerhaften Pakete und es ist eine höhere Bitrate möglich.

[Kenny]

nur ändert sich im Upload ja eigentlich gar nichts, da steht bei mir immer noch interleaved (confused).
Im Download war das klar, aber im Upload?!



Greetz Kenny

[/dev/null]

Das macht keinen Sinn, man kann FP nicht nur für den kompletten Anschluss schalten und nicht nur für den down- oder den upstream... komisch, komisch...

[Herbie]

Das kommt wohl auch auf die Größe der Dateien bzw. verschickten Anfragen an.

Bsp.: Du möchstest einen Download starten. der Befehl an die entsprechende Seite ist relativ klein, sollte sich daher in einer geringen Anzahl von Paket verschicken lassen. Wenn da mal eines verloren geht oder nicht intakt ankommt ist das Latz.

Dein Download von mehreren MB besteht dagegen aus einer großen Anzahl an Datenpaketen. Diese werden immer in Schüben übertragen (sagen wir mal immer 10 Pakete auf einmal). Da der bisherige Standard keine Identifizierung der einzelnen Pakete vorsieht bedeutet das: kommt auch nur eines nicht oder nicht korrekt an werden alle Pakete dieses Schubs noch einmal neu gezogen. Wenn jetzt von 100 Paketen acht defekt sind (und sich "günstig" über die Pakete verteilen) müssen im Extremfall statt 100 180 Pakete transportiert werden, und das kann die Bandbreite dann doch schon ein wenig drücken.

Die Fehlerkorrektur hilft zwar nicht bei jedem beschädigten Paket, aber wenn 50% gerettet weren wären das in meinem Beispiel 40 Pakete die nicht erneut über die Leitung gehen müssen, und da kann sich dann schon was bewegen.

[Kenny]

und warum zeigt meine Fritz.Box dann im Upload immer noch "interleaved" an???
irwie versteh ich das nich


Empfangsrichtung Senderichtung
Leitungskapazität kBit/s 7504 712
ATM-Datenrate kBit/s 7487 707
Nutz-Datenrate kBit/s 6781 641
Latenzpfad fast interleaved
Latenz ms 0 2
Frame Coding Rate kBit/s 16 8
FEC Coding Rate kBit/s 0 261
Trellis Coding Rate kBit/s 632 72
Aushandlung adaptive adaptive

Signal/Rauschtoleranz dB 5 6
Leitungsdämpfung dB 33 29
Status f003ce20 f0000074

(man beachte die FEC Coding Rate, die is im Download auf 0, aber im Upload auf 261).
Irgendwie verwirrt mich das, kann mich mal jemand aufklären???



Greetz Kenny

[/dev/null]

Zur FEC sagt Wikipedia folgendes:

The code rate or information rate of a forward error correction (FEC) code, for example a convolutional code, states what portion of the total amount of information that is useful (non redundant). The code rate is typically a fractional number. If the code rate is k/n, for every k bits of useful information, the coder generates totally n bits of data, of which n-k are redundant.

If R is the gross bitrate or data signalling rate (inclusive of redundant error coding), the net bitrate (the useful bit rate exclusive of error coding) is ≤ R•k/n.

For example: The code rate of a convolutional code may typically be 1/2, 2/3, 3/4, 5/6, 7/8, etc, corresponding to that one redundant bit is inserted after every single, second, third, etc, bit. The code rate of the Reed Solomon block code denoted RS(204,188) is 188/204, corresponding to that 204 - 188 = 16 redundant bytes are added to each block of 188 byte of useful information.

A few error correction codes do not have a fixed code rate -- rateless erasure codes.
(Quelle)

Etwas ausführlicher steht es hier

[Kenny]

soweit war mir das klar, es erklärt aber nicht, warum ich nur im Upload dieses FEC "aktiviert" habe....




Greetz Kenny

[/dev/null]

Das kann ich Dir auch nicht sagen. Hast Du mal bei AVM nachgefragt? Das würde mich auch interessieren was die dazu sagen...

[Kenny]

das wäre mein nächster schritt gewesen^^
Nachdem jetzt keiner so richtig zu wissen scheint, woher das kommt (worüber ich, wegen meines selbstvertrauens, sogar fast glücklich bin XD *gg*), schreib ich mal ne mail an AVM.



Greetz Kenny

[/dev/null]

hrhr
halt uns auf dem laufenden

[Kenny]

aber natürlich
E-Mail ging gerade raus.
So wie ich die Jungs von AVM kenne, wird da ne ziemlich ausführliche Antwort kommen, die ich natürlich hier veröffentlichen werde.


Greetz Kenny

[Kenny]

Jetzt ist dann endlich mal ne Antwort zu diesem Thema eingetroffen, hört sich für mich so an, als ob die auch nich wüssten, warum das so ist mit dem Fastpath im Upload.

Code: Alles auswählen

Sehr geehrter Herr *****,

vielen Dank für Ihre Rückmeldung.

Unserer Analyse zu Folge hat der Anbieter Fastpath ganz offensichtlich nur für den Downstream aktiviert.

Bitte beachten Sie, dass der Anschluss hier ohnehin schon mit einer übermäßig hohen max. Bandbreite sowohl im Downstream als auch im Upstream gefahren wird. Der Wunsch hier dennoch auch noch Fastpath zu schalten und somit latent eine massive Instabilität zu erzeugen, erscheint jedenfalls schon durchaus etwas "abenteuerlich". Es ist daher gut nachvollziehbar, dass der schon ohne Fastpath extrem kritisch zu bewertende Zustand des Anschlusses im Upstream nicht auch noch mittels Fastpath vollständig überdehnt wird.

Mit freundlichen Grüßen aus Berlin

*******(AVM Support)

Meine Meinung zu diesem Thema:
Die Fritz.Box verträgt sich nicht mit dem DSLAM (Centillium Chip) und irgendetwas läuft bei der Aushandlung mit dem DSLAM schief.



Greetz Kenny

[/dev/null]

Interessante Antwort von AVM...