Hi, I have had BT infinity 2 (76/19) since December. It has slowly started to creep down over this time, initially ping times were sub 10s, down was about 75MBs and Up ~20MBs (wired). It now down to 40 down, 10 up.
The street cab is literally over the road, the the cable run, overhead via a pole to the cab can't be more than about 50m
I work from home so have noticed the VDSL connection drop about 2x a day, only for a minute or 2 until it reconnects. I was using a Draytek 2850VN as the modem router. I have now switched to the Huawei HG612 just in case.
Is this as to be expected.. In the really cold weather the speed seems to creep up to late 60's Mbs for download, not sure if that was just a coincidence. Quick stats below
Solved! Go to Solution.
For a 80/20 service, that's completely wrong!!!
You are currently capped, as you mention at 40/10 (39998/9999 sync speeds).
Your SNRM levels are high enough to get much closer to capped 80/20 sync speeds & your attainable rates are 110572/32092.
Your attenuation levels for each band are very low & that can also be seen in the Hlog graph.
You have very, very high Interleaving depths ('D:') of 2211/230 for such an apparently high speed capable connection, suggesting a line problem or many, many reboots.
The issue(s) may be a faulty modem/power supply, causing disconnections or a faulty cable joint/connection somewhere.
You are using a Huawei modem on an ECI DSLAM, so not a 'perfect' match.
However, you SHOULD be seeing much higher speeds.
The 2850VN as the modem router could have caused the problem in the first place, in which case using a BT supplied modem may resolve things in a few days/weeks.
If not, a fault should be reported, firstly that you are on what appears to be the 40/10 service.
That should be an easy matter to resolve.
Secondly, if you don't see any speed increase from when it is CONFIRMED that you are indeed on a 80/20 service, DLM may need to be reset to allow the higher speeds.
What is your IP Profile from the BT Speed test (Further diagnostics):-
When my own connection had physical line problems, it ALWAYS worked much better in cold/wet weather than in warm/dry weather.
It took almost 11 months to resolve & it eventually turned out to be a defective joint between the underground cable & the pole top mounted Distribution Point (DP).
I'm 1000m from the cab, so my speeds aren't great.
However, my connection is now stable.
P.S. The newer quicker/more robust & configurable programs for the HG612 (based upon the original batch file script versions) can be downloaded here:-
Many thanks for your detailed response.. I will keep an eye on the speed over the next week or so.. I am sure I am not on a 40/10 cap as have been above that recently, BT swapped some pairs over in the last few days (between customer and exchange side on the street cab) but otherwise, I think the Draytek is stable, at least whenever I notice the line drop, I can log right into the router and wtach the line come back up again, as the 2850 has a reasonable GUI, so don't think its power supply related.
I am preety sure its not the wiring on my side, as the master socket used to be downstairs and when I had infinity installed, the engineer took the external cable and put it into my home office upstairs, so comes straight off where the overhead line connects to the house and through the wall.
My IP Profile is as follows
|0 Mbps||38.71 Mbps|
Max Achievable Speed
| Download speedachieved during the test was - 38.01 Mbps|
For your connection, the acceptable range of speedsis 16 Mbps-38.71 Mbps .
IP Profile for your line is - 38.71 Mbps
2. Upstream Test: -provides background information.
|0 Mbps||20 Mbps|
Max Achievable Speed
|Upload speed achieved during the test was - 7.85Mbps|
Upstream Rate IP profile on your line is - 20 Mbps
Your US IP Profile of 20 Mb confirms that your phone No. SHOULD be delivering an up to 80/20 service.
All your stats (apart from Interleaving depth) confirm that you should actually be seeing 80/20 (or very, very close to it).
At such a short distance, you should really be on fastpath (D: = 1 for both DS & US).
It is NOT unknown for pairs to be accidentally switched to a port that is capped at 40/10.
That's what looks like MIGHT have happened to your connection.
At only 50 m from the cab you SHOULD be seeing 80/20 sync speeds.
You can run the BT speed test using someone else's phone No.
If you know someone on ADSL, try using their phone No. & see that you actually get higher throughput speed than the IP profile reported for the ADSL phone No.
So, it seems (to me) that your phone No. is connected to the wrong VDSL2 port in the cab, where IP Profile is capped at 40/10, thus restricting (capping) your sync speeds.
Alternatively, the regular drops you have been seeing may have caused DLM to cap your connection at 40/10.
It is definitely capped (for whatever reason).
Just as a another test, does your own phone actually ring if you dial it from a mobile phone?
I'm not on Infinity, so I'm not sure how you would go about reporting this. Maybe you do it through one of the Mods of this forum or directly to BT?
I believe you do need to report it though & soon.
If it isn't an incorrect profile/DSLAM port setting setting, it MUST be a physical fault, probably external to your master socket (assuming it wasn't one of OpenReach's subcontractor installers cocking up your installation (also unfortunately NOT unknown).
Report it via the mods. They do take up to 3 days to reply but will get to the bottom of it.
I am sorry to see you are having problems
I suggest you contact the forum mods they should be able to get this problem sorted for you this is a link to them http://bt.custhelp.com/app/contact_email/c/4951
They normally reply by email or phone directly to you within 3 working days they will take personal ownership of your problem until resolved and will keep you informed of progress
They are a UK based BT specialist team who have a good record at getting problems solved
This is a customer to customer self help forum the only BT presence here are the forum moderators
Slower this morning still, switched over to the newer graphing package as recommended
Firstly, we can see that Retrain Reason is now 2.
That indicates an 'on the fly' DLM initiated resync.
It was previously Retrain Reason 0, which indicates a full modem reboot from its GUI or power OFF/ON or some other 'fault' such as Loss of Frame (LOS) etc.
If you have the modem's own logging enabled, you should be able to see all resyncs / reboots etc:-
2013-4-19 17:31:26 Notice 104500 DSL activate succeed
2013-4-19 17:31:4 Notice 104500 DSL deactivate
(Notice the LAN -PPP session didn't go down i.e. the resync was 'on the fly' - very quick)
2000-1-1 0:0:25 Notice 104500 DSL activate succeed
2000-1-1 0:0:17 Debug 104500 LAN1 up
2000-1-1 0:0:15 Debug 104500 LAN2 up
2000-1-1 0:0:15 Notice 1 System up
2000-1-1 0:0:3 Warning 10400 KLOB Pool 1 Initialized: 1048576 bytes <0x80300000 ... 0x80400000>
2013-4-19 10:12:2 Warning 104001 System reboot
This time the LAN did go down as the connection was completely rebooted.
Unfortunately, when the HG612 is used on a VDSL2 connection, it doesn't synchronise its time with any servers, so following reboots/power OFF/ON, it has to be reset via "SET_HG612_DATE_AND_TIME.BAT" (stored in the Scripts folder).
When we released the program version, we hadn't noticed that the time setting batch file contained Ronski's own modem IP address (192.168.1.3 - from memory).
If you edit the batch file to show the IP address for your own modem in the relevant section (it starts with "(sleep 1 & type login1.txt & sleep 1 & type login2.txt & sleep........"), it will reset the time to your PC's system time each time you run it:-
This is the default that most users retain:-
Plink -telnet -P 23 192.168.1.1
The correct date/time will be retained following 'on the fly' resyncs, but not full reboots/loss of power etc.
The next release will pick up the correct modem IP address from the ini file.
As you are connected to an ECI DSLAM, you will occasionally see upstream data in green in the QLN, Hlog & SNR graphs (as per your example from today).
This data is NEVER reported from a Huawei DSLAM.
So, apart from noting the 'on the fly' resync, what can we see?
You have quite a 'noisy' downstream base QLN level.
Ideally -140 dB is classed as quiet & -100 dB is classed as noisy.
This is electrical/radio/crosstalk 'interference' noise, not necessarily audible noise that would be heard when running the telephone Quiet Line Test.
DS Interleaving depth has increased again to 2649, which really is fairly high (no doubt part of the reason for the even lower sync speed).
My own DS Interleaving depth is only 373 & that's over 1000m or so of old copper, now suffering from increased crosstalk.
No RSCorr errors are shown in your data though.
Have you already set up the 24/7 Ongoing logging that detects & graphs resyncs & this is the output from the resync?
RSCorr errors are reset, but the equivalent FEC errors remain cumulative (these can be viewed in the Plink log).
Or, did you force an 'on the fly' resync via the modem's GUI or via Telnet commands?
SNR is low in the U1 band - hence the gap in the bitloading graph.
The completely flat line in the SNR graph & the corresponding gap in the Bitloading graph suggests that 'something' is completely blocking out those downstream frequencies/tones.
Your Hlog graph looks fine (very low attenuation), indicating that your internal wiring is O.K. - i.e. no star wiring/bridged tap issues etc.
It all looks (to me) that you have one or a combination of these issues:-
If you haven't already done so, it would probably be worth starting the 24/7 Ongoing harvesting/graphing that would identify any patterns of 'interference' connection drops etc.
As you are aware, we aren't supposed to be able to see our detailed connection stats, so I don't know how you would get on when officially reporting these issues to BT.
I have a very understanding ISP (Plusnet) who saw my graphs/data & were very patient throughout the 11 months of issues with my connection, regularly hounding BT to send suitably skilled engineers out accordingly.
Even though many engineer visits were required before it was permanently fixed, most of them unable to actually find physical faults, I wasn't actually charged for any of them.
Good luck with getting this resolved & when/if it does get resolved, please update us as to the cause/remedy.