Print

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

[whatkatedoes]

Or you could get an Openreach technician to fix the fault

I suppose that depends on whether or not it will be classed as a fault, or a de facto Fact of Life of current VDSL delivery methods.

I'm a pessimist, so I'm anticipating the worst, and like to be sufficiently armed with The Knowledge regardless.

Anyhoo - Limit applied, sync currently @ 50/7.8, so am waiting for the "hit" of next door, but there's also tomorrow's OR engineer visit, so I feel appropriately ready either way

[Dray]

Hopefully you're ready to plug in your ISPs supplied equipment so the OR guy doesn't just blame your modem, confiscate it and charge you £120? 

[whatkatedoes]

Hopefully you're ready to plug in your ISPs supplied equipment so the OR guy doesn't just blame your modem, confiscate it and charge you £120? 

Fortunately I'm going to assume that they have a brain, since plugging in the BT hub (which am out of contract for now anyway) changes *nothing*.

Also - the changes made above can be enabled/disabled at the tick of a box.

[kitz]

Looks like crosstalk to me.   Unfortunately both upstream and downstream take a hit at the same time.  You may get some temporary relief when they have their router disconnected but thats about it.   Last year I did a rough analysis of members of the kitz forums and the average loss per line was ~20Mbps.
At that time my own headline loss was ~25Mbps.   About 3 weeks ago another of my neighbours must have got vdsl and I took an immediate 9Mb loss, so my total headline loss is now 33-34Mbps.

Unfortunately there isn't anything that can be done about crosstalk (aside from vectoring).  Openreach could swap you to another pair, but it will eventually catch up, which is why they dont like doing so as its only a temporary fix.

Your Hlog looks fine, indicating no physical line fault at the time the snapshot was taken. (Wonders why the graph colours are wrong)

Your QLN graph shows signs of crosstalk especially in D2 (1218-1950).  Bumps and curves also in evidence for D3.  There's also a nice trough in U2 but its harder to read upstream due to power cut back. 
- I tend to compare both QLN and the bitloading graph to give me a better idea.. especially as I was 'brought up' looking for crosstalk before there were QLN graphs so had to look for it on bitload alone.   

[roseway]

(Wonders why the graph colours are wrong)

That's because the band plan in use only goes as far as tone 2100 (or thereabouts). The QLN and HLog graphs cover a much wider tone range, but tones beyond 2100 are shown in blue because they are unallocated.

[kitz]

d'oh... of course...  need to put my brain in gear.  Would have spotted that if Id also seen bitload.

[whatkatedoes]

For interest's sake, here we go, rate limit applied, whilst we wait for the big hit.

[kitz]

hlog is near perfect as Ive seen. The jump at U2 is normal. 

PS.. for your info.   Hlog shows physical line health/bridge taps as its based on the atten.   QLN shows up things like interference and crosstalk.

[whatkatedoes]

hlog is near perfect as Ive seen. The jump at U3 is normal. 

PS.. for your info.   Hlog shows physical line health/bridge taps.   QLN shows up things like interference and crosstalk.

Thank you   I was nodding obliviously to your original post

[kitz]

edited my post btw.   Typo - should have said U2 not U3.... as upstream starts at U0.   I did say U2 in the prior post.

[whatkatedoes]

Boom.

Er...  what?

SNR Margin (dB)   2.3   3.8
Attenuation (dB)   23.2   0.0
Output Power (dBm)   11.7   3.3
Attainable Rate (Kbps)   43911   7251
Rate (Kbps)   50000   7887


(Above was taken whilst remoted in, so is not entirely accurate)

So this is showing that the neighbour switched on, my attainable sync took the expected hit to 43.9 - but the router has remained connected at 50.  for now!

[S.Stephenson]

Just keep a eye on the error seconds if they creep too high just lower the cap so the line doesn't get hit by DLM.

[whatkatedoes]

Just keep a eye on the error seconds if they creep too high just lower the cap so the line doesn't get hit by DLM.

Total ES   Down:1   Up;113

This during the current 5 hour connection period.

[WWWombat]

That ES figure is the most important one to watch, but looking at other error indicators can give you a heads-up as to whether things are working well or not. The graphs on MDWS makes it easier to see over time.

I've just checked, using the "last 30 hours" timescale, and can see
- At 11:25ish, when the neighbour's modem was turned on, your downstream SNRM dropped to 2.3dB
- This has triggered no CRC errors, so the ES counter isn't changing [Errored Seconds graph, and B0 CRC Errors graph]
- However, we are seeing FEC errors (ie miniscule, correctable errors) start up - at about 300-400 per minute [B0 FEC graph]
- And G.INP retransmission is being pushed a little harder [G-Retransmit Tx graph]

Both FEC and Restransmit-TX have started showing spikes since 16:30, so I'd suggest that a careful watch is needed to make sure the ES rate doesn't suddenly start to climb (especially as it gets dark).

If it starts to go up much, you want to alter your speed-limit down a notch. A downstream SNR of around 3dB seems to be the point where errors become more plentiful.

[j0hn]

Glad that worked for you. As others have said you can now tweak that up/down to suit. You've achieved the 1st goal of maintaining sync when the neighbour connects. Now you need to keep an eye on errors, the ES rate in particular. If they start to get too high I would be aiming more for a dip to 3dB than 2.3dB.

Or you could get an Openreach technician to fix the fault

With his line resyncing every time the neighbour connects it shouldn't be too hard to get a pair swap. It could end up being worse though. At least at the moment his disturber turns their modem off for large periods of time.