Schwellwert für LTE Bündelung

      Schwellwert für LTE Bündelung

      Hallo Zusammen,

      klasse was ihr hier mit dem Firmware anstellt, ich bin beeindruckt.

      Habt ihr schon herausgefunden wie Festgelegt wurde ab wann über LTE geroutet wird? Ich habe das Problem das ich zu manchen Tageszeiten so wenig Bandbreite über DSL bei mir ankommt, dass der Schwellwert für LTE nicht erreicht wird. Wenn so ein Fall auftritt habe ich bisher das Telefonkabel gezogen damit ich wieder mit 30mbit statts 10mbit surfen kann. Die Lösung die DSL Route zyklisch wegzuwerfen damit alles über LTE läuft ist schon ein sehr guter Workaround, doch richtig genial wäre es wenn man den Schwellwert finden und ändern könnte damit man sowohl eine stabile Festnetzverbindung als auch eine schnelle LTE Verbindung gleichzeitig nutzen kann.

      Viele Grüße
      Falco
      Hey super,

      das ist ja ein fießer Hack :D
      Einfach dem xdslcmd Aufrufer einen anderen Wert zurück geben.

      Danke schon mal für die schnelle Antwort.

      Ist physischen ReTransmit für die Fehlerbehandlung?
      Bei SRA verstehe ich nicht ganz den Nutzen, welchen Einfluss haben diese auf die Bündelungsschwellwerte?
      Und was bedeutet SESDROP in dem Kontext?
      Moin @Falco!

      Falco schrieb:

      das ist ja ein fießer Hack
      da unter Linux Scripts absolut gleich behandelt werden zu Binaries, ist sowas möglich ;)

      Falco schrieb:

      Ist physischen ReTransmit für die Fehlerbehandlung?
      Der physische Retransmit ist eine Broadcom-eigene Fehlerbehandlungs-Option - dabei wird bei Paketfehlern, daß Neuanfordern des Datenpakets auf Hardware-Ebene durchgeführt, ohne daß die oberen logischen Schichten davon etwas mitbekommen. --> wenn der DSLAM es unterstützt gibt's weniger messbare Fehler.

      Falco schrieb:

      Bei SRA verstehe ich nicht ganz den Nutzen,
      Tja, im SPH ist SRA standardmäßig aktiviert... obwohl die Telekom es offiziell gar nicht unterstützt. Hierfür werden aber Bits reserviert - die man besser nutzen kann. Deaktivieren wirkt sich positiv auf das Interleaving/Ping aus.

      Falco schrieb:

      Und was bedeutet SESDROP in dem Kontext?
      Der SesDrop ist dummerweise nicht wirklich dokumentiert - die meisten gehen davon aus, daß es für 'Session Drop' steht und Einfluß darauf nimmt, wann die Verbindung bei Fehlern getrennt wird.
      Aber auch hierfür werden Bits reserviert - das Abschalten führt zu besserem Interleaving/Ping.

      Der Wrapper ist im Grunde an meine damalige Leitung angepasst - und sollte eventuell bei stärkeren Leitungen angepasst werden.
      (er nutzt im Bonding-Betrieb nur noch 200kbit/s in beide Richtungen - fast alles geht also über LTE)

      Wenn es Dir also darum geht, die Schwelle nur etwas zu verschieben, dann solltest Du drate/urate anpassen.
      urate --> etwas niedriger, als dein minimaler UP-Sync
      drate --> etwas niedriger, als dein minimaler Download zu schlechten Zeiten

      mfg, emkay
      Danke dir.

      Deine ursprüngliche Nachricht ließt sich so als hättest du Telnet dauerhaft an. Hast du schon ausprobiert ob die Inhalte von /bin persistend sind? Wäre interesannt zu erfahren ob anpassen einen Neustart oder den Firmware Update Process überstehen.

      Ich schau mal ob es sinvoll ist sich etwas mehr mit der LTE Konfiguration zu beschäftigen.
      @Falco ...in der V2 ist der telnetd vorhanden und man hat root-Zugriff und kann über ein remount Schreibzugriff auf das /bin Verzeichnis bekommen und Dateien verändern. Die Änderungen sind bis zum nächsten Firmwareupgrade persistent. Alternativ dazu kannst Du das bin-Verzeichnis auch auf USB-Stick auslagern und so nur minimal ins Originalsystem eingreifen.

      In der V3 wurde deswegen von Telekom/Huawei der telnetd entfernt.

      Grüße

      danXde
      Ein zusätzliches Bin auf dem USB Stick klingt ja verlockend. Habt ihr schon ausprobiert ob es für die Bündelungsfunktion ausreicht den Stick ganz vorne in den Path zu legen? Nicht auszuschließen das jemand die Verbindungsparameter über einen absoluten Pfad aufruft, da müsste ich das Root Dateisystem nicht für jede Ändernung mit Schreibrechten versehen.

      Ich würde gern die Profile Datei ausführen um zu sehen das die Übertragen fehlerfrei war, denn mehr als Berechtigungen kann ich auf dem gehärteten System vermutlich nicht auf der Komandozeile prüfen. Mir macht der bootsrap etwas sorgen wenn ich das profile noch mal ausführe. Nicht das bei einer ungeprüften Profile Änderung die Oberfläche nach dem Reboot nicht mehr läuft.
      Da sind Schreibrechte auf das Root Dateisystem bald noch sicherer, denn ein Tippfehler ist schnell gemacht.

      Mit welcher Zugriffsvariante auf eure bin Wrapper fühlt ihr euch denn wohl? Find das mit dem Profile grade nicht mehr so toll. Vermutlich ist ein dauerhafter Telnetzugang doch das beste.
      Moin @Falco!

      Was genau meinst Du denn bitte mit Bündelungsfunktion?

      Der xdslcmd-Wrapper sollte wohl besser im echten RootFS liegen - der USB-Stick ist erst etwa 50-55Sek. nach dem Boot des SPHs verfügbar... das könnte etwas spät sein.

      Für alles, was nicht unbedingt im echten RootFS liegen muß, ist der BootStrap der sicherste Weg.
      Den macht man einmal - danach macht man alle Änderungen nur noch am Stick - sollte etwas schiefgehen, zieht man einfach den Stick ab und alles ist wieder normal...
      (genau das war der Grund, den BootStrap zu entwickeln ;) )

      Die Profile-Datei auszuführen ist keine gute Idee - bringt den Router zum Absturz, da sie als Init-Datei mißbraucht wird.
      (das kann man verhindern, in dem man sie mit einer Schutzzeile versieht -- unbedingt notwendig, wenn man zB. OpenSSH installiert)
      Wenn aber Dateigröße und Dateirechte stimmen, sollte es schon passen... sonst könntest Du natürlich auch eine Checksum berechnen - wenn Du ganz sicher gehen willst.

      Solange Du bei Anpassungen nur mtd0 berührst - und Dich von anderen Devices fernhälst - kommst Du im Notfall immer wieder per Firmware-Flash zum Originalzustand zurück. (es gibt ein Notfall-Formular, welches selbst bei zerstörtem RootFS noch funktioniert)
      Zusätzlich hat der SPH ein Auto-Recovery, welches anspringt, wenn der BootLoader meint, die Installation ist unbootbar --> dann ist man plötzlich in der zuletzt lauffähigen FW-Version und wundert sich :D
      (der SPH hat 2 Flash-Bereiche für Firmwares, die er abwechselnd nutzt - deshalb kann er zurück switchen)

      Der Telnet-Zugang ist übrigens eh persistent - bis Du ihn deaktivierst oder einen Werksreset machst.

      mfg, emkay
      Gut, da reicht mir die einmalige Konfiguration. Noch hab ich keine hoch optimierte LTE verbindung bei der man am liebsten Wetterabhängig an der Konfiguration schraubt ;)

      Mit Bündelungsfunktion mein ich das Stück Software welches steuert ab wann basierend auf xdslcmd nach LTE geroutet wird. Wenn dort /bin/xdslcmd direkt aufgerufen würde, dann wäre das mit dem USB Bin sowieso nicht möglich gewesen.

      Mit Schreibzugriff auf dem Dateisystem fühle ich mich auf jeden Fall wohler als an Boot Dateien zu schreiben ohne diese zum test ausführen zu dürfen.
      Danke euch.

      Warum hat man Bedarf OpenSSH zu installieren?

      Falco schrieb:

      Noch hab ich keine hoch optimierte LTE verbindung bei der man am liebsten Wetterabhängig an der Konfiguration schraubt
      Ich meinte, wetterabhängig an der DSL-Konfiguration zu schrauben :D
      Man kann in dem Wrapper eben auch den SNR anpassen (der steht normal auf 100% und beeinflusst Fehlerquote und Sync)

      Falco schrieb:

      Mit Bündelungsfunktion mein ich das Stück Software welches steuert ab wann basierend auf xdslcmd nach LTE geroutet wird. Wenn dort /bin/xdslcmd direkt aufgerufen würde, dann wäre das mit dem USB Bin sowieso nicht möglich gewesen.
      Wenn ich ehrlich bin, hab' ich gerade nicht im Kopf, ob der Hybrid-Client xdslcmd mit oder ohne kompletten Pfad aufruft -- allerdings passiert das schon recht früh, so daß eh die Gefahr bestünde, daß der USB-Stick noch nicht eingebunden wäre...
      Ich selbst habe den xdslcmd-Wrapper immer im echten RootFS gehabt.
      (nach jeder Änderung am besten 'busybox-mips sync' und ein sauberes 'umount' -- und einen Moment warten, bevor man rebootet)

      Falco schrieb:

      Warum hat man Bedarf OpenSSH zu installieren?
      Das eingebaute Telnet des SPHs hat ein nerviges TimeOut...
      Und mit OpenSSH funktioniert Syntax-Highlighting in der Konsole und man kann auf SSH 'pipen' -- ein Script am PC kann also Befehle auf dem SPH direkt ausführen und bekommt die Ausgabe zurück. Ausserdem hat man damit dann auch SFTP...
      (ist aber wohl nicht für jeden interessant/wichtig)

      mfg, emkay
      Stimmt, die xdslcmd binary wird vermutlich nur nach dem Verbindungsaufbau aufgerufen. War jetzt noch von einem regelmäßigen Aufruf ausgegangen, aber das wäre unlogisch da sich die ausgehandelten Verbindungsparameter wärend der Verbindungslaufzeit nicht ändern.

      Das macht ein bischen die Möglichkeiten zur Erweiterung kaputt, aber unflexibel ist mir auch recht. 40mbit mehr oder weniger im Download ist mir eigentlich recht egal solang wenisgtens 20mbit übrig bleiben. Hauptsache der Upload ist voll da, der hatte bisher noch keine Probleme gemacht. Daher werde ich den Upload nicht überschreiben und vom Download das nutzen was das LTE an Bandbreite für mich übrig hat.

      Falco schrieb:

      War jetzt noch von einem regelmäßigen Aufruf ausgegangen, aber das wäre unlogisch da sich die ausgehandelten Verbindungsparameter wärend der Verbindungslaufzeit nicht ändern.
      xdslcmd wird alle 10sek. aufgerufen - eben weil der HAAP alle 10sek. den Status der DSL-Verbindung haben will...
      (naja - könnten mittlerweile auch 20sek. sein - glaube da wurde gedreht.)

      Der Grund ist einfach --> der HAAP reagiert auch, wenn Du im Betrieb einen Re-Sync hast oder die DSL-Verbindung wegbricht.
      Wie überwacht ihr die Verbindungsunterbrechungen DSL? Würde gern etwas beobachten ob es bei meiner Leitung Wert ist SRA zu deaktivieren.
      Sollte man die Auswirkungen von SRA nicht auch direkt über die Leitungsparameter überprüfen können? Rein theoretisch sollte die SRA Abschaltung nur vom Vorteil sein wenn die SRA Implementierung zu defensiv ist und zu schnell nachgibt und zu lange auf den langsamen Parameter verharrt.

      Im übrigen ist mein Upload permanent niedriger als syncronisiert, ich habe noch nie den Syncronisierte Uploadbandbreite erreicht. 80% reichen aber schon um die ausgehenden Packete über LTE zu Routen. Es wundert mich dass das bei Upload funktioniert. Es könnte aber daran liegen das der Router für ausgehende Daten die Warteschlange analysieren kann.

      Aber zumindest bei überschreitung von 100% Syncronistaion wird automatisch LTE geroutet, nehme ich zumindest an, nachdem du uns gesagt hast dass die Definition der angepassten Rückgabewerte das DSL Routung begrenzt.

      Wie macht ihr das eigentlich wenn die Leitung unlimitiert ist? Ich hab für die Uploadnutzung über Hierarchy Token Bucket geregelt. Grundsätzlich funktioniert das auch wenn die Bandbreite Variable ist. Doch es gibt da ein Problem wenn du Leitung sehr viel langsamer als die Angenommene Maximalbandbreite ist. Denn der Speedport nimmt zu viele Pakete an obwohl er die noch garnicht versendet. Die Ausgehende Warteschlange ist zu groß was dann dazu führt das keine Downloadanfragen mehr raus kommen.

      Wisst ihr wie man die Ausgehende Warteschlange Konfigurieren kann? Im besten fall wäre ein Warteschlangenauslastungsmonitoring toll um einschätzen zu können ob die Warteschlange nach Anpassung zu klein ist und leer läuft.
      Aktuell verhindere ich das selber da ich genau weis was die Leitung ausgehend Leistet wird die Warteschlange nicht mit mehr befütter als übertragbar ist.

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

      Moin Leutz!

      Wie ich oben ja auch schon geschrieben habe, unterstützt die Telekom offiziell kein SRA.

      An der Schraube zu drehen macht nur deshalb Sinn, weil bei eingeschaltetem SRA dafür eine Marge an Datenbits reserviert wird.
      --> und die kann man besser nutzen... (das habe ich oben aber auch geschrieben)

      Den Einfluß der Parameter kann man zB. mit 'xdslcmd info --show', 'xdslcmd profile --show' ...etc. sehen ;)

      Was die Schwellen betrifft: eigentlich simpel...
      Der SPH sendet in regelmäßigen Abständen die DSL-Sync-Werte an den HAAP, dieser berechnet die Schwellen.
      Die Download-Schwelle wird auf HAAP-Seite erzwungen - die Upload-Schwelle sendet er zurück an den SPH.
      Dieser setzt sie als Überlauf um.
      Der DSL-Tunnel (gre1) ist das Hauptinterface und hat eine feste Schwelle per Filter, alles darüber läuft auf den LTE-Tunnel (gre2) über.

      Täuscht man anderen Sync vor, nutzt der HAAP diese Werte, um daraus die Schwellen zu berechnen -- fertig.

      Den Upload einzeln kann man auch direkt beeinflussen, indem direkt die Überlauf-Grenze des gre1 verändert - das geht.

      Was die Warteschlangen betrifft -- es ist Linux... irgendwo im /proc-Dateisystem solltest Du fündig werden.

      mfg, emkay

      hefr54 schrieb:

      Dabei sollte man aber bedenken die DSL- Bandbreite wird um den Betrag reduziert den man setzt
      nicht um, sondern auf...
      (streng genommen, wird die DSL-Tunnel-Bandbreite auf den gesetzten Wert minus VOIP-Reserve gesetzt -- die DSL-Bandbreite bleibt unberührt)
      Bei meinem 2000RAM machte das auch SInn - habe auf 1,8MBit/s verzichtet, dafür aber keine LTE-Zuschaltverzögerung mehr gehabt. Und hatte rund 50MBit/s LTE...
      Die Ausgangs-Idee in diesem Thread ist aber: je nach Tageszeit erreicht die DSL-Leitung die Schwelle nicht.
      Und da ein leichtes herabsetzen des DSL-Syncs durchaus sinnvoll ;)

      danXde schrieb:

      ...und schafft platz für DSL-only Anwendungen. Somit ist die Bandbreite nicht komplett verloren. ;o)
      Nicht nur das... es macht auch Platz für Tunnel-Steuernachrichten, bei gestörten 384ern kann das den DSL-Tunnel stabilisieren... (hatten wir hier im Forum schon -- half)

      mfg, emkay

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