LTE+DSL < DSL

      LTE+DSL < DSL

      Hi...ich gebe zu, der Titel ist etwas kreativ, trifft aber genau auf mein Problem zu.

      Nachdem ich mit Hilfe des Forum hier leider feststellen musste, dass es aktuell für mich keine Möglichkeit gibt, mich mit einem anderen Sender zu verbinden, habe ich noch ein anderes Problem mit meinem SPH.

      Gerade wenn meine Sender gut ausgelastet ist, habe ich das Phänomen, dass meine download deutlich schlechter ist, als mir mein "fester" DSL-Anschluss eigentlich bieten müsste. Um der ganzen Sache mal Zahlen zu geben: Mit meinem 6000er DSL erreiche ich stabile Download-Raten von um die 650-6800kb/s. Schalte ich nun mein LTE dazu (also DSL+LTE) sind meine Download-Rate auf etwa 200kb/s. Das kann man auch sehr einfach nachvollziehen, indem ich während eines Downloads LTE einfach einmal ab und wieder zu schalte. Wie gesagt tritt dieses Problem aber nur auf, wenn mein LTE-Sender recht ausgelastet ist.

      Der Techniker der Telekom meint dazu, dass dies ein bekanntes Problem wäre und Huawei bereits an einem Firmware-Update arbeitet, welches Mitte diesen Jahres kommen soll.

      Gibt es hier ähnliche Erfahrungen oder hat vielleicht sogar jemand eine eigene Lösung dafür gefunden?

      Moin Leutz!

      @kingofpain: das ist ein bekanntes Problem -- sobald einer der Tunnel stark beeinträchtigt ist (oder schwankt), kann er den anderen ausbremsen. Die Tunnel müssen nämlich möglichst synchron gehalten werden...
      Ist also dein LTE extrem mieß - kann das den DSL stören. Wahrscheinlicher ist jedoch, das Störungen auf dem DSL (CRC-Fehler) das Ganze aus dem Tritt bringen oder eine Überlast am DSLAM zu Problemen führt. (schwankende/gestörte Bandbreite + verzögerte LTE-Zuschaltung)
      Der QueueSkbTimeOut könnte eine Lösung sein - eine andere Möglichkeit ist, die DSL-Verbindung zu stabilisieren durch einen höheren SNRM. (ich selbst habe momentan meinen DSL-Sync per SNRM sogar gedrückt - weil das fehlende DSL bei meinem 2000RAM zu verschmerzen ist, aber das LTE so früher zündet --> dadurch ruckeln viele Streams nich mehr, deren Bandbreite um die Schaltschwelle tänzelt)

      @genevt: der QueueSkbTimeOut ist die Wartezeit, bevor der Eingangspuffer geleert wird, wenn noch Pakete in der Reihenfolge fehlen...
      Höher bedeutet: lieber noch 'nen Moment warten, als den ganzen Pufferinhalt zu verwerfen und die Pakete neu anzufordern.
      ==> das macht bei eher langsamen DSL Sinn, weil Warten schneller als Neuanfordern ist.

      Niedriger bedeutet: früher verwerfen und neuanfordern.
      ==> kann bei schnellem DSL Sinn machen, wenn Neuanfordern schneller klappt, als auf die verspäteten Pakete zu warten.

      Bei meinem 2000RAM habe ich mir einen Wert von 4800 ertestet - höher beeinträchtigt manche UDPs.
      Damit fahre ich seit der FW.009 sauber ohne Aussetzer - weder im Up- noch im Download. (die .009 hatte bei mir vorher Denkpausen - dabei war dann 10-120sek. die Verbindung komplett blockiert, die .010 hatte nur noch Bandbreiteneinbrüche mit dem Standard-Timeout, aber immerhin keine Blockaden mehr. Beides konnte durch die 4800 behoben werden.)

      (übrigens entscheidet der HAAP die Verbindungsparameter anhand von Daten, welche der SPH im sendet ;) -- aber das ist ein anderes Thema...)

      mfg, emkay

      genevt schrieb:

      Ja, ich weiß, in dem Protokoll ist es sogar vorgesehen, dass man eine Bandbreite konfigurieren kann, die während des Bestehen des Tunnels geupdatet werden kann, nicht nur die Sync-Rate wie beim Verbindungsaufbau.

      Das ist nicht nur vorgesehen - das passiert sogar...
      Alle 10sek. holt sich der hybrid-Prozeß per xdslcmd die Verbindungsparameter und justiert notfalls nach (dank SRA kann der DSL-Sync während der Linktime schwanken)

      mfg, emkay

      genevt schrieb:

      Ich meinte, dass es vorsehen ist, den Wert zu ändern, oder warum heißt der Wert "Configured"?

      Kann ich nicht genau sagen, weil ich nicht weiß, auf was genau Du Dich beziehst (RFC/Quellcode) - sicher weiß ich momentan nur, das der hybrid-Prozeß regelmäßig die Daten für den HAAP updatet (und die Upload-SOAP per tc filter setzt).
      Ob mit configured nun gemeint ist, der User kann das konfigurieren - oder nur, daß der Client/SPH das konfiguriert - kann ich nicht genau sagen.

      Die Anderen Sachen kann man per strace ganz schön sehen.

      Quellcode

      1. strace -v -tt -y -yy -f -s4096 -p $(busybox-mips pgrep -f 'hybrid ')


      mfg, emkay

      hefr54 schrieb:

      Moin,
      @kingofpain
      mit Hilfe des Forum hier leider feststellen musste, dass es aktuell für mich keine Möglichkeit gibt, mich mit einem anderen Sender zu verbinden

      Ich glaube Du machst es dir zu einfach, was hast Du denn bisher unternommen um die Situation zu verbessern?
      Nur zu hoffen das jemand den "Zauberschalter" findet ist mir jedenfalls zu wenig. Man muß auch selber mal was
      probieren um weiter zu kommen. ;)
      Es gibt doch bestimmt noch andere Funkzellen in deiner Gegend. Darauf zu hoffen, dass die "T" eine Firmwareänderung mit Huawei
      zustande bringt kann noch sehr lange dauern :) Bisher kam da jedenfalls nichts "weltbewegendes" heraus :D

      Gruß hefr


      Naja...das eine Antenne 160m über den Erdboden quatsch wird hatten wir ja erörtert ;). Ansonsten gibt es leider keine anderen Funkzellen in meiner Nähe, die in Betracht kommen. Insgesamt sind es nur drei die möglich wären - eine davon ist halt zu weit überm Berg und die anderen beiden nehmen sich von der Auslastung her nicht viel - das würde also an dem Grundproblem nix ändern.

      Ich habe gerade mal bei mir einen QuesueSbk-Wert von 4800 getestet...als Änderung kann ich hier verzeichnen, dass es immer mal ein kurzes "Aufbäumen" der Downloadrate gibt...also der Download geht mal kurz auf >800kb/s, bevor er wieder auf 500kb/s und weniger fällt.

      Was DSL-CRC Fehler angeht liege ich aktuell bei 1 Fehler pro Minute. FEC-Fehler gibt es deutlich mehr aber das ist glaube ich "egal" oder? (hab ich zumindest mal gelesen).

      Kleiner Nachtrag:

      Ich habe gerade mal einen sehr niedrigen Queue-Wert probiert. Aktuell bin ich bei "5" und merke einen deutlichen Unterschied. Bisher sieht es so aus, als könnte ich meine DSL-Geschwindigkeit dauerhaft halten und bekomme über LTE das an "Plus" was gerade verfügbar ist. Ich werde das nochmal ne Weile so testen.

      hefr54 schrieb:

      Moin,
      mit dem Queue-Wert kannst Du das Problem schätze ich mal nicht lösen. Das hilft nur bei DL einbrüchen auf Grund von Paketverlusten.
      Was Du brauchst ist eine Automatik, die erkennt wenn LTE schlapp macht und es dann deaktiviert. Wenn ich es recht in Erinnerung
      habe zieht es ja bei Dir das DSL mit runter oder? Wenn also LTE einbricht wäre ja DSL only die Lösung ist nur etwas unbequem zu
      händeln. Da wäre eine Automatik schon gut, der "Schalter" ist ja da - muß "nur" noch mit einer Auswertelogik des LTE vernüpft werden.
      Trotzdem würde ich an deiner Stelle noch mal schauen ob nicht doch eine ander Zelle ohne 100m+ Mast zu erreichen ist. Es kommen ja
      immer neue dazu. Ich hatte vorhin im Haus unten eine Zelle aus 11Km (800MHz) auf dem Smartphone und eine aus 14Km.
      Da lohnt es sich öfter mal die EMF-Datenbank zu bemühen.

      Gruß hefr


      Naja zumindest macht es bisher den Anschein, als würde ein sehr niedriger Queue Wert bei mir helfen. Meine Durchschnittsgeschwindigkeit hat sich jedenfalls deutlich verbessert.
      Natürlich hoffe ich auch, dass es vielleicht mal noch einen neuen, günstigeren Mast für mich gibt. Aber lt. Auskunft der Telekom soll sich da in nächster Zeit bei mir nix tun.

      Moin Leutz!

      Ich hab' jetzt auch noch mal einen niedrigen QueueSkbTimeOut im Test - sieht eigentlich soweit gut aus.
      ==> könnte darauf hindeuten, daß da seit damals was am Hybrid-Server gedreht wurde.
      (eher nicht die SPH-Firmware - dafür ist die .012 der .010 zu ähnlich - und mit der .010 hatte ich damals mit niedrigem TimeOut Probleme)

      Laut Schmidti im TH-Forum sollte die Einstellung eh aus der Firmware verschwinden - da wär's schon ok, wenn vorher auch das Problem beseitigt wird, wofür wir die Einstellung brauchten :D

      @kingofpain: wie gesagt - notfalls könnt' man noch am SNRM schrauben um das Bonding zu stabilisieren.
      FECs sind allerdings nich so wichtig - die werden korrigiert. Sind aber ein Anzeichen für die Güte des Signals.
      Ein CRC pro Minute kommt mir persönlich hoch vor (ich hab' 1 seit gestern), aber habe da auch nicht so den Vergleich.

      mfg, emkay

      EDIT: So... jetzt zur Nachtzeit konnte ich mal etwas testen.
      Mit QueueSkbTimeOut von '4' kam es zwar nicht zu irgendwelchen Unterbrechungen/Einbrüchen - aber die LTE-Rampe war wieder da... Die Bandbreite beim Download steigt bei mir mit niedrigem QueueSkbTimeOut nur langsam an, mit dem Ergebnis das die Durchschnittsgeschwindigkeit niedriger ist. Mit meinen gewohnten 4800 ist die LTE-Rampe kaum wahrnehmbar.
      (eventuell glättet die längere Pufferung die gemessene Bandbreite)

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „eMKay77“ ()

      Also hast Du Deinen "Ursprungswert von 100" auf 5 geändert ?

      Habe keine Abbrüche bei DSL, aber meine Werte gehen in der Rush-Our ganz schön in den Keller.

      Aber für das Problem werde ich mit dem Ändern des Wertes wohl keine Verbesserung erzielen können, oder was meint Ihr ?

      Falls doch, Wert eher erhöhen oder niedriger setzen ?

      Richtig...ich habe dir ursprünglichen 100 auf 5 gesetzt. Nach wie vor kann ich dadurch eine deutliche Verbesserung sehen. Meine Download-Werte gehen selbst zur Rush-Hour nicht unter "DSL-Niveau" - meist habe ich auch noch ein kleines LTE-Plus (zu Stoßzeiten) - wenn nix los ist, komme ich auch auf meine volle Geschwindigkeit.

      Ich würde an deiner Stelle einfach mal mit den Werten spielen. Falls es nix bringt kannst du es ja wieder auf 100 zurücksetzen. Ich habe die positive Änderung sofort gemerkt.

      Moin @Snoopy!

      Nein... ab der v03 macht der QueueSbkTimeOut an den meisten Anschlüssen wenig Unterschied.
      Sehr hohe Werte erzeugen bei mir einen schönen Sinus im Download :D
      Der Standard-Wert passt bei mir jetzt ganz gut (hab' allerdings ja auch mittlerweile 94.000 statt 2.000 DSL ;) ).

      --> ab der v03 überlebt die Einstellung keinen Reboot mehr!
      (müsste man also nach jedem Reboot neu machen)

      Naja - und bin ja grad' eh am 'Basteln', um auf den Asus umzuziehen - da braucht's hoffentlich sowas nich mehr...

      mfg, emkay