Print

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

[tristan]

Not that I'm aware. Would it be obvious if he was doing that?

Next time it goes off (next hot day I'm guessing - could be a fan / air conditioner in a neighbour's house) I'm to contact the twitter guy again.

Today felt like another box ticking exercise TBH. The H612 is 'obsolete' and shouldn't have been given to me by the previous engineer. And the socket should have been replaced as part of SOP.

Apparently there are 2 REIN guys in Oxfordshire. I'll also start knocking on doors and see if anyone had something on corresponding to the 'down' times.

[GigabitEthernet]

If he suspected REIN he should at least tried to build a REIN case? He'd be on the phone to the REIN team if that was the case.

In my case the engineer tried to build a REIN case but apparently the connection is too stable (sounds like rubbish but that's what he said).

Edit: I'd rather have an HG612 that an ECI...

[tristan]

He did make a couple of calls, but I didn't get the impression he was at that stage. I think it was a "let's do some more internal work and hope it goes away". I've a lovely MK3 socket now, about 3 times the size of the early 80s one it replaced.

I am on their 'boost' list which means I should get further support quickly when it goes wrong next.

And yes, I am fully intending to swap back to the H612 but will do that after I've spoken to the twitter guy. There's no way I am being blindfolded on this by lack of stats.

[GigabitEthernet]

If he suspected REIN I am surprised he didn't at least try and build a REIN case?

[Black Sheep]

The REIN Case can be built retrospectively, it doesn't have to be done there and then in front of the EU, and waiting time for the REIN team may not be conducive at that time ??

As a REIN engineer I can confirm quite a lot of cases built are proven not to be REIN, so the REIN team are tasked to scrutinise data and make a judgement call as to whether it's frugal to build a case or not.

[tristan]

As a REIN engineer I can confirm quite a lot of cases built are proven not to be REIN, so the REIN team are tasked to scrutinise data and make a judgement call as to whether it's frugal to build a case or not.

Thanks Black Sheep. The OR guy, after I described what was happening and showed him the SNMR graph from Friday - Sunday on MDWS, seemed to think the way the SNMR collapsed so quickly and then recovered a period of time later indicative of REIN. Would you agree? (username "tristanc")

He gave local examples in Oxfordshire of a pub's cellar cooling system interrupting a small village and an arc welder on a local industrial estate causing havoc to businesses near by.

I spoke to a neighbour who indicated that a business I'm living in the shadow of (a large publisher) has had a dodgy aircon device which, in the recent past, interrupted the TV reception (my digital terrestrial has been fine). Not sure if this is likely to impact the VDSL frequencies after passing through a few brick walls etc.

I'll knock on a few doors tonight: the correlation to warmer temperatures could indicate someone's cheap fan or aircon is causing it.

The connection has been stable since Saturday evening - Sunday and today were rainy / not as warm... But the historical stats I have shows less of a correlation - almost random. Will look again.

EDIT: Just made the attached plot of SNMR up and down over the dates across the x-axis. The large tics indicate midnight. This suggests, tenuously perhaps, the SNMR being impacted between 6am and 6pm on the 1st, 3rd and 9th July. This could be a pattern.

The other times I think were me rebooting / the line being resynced etc. [There is an erroneous purple horizontal line at ~13.5dB for some reason]

[Black Sheep]

I'm not on MDWS, I'm afraid ….. but there are plenty of individuals on here better at interpreting the graphs than I, so hopefully someone will be along soon to give their thoughts on your circuit ?? 

The graphs we look at are slightly different, they tend to be most summary-biased …….. however we can drill into daily/hourly data to try and get a handle on what is happening.

This is where it can be difficult for the REIN team, as there can be false-positives within the data that point to wards possible REIN (i.e.: pattern based data), but can in fact be something like a hot-VLAN, or a business with static IP addressing having their router incorrectly set up to dynamic IP.

I've had both scenario's, the business one only a few months ago. But to the engineer/REIN desk analyst viewing the stats on both types mentioned, it will appear as a REIN pattern, as the MTBE's/Initialisations etc only occur when the EU's are at work and using the connection.

So in a nutshell, there is no A or B answer with REIN. It's all about collating data from DSL circuits on various local DP's, speaking with the EU (and neighbouring premises) as they will generally know exactly when the issues are occurring, and hopefully being on-site when the suspected REIN is present. 

[tbailey2]

Personally, I couldn't get my head around that graph...

Maybe it would be more understandable in MDWS format while looking at the DS and US SNRM data separately?

The attachment does this and the graphs are in one of the optional new formats for the UI in MDWS V2 when it's released. I'll leave it to others to analyse it ...

[NewtronStar]

3) reset the line


Alas, according to speedtest.btwholesale.com I'm left with max achievable 63 down and 20 up. And the actuals are 57 and 12. My pings (to BBC) have gone from 14ish to 20.

Any advice?

After your line was reset you will loose G.INP for a few days that's why your ping has decreased 

[tristan]

Maybe it would be more understandable in MDWS format while looking at the DS and US SNRM data separately?

Thanks - attached is a bodged attempt at something similar from gnuplot.

Annoying I can't get stats from the current setup with the ECI modem.

[tristan]

After your line was reset you will loose G.INP for a few days that's why your ping has decreased 

Ahh, that explains it. So would it be prudent to stick with the ECI for a week or so before swapping back to the H612?

I've had almost 24hrs uptime - but no idea what state the connection is in. The wholesale speed checker still indicates I'm pegged to an IP profile of 65 down 15 up, and getting an actual 45 down, 10 up. So still way, way worse that I was getting a few weeks ago before the issue occurred.

[NewtronStar]

So would it be prudent to stick with the ECI for a week or so before swapping back to the H612?

I wouldn't turn the line off to swap modems for a least 5 day, and it's a good time to see if the ECI G.INP fix actually works 

[tristan]

Darn it - I swapped them over earlier after speaking to the twitter guy...

We agreed to wait until it goes haywire again, whilst I call round the immediate neighbours asking if anyone else has a problem...

Switching back to the H612 makes it easier to track in the background.

Apart from my SNMR down being pegged to 6db (is this normal?) things look OK. I'm limited to 68meg down for the time being.

[NewtronStar]

Apart from my SNMR down being pegged to 6db (is this normal?) things look OK. I'm limited to 68meg down for the time being.

Ah well it would have been good to witness G.INP reactivated on a ECI modem, as long as you waited 30 minutes between turning off the ECI modem and then turning on the HG612 you will be ok.

As suspected you have lost G.INP and now on a heavy interleave DS depth of 1337 for some reason you have bypassed the so called fastpath profile, so at some stage after the line was reset your line must have seen to many errored seconds or HR/Rein fault has caused a few retrains and the DLM has taken action.

[GigabitEthernet]

I am surprised too that the engineer's testing didn't pick up the HR fault?