In reply to a post by Chrysalis:

I think its a matter of time before I am interleaved, at least if I carry on using the HG.

I have 16 red specks on my tbb graph today, using the ECI just about every day there is 0. I am only using the hg currently for a few weeks to see if DLM touches my line again so I can monitor the sync speed. I plan to long term use the ECI again as its better for my connection.

That makes sense. I set up a BQM to monitor mine, but don't put the link in my .sig as the IP changes too often, as my router likes to reboot whenever I change anything simple.
http://www.thinkbroadband.com/ping/share/a7bc1dbd1b4...

In reply to a post by jchamier:

In reply to a post by Andrue:

Attainable rate has been steady at 73Mb/s throughout. BaldEagle has looked at the complete set of the last week and pointed out that I don't have interleaving either. My line might not be running as well as one would expect but I don't see anything that would explain this:

I'm guessing a fault on your port in the FTTC cabinet, but I have no idea you'd get a "lift and shift" equivalent.

i have an engineer booked for tomorrow PM. Apparently he has been advised by BTor to investigate throughput rather than line characteristics so there's hope. Of course he may just turn up and insist on sticking his JDSU on the line anyway but who knows - I'm surprised and impressed that IDNet arranged for him to come within twelve hours. I only told them to go ahead at 5pm today.

All things considered a lift and shift at the cab seems the best bet. It doesn't seem to be my line and if it was the backhaul to the exchange or beyond you'd think other people would have noticed or BTor's systems would see something. It's just about feasible that the port in the cab is the culprit.

In reply to a post by Chrysalis:

yeah you can either check in the gui one day then check the same time the next day and do a maths calculation or there is this telnet command.

It's right down the bottom:

Since Link time = 9 days 1 hours 21 min 29 sec
FEC: 0 3851
CRC: 11270 517
ES: 7545 494
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0

So that's 11,270 over 9 days which is 1,252 per day or 52 per hour. Doesn't sound cataclysmic to me

In reply to a post by Andrue:

i have an engineer booked for tomorrow PM. Apparently he has been advised by BTor to investigate throughput rather than line characteristics so there's hope. Of course he may just turn up and insist on sticking his JDSU on the line anyway but who knows - I'm surprised and impressed that IDNet arranged for him to come within twelve hours. I only told them to go ahead at 5pm today.

Excellent that sounds like when I had a line fault that BE organised an SFI, they managed that within 48hours and the SFI was VERY thorough. The very experienced BTO guys on DSL faults are very good, if they're given enough time.

All things considered a lift and shift at the cab seems the best bet. It doesn't seem to be my line and if it was the backhaul to the exchange or beyond you'd think other people would have noticed or BTor's systems would see something. It's just about feasible that the port in the cab is the culprit.

Yes, or the copper tie-pair between the FTTC cab and the PCP - I suspect even an SFI won't be able to touch the FTTC cab as their effectively sealed, but he/she should be able to move you to a new tie-pair.

This could well be very wrong, but according to G993.2 [1] - those are the specs for VDSL2 - the CRC error count relates to corruption of the Overhead (OH) Frames. Those frames carry timing references, sync bytes, and system primitives.

You have a higher level of CRC errors. And yet you also have a low or even a zero FEC error count. The FEC counter is part of the Reed Solomon decoder and records errors in the payload. High CRC and zero FEC suggests a problem that is not related to noise.

The CRC errors in the absence of FEC errors suggests a framing problem, perhaps some sort of timing error. It would seem impossible to have noise that corrupted only the Overhead frames.

Could well be wrong though.

cheers, a

[1] http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-R...

Edited by asbokid (Fri 22-Feb-13 21:18:18)

so about the same error rate except maybe you dont get these occasional small bursts I get.

I think you have done well to get an engineer out, I cant imagine BT entertaining me asking for one with a 71mbit sync on a 65mbit estimated line

In reply to a post by Chrysalis:

I think you have done well to get an engineer out, I cant imagine BT entertaining me asking for one with a 71mbit sync on a 65mbit estimated line

Doesn't look like I did either since no-one has turned up. Although I suppose it's possible that the SFI agrees that the fault is in or beyond the cab and didn't see any need to come here :-/

In reply to a post by Andrue:

In reply to a post by Chrysalis:

I think you have done well to get an engineer out, I cant imagine BT entertaining me asking for one with a 71mbit sync on a 65mbit estimated line

Doesn't look like I did either since no-one has turned up. Although I suppose it's possible that the SFI agrees that the fault is in or beyond the cab and didn't see any need to come here :-/

The engineer turned up this morning instead. Unfortunately as I expected all he did was stick his JDSU on the line and run the usual tests. He was interested in the TBBQM graphs I have but was mystified.

I think that in April I'll see if IDNet can create me a second login to try. Perhaps the problem is RAS related and a new account will not have the problem.

One problem is that the BT Techs are not taught everything that their test equipment can do or see.

Last week I spent time explaining the basics of VDSL to a BT Tech and what the graphs were showing ... Even if the knew what a Good/Average/OK/Bad graph will look like it could help.

Just logged into my HG gui and DLM has fiddled with the power again.

Now I got.

Downstream Upstream
Attainable rate (kbit/s) 85544 32158
SNR margin (dB) 9.8 14.4

Edited by Chrysalis (Mon 25-Feb-13 12:27:05)