Leider ist mein englisch nicht gut genug, um das auf englisch fragen zu können.
Seit Kurzem nutze ich einen BT Home Hub 5A für alles. Also auch für die Verbindung mit dem DSL. Es handelt sich um DSL 100 bei O2 (über eine Telekom-Leitung). Es funktioniert soweit sehr gut. Allerdings wird die Verbindung etwa 3 mal am Tag getrennt und neu aufgebaut. Das neu verbinden dauert allerding immer ein wenig, weshalb es teilweise stark stört.
Mit der Original O2-Box, hatte ich das m. E. nie, dass die Leitung mehrmals am Tag neu verbunden wurde. Ich kann man gar nicht erinnern, dass ich die Trennung jemals bemerkt hätte.
Kann es sein, dass der Router zu schnell bzw. schneller bemerkt, wenn dsl.0 down ist und die O2-Box länger wartet und dadurch ein keep-alive greift?
Hier mal eine Liste der Neuverbindungen bzw. der jeweiligen Verbindungsdauern:
Thu Jun 10 18:51:55 2021 daemon.info pppd: Connect time 357.4 minutes.
Thu Jun 10 23:20:13 2021 daemon.info pppd: Connect time 265.8 minutes.
Fri Jun 11 03:31:16 2021 daemon.info pppd: Connect time 248.5 minutes.
Fri Jun 11 04:03:34 2021 daemon.info pppd: Connect time 30.1 minutes.
Fri Jun 11 06:08:45 2021 daemon.info pppd: Connect time 122.7 minutes.
Zumindest bei diesen 5 Trennungen dauerte es immer etwas über 2 min, bis die Verbindung wieder Up war.
Das ist per se kein Problem, aber da dies ein internationales Forum ist, solltest Du immer auch eine Uebersetzung Deines Textes ins Englische mit posten, z.B. von Google Translate oder aehnliches.
Please always include an english version of your post, machine translations like google translate should be sufficient...
Die 2 Minuten Pausen deuten darauf hin, dass die DSL Verbindung abbricht und neu aufgebaut wird (das dauert halt ein bisschen), die pppd Fehler kommen daher, dass ohne DSL auch PPPoE sitll steht. In der Uebersichts-Seite der LUCI-GUI solltest Du mal beobachten welcher Status da fuer den DSL link steht, vor, waehrend und nach einer solchen Stoerung, ich erwarte, dass da waehrend der AUszeit nicht showtime stehen wird.
You report PPPoE reconnects which take around 2 minutes to clear up again, which IMHO indicates that the issue probably is a loss of sync of the DSL connection, with PPPoE "just" failing because its underlaying carrier got lost. Looking at the Overview page in the GUI should give you some insight of the DSL status during the epochs when PPPoE is down, I would expect that to be a different state than the normal showtime state for an operational link.
Ich stimme @gromx, dass es sinnvoll ist, verschiedene Firmware blobs fuer das DSL modem auszuprobieren, xrx200 modems wie im HH5A oder auch der FritzBox 7490 sind bekannt dafuer an Broadcom Linecards mit Vectoring und G.INP Probleme zu haben. (AVM verwendet modernere Blobs und modernere Kerntreiber als OpenWrt so dass es leider nicht ausreicht einfach den aktuellsten Blob einer FB7490 zu verwenden....)
@gromx recommendation to try different DSL firmware blobs on the modem seems spot on, the xrx200 SoC used by the HH5A anf the FB7490 is known to have soe issues with Broadcom line cards, especially once bi-directional vectoring is used and even more bidirectional G.INP retransmissions (which is exactly how Deutsche Telekom operates the lines/TALs that O2 rents from them)
Please note, posting your original german text is fine, as long as there is an english translation for the majority of poster's not capable/willing to read German.
This indicates a loss of sync event and a subsequent resynchronization. Unfortunately not uncommon with the combination of xrx200 modems with Deutsche Telekoms MSAN Line cards. I was in the same boat and ended up switching to a broadcom based modem, simply because the frequent re-syncs became to annoying, and I had tried multiple firmware blobs and desired a stable solution (because the other users on my network started to complain ;))
That indicates a non-vectoring capable firmware, for which the MSAN selects a fall-bach VDSL2 profile without vectoring restricted to the lowest 2.2 MHz as these are not used for vectoring to allow older non-vectoring-friendly ADSL modems to not cause problems....
I admit this is not nice and I remember that I also experimented with various firmware before getting to this stable state. On Swisscom infrastructure this really worked rock solid for me. I don't know what exact DSLAM they used. However, I do remember that regardless of that some Swiss ISPs are just insanely stupid and mess with their network all the time which can also cause frequent disconnects. Once moving to a sane provider on the exact same last mile equipment and all such troubles were gone. Sorry, that I can not be more helpful on this.
As a side note I'm still dreaming of an equally well single OpenWrt router solution for the 500+ Mbps g.fast connection I got for X-mas but so far no such is in sight...
These numbers imply that your 80/27 and now 70/30 might be caused by the Assia DSLExpresse DLM system Deutsche Telekom operates on all its DSL-links (and which L2-BSA resellers like O2/Telefonica inherit). If that system's stability criteria are not met it configures the DSLAM to only sync at reduced rates (these limit currently seem to be even Mbps values, but many modems sync a few Kbps below that limit, e.g. 79.987 looks like a sync with the DSLAM's maximum limited to 80.000, another symptom of that intervention are relative large SNR margins >> 10 dB). The DLM system interprets resyncs as a sign of instability and iteratively reduces the sync rates. Now, once the modem is stable again the same system will slowly increase the maximum sync rates again IFF the combination of performance and error counters is collects and evaluates indicate that a highe sync rate will be sufficiently stable....
In my case with the HH5A I never really reached stability, only after switching to a broacom modem sync rates climbed up again from 92/27 to my current 116/37, but I probably gave up on the "finding the perfect firmware blob" too early, and after the modem change I re did my internal wiring which reduced the number of errors per tie significantly (so it might be worth trying again with the HH5A, it is just hard to motivate myself to do this, the broacom modem in bridge mode simply works reliably, and my OpenWrt router behind it does not care whether the bridged modem runs openwrt or a proprietary system...)
I will definitely do a little more testing. I absolutely wanted everything in one device.
Unfortunately, I don't understand what U say about the values. That are my actually values:
Data Rate:69.987 Mb/s / 26.997 Mb/s
Max. Attainable Data Rate (ATTNDR):69.836 Mb/s / 35.127 Mb/s
Latency:0.18 ms / 0.0 ms
Line Attenuation (LATN):16.9 dB / 18.4 dB
Signal Attenuation (SATN):16.9 dB / 18.3 dB
Noise Margin (SNR):14.3 dB / 14.4 dB
Aggregate Transmit Power (ACTATP):7.8 dB / 14.4 dB
That severely limits your choices, especially f you want to use OpenWrt. When I got my HH5A I had the same idea, but quickly realized that for my use case (DSL, NAT, firewall, SQM, WiFi) the router was simply not performant enough (on a 100/40 link) so I grudgingly configured it as bridged modem only (albeit one with a nice OpenWrt GUI ) and connected another router (which I had already sitting on a shelf anyway). I note that when I switched from classical analog telephony to all-IP/VoIP I bought a gigaset VoIP basestation so I do not relay on my router for VoIP services beyond internet access...
Sorry, I tried to put too much information into too few words ;). The core message is, that once you found a firmware that results in higher stability it is very likely that over some weeks the sync speed will also increase again....
These are the sync speeds, and these look damn close to a hypothetical DSLAM-limit of 70.000 / 27.000 Mb/s.
These look quite high, given that Telekom policy seems to be either configure 10 or 6 dB as SNR margin (the higher the SNR the lower the sync/speed but the more robust the link against interference).
So again, if you find a reliable firmware blob fir the modem, your sync will in all likelihood increase again somewhat.
Broadcom DSL modems are not supported by any open source OS, and that includes OpenWrt, no idea about WiFi, but probably also problematic.
I don't know if is is useful, but this is what I get on a Telekom VDSL with the same hardware and the same Firmware:
Data Rate: Down: 63.668 Mb/s / Up: 12.735 Mb/s
Line Attenuation (LATN): Down: 13.5 dB / Up: 13.1 dB
Signal Attenuation (SATN): Down: 13.5 dB / Up: 13.5 dB
Noise Margin (SNR): Down: 4.8 dB / Up: 25.6 dB
Aggregate Transmit Power (ACTATP): Down: 0.5 dB / Up: 8.3 dB
Max. Attainable Data Rate (ATTNDR): Down: 61.050 Mb/s / Up: 38.219 Mb/s
Line Uptime Seconds: 13645821
Line Uptime: 157d 22h 30m 21s
I pay for a 50/10 connection, thus I don't have much to complain about. If I look at the historical data, it seems that it was syncing at an higher max down rate initially and it stabilized to these values after a few reconnects and from what I can see it never tried to bump them up again. I don't remember if the higher data rates where with this firmware or another.
So when they introduced vectoring DT also tried to introduce "open profiles" that is they tried to configure all links to use (up to) the highest sync rates they allow (the exact numbers changed, but right now for profile 17a that would be something like 116/42? or so). It turned out that this was not working as well as hoped, so DT switched back to profiles tailored for the specific contract rates (50/10 in your case). BUT at the same time the German regulator also clarified that contract rates are to be interpreted as net TCP/IP goodput and ISPs started* to (over-)provision** plans such that the contract speed could actually be measured. And since there are also yearly reports about the level of "over-achievement/-provisioning" by ISPs, DT opted for generous sync corridors for a given contract rate, with your ~64/13 being close to the allowed maximum sync of the DSLAM/MSAN.
I would guess you might have looked at these values before and after the switching of the provisioned rates?
*) Well the DOCSIS ISPs traditionally configured enough gross speed so that end users actually could see the contracted speeds (and more) as goodput in speedtest results; IIRC this was based/codified in a CISCO note or whitepaper, but DSL ISPs tended to interpret contract speeds as gross rates....
**) Over-provisioning is one way of describing it, under-reporting is another way ;), but this is semantics as the consequence is that consumers git a slight speed increase without a price hike, so thanks EU!