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