Print

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

[William Grimsley]

Crikey, I didn't realise that, thanks.

[ejs]

With ADSL though, downloading or not made no difference to the amount of CRC or other errors, if the CRC rate is very high, then you won't be able to transfer any data successfully. But that's because it's constantly sending and receiving idle ATM cells when not transferring any higher level data. VDSL2 uses PTM not ATM, but I think it still sends and receives idle PTM codewords (64/65-octet coding) when not transferring any higher level data. I think G.INP will re-transmit idle codewords, I don't think it "knows" not to bother if they don't contain any actual data.

kitz, didn't you recently have several hours with vast numbers of CRCs? I assume you weren't using your connection at a constant rate the entire time.

Anyway, I thought the point was that William Grimsley's line currently has a lot of work for G.INP to do, compared to other lines which have very little for G.INP to need to re-transmit anything.

[WWWombat]

In fastpath, it is only CRC, ES and SES that give you a feel for how the line is working

In old-style FEC+interleaving, it changes to FEC, CRC, FECS (rarely visible), ES and SES.

With retransmission activated, it becomes FEC, retransmit-tx, CRC, FECS (rarely visible), LEFTRS, ES and SES.

DLM is likely to only react to ES - but that is (and always will be) something of a guess about how a hidden system works.

A reminder: Statistics gathering (such as MDWS) only works when you can compare an idea of "before" with that of "after". If it isn't running when an event occurs, it is already too late to ever see the picture of "before".

[William Grimsley]

I know I sound like your typical customer, but the modem resynced by itself, I didn't make any of this happen, I just want to leave it be because it's obviously happy if it hasn't lost sync yet.

[burakkucat]

Taking a broad, overview of the circuit's behaviour for the last 24 hour period (the "traffic lights" image, attached below) we see that there is very little nothing that could cause the DLM process to intervene. No DS ES, just 48 US ES and no resynchronisation events. Everything in the "green zone".

Looking at the various plots for the same time-frame, we can see that the circuit is reacting to RF ingress during the hours of dusk to dawn. The SNRM, FEC and Bit Swapping plots look somewhat "dramatic" but when they are each viewed in a full screen, respectively, there is nothing significant.

Overall it would be interesting to see what, if any, events occur with that circuit in the forthcoming days/weeks/months.

[WWWombat]

I know I sound like your typical customer, but the modem resynced by itself, I didn't make any of this happen, I just want to leave it be because it's obviously happy if it hasn't lost sync yet.

I don't know if you're still around William, but here's a story of what happens when the resync happens and results in a lower SNRM of around 1dB:
http://forum.kitz.co.uk/index.php/topic,18102.0.html

There is no black-and-white answer here. It is all a case of risk management ... and a low SNRM value just makes for more manual monitoring effort.

[William Grimsley]

Line in a bit of a mess this morning as you can see on MDWS. Not sure what's causing it. :/

Aha, there's an Openreach engineer working on a pole near the bottom of our lane!

[mlmclaren]

Aha, there's an Openreach engineer working on a pole near the bottom of our lane!

Why would that interfere with your line... to be honest looking a MDWS I can't see anything irregular... *ahem* or even even 'more' irregular than its current status which is low SNR, increased error correct rate and traditional affects of a long unstabl'ish' line.

What's the issue you had?

[William Grimsley]

Check the Downstream CRC Errors, there's a huge amount showing there especially in a short space of time.



Just to let you know, the line is not long, check the line attenuation.

Recently, there has been more Downstream CRC's per day than there was a few weeks ago on the line. Something isn't right.

[mlmclaren]

Well, the fact the weather has changed since the other week, also if your saying BT was up a poll that probably means a new connection coming on to the network so potential crosstalker....

As for your line length... its certainly not short, my Sky connection in Brum which is connected to an ECI cab, is considered long (750+m) yet that's happy to get 61/12....

Anyway, don't go calling BT, they might ask you to reset your modem

[William Grimsley]

Could be another connection, but to me it looked like a fault being fixed. Why would I call BT? That's the last thing I want to do.

Anyway, my original issue hasn't been explained, I have no idea what caused the Downstream CRC's, but it certainly wasn't crosstalk.

The Openreach engineer has only just left the lane, he's been fiddling next to quite a few poles.

Oh, and I highly doubt it's got anything to do with the weather. I'd have expected a slow rise in CRC's, not spikes.

[ardsar]

Check the Downstream CRC Errors, there's a huge amount showing there especially in a short space of time.



Just to let you know, the line is not long, check the line attenuation.

Recently, there has been more Downstream CRC's per day than there was a few weeks ago on the line. Something isn't right.

That line is considered long attenuation is the same as mine. It's over 1000m to the cabinet 

Sent from my SM-G935F using Tapatalk

[William Grimsley]

Alright.

[William Grimsley]

I must apologise to mlmclaren, my mum asked the Openreach engineer what was going on and he said he was installing a new line into a property up the lane. What makes me curious though is why did the SNR Margin increase and then decrease shortly after? Was the previous line disconnected (SNR Margin increased meaning less noise and crosstalk) then the new line connected (SNR Margin decreased meaning more noise and crosstalk)?

[ejs]

I guess it's nothing more than the engineer moving wires in a big bunch of wire pairs around, to access an unused pair in an existing cable, and then tucking them all back in when they had finished.