Print

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

[crgbt]

Hi all,

I've had a copper pair + VDSL service from A&A since November/December 2018 when I moved into this property and I've not had too many issues with it, except very low sync rate when I first moved in which was resolved after three engineer visits and some issues with faulty Draytek 130's. This was until 5th of this month when between 06:00-08:00 Mon-Fri and 09:30-11:30 Sat-Sun I get thousands of DS Error Seconds on the line, likely as a result of a drop or fluctuations in DS SNRM, which in turn is causing DLM to take action and eventually band the line. I've been monitoring this line since and also had Openreach out who found no faults on the line, although they did change some of the copper pairs I was on which resulted in slightly increased sync rates but the errors remain. I've also had a second line installed on 8th of this month and the issue isn't apparent on this line.

Here are some photos from DSLstats:

Sometimes, the errors are not too bad (you can see the time of day change between Fri and Sat):



However most days it is this bad (the US errors you see around 2am are DLM kicking in both days to resync the line):



I can post further stats if it helps. A&A are getting back to TT/Openreach to see if there is anything further they can do, but I know cases of interference are often just left and they eventually resolve themselves once whatever causes the interference is no longer in use.

Also, for what it's worth, I've replaced the modem, PSU and RJ45/RJ11 cable this AM to make sure it's not that, and I've tried turning everything in the house off with the exception of the equipment that powers the broadband on a weekday between 06:00-10:00 to rule out anything inside the house.

My setup is 2x VMG1312-B10A (1 A&A TT backhaul line, 1 A&A BT backhaul line) and an FB2900.

To me this looks like a case of REIN or SHINE, but what do you all think?

Thanks for looking
crgbt

[Black Sheep]

There is undoubtedly a pattern there, confirming the 'R' in REIN. 

Quite a lot of good things have been happening in OR engineering, since I last frequented these boards, none more-so than the launch of NATO (Neighbourhood Analysis Tool for Openreach).

This is an extremely powerful tool compiled by the guys in the Chief Engineers Unit, and takes information from a plethora of
 databases to give a view of what is happening on nodes. I can't begin to tell you how this has been a long time coming !!
Trials ended a while back and now all engineers can access it if they apply for it.

This tool (or analysis by this tool) is also used as the only way to build a REIN case these days. It can look at all the other circuits off the node (even LLU's) and presents it in an easy-to-read format. Of course, we can then 'drill-down' to try and pin-point other circuits that may be affected at the same time the REIN is prevalent, and if any are experiencing greater issues etc etc ... to try and determine which premises may be bringing about this extra unwanted noise.

Like I say, not all engineers will have it or may not even be aware of it if they only do UG faults, or CAL faults (ie: not broadband). But your circuit certainly does show signs of REIN on those graphs.

[crgbt]

There is undoubtedly a pattern there, confirming the 'R' in REIN. 
...

That’s some great info there, thank you Black Sheep. I’m relieved OR have better tooling for investigating REIN these days and it makes me a little more confident they can find the cause.

I have OR scheduled to come out again in 07/11 for further investigation work, but apparently the ISP can’t raise a REIN fault - it has to be the fault condition (e.g. high ES in my case) and then the OR engineer raises the REIN fault. Here’s hoping the OR engineer knows what REIN is!

Thanks,
crgbt

[Black Sheep]

Ha ha .... me too.