Print

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

[waltergmw]

Gentlefolk,

I've been puzzling over the performance of the 2Wire on one of our un-favorite long lines which seems to behave in an erratic way. The picture shows two distinct patterns which have been swapping for several months.
I'd really like to solve the underlying problem but as the line test says no fault found and the JDSU broadband tester only syncs at around 500 the chances of getting BT to investigate look very slim.

The resyncs on 19 Oct show much higher downstream starting rate speeds but a very bad final rate, lower upstream rates, higher noise margin and many drops in the day.
The starting and final downstream noise margins remain high.
There are no FECs.
There is no Inpulse Noise and a delay of latency of 0.25 ms
Most drops report Loss Of Signal errors.

Then there are long stable periods of over 3 days, 2 days, 2 days, 1 day, 3 fails in 1 day, 2 days and finally up to "time now" 2 days.
During these periods there is a lower starting rate speed and similar final rate speeds, there are FECs and CRCs, fluctuating downstream start and final noise margins, slightly higher downstream power and higher upstream rate.
There is impulse noise and a higher delay of latency of 8.00 ms.
There are 4 Loss of Frame Errors as well as Loss of Signal errors.

QLT at the moment is almost silent but there are periods of electric fence ticking, although I haven't had the opportunity to test whether that is the root cause of the problem.
Ring back test seems to have no effect at all.

Can anybody offer any suggestions as to whether these observations are caused by differing line conditions or whether DLM (or DSLAM ?) is taking a hand as well.

If there are any real wizards who could predict how to solve the performance issues we would be absolutely delighted.

Kind regards,
Walter



[attachment deleted by admin]

[sevenlayermuddle]

Walter,

It looks to me like the line has swapped between a  capped(/fixed?) 576/288 profile, and an adaptive one.  I think I remember reading somewhere that capped profiles don't normally have interleaving enabled, so that would explain the absence of FEC errors in that condition.

I'm not sure when capping is applied, though I think it's probably done when either BT or the ISP come to the conclusion that a line is just not stable enough to be trusted to find its own adaptive rate.  Some of the DLM papers I've read suggest that a line that fails to achieve its FTR may be 'flagged for investigation', and I've often wondered if that may involve capping it.

One purely speculative explanation may be that the line was put onto a capped profile and flagged for fault-investigation by BT.  BT may then have tested the line at a time the line-noise was absent, decided no fault existed, and put the line back on adaptive?  

- 7LM

[sevenlayermuddle]

I'm not sure when capping is applied, though I think it's probably done when either BT or the ISP come to the conclusion that a line is just not stable enough to be trusted to find its own adaptive rate. 

Actually, see section 4.1 of the BT IPStream Max Customer handbook, which describes auto-capping of 'chronic lines'.  See also the note ate end of section 4.15, which sates that capped profiles will be excluded from interleaving.

I can't provide a link as I can't find that document in a freely accessible (non password-protected) area of btwholesale.com.   Maybe I just haven't looked in the right places but, alternatively, if you just google for the title you'll find copies in caches from btwholesale.com and bootleg copies elsewhere.

[waltergmw]

Thanks very much 7LM,

I think you've spotted what I couldn't see for the trees !
You're absolutely correct that a capped line doesn't have FECs.

Here's a picture underneath of another lousy line I had to get capped to retain a modicum of stability.

Now to find out if the ISP knew anything about these antics.
I had been complaining publicly about its problems so it's just possible that it had been investigated anonymously.

http://www.ewhurst-broadband.org.uk/?p=640#more-640

Kind regards,
Walter

[attachment deleted by admin]

[waltergmw]

Zen tell me that there was an outage of about 3 hours on the 19 October but they have no records of any intervention from them.

I can't believe that BT would have done anything manually without a Zen request, so I have to conclude there was some automatic process as 7LM has described.

I've been observing a few lines around here for about 3 years now and I've never seen this type of capping or banded profile incident which presumably is quite rare.
Resyncs with lower IP profiles are however far too common.

Kind regards,
Walter

[sevenlayermuddle]

Walter,

That BT handbook I referred to does seem to describe how BT have their own process by which they can cap a 'chronic line' (a line with  excessive re-trains over 24 hours), on the justification that it places a burden on the network as well as affecting the end-user, which actually seems reasonable to me.

However, it does suggest that the ISP will always be notified when a chronic line is capped and advised what is needed to fix the fault, and that after the fault is rectified  the ISP needs to raise a 'Performance fault' with BT in order for IPStream Max to be restored.  The line then undergoes a new stabilisation period to recalculate FTR and MSR ( I guess it just  'ten-day-trains' again).

Note that versions of the document that I found on the web are quite old (July 2007) so processes may have changed.

If that is what happened in this case, then it looks like Zen were 'on the ball' and got the line uncapped without waiting for complaints from the end-user.   But it's scary to think how some of the less competent Indian-based ISPs would deal with it (or not).  It may even explain a few forum threads, where ceretain ISPs have been unable to explain to end-users why their lines were capped, and seemingly incapable of getting them uncapped.

- 7LM

[waltergmw]

@ 7LM,

I agree that it must be an automatic activity. Zen say they won't make changes without informing the client and I would have been informed as well.

Perhaps Azzaka might like to comment ?

Kind regards,
Walter

[Azzaka]

'...However, it does suggest that the ISP will always be notified when a chronic line is capped and advised what is needed to fix the fault, and that after the fault is rectified  the ISP needs to raise a 'Performance fault' with BT in order for IPStream Max to be restored.  The line then undergoes a new stabilisation period to recalculate FTR and MSR ( I guess it just  'ten-day-trains' again).'

We do not get notified at all unless the EU tells us there is an issue. At this point the only fault we would raise will be an intermittent fault to remove cause of the cap, and once done the cap itself will be removed.

Please note 7LM, that you are quite right in what you are reading. The cap is applied to lines that are very/chronically Intermittent as it does cause undue stress the exchange equipment. The uncapping has come from the implementation of the new DLM whereby it will note system wide and hardware changes, then applies the change it feels the line can handle.

In this case the DLM uncapped the line and allowed it to continue at full speed. Howevever as there is a slight pulse in the background I dare say there is an electric fence hitting the line, and as for the JDSU testers they can only test a looploss of 60db.

-Azz

[waltergmw]

Thanks very much indeed Leo,

I am very uncomfortable about a fully automated process not at least flagging up the capping to the ISP.
If they then choose not to tell the customer that is their decision.

As a semi-intelligent end user - together with 7LM's expert knowledge, I would be profoundly unhappy if my line's performance was unnecessarily capped as I would no doubt still be expected to pay the full ADSL service charge.
We (end users) would all remain in the dark if I had not kept records of the 2Wire 2700HGV diagnostics which, as far as I'm aware, are unique to that modem?

As noted by 7LM, I wonder just how much of this story is known and understood by the Indian brigades ?

I wonder if Kitz might at some stage add a little more to her splendid ADSL descriptions pages ?

Kind regards,
Walter

[sevenlayermuddle]

As noted by 7LM, I wonder just how much of this story is known and understood by the Indian brigades ?

From my own experience of Indians I've spoken to, they don't know the difference between a Target Margin and a Tuesday, so it's hard to imagine them being able to comprehend a capping process that sits on top of DLM.

IMHO, the fundamental flaw is that the UK infrastructure model gives the network provider (BTw, in this case) all-encompassing powers of discretion over individual EUs broadband access, and yet allows BTw to disclaim any direct responsibility to the EUs.   

Common sense seems to dictate that when BTw cap a line,  the end-user is the affected party,  and so the end-user MUST be told what has been done, and why.  Yet, even if BTw were to tell the ISP, there would be nothing to guarantee the ISP would tell the EU and, if they didn't, BTw would be able to blame the ISP.  I'm afraid I think that is all quite ridiculous.

- 7LM

[waltergmw]

@ 7LM,

I'm sorry to say that common sense is not an attribute that comes readily to mind to describe BT.
Any pretence at that would violate their first commandment - Thou shalt not talk to the EU and only grudgingly do so to the ISP.

I'll start another thread on other aspects of this unacceptable situation shortly.

Kind regards,
Walter

[kitz]

>>> it does suggest that the ISP will always be notified when a chronic line is capped and advised

There definitely is some sort of automatic procedure...  and several times Ive been aware of the ISP not being notified by BT.

More often its spotted by an ISP CS person who is astute enough to recognise the signs.
IIRC there was a case on here last year when the ISP rep only released what had happened after seeing the obvious telltail signs from the line stats posted in here by the OP..  and there was nothing on the account or anything from BT to advise them that the line had been put on Max capped rate.

[waltergmw]

@7LM & Kitz,

I'm pleased that you too were astute !

Two other points around here.

I know of another lousy line that would not maintain sync when on a capped service but it manages to blunder on when left on rate adaptive; in this case an auto-cap would be a disaster.

The line in question here

http://forum.kitz.co.uk/index.php/topic,8282.0.html

is also very bad but it does not seem to have done an auto-cap. I note it is on an Alcatel based DSLAM whereas many of our lines (as above) are on a TI based DSLAM.

Am I correct in thinking that the DLM & auto-cap logic operates within each DSLAM ?
That might explain the different observations?

Kind regards,
Walter

[waltergmw]

@ azzaka, kitz and 7LM,

Herewith another very strange twist to this enthralling story. The picture below shows that the modem recovered from a power fail and managed to get on line at 03:14:38 this Saturday morning and then a disturbance continued restarting the modem again at 03:17:56, 03:19:41, 03:23:14 and then it remained online until 08:13:43 when I started the diagnostic observation. However the connection failed and I re-started my remote session which did not cause the modem to resync, but the line's throughput performance was so poor as to trip my remote LogMeIn session.

However the intriguing thing is that the TI DSLAM resynchronised twice with a capped connection within the space of a few minutes before resynchronising again properly in rate-adaptive mode. It then remained connected probably from say 03:24 this morning. For those unfamiliar with the 2Wire diagnostic the last time entry starts with the start time of the session but is then updated with "time now" every time the display is manually refreshed. When the modem resyncs again I think that time on that line of the diagnostic display is re-written as the start time of the now failed session.

The above suggests to me that BT have re-programmed this particular TI DSLAM to synchronise (maybe only with a BT Business hub ?) in capped or uncapped mode EVERY TIME as it thinks fit and that this process is entirely automatic.

Kind regards,
Walter


[attachment deleted by admin]

[waltergmw]

Gentlefolk,

Another point I've just noted with the 2700 HGV diagnostics on a capped line is that the bit loading diagram does not illustrate how the tones are allocated to upload and download functions.
(See the diagram above on my Nov. 3 entry)
As the upload speed is halved approximately one might expect to see the shape of the diagram change to reflect this condition, but the 2700 shows the standard rate-adaptive view of bit loading at all times.
However even with this "feature" it still provides an invaluable insight into the line performance which must consume the modem's resources.

Similarly I don't think bit swapping is illustrated either.

Kind regards,
Walter