How Long to return to previous IP Profile?

[sparky]

How long does it take BT to return a line to normal after a fault condition?

About 19-20 days ago I noticed that my router was bouncing and failing to connect (Netgear Dg834G V2). It seemed to be OK during the afternoon and evening, but my connection speed had dropped from 4640 kbps and an IP profile of 4000 kbps to something like 3580 kbps and a profile of 3000 kbps, I guess due to the line problems. It then started bouncing again the following morning. I spoke to IDNET support (thanks to Brian for his help) and was advised to get BT to do a copper line test, which came back "inconclusive", so they put it out to an engineer. This was fixed at the exchange about 48hrs later, but the connection speed stayed at something like 3580 kbps. It has crept up now after 16 days of a solid connection to 3744 but with an IP profile of only 3000 Kbps.

My router stats are OK again, :-

System Up Time 352:48:55
Port Status TxPkts RxPkts Collisions Tx B/s Rx B/s Up Time
WAN PPPoA 848842 917893 0 342 502 352:48:26
LAN 10M/100M 857033 841133 0 505 357 352:48:50
WLAN 11M/54M 35068 7572 0 15 0 352:48:40


ADSL Link Downstream Upstream
Connection Speed 3744 kbps 448 kbps
Line Attenuation 49 db 15.5 db
Noise Margin 15 db 23 db

My understanding is that the target noise margin should be around 4 - 6 db, which means I still have room for improvement. Will my line return to what it was, without manual intervention somewhere in the system? If so, after how long? Thanks.

[Rik]

The profile is correct for the sync speed, Sparky, you need to hit 4000 to get a 3.5M profile.

Your real problem is that the target NM has been raised to 15db. For that to normalise, you need to maintain a stable sync for 14 days, after which it will reduce by 3db (5-700k of sync speed), repeating every 14 days until the target of 6 is reached or the line becomes unstable. Note that any re-sync will cause the clock to start over.

Given that an engineer has cleared a fault on the line, IDNet may, and I emphasise may, be able to get BT to re-set the target NM manually, it will do no harm to ask.

[sparky]

Ah. So that's how it works. Thanks Rik.

It has been stable now for 14.6 days!  I'm interested to see if this really will happen by itself, so I will give it another 24 hrs or so to see if anything changes before I bother support, after all, it's not really going to make a lot of difference to me, it would just be nice to get the figures back to what they were.

[Rik]

It will require a manual re-sync for you to see the change, Sparky, but I'd wait at least another day for that as BT have a strange idea of what constitutes 14 days.

[sparky]

By a manual re-sync, do you mean I need to power the router off/on ?

Thanks.

[Rik]

That's the best way, yes.

[sparky]

OK. I'll leave it another couple of days just to be sure then try it.

Thanks for the info Rik.  Cheers.

[Rik]

NP.

If it doesn't work, check in with support.

[Odos]

I've got exactly the same problem. I have just got back from a weeks holiday. Before going and switching off the router I saved the router stats which show that I'd been continuously connected for 17 days 20 hours. On arriving home, I switched on expecting a 12db margin but found find my SNR target is still at 15db.

I've been in touch with support and I'm now waiting to see what if anything happens 

[Rik]

That is odd, Tony. I'd expect to have seen a low-sync event to trigger that margin staying high. Does your router log an error count?

[Odos]

That is odd, Tony. I'd expect to have seen a low-sync event to trigger that margin staying high. Does your router log an error count?

Yup it's a 2700 Rik. Problem is I've been reading a lot of forums on the subject and no two seem to agree on what the actual "error" criteria is. Anyway the log is attached, let me know what you think

Just checked the txt file and the formatting has gone west, Sorted now


[attachment deleted by admin]

[Rik]

The formatting always goes, Tony.

I suspect your error count(>1,000/day) may be stopping the margin dropping, but check with support.

[Odos]

Which error count are you thinking of Rik ? I only ask because as I said I've checked on numerous forums and can't find any type of consensus as to which particular error,if any, is the important one. 

[Rik]

Uncorrectable blocks, Tony.

[Odos]

Uncorrectable blocks, Tony.

Thats what I thought was the important one, but on some forums they claim it is the number of lost frames and error blocks are not relevant. As I said before   

I'll just have to wait and see what support have to say 

[Rik]

I honestly don't know, Tony, given the 2700 doesn't use the normal FEC etc terminology. However, I know that the BT systems regard errors as instability, so uncorrected blocks are what I think they count.

[Odos]

However, I know that the BT systems regard errors as instability, so uncorrected blocks are what I think they count.

You are most likely correct Rik  Funny how all problems come back to BT and how they tend to keep their working practices as secret as possible 

[Rik]

Including from themselves at times, Tony. 

[Odos]

Just out of interest, I've been doing some more web hunting on this subject. On a BT forum and a Plusnet forum, this self same question was asked. Both of the below answers came from supposed ISP staff members responding.

BT Broadband claimed it's 30 days without any disconnection at all. Any errors are ignored provided the connection remains solid.

Plusnet claimed the same as BT only they seem to think it's only 28 days.

On a general note Thinkbroadband forum users adopt the general consensus of the 14 day rule with errors having a bearing.

So I think the conclusion we've already arrived at is correct.

NO-ONE KNOWS HOW THE HELL IT WORKS 

[Lance]

We've certainly seen it after 14 days. I wonder if the ahort period depends on errors and the 30 period doesn't.

[Lance]

Just re-read the original post and picked up on this:

the connection speed stayed at something like 3580 kbps. It has crept up now after 16 days of a solid connection to 3744

if the sync speed has changed during the 16 days it means that the connection hasn't been as solid as you might think and has in fact had at least one resync.

[Rik]

Well spotted that man.

[sparky]

But sureley, if there had been a re-sync, the uptime of the WAN would have reset ??

Also a question on this "uptime" business. How does this work, if you are a customer using a USB Broadband modem or an internal broadband modem, as every time you power off your PC the broadband goes down ??

[Rik]

Not necessarily, it depends on how good the router's reporting is - it may not register a short downtime. The log, though, should record the re-sync. Whatever the router data is saying, though, the only way a sync speed can change is if there's been a re-sync.

If you use a USB modem, you will never me able to get the target NM lowered, due to the powering down that will keep happening. It's just one of the arguments for using a router.

[sparky]

Looks like there was a loss of sync on 4/9.  Could that be it?  It might have been when I was tidying up the wiring again after having to move everything to the master socket to prove the fault. Looks like its been ok since then, just have to keep my fingers crossed. I'll not force a re-sync just yet.

Sun, 2009-08-30 15:31:32 - Router start up
Mon, 2009-08-31 15:17:59 - Administrator login successful - IP:192.168.0.2
Tue, 2009-09-01 09:28:13 - Administrator login successful - IP:192.168.0.2
Tue, 2009-09-01 14:49:06 - Administrator login successful - IP:192.168.0.2
Tue, 2009-09-01 15:22:35 - Administrator login successful - IP:192.168.0.2
Wed, 2009-09-02 08:02:58 - Administrator login successful - IP:192.168.0.2
Wed, 2009-09-02 13:32:08 - Send out NTP request to time-g.netgear.com
Wed, 2009-09-02 13:32:13 - Receive NTP Reply from time-g.netgear.com
Wed, 2009-09-02 14:40:13 - Administrator login successful - IP:192.168.0.2
Thu, 2009-09-03 10:30:57 - Administrator login successful - IP:192.168.0.2
Thu, 2009-09-03 19:25:55 - Administrator login successful - IP:192.168.0.2
Fri, 2009-09-04 06:56:37 - Administrator login successful - IP:192.168.0.2
Fri, 2009-09-04 08:00:21 - Administrator login successful - IP:192.168.0.2
Fri, 2009-09-04 08:12:19 - Administrator login successful - IP:192.168.0.2
Fri, 2009-09-04 11:08:14 - Loss of synchronization :1
Sat, 2009-09-05 11:32:13 - Send out NTP request to time-g.netgear.com
Sat, 2009-09-05 11:33:33 - Send out NTP request to time-h.netgear.com
Sat, 2009-09-05 11:35:43 - Send out NTP request to time-g.netgear.com
Sat, 2009-09-05 11:39:33 - Send out NTP request to time-h.netgear.com
Sat, 2009-09-05 11:46:43 - Send out NTP request to time-g.netgear.com
Sat, 2009-09-05 11:46:48 - Receive NTP Reply from time-g.netgear.com
Mon, 2009-09-07 07:29:23 - Administrator login successful - IP:192.168.0.2
Tue, 2009-09-08 09:46:48 - Send out NTP request to time-g.netgear.com
Tue, 2009-09-08 09:48:08 - Send out NTP request to time-h.netgear.com
Tue, 2009-09-08 09:50:18 - Send out NTP request to time-g.netgear.com
Tue, 2009-09-08 09:54:08 - Send out NTP request to time-h.netgear.com
Tue, 2009-09-08 10:01:19 - Send out NTP request to time-g.netgear.com
Tue, 2009-09-08 10:01:23 - Receive NTP Reply from time-g.netgear.com
Tue, 2009-09-08 16:01:03 - Administrator login successful - IP:192.168.0.2
Thu, 2009-09-10 06:57:32 - Administrator login successful - IP:192.168.0.2
Thu, 2009-09-10 12:30:23 - Administrator login successful - IP:192.168.0.2
Fri, 2009-09-11 08:01:24 - Send out NTP request to time-g.netgear.com
Fri, 2009-09-11 08:02:50 - Send out NTP request to time-h.netgear.com
Fri, 2009-09-11 08:05:12 - Send out NTP request to time-g.netgear.com
Fri, 2009-09-11 08:05:17 - Receive NTP Reply from time-g.netgear.com
Sun, 2009-09-13 07:46:33 - Administrator login successful - IP:192.168.0.2
Mon, 2009-09-14 06:05:17 - Send out NTP request to time-g.netgear.com
Mon, 2009-09-14 06:06:10 - Send out NTP request to time-h.netgear.com
Mon, 2009-09-14 06:07:26 - Send out NTP request to time-g.netgear.com
Mon, 2009-09-14 06:09:28 - Send out NTP request to time-h.netgear.com
Mon, 2009-09-14 06:13:02 - Send out NTP request to time-g.netgear.com
Mon, 2009-09-14 06:13:07 - Receive NTP Reply from time-g.netgear.com
Mon, 2009-09-14 08:20:25 - Administrator login successful - IP:192.168.0.2
Tue, 2009-09-15 09:21:19 - Administrator login successful - IP:192.168.0.2
Tue, 2009-09-15 09:38:13 - Administrator login successful - IP:192.168.0.2

[Rik]

It certainly could, it seems to have been brief.

[Odos]

Just a quick update for information purposes, Brian in support has got BT to manually drop my SNR target to 9db. At the moment I'm now connected at a sync of 3872 on 9db.  Only time will tell if my line can hold this 

[Rik]

 

Score one for Brian. 

[Sebby]

Just a quick update for information purposes, Brian in support has got BT to manually drop my SNR target to 9db. At the moment I'm now connected at a sync of 3872 on 9db.   Only time will tell if my line can hold this  

That's impressive - BT are notoriously difficult when it comes to manually adjusting the target SNRM downwards.

[Odos]

Further update. My line held the 9db till today when it suddenly did a re-sync at 12:36. No obvious reason why, it was still showing the full 9db margin. As far as I can tell from the logs, it just dropped once and re-connected first time BUT when it re-connected it was at 15db, it didn't appear to attempt a connection at 9db or 12db just right up to 15db. And that makes me believe if I had just switched it off and back on it most likely would have jumped back up.

From this I'm assuming two things. (1) My line is subject to some outside part time interference somewhere along it's long length. (2) The system doesn't like to be manually over-ridden hence no attempt at an intermediate margin just a straight jump back up to 15db after a single connection drop   

Oh well at least support tried for me 

[Rik]

It could be the error count which triggered the re-sync, Tony.

[Odos]

It could be the error count which triggered the re-sync, Tony.

Could well be Rik, though it wasn't all that much more than I get on 15db. Up until it dropping it was around 3800 for the 2 days. Well whatever it was I now know that I'm stuck at 15db margin. Unless I go back to the old speedtouch router, with that I can tweak the margin down to 10db 

[Rik]

BT seem to be indulging in some strange tricks, atm, Tony - one of which being the defined 'acceptable speeds' for a connection, so I wonder whether they are deliberately withholding investment to make larger profits.

[Odos]

BT seem to be indulging in some strange tricks, atm, Tony - one of which being the defined 'acceptable speeds' for a connection, so I wonder whether they are deliberately withholding investment to make larger profits.

As a coincidence, I heard an advert on our local radio today for BT broadband, line and something else ( can't remember what as I wasn't paying much attention) but I do remember thinking to myself "how are they going to manage that". Maybe it's by the method you've mentioned 

[Rik]

BT Retail are launching WBC themselves now, so that might have been the ad you heard. When you look at my most recent (WBC) speed test, though, you realise that any claims they make are now a bit of a joke (certainly the FTR seems to have been thrown away...):

Download speed achieved during the test was - 1595 Kbps
For your connection, the acceptable range of speeds is 600-7150 Kbps.
Additional Information:
Your DSL Connection Rate :4632 Kbps(DOWN-STREAM), 760 Kbps(UP-STREAM)
IP Profile for your line is - 3500 Kbps

[sparky]

Just to finalize this one, as far as I'm concerned anyways,

My router held firm for 17 days, no change of connection speed, no re-syncs.  So, I did a Power cycle and re-connected, but still no change to the noise margin, still sat at 15db.

Emailed support and James has managed to get BT to reset it manually, so I am now back to a 5db noise margin and my original connection speed. So many thanks to support, but BT's software obviously doesn't always do its job after a clean 14 days.

Cheers for help guys, Sparky.

[Rik]

Hi Sparky

That's one of the problems with BT, the systems don't always work. WBC seems better than Max in this respect.

[sparky]

Bl**** BT.  I think I have another line problem developing.

The last few days have seen a steady increase in re-synch's in my router log. Yesterday I had 8 "loss of synch" messages throughout the day. We are rural and it seems to get worse with the weather. This isn't a problem to me, I don't use it for gaming,  but what is the level at which BT's system will start to increase my noise margin?  I seem to remember reading somewhere that it was 10 per hour ?

I have noticed that there has also been an intermittent "crackling" sound on my voice, people that have called me can not hear it, only at my end is it audible. It also seems to tie in with the resynchs when I look at the time stamps. The problem is that if I rang BT, because it is so intermittent, they would test the line and say "all OK". So I'll probably have to wait and see if it goes "harder". Every time I try a quiet line test on 17070 it seems OK.

Just wondering though, how it's going to affect my line profile?

[Lance]

Unless you resync lower than you currently are, then profile will bot be directly affected.

However, if the DLM sees lots of resyncs (normally around 10 within an hour) then this will push up your noise margin, and therefore your sync will fall as will you profile.