Billion UK Forum

TangoWhisky wrote: ↑Mon Oct 29, 2018 10:09 am My trusty Billion 7800DXL failed a week or so ago and I replaced it with an 8800 AXL R2 nine days ago (bought via Amazon). I would have recommended to 7800 to anyone - but this router has been nothing but trouble since I installed it. Its reliability is terrible - and not just in terms of drop outs. The line drops out at least once a day and on re-connection the line speed drops to a rediculously low rate. Only on a reboot does it return to normal. Combined with other lockups, the performance is well below acceptability. The software version is 2.52.d12.

We have BT Infinity, but with a long line (~1.1Km) and a 29.1dB attenuation. I had been using a Netgear DM200 as a modem working with the 7800DXL (which I had kept following the upgrade to BT Infinity 18 months ago). This pairing worked very well with drop outs at most once a week. The line speed is typically 27Mb/s.

The 8800 initially syncs at the same line speed over a VDSL2 connection, but has so far dropped out every day and, as I said above, reconnects following the daily drop out at a much poor line speed, typically ~10 Mb/s. Noticably, on the statistics page, on initial connection the downstream output power is measured at around 10.4 - 10.7 dB, while after the resync the measured figure drops to about 8.7 dB. Only on a reboot is normal performance restored.

I have tried putting the DM200 back in place and using the 8800 as just a router in the same mode as the 7800. That is with the 8800 handling the PPPoE connection and the DM200 as the modem. That works - for a while. The DNS Proxy stopped working after a day this time.

To be honest, this looks like a serious memory leak with different functions grinding to a halt depending on the configuration.

I recall a similar problem with the 7800 when IPv6 was enabled and before it was supported by BT. DHCP also ground to a halt after a few months of up time. But this is a couple of orders of magnitude worse.

Regretably, this router seems only fit for the bin.

TangoWhisky wrote: ↑Mon Oct 29, 2018 11:41 am >>Can you provide more information on DNS proxy issue??

Basically, it failed to respond to queries. I was still able to connect to remote systems using their IP Address and to access remote DNS Servers, but could not get a response for the DNS Proxy in the 8800. I tried changing the DNS Server IP Addresses from the default provided by BT to Google's DNS Servers, but no change. The only way out of the problem was to reboot the router.

Since then I have gone back to using the built-in VDSL2 in the 8800. I have not seen the DNS issue resurface since then - but maybe this is because the line drops out first.

billion_fan wrote: ↑Mon Oct 29, 2018 12:06 pm

TangoWhisky wrote: ↑Mon Oct 29, 2018 11:41 am >>Can you provide more information on DNS proxy issue??

Basically, it failed to respond to queries. I was still able to connect to remote systems using their IP Address and to access remote DNS Servers, but could not get a response for the DNS Proxy in the 8800. I tried changing the DNS Server IP Addresses from the default provided by BT to Google's DNS Servers, but no change. The only way out of the problem was to reboot the router.

Since then I have gone back to using the built-in VDSL2 in the 8800. I have not seen the DNS issue resurface since then - but maybe this is because the line drops out first.

Let me check with our engineers if they have a newer firmware with a different DMT code

TangoWhisky wrote: ↑Fri Nov 02, 2018 9:24 am The "dtest" software version is certainly better than "d12" but the router is still below acceptable in terms of reliability.

The big gain with "dtest" is that I do not have to reboot the router after every VDSL resync. However, it still resyncs several times a day and that is the reason why it is not giving acceptable performance.

On a PPP reconnect, it does not always seem to pick up the IPv6 address. With BT that is a big problem because of their broken IPv6 implementation and use of dynamic (/56) IPv6 Address assignments. When the router fails to pick up the IPv6 address it seems to lose its current assignment and then gets a different one on reconnect. Not a great situation. I'd rather use IPv4 and NAT than suffer this problem. The same problem also seems to exist with a reboot - but at least I haven't had to reboot the router since Monday.

The EMail Alert on reconnect also seems to be unreliable. Sometimes I get it, sometimes I don't.

I don't know enough about the algorithm behind the decision to perform a DSL resync but, observing what is happening, suggests that the decision is made on SNR Margin. With a long subscriber line, the SNR Margin does naturally vary during the day. I have seen it as high as 4.8 and as low as 3.3dB on the same DSL session and only a few hours apart. My guess is that the router is too sensitive to SNR Margin changes, resyncing when it sees too low or too high a value, and the natural variation on this line is more than expected by the DSL resync algorithm. If my guess is correct then it would be useful to have more configuration control over the algorithm.