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.
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.
That is the normal message O2 sends in the PPPoE AuthACK Message field; nothing to worry about. I note that other German ISPs like Telekom and 1&1 actually use that message to inform the modem about the approximate settings of the traffic shaper, which is overall more useful than the cute Tolkien quote O2 uses...
If you add the keyword "debug" (without quotes and without a leading #) to /etc/ppp/options you will get slightly more verbose ppp output in the log (use logread | grep -e pppd to extract only the ppp related entries from the system log, but you probably knew that)...
Ok.Thank U both. I only meant if it is a message that the modem should use to take the correct values or something like this. I'll add "debug" to /etc/ppp/options and tell U the results when it reconnects the next time.
Yes, that is a sign of LLU, especially the bitstream access variant, in this specific case the ISP operating the actual lines (Deutsche Telekom), routes these packets to PPPoE-termination nodes operated by telefonica/O2 and these are configured to use that message during the negotiation... I note that normally this message is not displayed anywhere, so I bet this was a small easter-egg the network techs at o2 left for their colleagues....
This message is emitted every time the PPPoE connection is established/re-established, which is at least every 24 hours...
I don't even know if you can buy something like that, and if it makes sense. It is my DSL connection cable and the HH5A has only RF11 socket. I think I've never seen a cable like this in CAT5e. But I'll look for it right away.
Well, FritzBoxes are the only known modems (to me at least), that actually evaluate the PPPoE Auth ACK message to set their internal traffic shaper correctly, but as far as I understand (last time I used a FritzBox was 2008) they will not show this message prominently in the GUI (they do show the extracted and processed shaper values however).
Cleaning up the internal wiring is good advise. I would also always try to mount the modem as close to the line's entry point in an apartment/house, and I would retire anf PLC/power line networking in my house as that often interferes with DSL...
You can manufacture your own cables, DSL only needs two wires, so you could just attach RJ11 connectors to both ends of an 8 wire ethernet cable, by just connecting a single pair on each side (make sure to use the same pair ). But you also could try to get an adapter....
Since I am cheap, I just used an RJ45-to-RJ45 connector (looks like two ethernet sockets back to back) and crammed the RJ11 connector in one side. Yes, this is a known method to make that socket unreliable for true 8-wire RJ45 connectors, but I simply kept using it for the HH5A where it worked okay...
BTW, since the prices are not that much higher, if you have no Cat5 cable sitting around in a cupboard, get Cat6, 7, or even 8, that way the cable might be put into service for 10Gbps-ethernet in an utopian future