Print

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

[kitz]

Have you asked PlusNet to run a Copper Integrated Demand Test (CIDT)?

I'd be interesting to see how that is answered.   I havent added it yet to my ticket, as I didnt want an addition to send it back to the bottom of the pile.

[mikehiow]

I've taken a quick look at your graphs and it does seem as if there is a definite infrastructure problem present -- possibly a HR or semi-conducting joint.

Have you asked PlusNet to run a Copper Integrated Demand Test (CIDT)?

The graphs posted in my last post? What on them would indicate that?

If you're looking at graphs before that, I did have an issue where one leg was DIS at the PCP which was repaired around a week ago - I imagine that issue was slowly getting worse until it cut out all together.

As for the CIDT, they may well have done that as they are claiming a copper issue as a result of tests stating possible HR.

[kitz]

As for the CIDT, they may well have done that as they are claiming a copper issue as a result of tests stating possible HR.

Ok thanks,  there was nothing on any of my tickets to specifically indicate a CIDT had been run.

[burakkucat]

I've taken a quick look at your graphs and it does seem as if there is a definite infrastructure problem present -- possibly a HR or semi-conducting joint.

Have you asked PlusNet to run a Copper Integrated Demand Test (CIDT)?

The graphs posted in my last post?

Yes.

What on them would indicate that?

I've based my assessment on the changes recorded in both the line and signal attenuation values. For the best interpretation of your graphs, they need to be inspected by an Eagle eye . . . All being well, I expect Bald_Eagle1 to be passing this way soon. 

[mikehiow]

Can you be more specific? I mean, the line had only really improved since the DIS killed my DLM profile.

I'm not well versed on this stuff, however.

Sent from my HTC One using Tapatalk 4

[Black Sheep]

Although an improvement on the bog-standard Eclipse/RAT/Fast Test systems, the CIDT will still miss a small 'HR'. Don't get me wrong, if the HR is sufficient enough, it will show a fault on the test result that the other low-end tests would miss. I wouldn't put all your eggs in this particular basket though.   

[Bald_Eagle1]

As it stands, I'm left with interleaving off again and a sync of 33/20.

Full monty stats over the period here, for anyone that is interested.

From the latest graphs you posted, it appears that US Interleaving may well be OFF, but that DS Interleaving is still ON (at a depth of 500+).

Definite problems were seen with Attenuation & SNRM variances.
These may now have settled down, but it does appear that the connection may have resynced again this morning.

If it did resync, it may be useful to see how it has performed since.

Indications are that your connection is capable of supporting higher DS sync speed (high SNRM values) & that error rates have been relatively low.

Hopefully, DLM will now see a reasonably steady connection & increase speeds (in small steps) over the next couple of weeks or so.

It does occasionally happen that connections can be capped/banded at low speed levels, seemingly indefinitely.
I have seen mention of DLM taking over 50 days or so to eventually restore decent speeds following repair works.
Hopefully, you won't have to wait that long.

You could always request a DLM reset via Plusnet, but it would no doubt require another engineer's visit (if BTOR actually do agree to it).

It may be wise to continue monitoring to demonstarate a stable connection i.e. daily or user initiated resyncs cease.

The daily resyncs may just be DLM attempting to deliver higher speeds (but unable to do so until it or manual intervention removes the capping/banding).

[mikehiow]

It certainly is off - although there's probably only a couple of samples on that graph. I can assure you DS Interleaving is currently set to 1.

The resyncs each day are DLM and happen around 6am usually, although there was one this afternoon where I accidentally knocked the power out reorganising my network.

It's worth noting that the 29th to the 1st is where the connection had the fault mentioned in the OP of this thread. It looks to me that any significant variances since then are simply where SNRM/Power etc. has changed with the resync at a different sync.

I've graphed from the time of this morning's until now here

As for requesting a DLM reset - I have, Plusnet have taken a long time to get back to me and now believe their is a copper fault, but I'm not convinced.

[Bald_Eagle1]

It certainly is off - although there's probably only a couple of samples on that graph. I can assure you DS Interleaving is currently set to 1.

Ah. I can see it now.

The resyncs each day are DLM and happen around 6am usually, although there was one this afternoon where I accidentally knocked the power out reorganising my network.

Hopefully a single resync where power was OFF won't have a negative effect on what appears to be somewhat improved stability.

It's worth noting that the 29th to the 1st is where the connection had the fault mentioned in the OP of this thread. It looks to me that any significant variances since then are simply where SNRM/Power etc. has changed with the resync at a different sync.

I've graphed from the time of this morning's until now here

As for requesting a DLM reset - I have, Plusnet have taken a long time to get back to me and now believe their is a copper fault, but I'm not convinced.

Are Plusnet planning to arrange an engineer's visit to investigate the copper 'fault'?

If so & if things remain stable with high SNRM & attainable rates, but still at capped/banded speeds, that might be your best opportunity to request the engineer to arrange a DLM reset.

[mikehiow]

Apparently it's "with" BTOR and I'm told a DLM reset will be part of the procedure in rectifying the fault.

I'm not convinced - hopefully the engineer phones me up again this time.

[mikehiow]

Engineer visit this morning - got me out of bed!

DLM Profile reset - now back at 80/20.

I asked him about this suspected copper fault, he reckoned the resistance was 1 ohm out and I shouldn't worry about it, but it was enough to flag up on the tests.

[mikehiow]

Now I'm stumped.

I woke up this morning to find DLM had shaved off some DS and added a fair bit of interleaving :/

The graph doesn't show anything obvious since the profile reset I don't think, so I'm a little confused.

Full monty: http://vxr.in/share/line_stats__FULL_MONTY_P-20130807-0657.png
Current stats at resync: http://vxr.in/share/line_stats-L-20130807-0434.png

[ColinS]

Now I'm stumped.
I woke up this morning to find DLM had shaved off some DS and added a fair bit of interleaving :/

I suspect that you're still on the 80/20 profile though.  Perhaps after DLM had moved you back up the profile bands, it decided that it didn't like something about the (previously observed) error rates that merited introducing a fairly hefty dose of interleaving DS.  Once it had done this, the actual sync rate is what the modem can achieve within the profile band given the DSLAM's input parameters.  They're not in the latest stats you've provided but I suspect that INP and delay are also set.

This has happened to me too. 
My parameters are now depth=1237, R/N=16/80 or 20% (INP=3, delay=8) and so the resultant DS actual sync rate is 78687Kb/s.
Compare your depth=1193, R/N=16/67 or 24% (INP and delay currently unknown to me), and your resultant actual DS sync rate is 76986Kb/s.

With interleaving at that depth you can expect high rates of FEC (corrected) errors reported.  AFAICS this is solely a result of the large ongoing interleaving depth, as ES and CRC rates are low.  Without interleaving, these would probably result in a (slightly) higher CRC rate instead.  Which is 'better', well that's something that only the DLM algorithm thinks it knows best (and you're on an ECI DSLAM, I believe, whereas mine's Huawei).

My observation (of the Huawei DSLAM) is that shifting this looks like it's going to take some time, if ever.

[mikehiow]

I wondered if it was looking at older rates, but shouldn't a profile reset remove all of that?

[ColinS]

I wondered if it was looking at older rates, but shouldn't a profile reset remove all of that?

Until CSPs like OR are willing to publish their DLM algorithms (which I doubt they will because of 'commercial confidentality'), we will never know for sure, but I believe that it has been suggested before that the entire line history is recorded (by OR anyway) in its WHOOSH system (BS will correct me I'm sure), and this could and may well be used by DLM. 
Your profile has been reset to 80/20, your history hasn't.  Only time might do that, I fear.