Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: 1 ... 3 4 [5]

Author Topic: Query re: OR Engineer visit & Zyxel modem  (Read 14160 times)

WWWombat

  • Kitizen
  • ****
  • Posts: 1674
Re: Query re: OR Engineer visit & Zyxel modem
« Reply #60 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.
Logged

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 32660
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: Query re: OR Engineer visit & Zyxel modem
« Reply #61 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
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

AArdvark

  • Kitizen
  • ****
  • Posts: 1008
Re: Query re: OR Engineer visit & Zyxel modem
« Reply #62 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)



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
« Last Edit: April 08, 2015, 07:22:55 PM by AArdvark »
Logged

AArdvark

  • Kitizen
  • ****
  • Posts: 1008
Re: Query re: OR Engineer visit & Zyxel modem
« Reply #63 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
Logged

WWWombat

  • Kitizen
  • ****
  • Posts: 1674
Re: Query re: OR Engineer visit & Zyxel modem
« Reply #64 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...
Logged

AArdvark

  • Kitizen
  • ****
  • Posts: 1008
Re: Query re: OR Engineer visit & Zyxel modem
« Reply #65 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.
Logged
Pages: 1 ... 3 4 [5]