Radiocrazy,
If what you're telling us is accurate, you're labouring under a number of misapprehensions as to the way that ADSL and VDSL work.
First, if you're getting regular re-syncs (linedrops) and your speed is coming down, your SNR is going up, not down. That's how it's supposed to work when you just leave the router to get on with sync'ing by itself. If the line is poor (long and noisy) and you don't want to see days and weeks pass before the line finally becomes stable, the only real option is to intervene manually and set the line's target SNR to something higher than the standard 6dB (say, to 9, 12 or 15dB instead). On my 3.3km line I get an ADSL sync speed of just over 4M bps at a target SNR of 15dB or thereabouts. It's low speed but at least it's rock stable. For the rubbishy line I've got at present, I can't expect anything different.
The Billion series of routers allow you to adjust the SNR by providing a tweaking facility within the user interface. The sacrifice in going to a higher SNR in order to get stability is sync speed - the speed will be lower. This configurable feature only works for ADSL mode, though. If you're instead running in VDSL mode, that facility won't be there for you and you'll simply have to accept the SNR and speed that it comes out to on your particular line. That SNR will in time self-adjust and give you your optimum speed, consistent with least errors. It could go down, it could go up, it just depends on the nature of the line between your house and the street cabinet/exchange.
If you yourself are running your Billion in ADSL mode, you don't need to keep contacting BT or Openreach to have them adjust the SNR. You can do that yourself, as I say, from within the Billion's user interface. There are plenty of users on these forums who can point you to that, if necessary.
8900AX-2400 Availability Update
-
ardsar
- Posts: 19
- Joined: Tue Mar 17, 2015 8:36 am
Re: 8900AX-2400 Availability Update
Thanks for the comments. Yes I know how VDSL works I'm an electronics engineer 
Firstly my line is banded and therefore I currently sync at 22400 with around 8dB S/N. If I left the D7000 connected on my line, the S/N would slowly drop over the days resulting in a S/N down as low as 3 or 4 dB. A quick resync and hey presto I am back at 8dB.
The billion 8800AXL would start with a S/N of 8, drop to around 6.5 at night BUT return to 8dB the next day. The D7000 would not recover the S/N. Look at my other post - you can see holes appearing in the bit loading graph due to bins being marked unusable - this was with the 8900 and was the same issue the D7000 had. Unfortunately over time these holes increase until the S/N drops.
Looking at 2 days worth of stats, the 8900AX is following the same path as the D7000 o will be going back
The 8800AXL, HG612, HH5a and ECI modem do NOT have this problem. However the D7000 and the 8900ax do. I spent 3 months working with Netgear trying to resolve the issue, running engineering logging firmware over a 24 hour period. I spent too much time on it, and don't really intend to do it again.
I'm about 900 - 1100 meters from the cabinet. Sync rate comparison:-
HH5A down 22400 (banded) S/N 8dB, Up 7200 S/N 6.2dB
8900 down 22398 S/N 9dB dropping to 6dB after 24 hours up 6325
HG612 down 22399 S/N 9dB Up 7128 S/N 6.1dB
Both the HH5 and HG612 S/N droped by around 1 dB during the evening but RECOVERED by the morning as one would expect with noise.
Firstly my line is banded and therefore I currently sync at 22400 with around 8dB S/N. If I left the D7000 connected on my line, the S/N would slowly drop over the days resulting in a S/N down as low as 3 or 4 dB. A quick resync and hey presto I am back at 8dB.
The billion 8800AXL would start with a S/N of 8, drop to around 6.5 at night BUT return to 8dB the next day. The D7000 would not recover the S/N. Look at my other post - you can see holes appearing in the bit loading graph due to bins being marked unusable - this was with the 8900 and was the same issue the D7000 had. Unfortunately over time these holes increase until the S/N drops.
Looking at 2 days worth of stats, the 8900AX is following the same path as the D7000 o will be going back
The 8800AXL, HG612, HH5a and ECI modem do NOT have this problem. However the D7000 and the 8900ax do. I spent 3 months working with Netgear trying to resolve the issue, running engineering logging firmware over a 24 hour period. I spent too much time on it, and don't really intend to do it again.
I'm about 900 - 1100 meters from the cabinet. Sync rate comparison:-
HH5A down 22400 (banded) S/N 8dB, Up 7200 S/N 6.2dB
8900 down 22398 S/N 9dB dropping to 6dB after 24 hours up 6325
HG612 down 22399 S/N 9dB Up 7128 S/N 6.1dB
Both the HH5 and HG612 S/N droped by around 1 dB during the evening but RECOVERED by the morning as one would expect with noise.
-
Radiocrazy
- Posts: 91
- Joined: Wed Feb 12, 2014 6:24 pm
Re: 8900AX-2400 Availability Update
I'm in total agree with ardsar specially on the modems, I have NO problem with them but the D7000 made my DSL speed drop by keep losing sync, the openreach modem is perfect.
I'm not sure where I state my S/N is coming down (gatekeeper) my speed has definitely dropped since using the D7000 due to the amount of disconnections, the line management which reduced my speed for stability, still I'm not someone who assumes I know more then anyone else I can’t be bothered with one-upmanship, there’s plenty of forums like that.
I have seen people really upset when others start picking on their spelling and grammar not realising that the poor person was half blind and suffered heavenly from dyslexia.
I try to keep things in plane English not too much technobabble so others can understand, I have been a service engineer as well, fault finding right down to component level not a board swapper which seems to be today’s practice.
Now that said back to ardsar I can show you what my line is doing now
Is yours similar worse or better, that may help me decide if to give the 8900 ago when Amazon gets stock.
I'm not sure where I state my S/N is coming down (gatekeeper) my speed has definitely dropped since using the D7000 due to the amount of disconnections, the line management which reduced my speed for stability, still I'm not someone who assumes I know more then anyone else I can’t be bothered with one-upmanship, there’s plenty of forums like that.
I have seen people really upset when others start picking on their spelling and grammar not realising that the poor person was half blind and suffered heavenly from dyslexia.
I try to keep things in plane English not too much technobabble so others can understand, I have been a service engineer as well, fault finding right down to component level not a board swapper which seems to be today’s practice.
Now that said back to ardsar I can show you what my line is doing now
Is yours similar worse or better, that may help me decide if to give the 8900 ago when Amazon gets stock.
-
Radiocrazy
- Posts: 91
- Joined: Wed Feb 12, 2014 6:24 pm
Re: 8900AX-2400 Availability Update
I forgot to mention I would hate to think how far my box is from the house as when the BT engineer knocked on the door he said what a walk you're box is 3 streets away the length of cable is ridicules he said he was expecting me to only get around 22mb download speed.
-
ardsar
- Posts: 19
- Joined: Tue Mar 17, 2015 8:36 am
Re: 8900AX-2400 Availability Update
Sorry but I can not really comment based over just those line stats. Also, I would take the figures given in the GUI interface of the HG612 with a pinch of salt as I have read that they can be incorrect, but the data over telnet is correct.
My issue is not caused by the errors, but the induced interference on my line during the evening and night time. Does your S/N swing at night and if so by how much? If it doesn't then the 8900AX would probably be a good choice for you.
My issue is not caused by the errors, but the induced interference on my line during the evening and night time. Does your S/N swing at night and if so by how much? If it doesn't then the 8900AX would probably be a good choice for you.
-
Radiocrazy
- Posts: 91
- Joined: Wed Feb 12, 2014 6:24 pm
Re: 8900AX-2400 Availability Update
I remember when I was on ADSL most of my disconnections were at night time, one ham I know had a lot of interference to his equipment at night so we went out to DF it (Direction find) and we tracked it down to 2 street lights which generated really high levels of RF interference so I can well believe that, I will see if the noise figures change more at night I suspect they do for the worse as the D7000 went potty over night.ardsar wrote:Sorry but I can not really comment based over just those line stats. Also, I would take the figures given in the GUI interface of the HG612 with a pinch of salt as I have read that they can be incorrect, but the data over telnet is correct.
My issue is not caused by the errors, but the induced interference on my line during the evening and night time. Does your S/N swing at night and if so by how much? If it doesn't then the 8900AX would probably be a good choice for you.
Thanks for the tip on the modem I didn’t realise that they were misleading.
-
gatekeeper
- Posts: 167
- Joined: Sat May 26, 2012 4:45 pm
Re: 8900AX-2400 Availability Update
Radiocrazy,
Sorry I've not responded for some time. Apologies. I've been contributing meanwhile to ardsar's rather important SNR problem, in a different thread.
Returning to your own submissions in this thread, ie. in '8900AX-2400 Availability Update', I've two or three comments to make. First, though, may I apologise for confusing you with ardsar on a couple of points. Sorry about that.
To put you right on a few matters, line errors are caused by induced interference such as impulsive noise and from crosstalk between users' lines in the same and adjacent cables going back to the DSLAM (the bit of Openreach kit at the end of the copper section of the line connection). It's not just user packets of data that are going to and from the DSLAM but also background error and line-control information. The DSLAM, together with your modem, will periodically take the various line error counts and, with them, jointly compute a fresh SNR, and therefore a speed adjustment for the line. This is what's sometimes referred to as 'continuous rate adaptation'. So, line errors play a huge role in determining the performance of the line, and obviously no two lines are ever exactly the same. Interference on the copper loop is also caused by pickup of AM Band noise, ie. AM radio transmissions. This has been known about for many years and becomes worse at night, due to the re-radiating effect of the upper atmosphere in the nighttime situation. Aside from the effects caused by periodic or random impulsive noise and of crosstalk, this is why the SNR always gets a bit worse at night but then recovers during daylight hours. Once a stable working condition has established, the SNR should change at night by only a dB or so. And yes, street lamps are a major source of impulsive noise, particularly when they switch on at night.
Re distance to street cabinet, don't assume that this is the walking distance. The cable might in fact take a completely different route. The distance-to-cabinet figure to go by is the one you see in Openreach's online estimate of line speed (use tel. no. not postcode). As far as I can recall, Openreach originally planned VDSL to operate on copper loops (the remaining length to the exchange being fibre of course) with an average length of 500m. Beyond about 800m, performance would sharply drop away. Noise and crosstalk on the fibre stretch would be, for all intents and purposes, zero; it's on that copper loop where all the problems tend to occur.
In the picture you posted in this thread on Sun May 15th, have you noticed a very obvious error? I don't know to which device that's referring (the Openreach modem?) but in the Line Status tab there, it shows Line Attenuation as 0dB. (Line attenuation is the degree of loss of signal, amplitude-wise, down a length of copper; the higher the number, the greater the loss). Are you right next door to the cabinet, because otherwise it's impossible for the attenuation on the copper section to be zero? Maybe there's just some shortcomings in that particular device's firmware, preventing it from computing and showing the line attenuation.
(Must go now, as I've other computing, but non-Internet, work to do. Been spending too much time of late contributing in these forums. Essential learning, though).
Sorry I've not responded for some time. Apologies. I've been contributing meanwhile to ardsar's rather important SNR problem, in a different thread.
Returning to your own submissions in this thread, ie. in '8900AX-2400 Availability Update', I've two or three comments to make. First, though, may I apologise for confusing you with ardsar on a couple of points. Sorry about that.
To put you right on a few matters, line errors are caused by induced interference such as impulsive noise and from crosstalk between users' lines in the same and adjacent cables going back to the DSLAM (the bit of Openreach kit at the end of the copper section of the line connection). It's not just user packets of data that are going to and from the DSLAM but also background error and line-control information. The DSLAM, together with your modem, will periodically take the various line error counts and, with them, jointly compute a fresh SNR, and therefore a speed adjustment for the line. This is what's sometimes referred to as 'continuous rate adaptation'. So, line errors play a huge role in determining the performance of the line, and obviously no two lines are ever exactly the same. Interference on the copper loop is also caused by pickup of AM Band noise, ie. AM radio transmissions. This has been known about for many years and becomes worse at night, due to the re-radiating effect of the upper atmosphere in the nighttime situation. Aside from the effects caused by periodic or random impulsive noise and of crosstalk, this is why the SNR always gets a bit worse at night but then recovers during daylight hours. Once a stable working condition has established, the SNR should change at night by only a dB or so. And yes, street lamps are a major source of impulsive noise, particularly when they switch on at night.
Re distance to street cabinet, don't assume that this is the walking distance. The cable might in fact take a completely different route. The distance-to-cabinet figure to go by is the one you see in Openreach's online estimate of line speed (use tel. no. not postcode). As far as I can recall, Openreach originally planned VDSL to operate on copper loops (the remaining length to the exchange being fibre of course) with an average length of 500m. Beyond about 800m, performance would sharply drop away. Noise and crosstalk on the fibre stretch would be, for all intents and purposes, zero; it's on that copper loop where all the problems tend to occur.
In the picture you posted in this thread on Sun May 15th, have you noticed a very obvious error? I don't know to which device that's referring (the Openreach modem?) but in the Line Status tab there, it shows Line Attenuation as 0dB. (Line attenuation is the degree of loss of signal, amplitude-wise, down a length of copper; the higher the number, the greater the loss). Are you right next door to the cabinet, because otherwise it's impossible for the attenuation on the copper section to be zero? Maybe there's just some shortcomings in that particular device's firmware, preventing it from computing and showing the line attenuation.
(Must go now, as I've other computing, but non-Internet, work to do. Been spending too much time of late contributing in these forums. Essential learning, though).
-
morgainemonk
- Posts: 2
- Joined: Tue Oct 18, 2016 3:17 pm
Re: 8900AX-2400 Availability Update
lamster wrote:Mine arrived yesterday afternoon
I set mine up on an old laptop via ethanet cable (Phone line not connected) Once I had changed the settings so it will work with Sky I then
setup all my static IP addresses as I wanted to make sure it didnt want to reboot incase it caused DLM to kick in, Once I added all the IPs I
backed up config, disconnected the Sky router and replaced it with the 8900.
Turned everything on and it booted up and connected withing 60 secondsMade up!!!!!
Im sure mine is connected to IPv6 also, A friend has an 8800AXL and he gave me his IPv6 setting that Billion sent him as he has just had Sky Q
installed and the mini box will only work with an IPv6 address, the settings sorted this out for him, so I put them in mine and it shows an IPv6
address in the Status>Device Info screen.
So... are these ipv6 settings available? Cant seem to find them anywhere on 'tinterwebz'! In fact, i think you may be the only reference to specific settings you applied that work...
yet, no mention of the settings ??
-
billion_fan
- Posts: 5398
- Joined: Tue Jul 19, 2011 4:30 pm
Re: 8900AX-2400 Availability Update
Click on 'Configuration >> WAN >> WAN Service' then edit your WAN profile (ATM = ADSL, PTM = VDSL) and make sure you have enabled IPv6morgainemonk wrote:lamster wrote:Mine arrived yesterday afternoon
I set mine up on an old laptop via ethanet cable (Phone line not connected) Once I had changed the settings so it will work with Sky I then
setup all my static IP addresses as I wanted to make sure it didnt want to reboot incase it caused DLM to kick in, Once I added all the IPs I
backed up config, disconnected the Sky router and replaced it with the 8900.
Turned everything on and it booted up and connected withing 60 seconds
Im sure mine is connected to IPv6 also, A friend has an 8800AXL and he gave me his IPv6 setting that Billion sent him as he has just had Sky Q
installed and the mini box will only work with an IPv6 address, the settings sorted this out for him, so I put them in mine and it shows an IPv6
address in the Status>Device Info screen.
So... are these ipv6 settings available? Cant seem to find them anywhere on 'tinterwebz'! In fact, i think you may be the only reference to specific settings you applied that work...
yet, no mention of the settings ??
Then click on 'Configuration >> LAN >>> IPv6 Autoconfig' enable the 'DHCPv6 Server' leave the 'DCHPv6 Server Type' set to 'Stateless', enable 'Issue Router Advertisements' and click on 'Apply'
Screen examples attached
You do not have the required permissions to view the files attached to this post.
-
morgainemonk
- Posts: 2
- Joined: Tue Oct 18, 2016 3:17 pm
Re: 8900AX-2400 Availability Update
Thanks billion_fan... That's what I was looking for - I thought I was missing something in my settings because they didn't appear to be working!!...
Bear with me... You'll like this...
I'm running the bipac 8800axl with the settings above on Sky fibre ... (Excepting it's IPoe and not pppoe for the ptm connection in WAN setup)
On the summary page at the bottom where it should be telling us the ipv6 default gateway / ipv6 address - there is no sign of an address and from my PC, no connection on the ipv6-test sites... Hence the running in circles the past few days pulling my hair out (what little I have left)
Turns out... My android devices pass the test and problems.. inspecting the LAN connection details on PC shows the correct IPv6 addresses ...
Seems the issues I'm having may be related to a certain VPN software installation which has killed the IPv6 connection (among other things) to/from PC ... - I'm working on it - it also has a kill switch - meaning if it's not running ... Zero connection to anywhere!!! ffs... A simple uninstall renders windows networking useless ha!... I'm working on it ....
Anyway, point is for anyone else who gets this far.... The setup above works perfectly on the 8800axl also!!.... Just no IPv6 address listed on the summary page where you would expect!..
It is however noticeable above there in the device information summary - LAN IPv6 address appears to be a global address...
Additionally the server is giving out equivalent global addresses to the client machines, which can be verified via the test sites...
Thanks for all the info and help
Bear with me... You'll like this...
I'm running the bipac 8800axl with the settings above on Sky fibre ... (Excepting it's IPoe and not pppoe for the ptm connection in WAN setup)
On the summary page at the bottom where it should be telling us the ipv6 default gateway / ipv6 address - there is no sign of an address and from my PC, no connection on the ipv6-test sites... Hence the running in circles the past few days pulling my hair out (what little I have left)
Turns out... My android devices pass the test and problems.. inspecting the LAN connection details on PC shows the correct IPv6 addresses ...
Seems the issues I'm having may be related to a certain VPN software installation which has killed the IPv6 connection (among other things) to/from PC ... - I'm working on it - it also has a kill switch - meaning if it's not running ... Zero connection to anywhere!!! ffs... A simple uninstall renders windows networking useless ha!... I'm working on it ....
Anyway, point is for anyone else who gets this far.... The setup above works perfectly on the 8800axl also!!.... Just no IPv6 address listed on the summary page where you would expect!..
It is however noticeable above there in the device information summary - LAN IPv6 address appears to be a global address...
Additionally the server is giving out equivalent global addresses to the client machines, which can be verified via the test sites...
Thanks for all the info and help