Kitz Forum

Broadband Related => FTTC and FTTP Issues => Topic started by: AArdvark on March 09, 2015, 07:34:15 PM

Title: Query re: OR Engineer visit & Zyxel modem
Post by: AArdvark on March 09, 2015, 07:34:15 PM
I have been advised by Plusnet that they have arranged a visit from an Engineer (OR).

What is the current accepted form re: substitution of the OR Modem.

I am running with a Zyxel VMG8324-B10A instead of the HG612 as supplied.

Should I put the original HG612 back and not mention the Zyxel or are OR Engineers more accepting of other kit.

Probably stupid question but I will risk asking anyway. ;D
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: loonylion on March 09, 2015, 07:35:49 PM
personally I would put it back so they can't argue about it.
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: AArdvark on March 09, 2015, 07:52:18 PM
loonylion:
You have confirmed my thoughts.
I was hoping that there was a more enlightened attitude now.

Collecting stats is not exactly working against OR/BT.
I will unlock my HG612 and put it back, unless convinced otherwise.

Tnx
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: Bald_Eagle1 on March 09, 2015, 08:22:41 PM
At least with a BT/Openreach branded HG612, the engineer shouldn't be able to intimate that a non-approved modem has been causing the issues all along.


A number of OR engineers saw the stats/graphs & the GUI from my unlocked HG612 a couple of years ago.

Some were very interested (particularly when watching in real time the quite significant effect of a DLM reset whilst still on site - via the modem's GUI & also in the graphs pre-DLM reset & post-DLM reset), some took no notice, saying their JDSU/EXFO hand held testers told them everything they needed to know & some said they didn't actually understand what the graphs were depicting (maybe the latter group were PSTN only engineers?).





Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: NewtronStar on March 09, 2015, 08:37:20 PM
One of the steps the Broadband engineer may do is to swap out the old HG612 and replace it with one from his van if you don't have the HG612 inplace during the OR inspection then they won't be able do to this.
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: AArdvark on March 09, 2015, 08:37:41 PM
Thanks BE1/NewtronStar,

I hoped things would have changed but my gut was telling me don't give any reason to blame the 'non-standard' kit.

The reported lack of interest is surprising to me.
I come from an IT background and when I worked with anything I wanted to know everything I could find out.
New methods and means of getting information was always valuable.

Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: NewtronStar on March 09, 2015, 08:47:54 PM
oh and for god sake unplug that lan2 cable from HG612  :blush: the BB engineer was not happy about that.
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: AArdvark on March 09, 2015, 08:51:11 PM
What Lan2 cable there is a sticky label stopping it from being used  ::)  ;D
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: NewtronStar on March 09, 2015, 09:04:51 PM
What Lan2 cable there is a sticky label stopping it from being used  ::)  ;D

 :D the first thing the OR Enginner noticed was the LAN2 led blinking on the HG612 and said that's not right that socket should not be used and bla bla bla something about the manufacturer had disabled that port

So not all OR BB engineers are easy going so beware !!!
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: AArdvark on March 10, 2015, 01:56:55 PM
Once it is all running again, how quickly can I replace the HG612 with the Zyxel vmg8324-b10a?
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: les-70 on March 10, 2015, 02:13:28 PM
  You could change it immediately but it would be interesting to see stats from the HG612 for 24 or 48 hours before making the switch so as to see if there are performance differences other than the extra few Mb/s Sync on the Zyxel.  The HG612 should be using the latest V100R001C01B030SP08 firmware.
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: jid on March 10, 2015, 04:28:25 PM
I personally get a more stable connection with the HG612. Both the Billion and Zyxel gave more unstable stats and higher error rates for me.

I think it's a trial and error thing - see which one is best for you!
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: Hitman on March 10, 2015, 09:59:34 PM
I had to contact the CEO at BT to get things moving with my line fault, I thought what the hell and told him I had an unlocked modem and inserted the stats into the email, TBH they've been really good about it and have passed the info on to their engineers.

I've pretty much had problems nearly every year, so I think they can't really say anything when you're pretty much forced to find out what's happening to your line and it helps towards finding the cause of the fault, that said I can understand why some engineers may not like the fact you've hacked their equipment  :P
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: AArdvark on March 11, 2015, 02:22:33 PM
  You could change it immediately but it would be interesting to see stats from the HG612 for 24 or 48 hours before making the switch so as to see if there are performance differences other than the extra few Mb/s Sync on the Zyxel.  The HG612 should be using the latest V100R001C01B030SP08 firmware.

Too late, I put the Zyxel back, before a DLM reset and I am now getting 70/20 on my line previously before errors 80/20.
I will see if DLM does anything in the next few days.

Engineer advised that he got 79xxx kbps at the 'Telephone manhole' at the bottom of my drive. so I should log another call if the speed does not return.

While he was at it he filled the cable cluster with sealant which had not been done 16 yrs ago [Sig from last opening in manhole]
This is before the house was built around the time the estate was created.
No work done since as I drive over the cover to get on/off my drive and I/neighbours would see if it had been touched/moved.
I had always seen changes in the telephone noise level & BB speed when having wet weather but could not prove it.
Last time an Telephone engineer investigated was 10-12 yrs ago and was told they could not improve it. ???
I know the manhole has a BT designation but cannot think of it  ??? [Has DAW DW & (94 in a Circle) on name plate]

See Photo (The red stuff is the sealant)
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: les-70 on March 11, 2015, 03:04:10 PM
  Fingers crossed for you.  You have however had an attainable of about 74-75 for most of this year and about 4 days before you went interleaved the attainable dropped further to about 71. The drops look like crosstalk.   As you say, at that time your sync was 80 but the SNRM was down to about 3.5 and well below 6.  Your attainable is thus now similar to values prior to the interleaving setting in and current sync is roughly what you would have had if you done a manual resync before the DLM reacted.  Your error increase may have just been the effect of the low 3.5 value of SNRM? (The attainable whilst interleaved was bigger but this always seems to be a rather misleading figure.)
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: burakkucat on March 11, 2015, 03:44:59 PM
According to our very busy B*Sheep --

Quote
3 lids = JF10 (Jointbox Footway 10), 2 lids = JF6 and 1 lid = JF4. There are other UG structures, but those three are by far and away the most common.  :)
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: Semmy on March 11, 2015, 06:31:11 PM
Yup, looks like a JUF4 to me though I've never seen a horizontal bearer channel before... Every day is a school day!
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: AArdvark on March 11, 2015, 08:27:11 PM
Burakkucat/B*Sheep/Semmy thanks Jointbox was what I was thinking of.
Read it somewhere when reading around all things GPO/BT on the 'interweb'.

I like old engineering stuff (All problems can be solved, just make it bigger and hit it with a bigger hammer ;D) and old Telecoms stuff back to the days of the good old GPO.
Can not say I understand most it  :( ;D
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: NewtronStar on March 11, 2015, 09:24:25 PM
You don't need a hammer these days all you need is a JDSU  ;)
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: les-70 on March 14, 2015, 11:17:15 AM
  Looking at MDWS the DLM has hit you again.  With gaps in your record the reason can't be exactly determined from MDWS but it looks like the ES count may be the cause.  Although many seem happy with the Xyxel a few of us have consistently found it to give quite a lot more errors than an HG612 with the latest firmware.  On my line the Xyxel performed well for most of the day but went nuts when ever I had some larger error events. It seems likely that success with the Xyxel depends on the lines error characteristics.

  Should you be able to get back to fast path you may want to consider giving the HG612 a go to see if does run with lower errors.   A safe way of testing devices without risking DLM action can be to cap the sync speed ( e.g. to 60 or 64Mbs/ in your case) so errors keep low and the difference in errors can be compared at a fixed sync speed.
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: AArdvark on March 14, 2015, 02:02:25 PM
Les-70, Thanks for keeping an eye on my stats.

It is useful to get another view on my line.
To clarify I still have a fault condition on my line which has been passed to BT's Telephone Engineers as a phone fault by Plusnet.
I know there is some fault there but cannot identify what yet.

I had run the 'BT Wholesale Broadband Performance Test' to see what the line was now classified as.
I ran all the test including the 3rd test where you connect to the bt_test@startup_domain & speedtest@speedtest_domain.
This still gave a faulty result as classified by BTW.
The gaps are because of Plusnet having a 'Internet access' problem last night at the same time I was running the tests.
I was unable to get a new connection when re-using my correct username/password. [DSL connects OK but PPP will not establish a session]
I did not know if the fault was at my end (Router) or their end (Internet access still not working).
It took me a while to re-try connecting a number of times [PPP connect retries then even power cycles], in-spite of DLM risks, before I tried using the HG612.
The HG612 would not connect ???
Resets of the HG612 / restore saved config / eventually it worked  :D :D :D
Tried Zyxel again still not working / checked settings and (username/password) character by character multiple times yet still failed.
Rolled the Zyxel back to original firmware version and restored original configuration backup.
Yay .... Works at last on the Zyxel.

End Result:
=======
Lots of gaps in stats
DLM kicking me hard again
BT Wholesale Broadband Performance Test states I have a fault [BB]
Phone appears to have a fault [Tele]

Overall a GOOD nights work by all & everything working at optimum ... NOT  :rain:
I will attach screenshots of results from BTW for completeness.

Stay tuned, on this channel,  for the next exciting episode in this 'Digital' Nordic Adventure ....... Real Soon !!!!
 
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: AArdvark on April 02, 2015, 10:24:56 PM
The next exciting episode in this 'Digital' Nordic Adventure ....... Starts Now
Are you sitting comfortably ?
So I will begin ....................

Please read until the end of the missive before comment.  ;D
This is a venting of speen more than anything and a scream to the skies re: OR and some of their Engineers, even if pressured.  ;D


I got a call from Plusnet yesterday (03/04/15) to query the status of my outstanding issue with my line.
I explained that my line was 'stuck' at 66999/20000 after the last OR fix.
I had been at 70000 when the engineer left, which was less than I had been before the fault, and the Engineer had stated if 'DLM does not fix it re-log a call'.
The sync had fallen to 66999 and stayed there for 3 weeks+.
I was able to point to a 64M profile on the line yet I got a 72M Speedtest on the BTW Speedtest.
This did not make sense to me or the Plusnet staff member.

It was agreed, after investigation, that the line appeared to be stuck on a 67M profile and and an OR Engineer would be sent out to reset DLM.
(The suspicion was that DLM reset, that had been promised by the Engineer at the end of the 1st job, had not done.)

Appointment arranged for today (02/04/15) between 08:00 and 13:00.
Engineer rang to query the 'Fault reported' at approx 12:30, and advise he was running late.
I explained that Plusnet had booked the engineer to reset DLM on the line as I had a stuck Profile.

1st response was to talk about attenuation on the line & possible crosstalk which may be responsible for the drop in sync.
(Even though the line tests performed by Plusnet all stated No REIN/RFI/Bridge Taps/Crosstalk detected).
Eventually agreed he would call and check the line.

Engineer arrives at 13:30 approx and immediately checks the physical line at the point of entry to the house. (Tester connected to line and sync checked)
Again straight into the spiel regarding attenuation & Crosstalk and it may be all you can get on the line now.
The intent from opening the door appeared to be 'get me to agree that the issue is simply the usual loss of sync speed due to new users being added to the cab etc.'

I had prepared all the stats and graphs from DSLStats + HGStats (Thank god for BE1, Ronski, & Roseway  ;D) + Plusnets Test results as entered into the call log on the Plusnet website.
I explain the situation again and demonstrate that the evidence to support the contention is not there, as far as I can see.
Round the houses once again re:Attenuation/Crosstalk ..... Yada Yada.
Agrees to check the cab. More testing at the cab and the line bounces up/down etc.
Apparently the port I was connected to was faulty and would not work at more than 71M when set to 80M.

Now getting 61489/19999, No G.INP and lots of Interleaving & delay.
Sync is less than I had before the Engineer arrived !!!
Another round of the usual spiel ..... Yada Yada
I explain with printed docs that the line is now worse than before he touched it.
Engineer trying to close down the call and pass it back to the ISP (Plusnet).
I explain that the ISP cannot impact the line speed in anyway as DLM is deciding what I get.
More discussion and its reaching the 'Its all I can do' point & exit stage left OR Engineer.
I cannot understand how I can have a 'worse line and that is it' and say this to Engineer (politely).
He goes to cab one more time.
Wait 10-15 minutes or so and get call on mobile.

Punch line: (Wait for it ....... wait for it !)

I am now told by the Engineer on the mobile that he has found the problem. Yay

The DSLAM has a fault affecting all users.
After escalating the fault to OR (Internal Support people ???), he had been advised to swap my line to another users 'working port' to test the line.
He swapped me to another port that was being used and found that when tested it was fine BUT randomly the speed would crash to 51M.
This was the fault I had originally on my line. A sudden drop to 52M and dropping (So I was told).

The whole DSLAM needs to be looked at and fixed or replaced.
This impacts approx 45 users on the cab according to Engineer.
So the cab is not exactly full to generate the huge crosstalk impact anyway.

My pain and grief over this is as follows:

1.) The fault was only found due to 'luck' & 'my persistance to NOT accept the Attenuation/Crosstalk spiel'

2.) The Engineer was obviously under extreme time pressure to close all jobs. The average user would have accepted the spiel and be worse off.

3.) The fault had also been missed by another Engineer on the original call. He also was under time pressure and walked off the call too quick.

4.) Only because of the fact I collected Stats, from the earliest date and anticipated the need to 'fight' my corner did this call NOT get closed.

5.) The Engineer found the fault inspite of the pressures put on him by OR, but I have no timescale for the fix nor did the Engineer.

6.) The need for the ability to collect Stats without having to 'Hack' your modem is self-evident, and should be supported by OR.

7.) I am now in no-mans land. As OR do not report anything to me and the resolution of this is invisible outside of OR.

I appreciate the Engineers problems but pushing the users to accept issues by using Crosstalk/Attenuation as an excuse it not good.
In this case the real problem impacts more than just me so it is not trivial.
OR are their own worse enemy at times by working against their own Engineers  ???

Comments & Ideas are welcome.
(My Brain & Fingers hurt !!!)

FYI:
I have logged all this (slightly less wordy) with Plusnet and asked for feedback from OR via Plusnet.
 
All Typos etc are a 'No-Cost Extra' just for you.  ;D


Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: boost on April 03, 2015, 05:50:24 AM
Well done :)
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: Ronski on April 03, 2015, 08:47:51 AM
Well done,  my brother recently had problems with his phone and adsl broadband dropping out, using the phone was enough to affect it. Twice his master socket was changed and they pronounced it fixed,  even though his speed was still appalling,  he was told it would improve with time, I told him he'd just been fobbed off. Sure enough it just stopped working again.

Eventually two engineers arrived and spent the morning looking for the fault, they wanted to swap him to another line,  but the state of the network is so bad there aren't any spares and it's been like this for years. Eventually by luck they found a corroded joint in the junction box in the path opposite his house. His line is now stable, but only running at about 8mpbs instead of the 11 he had before.

This took around 3 months to get fixed, mainly because he needs to work, so didn't keep pushing. When he first moved in it took me months of constant battling and an email to the ceo's office to get his broadband up and running,  this is why I know how bad the lines are in his part of the town.

We had problems at work over Christmas,  the gas board sent a mole through some cables (1000 & 500 pair cables), that took bt over a month to reconnect around 64 customers. Again the engineer told me there wasn't enough good pairs to by pass the damaged ones.

The picture I see from what BT engineers have told me many times is they are not replacing old corroded cables, they just keep patching them, and this leads to constant problems.
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: kitz on April 05, 2015, 12:42:54 PM
>>> would not work at more than 71M when set to 80M.

Just to clarify & satisfy my curiousity.  When you say would not work, is this would not sync?
I'm recalling the problems you had the other week when you had difficulty getting both the Zyxel and HG612 to get a connection.
.. and further clarification was this sync or ppp.

>>> I explain that the ISP cannot impact the line speed in anyway as DLM is deciding what I get.

Good for you for being persistant when you knew you were right.  Most people wouldnt know this and at this point the visit would be terminated completely.

>>> The whole DSLAM needs to be looked at and fixed or replaced

Eke! I wonder if it is the whole dslam or faulty line card(s) as it isnt clear if the other port he tested on was on the same line card.

----

I agree with all of your points. Unfortunately you are piggy in the middle,  so it will be up to you to ensure Plusnet keep pushing this too. Please do keep us updated.
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: AArdvark on April 05, 2015, 02:23:47 PM
Quote
>>> would not work at more than 71M when set to 80M.
I mean would not sync at more than 71M. Must not use vernacular !!!  ;D

Quote
Good for you for being persistant when you knew you were right.  Most people wouldnt know this and at this point the visit would be terminated completely.

This is what really annoyed me. I am fighting with the Engineer who should know more than me and who usually would say as much and win the arguement by default.

Quote
>>> The whole DSLAM needs to be looked at and fixed or replaced
I would have expected the port on another line card would be checked as he had moved the port I was on to start with (1st visit to cab).
He did say there were 45 other users on the cab and all would be affected. (Not clear in how I have written the comment)
(Read: 45 users in total on the cab. Hence the comment about Crosstalk not being huge as its not a lot of users )
That does seem to indicate more than 1 line card.
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: kitz on April 05, 2015, 11:28:22 PM
Thank you for the clarification re sync :)

Quote
He did say there were 45 other users on the cab and all would be affected. (Not clear in how I have written the comment)
(Read: 45 users in total on the cab. Hence the comment about Crosstalk not being huge as its not a lot of users )

Thanks again for further clarification.  I couldnt recall which type of Huawei cab you were on, as the MA5603 can hold up to 48 users per line card....  and I also had in the back of my mind the VCMM line card swap out issue (http://forum.kitz.co.uk/index.php/topic,15205.msg283625.html#msg283625) as reported by BS.  Its far more common to hear of line card faults rather than total dslam faults.



I could almost see a case here whereby if you were on one of the cabs whose line cards that needed swapping out because the ELE-M1 was calculating the line length wrongly, it could be applying an incorrect PBO/PSD mask which in turn would reduce bitloading and will affect the maximum speed at which the line could get sync at.

Only flaw in this theory is that BT reported it was reducing the upstream sync speed & loss of sync...  but since ELE-M1 also controls Downstream PBO, it was a hmmmm moment. :hmm: 
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: boost on April 06, 2015, 12:21:53 AM

Only flaw in this theory is that BT reported it was reducing the upstream sync speed & loss of sync...  but since ELE-M1 also controls Downstream PBO, it was a hmmmm moment. :hmm:

Sounds more than plausible? The only other thing that's been mentioned is cab rot but you would imagine the synch speeds to be more erratic than nailed at a specific figure? :)
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: AArdvark on April 06, 2015, 12:49:07 AM
Cab rot would be unlikely, unless very unlucky, as the cab has been upgraded for Fibre only 8-9month old.
This of course would be par for the course with my luck  ;D

Maybe if they have to start playing with the cab it would be an ideal time to do the 'VCMM line card swap out'. Yay  ;D :lol:

I did not know that line cards could support 48 on one card.
This may mean 'just' a line card swap  ;D
All we need now is for OR to source a new card quickly.
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: boost on April 06, 2015, 12:54:47 AM
I wonder what the lead time is on a new card?
Hopefully it will go out as an emergency PEW and not involve several levels of hierarchy to reach a decision! :)
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: AArdvark on April 06, 2015, 01:01:29 AM
Quote
involve several levels of hierarchy to reach a decision! :)
Its BT, its OR .............................................. what does experience tell you ?

 ::)  ;D
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: AArdvark on April 06, 2015, 08:45:33 PM
Plusnet Question Number: #100230761

Joy of Joys, BT have 'fixed' the problem ..........NOT >:(  >:( >:( >:( :rant: :shoot:
But they have closed the call and thrown it back to Plusnet.

[FYI: Plusnet liase with BTW who then engage OR. So there is no direct link to OR for Plusnet (As told by Plusnet Helpdesk)]

My line re-synced this morning at 4:58am.

I have been 'Lift & shifted' at least twice yet I am worse off.

Until the onset of line faults the line was 79987/19999 this was solid for months on end. I have been with Plusnet from Aug 2014.

This is worse than I had before the 2nd OR Engineer call out. (Max attainable was 77xxx just the profile was locked at 67M !!!)
My Max Attainable is now lower than ever and it is unlikely to increase once DLM gets to work 'Tuning the line'. (Decrease more likely)
This is worse than I had after the 1st OR Engineer callout on 10/03/2015 when it was 'Fixed' but not fixed if you understand.


Line performance at 6:00 on the day the 2nd Engineer came was as follows:

(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi1072.photobucket.com%2Falbums%2Fw364%2FGrapheneMan%2F020415-0600_zpsl4iqbgnh.jpg&hash=4941a1810f0feda47a055c9ba4632a1d9c25563a)


After 1st fix by 2nd Engineer:
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi1072.photobucket.com%2Falbums%2Fw364%2FGrapheneMan%2F020415-1338_zps2jmolpoi.jpg&hash=68a5c3198b7bd0d728f50108c6a1b37415fb0d5e)

I now have the following:

Max Attainable:   69300
Sync:                  69288
Interleaving         1/1
INP                     0
Delay                  0
G.INP                  Off


From here it is all downhill................

Plusnet insist there is no problem as I am "in the range expected'  ::) (What a surprise that one is !!!)
Very long conversation, lots of banging of my head against a brick wall.
No means to query what has been done by OR in relation to original line performance.
Quote: "There is no fault to log so cannot raise this with OR."

I am now posting the full Call Log for your information & comment.

[Sorry 'BIG' Consists of PDF's+Screencaps etc. All docs as uploaded to Plusnet.]
https://www.dropbox.com/sh/qb28aae0dqi8cxh/AABnMVvW-q_z-gAr410-keKpa?dl=0 (https://www.dropbox.com/sh/qb28aae0dqi8cxh/AABnMVvW-q_z-gAr410-keKpa?dl=0)

Frustration levels are off the scale & I need ideas to progress this. (Please  :))

Please let me know if there are problems with the docs etc.
TIA
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: Dray on April 06, 2015, 08:57:06 PM
Migrate to AAISP  :cool:
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: Black Sheep on April 06, 2015, 09:41:54 PM
Quick reply, and have only sped-read the thread so apologies if I haven't understood the issue fully ?

A few years ago we had massive issues with the VTUC cards on the ECI cabs, (don't know which you vendor are on ??). They were swopped out to version 3 but some incompatibility with the firmware (if memory recalls ?) caused very similar problems with what you have covered. There were umpteen Cabs/DSLAMS affected, and only by retro-fitting the version 2 cards did this cure the mammoth amount of faults being raised on a daily basis.

I have no idea what your metallic path facility tests like, just thought I'd throw in a scenario that took quite a while to bottom out.

Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: AArdvark on April 06, 2015, 10:02:41 PM
Migrate to AAISP  :cool:

I would if I could.
I only have TalkTalk, Sky, BT, Plusnet to choose from.

(Ex Sky after Be was bought  :( :'( and TalkTalk were told to go away in short sharp jerkys for saturation tele-marketing to my address)
TT, Sky are out. So no choice.  :(
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: AArdvark on April 06, 2015, 10:08:07 PM
just thought I'd throw in a scenario that took quite a while to bottom out.

Thanks but the response from OR & Plusnet is that the problem is solved and call is done.
I do not agree but I count for nothing apparently, I only pay for the random service OR gives BTW who supply Plusnet.
[Sorry, not personal but I am 'Not Happy' surprisingly. Who would have thought. ??!!]  ;D ;D
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: AArdvark on April 06, 2015, 10:11:00 PM
Black Sheep,

Forgot I am on Huawei DSLAM and using HG612 when Engineer calls.  ;)
Zyxel 8324 at other times as it gives at least 5M higher Sync.
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: kitz on April 06, 2015, 10:20:08 PM
Posting my stats, just for the record and for comparison.  Purely because Aardvark previously always had very similar stats to mine.

Code: [Select]
adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason:    0
Last initialization procedure status:   0
Max:    Upstream rate = 30295 Kbps, Downstream rate = 82806 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 79987 Kbps

Link Power State:       L0
Mode:                   VDSL2 Annex B
VDSL2 Profile:          Profile 17a
TPS-TC:                 PTM Mode
Trellis:                U:ON /D:ON
Line Status:            No Defect
Training Status:        Showtime
                Down            Up
SNR (dB):        6.7             12.6
Attn(dB):        0.0             0.0
Pwr(dBm):        14.3            6.1
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: kitz on April 06, 2015, 10:22:21 PM
Ardvark.  I note you say you have had 2 previous lift and shifts but I presume that they are on the same card.   Has there been anything about the fact that the OR engineer found an issue that seemed to be affecting a lot of lines on the same linecard.

I'm highly suspicious that the OR engineer who visited you (the afternoon before a bank holiday) said that there was an issue at the DSLAM... and here we are bank holiday not yet over and its been closed.   I do not see anyway where they over the bank holiday weekend would have swapped out linecards.   More likely your 'fault' got closed as he walked away and its taken a couple of days for this info to filter back to Plusnet and then back to you.

Quote
Thanks but the response from OR & Plusnet is that the problem is solved and call is done.

Let me see if I can poke someone for you.


-----
PS can you add your ticket# to this thread.

Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: AArdvark on April 06, 2015, 10:50:36 PM
The 2nd Engineer did a L&S and the call detail on the call (Read PDF) states another L&S was done which is called the solution to the problem.

I know it is confusing, I could not condense the information from the call, I tried.

In the end I had to post the lot to ensure no 'truths' were lost or inadvertent 'lies' make by me.
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: AArdvark on April 07, 2015, 01:32:38 AM
I'm highly suspicious that the OR engineer who visited you (the afternoon before a bank holiday) said that there was an issue at the DSLAM... and here we are bank holiday not yet over and its been closed.   I do not see anyway where they over the bank holiday weekend would have swapped out linecards.   More likely your 'fault' got closed as he walked away and its taken a couple of days for this info to filter back to Plusnet and then back to you.
That is one of my points.
Reading the reply from Plusnet they have been told.
Quote
Engineer Notes
2015-04-02 15:40:36 : 02/04/2015 15:40:32- Notes - DCOE DONE LIFT AND SHIFT BUT PORT STILL DROPPING AND SLOWING DOWN TOLD TO SEND BACK INCOMPLETE FOR DIAGNOSTIC TEST E/U MOBILE 0744949

DCOE: The woosh test is a pass no fault found, an engineer has today done a lift and shift and the line is now in full sync at speeds of 61.5 down and 20 up which are slightly exceeding the predicted 54.5 down and 15.7 up. The line may needsome time to settle but i am passing it back to the cp as OK RWT by DT.

Summary
line not banded, no errors, REIN and Crosstalk not detected. sync above estimate, updated WP profile.
The bold is my emphasis.
This is a line which before being touched was at 66999/20000 G.INP On & was being investigated for a fault.
Suddenly the line is predicted to be 54.5/15.7 so 61.5/20 is a win. (How convenient just the sync I got after the 1st fix by the 2nd Engineer!!!)
End of Game, pack up & go home  ???

As you rightly say nothing has happened over the Easter period, the DSLAM fault is 'no-more' and I am worse off.
This is the reason I am doing 'Hulk' impressions. (I am running out of Shirts  :( ;D )

Someone has simply cleared all the faults associated with the call on the back of a woosh test.
The engineer had said the line tested good but had random drops so the Woosh test proves nothing.
I am also assuming the Woosh test is remotely done so not even testing at the DSLAM itself which is where the problem was reported.
I assert Remote Diagnostics are NOT 100% fool proof.
Anyone who wants to prove me wrong is welcome to do so.
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: burakkucat on April 07, 2015, 01:47:25 AM
Migrate to AAISP  :cool:

I would if I could.
I only have TalkTalk, Sky, BT, Plusnet to choose from.

Why does that preclude you from using the services of A&A?  ???
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: AArdvark on April 07, 2015, 02:19:40 AM
When I have looked up Isp's I can use on my exchange AAISP does not come up in any list.
Can I use anyone ?
How does that work ?

Send from LG G3 via Tapatalk (Typos & bad formatting are free)

Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: Dray on April 07, 2015, 03:05:36 AM
You seem to be looking at ISPs with an LLU presence i.e. their own backhaul.

Most other ISPs use BT Wholesale backhaul and perhaps TT backhaul, AAISP included.
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: kitz on April 07, 2015, 11:20:41 AM
Quote
Engineer Notes
2015-04-02 15:40:36 : 02/04/2015 15:40:32- Notes - DCOE DONE LIFT AND SHIFT BUT PORT STILL DROPPING AND SLOWING DOWN TOLD TO SEND BACK INCOMPLETE FOR DIAGNOSTIC TEST E/U MOBILE 0744949

DCOE: The woosh test is a pass no fault found, an engineer has today done a lift and shift and the line is now in full sync at speeds of 61.5 down and 20 up which are slightly exceeding the predicted 54.5 down and 15.7 up. The line may needsome time to settle but i am passing it back to the cp as OK RWT by DT.

Summary
line not banded, no errors, REIN and Crosstalk not detected. sync above estimate, updated WP profile.

Good.  You have on there that the engineer recognised there was still a problem

Bad.   Dont know what DCOE is, but a woosh test is a remote test that basically checks your line stats and things like how long the line has been in sync etc.   This is an old version of what they used to look like - Woosh (http://www.kitz.co.uk/adsl/images/WOOSH.gif).  It checks your line and not the line card.

Bad.  The line checker adjusting to 54.5/15.7.   Prior to the fault I can confirm that you indeed did have a 80/20Mbps connection.  That is so unfair that in the case of a linefault then the BT estimates go down in line with the rate of loss and they say hey its syncing within our estimates.   I'd be furious too.
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: boost on April 07, 2015, 11:43:03 AM
I wonder how the speed checker can change like this? What are the pre-reqs or the composite measurements that make up the reported speed?

Openreach will have a record of the speed you were provisioned at and depending on the dates you were at those speeds, PN might even be able to access it via the OR website too.

Whether any of this will help...
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: AArdvark on April 07, 2015, 11:52:49 AM
Kitz,

Every point I KNOW !!!!! Arrrrrrrrrrgh  >:( >:( >:(

It apparently makes no difference.

OR via DLM slide your Estimated 'Range' down on a fault and then have a lower target to meet.
This has been done twice.
i.e.  on each Engineer visit.

:rant: :shoot: :wall: :rant: :shoot: :wall: :rant: :shoot: :wall: ...... (Ad nauseam)
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: kitz on April 07, 2015, 12:11:43 PM
The only reason I recall your stats is because at one time they were so similar to my own, but admittedly that was last year and things can change.  So Ive just gone back through on MDWS to give you my analysis.

On the 17th of Nov, it looks like you may have picked up a heavy crosstalker, theres nothing much that can be done about that, but the line still remained in sync at 80/20.

Jan 08 it looks like the line started a slow degrade of SNR (possibly mild crosstalkers), the SNRm went down to 5dB, then 4dB yet the line still stayed in sync and the Err Secs were low enough so that the DLM didnt care. That suggests that the line was a very stable 80/20 but hanging on in there, but the next time you did a resync then you will have lost some of the 80Mbps.
I'm afraid to be the bearer of bad news in that crosstalk has cost you some speed and you may not quite get 80Mbps again, but that does NOT justify the 57Mbps sync in March and 60Mbps.   At a guess you should still be reaching somewhere in the mid 70's but I haven't calculated it exactly, certainly no lower than 70Mbps.**


Something drastic happened on Feb 14th.  Not only did you lose your downstream speed, but your Upstream SNRm took one hell of a hammering.  Your Upstream SNRM dropped from 12dB to 6dB.   You lost 6dB of upstream SNR overnight and that certainly isnt right.  You probably wouldn't have noticed this because there was still sufficient SNRm to give you the 20Mbps.

There is also something strange occurring with your upstream SNRm.  If you look at it over the period of the last 6 weeks it has some 'castle top' like activity _|¯|__|¯|_  down to 6dB, up to 15dB, down to 6dB up to 11dB, down to 7db and now back up at 15dB.   That certainly is not expected behaviour and something odd going on for your upstream.

There are certain things I cant tell from MDWS and so can you please post me a full set of your current stats. (adsl info --stats)


----
**  ETA

I just thought, I hadnt included any compensation for g.inp in that calculation so in theory you should gain some of the loss back again, and if g.inp works as it should then you 'should' be in the high 70's
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: AArdvark on April 07, 2015, 12:13:29 PM
You seem to be looking at ISPs with an LLU presence i.e. their own backhaul.

Most other ISPs use BT Wholesale backhaul and perhaps TT backhaul, AAISP included.

I checked via www.samknows.com and Uswitch.

There is no AAISP !!!

I have even tried other ISP 'Check your Phone Number' options and no-one has been able to supply that was outside that list.
It seemed to prove that the list was it.
If AAISP run on the back of BTW then it will be available.

Had a quick look. Looks good from the website but 'dearer' and monthly limits on traffic volumes.
I will keep it as a fallback BUT should not have to 'pay' for someone to get the line performance I had.
I am the sort of person who will fight over 'principles' rather than walk away.
I will spend £10 to fight a principle over 5p. Its 'Hardwired' in. ;D
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: Black Sheep on April 07, 2015, 12:17:31 PM
I can't give much input other than stating what may be the remit ?. 
DCoE = Diagnostic Centre of Excellence. Basically, they have in-depth analysis tools to view the circuits performance. If 'The computer' says it's ok and within acceptable parameters, then I assume they are told to close the job down ?? I don't know for certain, as I've no dealings with that side of the fence and their goings-on .

Kitz is correct in that all tests are done through the WHOOSH systems. 
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: kitz on April 07, 2015, 12:20:17 PM
AAISP are a BTw based provider.  Only LLU's are listed separately.   As an FTTC customer LLU makes no odds anyhow as all fttc lines are provided using BTOpenreach.

On my own checker I try clarify it by saying

Quote
The vast majority of UK ISPs use BTs exchange equipment to supply their broadband, for those ISPs you should use the information on the left.
The following is a list of providers offering an alternative service to BT Wholesale based broadband in your area.
/snip/
Available ISPs are too numerous to list, but some examples would be: Zen, Plusnet, IDNet, Enta, etc
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: AArdvark on April 07, 2015, 12:22:34 PM
There are certain things I cant tell from MDWS and so can you please post me a full set of your current stats. (adsl info --stats)

Here they are.

I have a full set of stats (gaps & crashes excluded  ;D ) until just before the 2nd Engineer visit (All via DSLStats)
I have now switched to HG612 Stats due to problems switching between HG612 & Zyxel which I need to get running quickly before the 2nd Engineer arrived.
HG612 Stats was up & running quickly so I switched.
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: AArdvark on April 07, 2015, 12:32:29 PM
At a guess you should still be reaching somewhere in the mid 70's but I haven't calculated it exactly, certainly no lower than 70Mbps.

I did. I should be getting approx 75M DS and 20 US based on the area the Max Attainable reaches. (+/- a meg or 2)   ;D


Something drastic happened on Feb 14th.  Not only did you lose your downstream speed, but your Upstream SNRm took one hell of a hammering.  Your Upstream SNRM dropped from 12dB to 6dB.   You lost 6dB of upstream SNR overnight and that certainly isnt right.  You probably wouldn't have noticed this because there was still sufficient SNRm to give you the 20Mbps.

This was the start of the degradation of the line. I assumed this was normal but monitored it. When it was getting close to 3db I resynced rather than let DLM do someting interesting.

There is also something strange occurring with your upstream SNRm.  If you look at it over the period of the last 6 weeks it has some 'castle top' like activity _|¯|__|¯|_  down to 6dB, up to 15dB, down to 6dB up to 11dB, down to 7db and now back up at 15dB.   That certainly is not expected behaviour and something odd going on for your upstream.

That was all DLM's doing 'playing' with the line.

There are certain things I cant tell from MDWS and so can you please post me a full set of your current stats. (adsl info --stats)
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: AArdvark on April 07, 2015, 12:37:19 PM
Kitz,

The 'I did' applies to the 'You probably wouldn't have noticed this because there was still sufficient SNRm to give you the 20Mbps.' comment,

Sorry finger/brain interface has its own 'DLM' problems.  ;D
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: AArdvark on April 07, 2015, 12:43:10 PM
DCoE = Diagnostic Centre of Excellence. Basically, they have in-depth analysis tools to view the circuits performance.
If 'The computer' says it's ok and within acceptable parameters, then I assume they are told to close the job down ??

Thanks Black Sheep,

Exactly what I assumed and hence my comments re: Remote Diagnostics ......
I know how this works I used be be a Techie working with Networks but NOT at the Telecoms end of the scale.
Also worked on & ran a Helpdesk so i know what instructions are given to cleardown calls.
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: kitz on April 07, 2015, 12:48:53 PM
Thanks for those stats,  I cant see anything obvious other than your atten is now lower than mine.   Your error rate on the whole looks pretty good, even when operating at a low SNR in Jan, so its obvious that prior to 14th of Feb that was one very stable line in good condition.  I don't yet fully understand all the g.inp part of stats so cant comment on those Im afraid.

Quote
That was all DLM's doing 'playing' with the line.

But why was it messing with your upstream.  Upstream and downstream DLM are independent of each other.   According to MDWS your MTBE rate was below any figure that should cause you to come under the scrutiny of the DLM for your upstream.

Quote
wonder how the speed checker can change like this? What are the pre-reqs or the composite measurements that make up the reported speed?

Openreach will have a record of the speed you were provisioned at and depending on the dates you were at those speeds, PN might even be able to access it via the OR website too.

I would hang on to this copy of your sync speeds from MDWS.   It shows your sync speeds over the past 4 months and proves that until Feb 14th you had a stable 80/20 connection. 
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: boost on April 07, 2015, 12:49:01 PM
You seem to be looking at ISPs with an LLU presence i.e. their own backhaul.

Most other ISPs use BT Wholesale backhaul and perhaps TT backhaul, AAISP included.

I checked via www.samknows.com and Uswitch.

There is no AAISP !!!

I have even tried other ISP 'Check your Phone Number' options and no-one has been able to supply that was outside that list.
It seemed to prove that the list was it.
If AAISP run on the back of BTW then it will be available.

Had a quick look. Looks good from the website but 'dearer' and monthly limits on traffic volumes.
I will keep it as a fallback BUT should not have to 'pay' for someone to get the line performance I had.
I am the sort of person who will fight over 'principles' rather than walk away.
I will spend £10 to fight a principle over 5p. Its 'Hardwired' in. ;D


OIL FOIT YA FOR UT!


https://www.youtube.com/watch?v=g7QBS0O7gT0 (prolly not considered work safe if you have loud speakers)




:D
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: AArdvark on April 07, 2015, 01:06:17 PM
Love it  :D :D :D :D

Remember the film and the 'Interesting acting' that I am sure offended many 'Travellers'  ;) ::)
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: Dray on April 07, 2015, 01:18:12 PM
My point was that AAISP have a history of kicking BT hard enough to get a line fixed.
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: AArdvark on April 07, 2015, 01:44:32 PM
Dray,
Thanks for the Heads-up,
I did see that they are happy to take on problem lines.

My issue is the line is NOT a problem line just BT/OR have screwed it up. Short & Sweet.
They should fix it and NOT I pay a premium to get an 'Attack Dog' to do it for me.


Back to this 'Principles' thing again  ;) ;D

 
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: WWWombat on April 07, 2015, 05:45:19 PM
At a guess you should still be reaching somewhere in the mid 70's but I haven't calculated it exactly, certainly no lower than 70Mbps.

I did. I should be getting approx 75M DS and 20 US based on the area the Max Attainable reaches. (+/- a meg or 2)   ;D


Beware interpreting the downstream "max attainable" when FEC and interleaving have been turned on: most modems appear to over-estimate the attainable speed at this time.

At the end of February, you were getting speeds of around 63Mbps, with attainables of around 77Mbps, with FEC and interleaving on. Under such circumstances, my rule of thumb would predict a real speed of 70Mbps (half way between the two) if FEC/interleaving were turned off again.

Right now, with FEC and interleaving turned off, it is achieving and estimating 69Mbps, and it is hard to disagree.

Something drastic happened on Feb 14th.  Not only did you lose your downstream speed, but your Upstream SNRm took one hell of a hammering.  Your Upstream SNRM dropped from 12dB to 6dB.   You lost 6dB of upstream SNR overnight and that certainly isnt right.  You probably wouldn't have noticed this because there was still sufficient SNRm to give you the 20Mbps.
This was the start of the degradation of the line. I assumed this was normal but monitored it. When it was getting close to 3db I resynced rather than let DLM do someting interesting.
There is also something strange occurring with your upstream SNRm.  If you look at it over the period of the last 6 weeks it has some 'castle top' like activity _|¯|__|¯|_  down to 6dB, up to 15dB, down to 6dB up to 11dB, down to 7db and now back up at 15dB.   That certainly is not expected behaviour and something odd going on for your upstream.
That was all DLM's doing 'playing' with the line.

Looking at the various MDWS graphs, it looks like the castellated variation in upstream SNRM coincide with the turning on/off of upstream DLM intervention. MDWS doesn't capture the amount of bandwidth consumed by the FEC overheads, but it does tell us INP values and the interleaving depth. We can make a good guess that, while the sync speed remained (almost entirely) at 20Mbps, the modems actually ended up using an extra 20% bandwidth to carry the FEC overhead when DLM intervened upstream (old-style, non-G.INP). The extra bit-loading necessary to carry these extra bits will have resulted in lower SNRM values.

I suspect that there was nothing else funny going on with the line - so the measurements are a consequence of DLM only.

Of course, quite why DLM intervened is not obvious.

Of interest is the drop from G.INP-style intervention to old-style intervention in the afternoon of April 2nd. That seems a strange step! I assume the subsequent removal of intervention at all was because of a DLM reset.

Equally of interest is the ES graph, especially by turning the totals on. Up to Feb 14, all behaves consistently - as said before, there is nothing to trigger DLM there. However, when DLM gets removed on March 10th, things look considerably worse. Horrible - and I'd guess that there are some  settings where this could indeed trip DLM back on. Yet the counts since the latest DLM reset took place are tiny. Almost no errors at all. In fact it looks great. G.INP will probably activate anyway, though!

The following is analysis that I would have done on the line stats, without any knowledge of a potential DSLAM fault.

When I look at the output from "--pbParams", I see attenuation figures that are very similar to my last line - which was around 350-400m of decent copper. In the 2.5 years we had FTTC on that line, the attainable speed dropped from close to 90Mbps, down to around 78Mbps (and a couple of temporary bursts of DLM intervention that took me to 72mbps).

What your line is currently showing - about 70Mbps, with no DLM intervention, and with low error rates - is not significantly different to that line of mine, and certainly the speed difference is within scope for what crosstalk can do a line.

It might just, just, be that BT have indeed fixed your line. Just that it isn't possible to make it as good as it once was.
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: kitz on April 07, 2015, 07:01:16 PM
Thanks vm wwwombat for your input

Quote
Beware interpreting the downstream "max attainable" when FEC and interleaving have been turned on: most modems appear to over-estimate the attainable speed at this time

I deliberately ignored any max attainables purely because of this fact ^.  This is how I arrived at my estimate.

My line is also circa 300m and atm Im finding that 1dB is circa 5Mb of speed without DLM intervention.
Yes I know all lines are different: If aardvarks line is slightly longer than mine then because of bit loading then the 1dB would be less than 5Mb and I was erring on the side of caution by using that as a rough guide. 

So based with a loss of 2dB over the past few months thats how I took it down to 70Mbps..  and then thinking perhaps g.inp activation should have given back a bit more... hence my no lower than 70Mbps estimate. 

Quote
Of course, quite why DLM intervened is not obvious.

Its also puzzling me that I couldnt see any reason why the DLM would have intervened.  The MTBE looked fine.
Whats happening with the upstream? - the loss of SNRm: 15dB -> 6dB is one heck of a lot for the DLM to be playing with especially when there is hardly any upstream {none} E/secs.     


-----
Thoughts

On zooming in closer on the graphs it looks like another disturber got added to Aardvarks cab on the 9th of Feb that I didnt notice first time as I was more concentrating on wth happened on 14th of Feb.   This took his SNRm down to 3.5dB so need another 0.5db allowance lopping off.  Using the conservative (and slightly harsh) figure of 5Mb per 1dB, thats taking it to 67.5Mbps. 

W3 are E/S intepreted differently on g.inp lines and do they dont show on MDWS? Could the DLM now be using a ReTX counter for e/s.  Sorry for the questions, with me not being g.inp'd yet Im a bit behind when it comes to how it shows on a line. I need to see some figures first hand on my own line to judge properly whats happening with g.inp & DLM
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: AArdvark on April 07, 2015, 10:22:32 PM
*** I have responded to the initial comments but have run out of steam and the will to live to continue any further  :( :wry: ***
*** I have pulled out the Stats from the numerous files and graphs to condense the problem down ***
*** Hope it makes sense ***
Quote
Beware interpreting the downstream "max attainable" when FEC and interleaving have been turned on: most modems appear to over-estimate the attainable speed at this time.
[My comments re: Max Attainable are based on real measurments from the Modem.
The period Sep24 --> Feb14 had no Interleaving.My line was good. The earlier Interleaving was a DLM Event through too much playing with the modem. Feb14 onwards was issues with my line. Please read onward.]
Quote
At the end of February, you were getting speeds of around 63Mbps, with attainables of around 77Mbps, with FEC and interleaving on. Under such circumstances, my rule of thumb would predict a real speed of 70Mbps (half way between the two) if FEC/interleaving were turned off again.
[Beware using a 'window' that is not able to encompass the scope of the issue. Very easy to do.
I am on the 'inside' and it is very difficult for me !!!

This is one of the difficulties at the momemt.
Getting Plusnet/BTW/OR to understand the correct issue & associated 'window' to view the issue correctly.

Mid Feb was when the first indication of problems with the line became obvious.
All stats are via Zyxel VMG8324-B10A Modem running Firmware that supports G.INP. Consistently gives 5M higher DS Sync.
Exceptions are on Engineer visits (in Green) (Sync drops by 5M approx using HG612 as supplied).

Feb 14 03:54 Max Attainable went from 72116/28971 --> 77670/26838 [UP]
Feb 14 03:56 Actual Sync went from 79987/19999 --> 62637/19999 [DOWN] Stayed at this sync until .....
Feb 19 04:00 Actual Sync went from 62637/19999 --> 63159/19999 [UP] until ......
Mar 01 05:00 Actual Sync went from 63159/19999 --> 65122/19999 [UP] until ......
Mar 04 05:59 Actual Sync went from 65122/19999 --> 57679/19999 [DOWN] ***<Remember this Sync>*** until 1st Engineer call out (Fixed HR fault) .......
Mar 10 16:28 Actual Sync went from 57679/19999 --> 70306/19999 [UP] ***<Advised line at JF4 (10M approx) from house tested at 79xxx>***
Told to wait to see if DLM recovered the sync speed and that a DLM reset would be asked for, if it does not recover log another call with Plusnet
The line did NOT recover, the Sync reduced to 66999/19999 and stayed there until 2nd Engineer + DCoE 'fixed' the problem.
During this period G.INP was enabled on the line, it did not change anything regarding sync speed.

<<- Quick weekly run to Present day via 2nd Engineer callout ->>
Mar 14 05:27 Actual Sync 62562/19999 Max Attain 77542/26342 [DOWN]
Mar 21 04:50 Actual Sync 66999/20000 Max Attain 77101/27022 [UP]            (66999/20000 started on Mar 17 continues to Apr 02 ... 2nd Engineer call out)
Mar 28 00:30 Actual sync 66999/20000 Max Attain 77178/26805 [NO Change]
Apr 02 06:00 Actual Sync 66999/20000 Max Attain 72660/26653 [No Change]     Before Engineer has touched line or attempted any fix
Apr 02 13:38 Actual Sync 61489/19999 Max Attain 73208/26211 [DOWN]          Engineer has, while at cab, request a L&S and this is the result.
Lower DS sync + High Interleave, INP on, Delay on, G.INP Off

Convinced Engineer this is not good enough as it is worse than before he touched the line.
Goes to cab again. 10-15 min wait and mobile call is received.
Advised fault at DSLAM, port tests OK but randomly drops speed of sync to 51M.
The original port I had been moved to would not sync at 80M when set but tested at 71M. So moved twice.
After Easter Holidays during which NO activity at cab.
DCoE test port with Woosh test. Declare all is Good and no mention of DSLAM fault.
Close call pass back to Plusnet.
I receive SMS stating all fixed.
Engineers notes from Plusnet Call Log are as follows:
========================================================================================================
2015-04-02 15:40:36 : 02/04/2015 15:40:32-
Notes - DCOE DONE LIFT AND SHIFT BUT PORT STILL DROPPING AND SLOWING DOWN TOLD TO SEND BACK INCOMPLETE FOR DIAGNOSTIC TEST
                                               
        DCOE: The woosh test is a pass no fault found, an engineer has today done a lift and shift and
        the line is now in full sync at speeds of 61.5 down and 20 up which are slightly exceeding
        the predicted 54.5 down and 15.7 up.
        The line may needsome time to settle but i am passing it back to the cp as OK RWT by DT.
========================================================================================================

The predicted DS sync is 55808, very close to 57679 ***<Remember this Sync>***
Just a little under what you 'already have', so you look to have 'gained' something.
Of course this is 'in the range expected' for your line, so No 'Line Fault' there.
The Woosh Test was a remote test which conveniently cleared all the faults including the DSLAM fault.
Somehow I am not convinced and the decimation of my Line Performance is NOT reasonable by any measure.

Reality is something else.
Until Feb 14 I had a good 79987/19999 line with no interleaving, delay, INP. [G.INP was working, when enabled, as Zyxel supports G.INP.]
After a HR fault which probably initiated around this time judging by the line degradation, 2 Engineer call outs & DCoE.
I now have a crappy line that by all measures of BTW/OR is perfectly good and 'in spec' only its now giving :
(Bear in mind that I am syncing 5M approx higher than the supplied HG612 so real sync is 64xxx lower than I started with on the morning of the callout)

(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi1072.photobucket.com%2Falbums%2Fw364%2FGrapheneMan%2FScreenshot%25202015-04-07%252022.05.42_zpsr4ueg7ky.png&hash=f115fe52c0221bdc8ad7bf7f8cb4cf2bb40d9358)

Right now, with FEC and interleaving turned off, it is achieving and estimating 69Mbps, and it is hard to disagree.
[Totally disagree, See above. The INP & Interleave has just gone off (06/04/15 05:05) with no change in Max Attainable or Sync speed.]

Update:
Posted on Plusnet Forum with Supporting Docs/Graphs.
See http://community.plus.net/forum/index.php/topic,138251.msg1217788.html#msg1217788 (http://community.plus.net/forum/index.php/topic,138251.msg1217788.html#msg1217788)
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: AArdvark on April 08, 2015, 12:29:41 PM
Update:
The game is afoot at Plusnet.

A number of negative responses including the standard OR Mantra.
All I am getting is the standard FUD.
Not good enough.

We continue the quest undaunted.  ;D
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: WWWombat on April 08, 2015, 02:24:52 PM
Quote
Of course, quite why DLM intervened is not obvious.

Its also puzzling me that I couldnt see any reason why the DLM would have intervened.  The MTBE looked fine.
Whats happening with the upstream? - the loss of SNRm: 15dB -> 6dB is one heck of a lot for the DLM to be playing with especially when there is hardly any upstream {none} E/secs.

My personal rule of thumb is that, for downstream VDSL2 17a lines with access to the full spectrum of bits, 3dB is worth 11Mbps. Something in the region of 60-80Mbps will be working with the full spectrum.

I have never tried to work out an equivalent rule of thumb for upstream, but let me just (for the sake of quick argument) guess at around one-quarter of the downstream amount. So for upstream, 3dB would be worth 2.8Mbps.

The overhead added by FEC downstream tends to be between 20% and 30%. Lets assume it is the same for upstream: 20% of 20Mbps is an extra 4Mbps; 30% of 20Mbps is 6Mbps. So FEC will use an extra 4-6Mbps - though I'd guess that 20% is more likely as a first step.

4Mbps would consume 4.3dB of SNR, and 6Mbps would consume 6.4dB.

Now, that kind of SNR difference matches with the values seen on Aardvark's line between early February (12dB) and late February (7.5dB); For an bit of on-the-fly calculation, I'm happy with the way that matches up.

But it doesn't explain the differences when the SNR jumps to 15dB, visible on March 1,2,3, March 10,11,12 and the last couple of days. Those are huge steps that don't fit with this calculation. My first thought was a difference in power, but that doesn't happen here.

I vaguely recall an occasion where I saw upstream SNR jump in an unexplained way (with no equivalent jump in attainable speed). I'm trying to remember where, so I can see if it offers any help here.

Quote
W3 are E/S intepreted differently on g.inp lines and do they dont show on MDWS? Could the DLM now be using a ReTX counter for e/s.  Sorry for the questions, with me not being g.inp'd yet Im a bit behind when it comes to how it shows on a line. I need to see some figures first hand on my own line to judge properly whats happening with g.inp & DLM

Yes, I think DLM will be monitoring someone else (beyond ES) on G.INP lines. Just like old-style DLM uses a "refined" ES value instead of a raw CRC counter, I'd expect new-style DLM to do something similar ... but I haven't figured out what yet. I *think* LEFTRS is the most "refined" thing we can see in the current stats, and probably better than a raw re-transmission counter.

Actually, because a line configured for G.INP-style retransmission *also* configures FEC and interleaving for REIN, I suspect that a decent DLM would monitor both halves separately, and adjust them independently. Patent wars allowing   :D

We continue the quest undaunted.  ;D

I'll have to go through your longer post later or tomorrow; I'm going to be a bit tied up for today now.

I agree, though, that it is hard to judge the point up to which we can accept the stats as being properly representative, and the point where they stop being trustworthy, and any subsequent point where they may be trustworthy again. This makes your case much harder to judge than normal.

But can I ask, in the meantime, that where you list sync changes, you are absolutely clear which modem is involved at the time. That 5Mbps difference can mask things...
Title: Re: Query re: OR Engineer visit & Zyxel modem
Post by: AArdvark on April 08, 2015, 08:12:23 PM
Quote
But can I ask, in the meantime, that where you list sync changes, you are absolutely clear which modem is involved at the time. That 5Mbps difference can mask things...

Was highlighted in text but now also highlighted in GREEN

FYI:
All the strange jumps are DLM 'playing' with my line as far as I can tell.
To what end I can only guess so my thoughts are not valid at this time.

Quote
I'll have to go through your longer post later or tomorrow; I'm going to be a bit tied up for today now.
Thanks appreciated.
My point was more to do with 'point events' being used to justify declarations by Plusnet which are meaningless.
A highlevel overview of the events and the Chronology needs to be understood.
Events compounded together caused DLM to reach 'decisions' that were not valid and provided the apparent justification for the end result when viewed through too small a 'time window'.
Confusing language but I cannot describe it any other way.
Without reading the 'condensed' info at least, the 'Issue' and my objections do not make sense.
I am 'embedded' in the data and chronology and can see patterns that are not obvious to a casual viewer/reader who may have preconceptions about the problem.
These preconceptions are based on past experience but may be getting in the way of seeing the 'real' issue.
This applies virtually 100% to Plusnet who are 'mapping' the problem to all the other problems where the EU is complaining about 'lost' performance which cannot be recovered for all the usual reasons to do with growing Attenuation/Crosstalk of a cab with increasing uptake of DSL based services.

As I have highlighted to Plusnet after recent responses, I an NOT asking for a 80/20 line as per day 1.
I am asking for the line to be put back as it was before the 2nd Engineer & DCoE decimated it.
Within minutes of arriving I lost what I had due to no fault or issue that was pre-existing on my line.
The fix process degraded the line performance and left me worse than I had started. This is my sticking point.
Talking about all the causes for degradation and how it will degrade with time is moot when all the degradation was within minutes.
 
I am not asking for something that is unrealistic based on a lack of understanding of how DSL/ BTW/OR operate.
I know all the standard arguments but they are not the issue this time, for once.

The problem being raised is focused on a timescale of minutes & the causes were therefore NONE of the usual suspects.