Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Greybeard33]

Hi all,

I have had Infinity since July 2011 and am about 1km from the PCP (as the road wiggles). From the start I got download speeds of about 36-37Mb/s (improved slightly earlier this year, presumably due to the VDSL2 profile change), with an IP profile well above this (don’t remember the exact number).  I have never attempted to access the modem stats, since these speeds seemed good for the length of line and the line seemed stable.

Recently I noticed that download speeds had dropped slightly, to about 34-35Mb/s. I then found that the BT Speedtester was reporting that my IP profile was now 35.73Mb/s, so the speed was being limited by the profile, rather than having some headroom as before.

I was not particularly concerned, since network congestion is often the limiting factor anyway, and the difference was hardly noticeable in practice. Nevertheless, out of curiosity, I decided to try rebooting the modem, which had been powered continuously since it was installed under the OR exchange programme some months ago. I powered it down for about half an hour this morning, and – lo and behold! Afterwards the IP profile had increased to 38.71Mb/s and download speeds were back to 37-ish. This evening I rebooted the modem again, this time using the reset switch, to check if higher noise levels after dark would cause a lower sync speed, but the profile and speeds have remained the same.

When previously on ADSL Max and later ADSL2+, I was aware that forced re-syncs were sometimes necessary to reduce the SNRM to the target and so get the best out of the line. However, I had read somewhere that the OR FTTC DLM was supposed to be “clever” enough to adjust sync speed on the fly, both down and up, without user intervention. Is this not in fact the case? If not, how many unsuspecting users are making do with unnecessarily slow speeds?

[eliw]

I get new IP profiles without any reboots (some up many down).
In fact reboots I noticed don't do anything in my case.

This is just my experience - I am new to FTTC.

[Bald_Eagle1]

Hi Greybeard33 & Welcome to the Kitz forum.

I can confirm that when things are working as intended, IP Profile is approximately 96.79% of sync speed for our FTTC connections.
e.g. 39999k sync speed = 38715k IP Profile (approx)
When contention isn't a factor, throughput speed can be up to approximately 97% of IP profile (i.e. 37554k throughput)

The HG612 modem can re-sync "on the fly" very quickly (only takes 16 seconds or so).
IP Profiles are only updated when a new PPP session is initiated.
These "on the fly" re-syncs are too quick for most ISPs to detect, so the PPP session is not renewed & thus the IP Profile is not updated.
Additionally, ISP connection logs do NOT show all these disconnections, so they argue that a connection is stable, when in reality it isn't, blaming contention as the cause of low througput & speed tests.

Due to physical line problems/issues (still not fully resolved), my connection re-syncs "on the fly" frequently, usually at a vastly reduced speed.
However, the IP Profile remains stuck at 96.79% of the PREVIOUS sync speed until a new PPP session is initiated either via the router, or by rebooting/powering off & on the modem itself.

So, there must indeed be many unsuspecting users suffering slow speeds despite seeing high IP Profiles as reported bt BT's speed test.

The only way to know how often a connection re-syncs is to use an unlocked modem.
Every re-sync can be seen by either logging ongoing stats, or via the modem's own inbuilt event log.

e.g:-

2012-5-13 17:11:40 Notice 104500 DSL activate succeed
2012-5-13 17:11:23 Notice 104500 DSL deactivate

2012-5-13 15:48:2 Notice 104500 DSL activate succeed
2012-5-13 15:47:46 Notice 104500 DSL deactivate

2012-5-13 13:23:38 Notice 104500 DSL activate succeed
2012-5-13 13:23:22 Notice 104500 DSL deactivate

2012-5-13 11:14:20 Notice 104500 DSL activate succeed
2012-5-13 11:14:3 Notice 104500 DSL deactivate

2012-5-13 11:10:6 Notice 104500 DSL activate succeed
2012-5-13 11:9:49 Notice 104500 DSL deactivate

Not one of those on the fly re-syncs caused a new PPP session & they are NOT reported in my ISP's own logs.

However, this one was:-

2012-5-13 10:24:27 Notice 0 admin login
2000-1-1 0:0:21 Notice 104500 DSL activate succeed
2000-1-1 0:0:18 Debug 104500 LAN1 up
2000-1-1 0:0:16 Debug 104500 LAN2 up
2000-1-1 0:0:16 Notice 1 System up
2000-1-1 0:0:3 Warning 10400 KLOB Pool 1 Initialized: 1048576 bytes <0x80300000 ... 0x80400000>
2012-5-13 10:17:54 Warning 104001 System reboot
 

HTH,

Paul.

[Greybeard33]

Hi Greybeard33 & Welcome to the Kitz forum.

I can confirm that when things are working as intended, IP Profile is approximately 96.79% of sync speed for our FTTC connections.
e.g. 39999k sync speed = 38715k IP Profile (approx)
When contention isn't a factor, throughput speed can be up to approximately 97% of IP profile (i.e. 37554k throughput)

The HG612 modem can re-sync "on the fly" very quickly (only takes 16 seconds or so).
IP Profiles are only updated when a new PPP session is initiated.
These "on the fly" re-syncs are too quick for most ISPs to detect, so the PPP session is not renewed & thus the IP Profile is not updated.
Additionally, ISP connection logs do NOT show all these disconnections, so they argue that a connection is stable, when in reality it isn't, blaming contention as the cause of low througput & speed tests.

Due to physical line problems/issues (still not fully resolved), my connection re-syncs "on the fly" frequently, usually at a vastly reduced speed.
However, the IP Profile remains stuck at 96.79% of the PREVIOUS sync speed until a new PPP session is initiated either via the router, or by rebooting/powering off & on the modem itself.

So, there must indeed be many unsuspecting users suffering slow speeds despite seeing high IP Profiles as reported bt BT's speed test.

The only way to know how often a connection re-syncs is to use an unlocked modem.
Every re-sync can be seen by either logging ongoing stats, or via the modem's own inbuilt event log.

e.g:-

2012-5-13 17:11:40 Notice 104500 DSL activate succeed
2012-5-13 17:11:23 Notice 104500 DSL deactivate

2012-5-13 15:48:2 Notice 104500 DSL activate succeed
2012-5-13 15:47:46 Notice 104500 DSL deactivate

2012-5-13 13:23:38 Notice 104500 DSL activate succeed
2012-5-13 13:23:22 Notice 104500 DSL deactivate

2012-5-13 11:14:20 Notice 104500 DSL activate succeed
2012-5-13 11:14:3 Notice 104500 DSL deactivate

2012-5-13 11:10:6 Notice 104500 DSL activate succeed
2012-5-13 11:9:49 Notice 104500 DSL deactivate

Not one of those on the fly re-syncs caused a new PPP session & they are NOT reported in my ISP's own logs.

However, this one was:-

2012-5-13 10:24:27 Notice 0 admin login
2000-1-1 0:0:21 Notice 104500 DSL activate succeed
2000-1-1 0:0:18 Debug 104500 LAN1 up
2000-1-1 0:0:16 Debug 104500 LAN2 up
2000-1-1 0:0:16 Notice 1 System up
2000-1-1 0:0:3 Warning 10400 KLOB Pool 1 Initialized: 1048576 bytes <0x80300000 ... 0x80400000>
2012-5-13 10:17:54 Warning 104001 System reboot
 

HTH,

Paul.

Paul,

Thank you for the detailed explanation. It therefore appears that my new IP Profile of 38.71M is the maximum available on the 40/10 service - not bad for a longer line than yours. Presumably the 96.8% factor does not apply to the upstream IP Profile? Mine has always been exactly 10M, although the attainable upload speed is only about 6M.

If a new PPP session updates the IP Profile as you say, an anomaly in my case is that my router logs show that the PPPoE connection was down for about 10min in the small hours of the previous morning, yet this did not increase the IP Profile. Of course, this could have been due to maintenance to the BT Wholesale network that did not affect the DSL sync, but the implication is then that it was the actual sync speed that was "stuck", not just the profile.

Before I first noticed the drop in IP Profile, there had been a number of PPP (but not DSL) disconnects due to me swapping routers, so it seems possible that these updated the profile in response to an earlier drop in sync speed.

When I switched off the modem, it took several minutes before my router "noticed" that it had lost the connection ("LCP appears to be disconnected") and initiated PPPoE reconnection attempts. This confirms that PPP connection logs do not provide a reliable record of "on the fly" resyncs. Also, the PPP logs cannot distinguish between loss of the DSL link and a problem further upstream. Even when the modem is manually reset, a router disconnect/reconnect or reboot may also be necessary to obtain a new PPP session.

I fully appreciate the advantage of monitoring the connection statistics from the modem itself and indeed used to do this regularly when on ADSL2+, using RouterStats with the O2-supplied router. However, the fact that OR has deliberately locked the UI of its VDSL modems implies that it is confident that it can provide a satisfactory service without any need for the end user to bother about the technical details - unless we believe it is just a cynical ploy to try to conceal inferior performance from the paying customer. Either way, it seems unsatisfactory that you and others with problems have to spend many hours of your own time just to prove you are not getting the service you are paying for.

Regards, G33

[Bald_Eagle1]

unless we believe it is just a cynical ploy to try to conceal inferior performance from the paying customer.

What do you reckon we users suffering with intermittent & frequently low speed & unstable connections really believe? 

I can understand that the providers of this "new" technology would not want users to "mess" with modem settings & then blame the providers for issues, but unless users are actually able to provide detailed feedback regarding connection performance & stats etc. (especially the info that simply cannot be seen from any remote testing), there really isn't much hope of a) service provider script reading staff accepting genuine problems & b) resolving such problems.

[Greybeard33]

Attached are 5+ weeks of stats from the (now unlocked) modem. Unfortunately the logging has been intermittent, but nevertheless they do show some features that I am struggling to understand (I have edited the logfile to avoid plotting spurious spikes of accumulated errors at the times when logging resumed).

After a modem reboot on 7 June, there was a period of 27 days without a resync. During this time, the DS SNRM slowly declined from 6dB to around 3dB, with a corresponding reduction in attainable rate from ~47000k to ~42000k; sync speed was 39751k. On 4 July, I forced a resync by unplugging the phone line from the modem for a few minutes. As expected, this restored the SNRM to the target 6dB, but the sync speed increased slightly to 40000k, with the attainable rate back up to ~47000k and a corresponding slight increase in IP profile from 38.71M to 38.72M. The interleaving depth increased slightly from 631 to 633.

On 6 July, the DS SNRM dropped over a 3 hour period from 6dB to 0, triggering an on-the-fly resync. However, this caused only a slight drop in sync speed to 39429, while the attainable rate shot back up from ~38000k to ~47000k. Interleaving depth dropped slightly to 623. The second set of stats is an expanded view of this incident, which coincided with a period of exceptionally heavy rainfall. Pre-FTTC, I occasionally had line noise problems with my ADSL2+ connection after similar weather conditions, but it always self-healed before I could persuade O2 to get Openreach to investigate. However, I do not understand how a VDSL2 resync can apparently "cure" line noise!

I can see from the logfile that the occasional spikes on the error plots are caused by bursts of errors lasting only 2-3 seconds, at seemingly random times of the day and night. I cannot correlate these with any possible interference sources inside or outside the house. Maybe these are the reason interleaving is on (INP is 3.00)?

I have also attached snapshot stats taken immediately before and after the resync on 4 July. The QLN plots show a reduction in "hairyness" that could be consistent with the slight increase in sync speed, but I cannot see anything to account for the large improvement in attainable rate.

Can anyone explain what is going on?

[Bald_Eagle1]

I have on occasions seen the gradual decline in SNRM values, albeit over much shorter periods than you mention.

I have also seen SNRM levels decline to zero over periods of up to 1 hour.

It also dropped to zero (sometimes negative values) when the phone was used, particularly during warm & dry weather.

These issues were fixed on my connection by initially using a dangly filter directly into the test socket & as that was conclusive proof, the filtered faceplate was then replaced during an engineer's visit.

During the same visit, the engineer repaired a faulty connection between the underground cable & the pole top DP.
(It actually came apart in his hands when he checked it (at my request as I had seen disconnections when other engineers maintained unrelated connections at different DPs on the same pole).

I once again have a stable connection, showing drops in SNRM of only 0.2dB when the phone is used (normal) & gradual but slight decline overnight, regaining the usual 6dB+ during daytime.

I notice your sync speed of 40000. I think that is the first time I have seen that. It is usually 39999.
I don't think that has any relevance though.

While I have been monitoring another connection, it has come to light that the scripts can't handle integer calculations with values exceeding 2^31. i.e. 2147483648.

This user has very high RSCorr error counts that exceed the calculation values in only a few days time.
The cumulative values are however still being recorded in modem_stats.log

Once RSCorr values reach the calculations limit, the graph shows a sudden ceasing of errors (the script can't actually calculate the 1 minute difference, so it uses a value of zero for %DS_RSCorr_THIS_PERIOD%).

He saw an unexplained resync a couple of days further on. He didn't see a gradual loss of SNRM though.
We are waiting to see if a magical RSCorr error count value causes a resync.

It might be interesting to see your modem_stats.log details from just before & just after the on the fly resync of 6th July for comparison purposes.

The differences in QLN plots from your snapshot graphs suggest that the resync occurred at a quieter time of day than the previous resync.

QLN & Hlog data remains static throughout the lifespan of a connection as it is only obtained as the modem "trains up" from a resync.
SNR & Bit-loading is dynamic data though. You may well see reduced SNR at "noisy" times compared to say 06:30am when it is usually quiet.

To summarise then:-

There may be an ongoing issue causing the SNRM drops (building up either over an extended period and/or sometimes over just a few hours).
This could just be a dodgy filtered faceplate, or it could be something like a high resistance D-Side cable issue.
Quite often, the ringing pulse when dialling IN to my my phone would temporarily stop the SNRM dropping issue for a few hours at a time.

The resync of 6th July may well have been simply that DLM saw a deterioration in connection conditions but, having seen reasonable conditions over the preceding 2 days, decided to lower Interleaving depth & let you have a bit more sync speed, or it may have been due to the RSCorr error count reaching a magical maximum number.

I suspect though that the quite rapid decline in SNRM, especially in the preceding 10 minutes or so were the cause.

Does that, or indeed any of the other more subtle occasional drops in SNRM levels correspond with using a telephone?

FWIW, my connection appeared to perform better in cold wet weather.

If you ever hear any crackling/noise on a quiet line telephone test, you will have a cast iron case for a free of charge engineer's visit.
Fixing that should also deal with "some" broadband issues.

Are you able to run your connection from a dangly filter in the test socket for a few days to rule in/rule out a dodgy filtered faceplate that MIGHT be causing the SNRM issue(s)?

Overall though, I would say you have quite a good connection, especially as it is over a longer distance than mine.

[Greybeard33]

Bald Eagle,

Thanks for the avian advice.

I am pretty sure there is no problem with the filtered VDSL2 faceplate, because voice calls (incoming and outgoing) have no discernable effect on the stats, and there is no noise on a quiet line test. When I previously (pre-FTTC) had a faulty ADSL filtered faceplate, the phone intermittently went dead or crackled, but the DSL connection (which bypasses the filter) was unaffected. It would be inconvenient to disconnect the faceplate, because I have three voice extensions wired into it.

I think I will just continue to monitor the stats for now. An occasional resync is not a problem, so long as the sync speed remains good. The SNRM has been stable again since the rain stopped - I suspect that one of the many underground joint chambers between my house and the cabinet is prone to flooding.

For info, the attached stats were taken after the most recent resync on 6 July. The QLN was slightly worse than in the previous retraining on 4 July, consistent with the drop in sync speed from 40000 to 39429. The PPP session "rode through" the resync, so the IP profile is unaffected for now.