DSL 6000Ram wird nicht geschaltet
- Ersteller BlackTigerWH
- Erstellt am
Kommt drauf an auf welcher Seite 
Die Fehlerkorrektur ( Interleave ) seitens DSLAM ( ES= eingeschränkte Sekunden ) gibbet ja auch noch und wird meines Wissens bei der FB mitgezählt.
Selbst wenn es lokale Fehlerkorrektur is, würde das ja nen Arsch voll rechenarbeit sein = langsamer
Die Fehlerkorrektur ( Interleave ) seitens DSLAM ( ES= eingeschränkte Sekunden ) gibbet ja auch noch und wird meines Wissens bei der FB mitgezählt.
Selbst wenn es lokale Fehlerkorrektur is, würde das ja nen Arsch voll rechenarbeit sein = langsamer
Zuletzt bearbeitet:
Richtig, die hohe Latenz führt z.B. bei Entertain zu Pixelbildung usw.
Bei so hohen FEC Fehlern wie der TE das hat ist es klar, dass die Leitung die 4,8Mbit nicht hergibt.
Meiner Meinung nach einfach auf 2Mbit lassen und gut ist.
@TE
Magst mal das Spektrum uppen.
Bei so hohen FEC Fehlern wie der TE das hat ist es klar, dass die Leitung die 4,8Mbit nicht hergibt.
Meiner Meinung nach einfach auf 2Mbit lassen und gut ist.
@TE
Magst mal das Spektrum uppen.
arvan
Admiral
- Registriert
- Juni 2008
- Beiträge
- 9.558
F
frankpr
Gast
Ich will mich ja nicht streiten, aber
Forward Error Correction heißt, daß das Paket an Hand der Checksumme rekonstruiert werden konnte und nicht nochmals übertragen werden muß. Und da die FEC in Hardware erfolgt, bremst sie auch so lange nicht, wie die Fehlerrate nicht zu hoch wird. Wie schon erwähnt wurde, steigt lediglich die Latenz. Das wiederum ist bis zu einem bestimmten Maß auch bei Entertain völlig unproblematisch.
Kritisch werden erst CRC Fehler, denn das sind Pakete, die nicht wiederhergestellt werden konnten. Bei TCP Anwendungen werden sie einfach erneut angefordert, was einerseits unkritisch ist, weil die Reihenfolge, in der die Pakete eintreffen, relativ unkritisch ist, da die Gesamtdatei eh erst zum Schluß wieder zusammengebastelt wird.
Zum Problem wird es bei Entertain, da das RTP Protoll, mit dem auch Multicast arbeitet, keine Transportsicherung benutzt und die unteren Layer einspringen müssen. Also werden Pakete mit CRC Fehlern in den Datenmüll geworfen. Eine erneute Übertragung hätte bei einer Echtzeitanwendung wie RTP auch keinen Sinn. Also hat man bei 1-2 aufeinanderfolgenden fehlerhaften und verworfenen Paketen Pixelfehler, werden es mehr, hat man Standbilder.
@TE: was bei einem testweisen Programmieren eines Profils läuft oder nicht, ist vollkommen irrelevant, entscheident ist, was das Produktionssystem zuläßt. Deshalb wird das Testprofil auch nicht lange auf Deinem Anschluß liegen, ein Update, und es ist wieder weg. Davon abgesehen, anderes Profil zum Testen schön und gut, es ist und bleibt ein Verstoß gegen geltende Arbeitsanweisungen. Wenn Du Pech hättest und auf der GBE Plattform liegen würdest, wäre die Möglichkeit relativ hoch, daß Du Dank dieses Tests und vor Allem, weil das Profil nach wie vor drauf liegt, bald gar kein DSL mehr hättest.
ist nicht korrekt.rooney723 schrieb:
Forward Error Correction heißt, daß das Paket an Hand der Checksumme rekonstruiert werden konnte und nicht nochmals übertragen werden muß. Und da die FEC in Hardware erfolgt, bremst sie auch so lange nicht, wie die Fehlerrate nicht zu hoch wird. Wie schon erwähnt wurde, steigt lediglich die Latenz. Das wiederum ist bis zu einem bestimmten Maß auch bei Entertain völlig unproblematisch.
Kritisch werden erst CRC Fehler, denn das sind Pakete, die nicht wiederhergestellt werden konnten. Bei TCP Anwendungen werden sie einfach erneut angefordert, was einerseits unkritisch ist, weil die Reihenfolge, in der die Pakete eintreffen, relativ unkritisch ist, da die Gesamtdatei eh erst zum Schluß wieder zusammengebastelt wird.
Zum Problem wird es bei Entertain, da das RTP Protoll, mit dem auch Multicast arbeitet, keine Transportsicherung benutzt und die unteren Layer einspringen müssen. Also werden Pakete mit CRC Fehlern in den Datenmüll geworfen. Eine erneute Übertragung hätte bei einer Echtzeitanwendung wie RTP auch keinen Sinn. Also hat man bei 1-2 aufeinanderfolgenden fehlerhaften und verworfenen Paketen Pixelfehler, werden es mehr, hat man Standbilder.
@TE: was bei einem testweisen Programmieren eines Profils läuft oder nicht, ist vollkommen irrelevant, entscheident ist, was das Produktionssystem zuläßt. Deshalb wird das Testprofil auch nicht lange auf Deinem Anschluß liegen, ein Update, und es ist wieder weg. Davon abgesehen, anderes Profil zum Testen schön und gut, es ist und bleibt ein Verstoß gegen geltende Arbeitsanweisungen. Wenn Du Pech hättest und auf der GBE Plattform liegen würdest, wäre die Möglichkeit relativ hoch, daß Du Dank dieses Tests und vor Allem, weil das Profil nach wie vor drauf liegt, bald gar kein DSL mehr hättest.
F
frankpr
Gast
Das ist in der Form aber aus keinem Post ersichtlich.
F
frankpr
Gast
Ja, von Dir.
- Registriert
- Nov. 2005
- Beiträge
- 255
hier das spektrum
Ergänzung ()
online Monitor
Ergänzung ()
dsl info
Ergänzung ()
Also bin jetzt noch nicht ganz schlau geworden das heißt jetzt definitiv das es die Telekom drosselt ? Könnte ich somit mit anderem Anbieter höhere Geschwindigkeit erzielen oder muß ich andere Wege suchen wie z. B. Optischen Kabel von Kumpel (ca. 0,8 Km entfernt hat DSL 16000) zu mir ziehen vielleicht beteiligt sich ja mein Nachbar bzw. mehrere hab selber Bagger kosten wären Kabel + Entschädigung für Landwirte + durchschießen unter Hauptstraße + Diesel und Verschleiß bzw. Zeit ca. 1 Tag)
Ergänzung ()
riegelt laut taskmanager genau bei 2000 ab also wird gedrosseltBlackTigerWH schrieb:
Da wird nichts gedrosselt, der Techniekr hat das genau richtig gemacht und zum testen deine Verbindung zwischen DSLAM und Modem auf 6Mbit RAM gestellt.
Die Verbindung vom DSLAM zum BBRAR jedoch ist immernoch auf 2Mbit konfiguriert, das bleibt sie auch bis du den 6000er bestellst.
- Registriert
- Nov. 2005
- Beiträge
- 255
Und wie bring ich die dazu das ich das bestellen kann ? Das ist ja mein eigenliches Problem das ich das nicht bestellen kann obwohl mehr gehen würde gibts da denn gar keine möglichkeiten ? Ist schon ganz auf Störsicherheit gestellt !
Zuletzt bearbeitet:
