I tried some other firmware from https://xdarklight.github.io/lantiq-xdsl-firmware-info/ but all with just 20Mbit down and 1.5 up. The only firmware which has the correct speed is this but here I have the reconnect 3 times a day:
ATU-C Vendor ID: Broadcom 194.80
ATU-C System Vendor ID: Broadcom
Chipset: Lantiq-VRX200
Firmware Version: 5.9.1.4.0.7
API Version: 4.17.18.6
XTSE Capabilities: 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2
Annex: B
Line Mode: G.993.5 (VDSL2 with down- and upstream vectoring)
Profile: 17a
Line State: UP [0x801: showtime_tc_sync]
Forward Error Correction Seconds (FECS): Near: 0 / Far: 18
Errored seconds (ES): Near: 0 / Far: 1519
Severely Errored Seconds (SES): Near: 0 / Far: 22
Loss of Signal Seconds (LOSS): Near: 10 / Far: 2
Unavailable Seconds (UAS): Near: 1740 / Far: 1740
Header Error Code Errors (HEC): Near: 0 / Far: 0
Non Pre-emtive CRC errors (CRC_P): Near: 0 / Far: 0
Pre-emtive CRC errors (CRCP_P): Near: 0 / Far: 0
Power Management Mode: L0 - Synchronized
Latency [Interleave Delay]: 0.16 ms [Fast] 0.0 ms [Fast]
Data Rate: Down: 79.987 Mb/s / Up: 26.997 Mb/s
Line Attenuation (LATN): Down: 16.9 dB / Up: 18.4 dB
Signal Attenuation (SATN): Down: 16.9 dB / Up: 18.3 dB
Noise Margin (SNR): Down: 11.3 dB / Up: 13.6 dB
Aggregate Transmit Power (ACTATP): Down: 7.8 dB / Up: 14.4 dB
Max. Attainable Data Rate (ATTNDR): Down: 99.139 Mb/s / Up: 33.717 Mb/s
Line Uptime Seconds: 49
Line Uptime: 49s
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 still have 2 other users and they can live with it.
Anyway. It is not nice. I think I will try all of the firmware step by step to check if I get the full speed and to test how long does the connection stay.
I hope so there is any better solution then the actual. My wish was to have only one device with the complete functionality.
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.
For me, on a Telekom line and a Draytek Vigor 130 modem, it takes somewhere between 10-14 days for the line rates to recover after multiple DSL disconnects (e.g. a modem firmware upgrade).
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!
Yes, that seems to be a number that comes up often, but according to DT there are no fixed intervals that a strictly enforced, so this is probably driven by the DLM's control law, which might also look at the derivative of the change of error rates or similarly (such that it carefully tries to approach what it considers to be the robustly sustainable sync rate from below, after all its main purpose seems not to be to stabilize links after they proved unstable, but ideally to pro-actively set each link's sync rate such that the link never gets unstable*)**.
*) With various degrees of success, seems to work well for some links and almost not at all for others....
**) Most users probably do not notice/care much about every individual Mbps of the sync rate, but almost everybody notices unenforced resyncs, especially if these happen during a video conference of a phone call, so the pro-active approach should result in a reduction in the costly support infrastructure (hotlines/technicians).
I am not sure I understand the question. This is on a new connection (I moved recently and DT had to sent a technician to connect some cables, thus I guess this is a new connection from their point of view too). I have been using the BT HH5A from day one, albeit with different firmwares in the first weeks. I was routinely getting higher sync max rates with another firmware but with frequent (a few per day) disconnect. I settled on the current firmware that seem to give adequate rates for my data plan.
I have a little RRDtool database that records the status of the DSL connection (via the monitoring framework included in OpenWRT and a custom data source) and I see that at the beginning of the monitoring period it was syncing at 116 Mbps downlink rate (but not significantly higher uplink rate). However, I didn't record the firmware version used (and I am too lazy to cross reference my notes to the data).
If trying a new firmware highly i recommend 60 days (2 months max)
30 days for the line to stable agan
30 days to test firmware
However i sold my bt homehub 5a in the end as FTTH was layed but when on VDSL2 (FTTC) i used a fritzbox 7530 in bridge mode (frizOS) and then used a tp link wdr3600 via PPPoE (OpenWrt) so was not double NATed.
Unfortunately this connetion breaks too. It was the longest time with about 870 minhtes, but after that reconnect it was only 89 min. I'll test the next firmware on monday.
Well, the sync is influenced by both the firmware blob, and by what the DLM system allows as maximum, the longer a link behaves unstable the lower the DLM system will configure the DSLAM's maximum sync profile, so the DSLAM will never negotiate a sync higher than that....
Again, if you find a firmware blob that is stable and does neither cause resyncs or larger error counts to accumulate, the DLM shoud relax the sync throttling.
Ah, thanks for this information, I had indeed become confused.
Latency [Interleave Delay]: 0.13 ms [Fast] 0.0 ms [Fast]
Data Rate: Down: 63.668 Mb/s / Up: 26.997 Mb/s
Line Attenuation (LATN): Down: 16.8 dB / Up: 18.6 dB
Signal Attenuation (SATN): Down: 16.8 dB / Up: 18.6 dB
Noise Margin (SNR): Down: 15.1 dB / Up: 14.1 dB
Aggregate Transmit Power (ACTATP): Down: 7.6 dB / Up: 14.5 dB
Max. Attainable Data Rate (ATTNDR): Down: 95.356 Mb/s / Up: 34.167 Mb/s
I hope so this will be better then the tests before.
I still have 2 other users and they can live with it.
) 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...