I had FEC in my statistics for some time and one day decided to stop worrying and love the FECs. They don't matter, like, literally they don't matter, so I stopped graphing them. Also keep in mind that, in contrast to the Lantiqs, the Zyxel does report FECs, not FECSs, and as such the number will always be much, much higher than with Lantiqs.
As for the bursts, when writing the collectd parsing script I noticed that sometimes the reported FEC numbers bump up for no reason at all, to the tune of 10000 more from one minute to the next. There's a bug buried there, somewhere.
Sure, they are effectively a sign that the links coding is sufficient close its capacity ;). But the tech provider (DT) of my ISP (O2) seems to also evaluate FECs for its automatic determination of the sync limits they enforce for each individual link.
Oh I think I looked at the true FEC counter on lantiq as well, but that was before I cleaned up my wiring and bach then FECs were the least of my concerns
Well possible, but I see FEC spikes in DSLStats as well (I did not bother to write something myself, much nicer to use something shiny with a GUI that works out of the box ) so the bug could be in the binary on the modem that actually reports these numbers...
I agree with you, I've been using the Zyxel VMG8324-B10A model in bridge mode for a while. Broadcom BCM63168 chipset is much more stable. I no longer use my P2812 modem. I am using my 100down / 8up mbps connection without any problems, it also has gigabit ports.
That's because DSLStats does exactly what I do: telnet into the modem and parse the output of xdslctl. Because that's the only way you can programmatically get those values from the modem at all.
We are literally puling the same numbers from the same place using the same means.
That's almost certainly it. I noticed these random spikes too, and being the compulsive yak shaver that I am, I thought I did something wrong in my parsing and tried to hunt down that bug. So I logged not only the parsed values, but also the raw xdslctl output until a spike occured and and ... nope, the number actually occasionally bumps up in xdslctl for no good reason.
That might actually be the best argument for digging out the lantiq once more, just to see whether this will show similar FEC storms (which truly could be driven by noise ingress). But I assume that your assessment, that this is an idiosyncrasy of xdslctl/broadcom SoCs is correct, so I guess I leave the zyxel connected and spend my time on better things
Using the stock firmware, 5.7.9.9.0.6, I was having line drops every 2-3 days. This was when I came across this thread and started to investigate different firmware versions.
I tried 5.9.0.12.1.7 which didn't last 24 hours. More importantly it didn't reconnect without intervention.
I then tried 5.7.8.12.0.7 which has given much better results, and I shall stick with it.
bt,homehub-v5a
OpenWrt 19.07.6 r11278-8055e38794
ATU-C Vendor ID: Broadcom 164.161
Firmware Version: 5.7.8.12.0.7
Annex: B
Line Mode: G.993.2 (VDSL2)
Line Uptime: 39d 13h 4m 17s
As a counterpoint, a friend with the same hardware and connected to the same exchange is fine with the stock firmware. The line remained connected for 40 days before the last disconnect.
bt,homehub-v5a
OpenWrt 19.07.3 r11063-85e04e9f46
ATU-C Vendor ID: Broadcom 164.161
Firmware Version: 5.7.9.9.0.6
Annex: B
Line Mode: G.993.2 (VDSL2)
Line Uptime: 5d 5h 32m 31s
Can we next to doing this, have a setting in the LUCI config file ( LUCI Interfaces -> DSL ) for a service provider/Country?
Reason being that as time goes on and we learn of specific settings for different providers for the firmware we collect these settings in the setup (LUCI) scripts.
So each provider specific setting translates to options in the low level startup script for the dsl_cep_contrl script. Changes can then be tracked in GitHub
Sorry, but that's a pipe dream. There's hundreds of providers, each with multiple products, each customer with their own line setup that can differ from another customer's, and any of those settings can change at any time. There's a reason only very few commercial router firmwares come with such presets, and only if they are sold in a specific country, and only for a handful of the largest providers.
Agree there are many variants, but not unlimited. In UK it is BT Infinity that 'owns' the infrastructure that a number of providers use.
At least the framework of doing this can be implemented so that different people/groups can create a installable profile via the software install interface that will then show up under the interface-> dsl settings page as choice for profile to use. This instead of having to know the annex, tone, etc etc . There could always be an advanced page for specifying the profile details for experts
By no means was the UK example meant as a "rule the waves", I think it is common knowledge around the world , except for WESTMINSTER government, that that has ended quite a while ago
As of the framework, is the command line interface for passing options via vdsl_cpe_control documented somewhere?
I run a pretty recent self-compiled trunk version of OpenWrt that does not show DSL statistics when running /etc/init.d/dsl_control status. Instead, you have to run /etc/init.d/dsl_control dslstat, which then runs ubus call dsl metrics. The output is in JSON format.
This means the command from the original post would not work. Forgive my ignorance, I adapted it to jsonfilter -e @.model.id </etc/board.json; grep '^OPENWRT_RELEASE' /etc/os-release | cut -f2 -d'"'; ubus call dsl metrics | jsonfilter -e @.atu_c.vendor -e @.firmware_version -e @.mode -e @.annex -e @.uptime
My results: 5.9.1.4.0.7 was horrible, I had disconnects every few hours. 5.7.8.12.0.7 works great, the line is up for nearly 9 days, which is the time I last booted the router:
OpenWrt SNAPSHOT r15734-6934d30cf8
Broadcom 194.80
5.7.8.12.0.7
G.993.2 (VDSL2, Profile 17a, with down- and upstream vectoring)
B
766574
Reading back on this thread someone has failed to mention that VDSL2 circuits will put interleaving (higher pings and speed changes) on your profile if you dont keep your line stable unless you live in a country where an engineer will visit the street cabinet and reset the DSLAM cabinet.
i myself always issue via SSH /etc/init.d/dsl_control stop which nicely terminates the VDSL2 session and puts the modem offline whats is better then yanking out the telephone cable or some other random disconnect registers as "Port error".via the ISP logs
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
My test setup seems to work fine with VES-1608FA-35 DSLAM and about 340m cable length.
Continuously transmits cctv video stream (about 3.5Mbit/s).
Firmware extracted from factory firmware.
Would anyone be able to confirm the last 5.7 version, is it:
5.7.B.5.0.7-5.7.5.4.0.1
On my DM200 it's clear that Netgear downgraded the DSL firmware from 5.8 on firmware version 1.0.0.34 and kept with 5.7 for all later firmware versions.
I'm stuck on Profile 17a VDSL2 without vectoring so if anyone could recommend a better firmware I'm happy to try it.
The DSL firmware from Netgear's DM200 v1.0.0.52 and later images definitely supports vectoring in my experience, at least for the Australian NBN VDSL implementation which has Broadcom based cabinets/nodes. v1.0.0.34 and earlier images were known not to be able to connect at all in this environment...
@sven What hardware are you running this on? I'm currently on a fritzbox 7360SL and I have severe speed deterioration problems. The line starts with 95Mbit downstream and after a couple of hours it ends up being only 20Mbit.
Broadcom 178.31
5.7.8.12.0.7
G.993.2 (VDSL2, Profile 17a, with down- and upstream vectoring)
B
29040
@stonerl I'm also using a FritzBox 7360SL. My provider is Vodafone. I have a 100 MBit/s line and it runs fine with full 100 MBit/s. But I have to admit I only use the 7360SL als a modem, NOT as a router because the CPU can't handle NATing full line speed.
