ADSL2+ target noise margin stuck?

[karvala]

Hi guys,

Moved on to ADSL2+ 7 days ago now, and it seems to be stuck syncing at a much lower rate than necessary (around 11000kbps, with an IP profile set at 10000).  The downstream noise margin when syncing is 15dB, because the attenuation is only 19dB (I'm quite close to the exchange).  For completeness, the upstream noise margin is 11dB with an attenuation of 5.5dB and syncing at 834kbps.

I know there's a training period for ADSL2+, but I've rebooted the router a couple of times, including keeping it without power for an hour, and tried a second router, but always the sync is around 11000kbps.  There have been no losses of sync, or significant levels of errored packets, or slowness (except during the recent LINX outage), but after 7 days still it makes no attempt to resync at anything higher.

I contacted IDNet, whose response was that they can't do anything with the target noise margin in ADSL2+ and "don't worry, I'm sure it'll sort itself out".  Somehow I don't share their confidence based on the above.  Is it really true that they can do nothing in this situation?  I seem to recall reading something similar on here recently where they did change the target noise margin, but perhaps I'm misremembering?

[Steve]

There was a trial recently where BT handed over some control of the MSANs parameters to the ISPs this has now finished I understand,but as yet BT have not allowed this to progress any further. I would trust support if they say it will sort itself out,it almost appears if a max sync rate is in place.

[karvala]

There was a trial recently where BT handed over some control of the MSANs parameters to the ISPs this has now finished I understand,but as yet BT have not allowed this to progress any further. I would trust support if they say it will sort itself out,it almost appears if a max sync rate is in place.

Thanks, Steve.  Why would a max sync rate be in place?  I don't quite understand the process for the ADSL2+ sync rate ajdustments; I'd have assumed that they would have started within the first seven days, but is that not the case?

[Rik]

One reason IDNet can't do anything is that you are still in the training period. ADSL2+ is far more sensitive to noise than ADSL1, so it's possible your internal wiring is picking up noise and keeping the sync at it's current level. Can you recall your noise margin before you switched?

[karvala]

One reason IDNet can't do anything is that you are still in the training period. ADSL2+ is far more sensitive to noise than ADSL1, so it's possible your internal wiring is picking up noise and keeping the sync at it's current level. Can you recall your noise margin before you switched?

Hi Rik, the downstream noise margin before I switched was 6dB; I was syncing around 7000kbps or so.  Presumably if I were picking up noise on my internal wiring that would show up in a reduced noise margin at the router?  I agree about the training period, but that was actually why I was concerned; there doesn't seem to be much, um, training, actually going on, it's always syncing around the same level and just sitting there.  It's not even attempted a single resync on its own yet, the only ones have been where I've rebooted or swapped the router.  

[Rik]

Noise doesn't necessarily show up as a reduced figure, paradoxically. If you sync during a noisy period, when you check the figure later, you may find the margin higher if the noise has reduced. You need to note the value immediately after a resync.

Once the 10 days are up, support can tackle BT to try to get things changed, but right now, BT will do nothing.

There has been a trial, last month, of allowing ISPs to override DLM and manually find the 'sweet spot' for a line. Once this is done, DLM doesn't play its games anymore. I was on the trial and can confirm it works well, I also know of one line with similar attenuation to yours being run at 1db target NM. We now have to wait for BT to implement the scheme.

[karvala]

Well as expected, I'm now at the end of the 10-day BT holiday, um, I mean training period,  , and sure enough the stats are exactly the same as they were at the beginning.  Not having updated my knowledge to ADSL2+, could someone please explain what one would typically see in terms of monitoring/adjustment activity.  For example, should there be any resyncs during the first ten days, at higher or lower sync speeds; should there be any attempts at reaching a lower noise margin (and ideally the 6dB that I was on before).  In short, what evidence should I look for that there has any successful active monitoring of the line (as opposed to it just being stuck at the first speed, which is what it looks like)?  Cheers.

[Rik]

In my case, it started on the highest speed it could negotiate for my noise margin, then gradually reduced, by resyncing, until it found a speed at which the line was stable. A few months later, it tried reducing the NM from my original 9db to 6db then 3db. It's now gone back to 6, as three was too unstable.

[karvala]

Thanks Rik, that's how I imagined it would be, but very useful to know.  Do you think I'm right in being suspicious of a connection that has not attempted a single resync throughout the training period, and it constantly sitting on a 15dB noise margin (with just 19dB attenuation)?

[Rik]

Yes. Assuming you've done all the usual noise reducing stuff, give support a call, you should be doing much better.

[karvala]

Hmm, well this is a worrying trend.  IDNet support are basically stonewalling; I came to this ISP precisely to get away from this sort of thing.  Their response is basically "if it's not changing then your line is erroring", while contradicting themselves by also saying "BT do have banded profiles to limit the maximum and minimum sync rates when a line is showing a high number of errors that may result in the line becoming unstable however your line is not being controlled by these banded profiles".  So they admit the line is not being limited due a high number of errors, but then argue if I'm not seeing any changes in sync speed it must be due a high number of errors.    Looks a lot like "please don't ask me to do any investigating, just accept whatever's happening; the system is flawless" to me.

Anyway, I will leave a different router connected to the test socket for 10 days, and log all activity on telnet during that time (including the number of errored packets).  If they're still not willing to act after that, then I guess it'll be MAC time.

[Rik]

They're not contradicting themselves. Banded profiles are applied to keep a line within certain parameters if normal DLM measures have failed to stabilise it, eg a line which syncs at high speeds but can't sustain them or a line which has a very high error count.  However, DLM will not reduce the noise margin if it sees even a small number of errors, and that appears to be your problem.

Tell me about your phone wiring, what's connected to the line, how many extensions do you have, where is the router relative to the master socket, have you removed the ring wire?

[karvala]

There's one short extension (same room), which I was using with the router and a landline phone attached to a single filter.  No other devices attached anywhere.  I've now attached the router and phone directly to the test socket again, which I did for a couple of days previously without any tangible difference.  I haven't removed the ringwire simply because it's not my apartment and it could be viewed as a form of damage; I guess that's a possible further option, though, if the current test doesn't help.

I take your point about high vs a smaller number of errors, but I don't really see any evidence of any errors.  For example, although we've only been reconnected for an hour or so, the stats so far are:-

          RX packets:33827 errors:0 dropped:0 overruns:0 frame:0
          TX packets:20773 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:41817071 (39.8 MiB)  TX bytes:3032957 (2.8 MiB)

I guess I'll just have to wait and see if that remains the case for the whole ten days.

[Rik]

You won't spot any immediate difference, that's why IDNet have asked you to use the test socket and a different router and filter. Currently, your router is negotiating a connection with a 19-20db noise margin. BT's maximum target is 15db, so that extra NM is down to the router's negotiations with the MSAN, iow, the router and MSAN regard it as necessary to maintain stability. Chances are it's going to be poor line quality, but you need to eliminate your equipment before IDNet can do anything, unless you're willing to pay a £170 BT call out charge.

After the 10 days, IDNet can look at the error levels and, if they are low enough, ask BT to reset the NM back down to 6db or 9db. However, as things stand, your router would still negotiate at 19db.

Removing the ring wire isn't destructive, it can be pushed back into place later. I would strongly recommend that you do remove it. I'd also suggest a quiet line test, dial 17070 and select option 2. You should only hear a low-level background hiss or hum.

One other thing to consider is mains-generated noise. If you can lay your hands on a battery-powered MW radio, de-tune it so you only have white noise, then move it around the phone wire, from where it enters the house to your router. Often, power supplies can be generating a lot of noise and causing this kind of problem.

[karvala]

I'm not sure where you're getting the 19-20dB noise margin figure from?  The downstream noise margin is, and always has been since I started ADSL2+, around 15dB (currently showing at 15.3 on this router; was showing at 15.0 on the other one).

I'll see if I can get hold of a battery-powered MW radio and play around, and also look at removing the ringwire.  There are certainly a good few power supplies in operation around the extension socket area, so I guess it's possible that might be interefering in some way.  I'd expect to see some errored packets if that's the case, though, otherwise the protection would seem to be overkill.

Thanks for the help so far; much appreciated! 

[Rik]

19db is what IDNet's records show that it synced at. Ambient noise doesn't always produce errors, just a higher noise margin on connection. Try what I've suggested and see how you get on. If you're not already, then using a screened RJ11 cable from socket to router might also help.

[Steve]

Its worth the effort trying to get rid of the source of the noise if you can.

see http://www.idnetters.co.uk/forums/index.php?topic=18201.msg440443#msg440443

[karvala]

Oh I certainly agree, but that's of course assuming there is noise, which isn't clear.  I don't understand the IDNet sync record; how can it show a sync at 19dB noise margin, when I've never with any out of now three routers seen higher than 15.4dB?  Surely they can't all be wrong?  Anyway, I'll be leaving it attached to the test socket for a few days, to rule out internal wiring issues etc. (which if there is noise I guess is the most likely source), I'll do the quiet line test this evening, and if I can get hold of a MW portable radio somehow (that might take a few days) I'll do the white noise test.

[Rik]

IDNet will be looking at the data reported back by the MSAN.

[karvala]

Just wanted to provide what I hope is a final update to this, as it may provide useful information.

Following previous comments, I looked again at my home setup, and attempted to find sources of noise, but there was nothing evident there.  This is exactly what I expected in view of the network stats which don't show any abnormally high count on any of the error measures.  The connection remained completely stable for two months, not losing sync, not significantly erroring, but the with the noise margin always stuck at around 15dB (and apparently being wrongly reported at IDNet as 19dB, which contradicts two routers that I have).  Not on a banded profile, apparently, but not even one single attempt at a resync.  My argument from the start was this is evidence of a problem with the MSAN; to me it simply doesn't make sense to argue instead that it's some nebulous untraceable type of noise that is resulting in a lower negotiated sync while not actually showing up in any noise measure.

So, a week ago the MSAN at the exchange fell over completely (confirmed by IDNet, who ran a test after my internet suddenly went down and stayed down for a few hours, and identified it as a clear problem in the exchange equipment).  It was quickly fixed by BT (for once   ), and what did I see this morning?  An automatic resync at a higher rate (and a lower noise margin), exactly in the way that it should have behaved from the start, and without any change whatsoever on my side.

Obviously I'm very happy, and it's case closed now as far as I'm concerned.  I think there is an important message as well here though, which is that exchange equipment is not infallible.  Sometimes when the customer says the problem is with the MSAN, and offers evidence in support of that after going through the normal troubleshooting tests, it's worth taking that seriously instead of inventing all sorts of implausible explanations which amount to saying that nothing should be done.  That isn't aimed at anyone here, I should stress, but IDNet get a yellow card from me for this. There is no place in good customer service for stonewalling on the basis that the problem must always be with the customer.  Sometimes it isn't.

[Rik]

IDNet will have been telling you what BT told them, unfortunately. I had a similar, if more dramatic, experience over Xmas when my line went down completely, but BT said I was in sync. Because I didn't even have a router connected, IDNet were able to argue more strongly, and BT found the line card was faulty. Unfortunately, when it comes to NM and the like, there's not such a definitive case to argue.

[miriam_idnet]

Hi Karvala,

I am glad to hear things are better for you.

I can assure you, we will always listen to what the customer has to say and will bear it in mind throughout the investigation. Unfortunately though, we cannot go to BT and say "customer believes there is a problem with the MSAN".  Instead, we have to perform all possible diagnostics to rule out possible local causes, then pass the case over to BT for further investigation. We can only report to you what the results of said diagnostics (ours and BT's) show us.

This does not mean we have not taken into account your ideas and we do not immediately assume the problem is local, we ensure local checks are carried out to reduce any possible charges being raised against you should the case require an SFI engineer.

I am sorry you feel we were "stonewalling" your ideas of what was causing the problem and hope this has helped clarify our position.

Regards,

Miriam
IDNet Support

[Rik]

Thanks, Miriam.