Kitz Forum

Broadband Related => Router Monitoring Software => Topic started by: Jaggies on July 04, 2014, 08:40:15 PM

Title: VDSL2 Connection Stats
Post by: Jaggies on July 04, 2014, 08:40:15 PM
I'm not sure if this is the correct forum, but I'm happy for it to be moved to another one if it isn't.

As a new user of FTTC, and the HG612 plus the monitoring software, I don't actually know how to interpret the stats and graphs produced. I can see that my downstream synch is a lot lower than both the attainable rate, and the estimated speed given to me on sign-up. I'm still happy with the overall performance, and I'm not really hammering the connection, however it would help if I understood the graphs before I potentially raise a fault with my ISP.

Snapshot graph from a few minutes ago is attached.
Title: Re: Connection Stats
Post by: Bald_Eagle1 on July 04, 2014, 09:51:26 PM
Hi Jaggies,


I moved your original message to this new thread as it's worth a thread of its own.

I can see from your version number & the fact that parts of your Bit loading graph are coloured blue (shared tones) that you are still using the 'older' HG612 modem firmware version.

The updated version seems to improve stability & slightly improve sync speeds for some users.

The updated version also reports some of the stats differently (perhaps more accurately) & it also allocates the tones used for the band plans slightly differently.

The tones being used for your Discovery & Medley phase band plans confirm that you are connected to a Huawei cabinet DSLAM.




I would recommend that you update the HG612's firmware from one of the GUI versions available in the Experimental area accessible via this link:-

https://mega.co.nz/#F!LdJFDIJL!e_E1twsIg2kTet8mPjrb4w



My personal preference is to view the snapshot graph montage in portrait format.


Have you been obtaining the Ongoing stats?

If so, a look at your line_stats__FULL_MONTY_P-20140704-xxxx.png montage may be useful to campare against mine.


I could then try to explain the differences that may assist in understanding what each graph depicts.


I have attached my recent snapshot & ongoing montages for reference.



Title: Re: Connection Stats
Post by: Bald_Eagle1 on July 04, 2014, 10:04:51 PM
Just as an exteme example of what's good & bad, I have attached Hlog graphs from a connection I have been recently monitoring remotely.


The graph with the pronounced 'V' shape depicts a bridged tap effect (it was found to be a star wired connection -  a typical cause of a bridged tap which has the effect of reducing sync speeds).


The wiring was sorted out today & the effect in the graphs is pretty obvious.

Sync speeds immediately went from a very poor 15 Mbps to 20 Mbps.

As SNRM immediately went from 6 dB to around 9.6 dB, it suggests the connection still has more to offer.

The new sync speed of 19998 Kbps more or less confirms that DLM had 'banded' the connection to a maximum of 20 Mbps sync speed.

It is hoped that DLM will relent within a few days & allow higher sync speed.


Title: Re: VDSL2 Connection Stats
Post by: burakkucat on July 04, 2014, 10:48:20 PM
As I have also been privy to the data, both before and after the remedial work was performed by a certain wheelbarrow trundler, I have attached (below) the corresponding bitloading/SNR v tone graphs. The improvement is clear to see.  :) 

(I just hope that my tail remains un-pecked . . .  :(  )
Title: Re: VDSL2 Connection Stats
Post by: Jaggies on July 05, 2014, 01:23:02 AM
Thanks for that, I've now updated to bcm96368MVWG_fs_kernel_HG612V100R001C01B030SP06_unlockedgui-nobtagent and restarted Stats Viewer. Snapshot graphs from after the upgrade and Full Monty stats from before attached.

Hope you can make something of these - it's all Greek to me...  8)
Title: Re: VDSL2 Connection Stats
Post by: Bald_Eagle1 on July 05, 2014, 09:34:15 AM
It looks like your firmware update hasn't fully completed.


I would suggest you should try again, ensuring the reset button is held down for 10 to 15 seconds when powering up the modem.
It is easy to accidentally release pressure on it & only achieve a 'partial' firmware update.

This is Wolfy's updated firmware version:-

xdslcmd --version
xdslcmd version 1.0
DSL PHY: AnnexA version - A2pv6C038m.d24j
******* Pass *********


Also your band plan tones haven't changed yet, there are still blue 'shared' tones showing in your bitloading graph.

This is how the pbParams data should look with the updated firmware version:-

Code: [Select]

Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3970)
Medley Phase (Final) Band Plan
US: (7,32) (871,1190)
DS: (33,859) (1216,1852)
  VDSL Port Details   Upstream   Downstream
Attainable Net Data Rate:      3855 kbps     21412 kbps
Actual Aggregate Tx Power:        6.9 dBm      12.4 dBm
====================================================================================
  VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
  Line Attenuation(dB): 8.3 55.7   N/A   N/A   N/A 22.1 68.4   N/A
Signal Attenuation(dB): 8.3 55.0   N/A   N/A   N/A 31.4 68.4   N/A
SNR Margin(dB): 6.2 6.2   N/A   N/A   N/A 6.0 6.0   N/A
TX Power(dBm): 0.8 5.8   N/A   N/A   N/A 11.3 6.1   N/A


Also, the text shown in red should be present when the firmware has been fully updated:-

xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason:   1
Last initialization procedure status:   0
Max:   Upstream rate = 3855 Kbps, Downstream rate = 21412 Kbps
Bearer:   0, Upstream rate = 3866 Kbps, Downstream rate = 21698 Kbps


The differences between our connection stats are visually obvious (I'm around 1100m from the cabinet so I'll never see great speeds), but I'll try to explain some of the more relvant stats:-

Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3970)
Medley Phase (Final) Band Plan
US: (7,32) (871,1190)
DS: (33,859) (1216,1852)


My connection 'Discovered' the relevant VDSL2 band plan tones, but due to distance from the cabinet, attenuation & possibly noise/crosstalk are too high for it to actually use all of them at 'Medley' phase.

The 'older' firmware version doesn't identify the current band plan tones correctly & doesn't distinguish between DS Line & Signal attenuation.

The higher Signal attenuation in my D1 band from the updated version indicates a loss of quite a bit of signal due to noise/crosstalk:-

Code: [Select]
  VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
  Line Attenuation(dB): 8.3 55.7   N/A   N/A   N/A 22.1 68.4   N/A
Signal Attenuation(dB): 8.3 55.0   N/A   N/A   N/A 31.4 68.4   N/A

For my connection, that equates to a loss of around 10 Mbps from when it was able to sync at 32Mbps upward.

Minimum Target SNRM for VDSL2 connections is 6dB.

As our connections are in sync at not much above 6dB, it confirms that currently we are unlikely to be able to achieve higher sync speeds.

Users with SNRM of around 9dB or more could potentially achieve higher sync speeds (unless they have intentionally restricted sync speeds or DLM or the ISP has temporarily or permanently capped sync speed).
e.g. I have recently seen a connection with 9.6dB SNRM but sync speed had been capped due to a bridged tap effect at 19998 Kbps, with an attainable rate in excess of 26000 Kbps.


The D: data confirms DS & US Interleaving depth (1 = OFF i.e. fastpath):-
D:      1      1


You have a fairly high DS depth of 863 which will currently be restricting sync speeds.
ISPs have no control over Interleaving depths for VDSL2 connections, so that value will have been determined by DLM based upon error counts, number of resyncs etc. that it has seen.

If your connection was able to regularly sync at higher speeds, it would indicate that either the connection's physical properties have deteriorated or that noise/crosstalk has increased.


With Interleaving applied, Impulse Noise Protection (INP) & delay (Ping times) will have been added at varying levels.

AS my connection is currently operating on fastpath, these values are zero:-

INP:      0.00      0.00
delay:      0      0


When my connection had DS Interleaving set at a low depth of 371, these were applied at the first stage:-

INP:      3.00      0.00
delay:      8      0

As the need for deeper interleaving depth increases, these values will also increase.
I'm nott 100% sure when DLM makes the decision to increase interleaving etc.
Examining your data in the raw xdslcmd info --stats section of a Plink log will confirm at what level yours have been set.

Too high levels of errored seconds, CRC, HEC or RSUnCorr errors or too many resyncs in fairly quick succession will drive DLM to apply interleaving.

Fast path connections do not generally use FEC (Forward Error Connection) a.k.a. RSCorr or since the firmware was updated they sometimes use very low levels.

Interleaving & FEC can be good things as they drastically reduce errors that would mean data has to be retransmitted & can actually speed up actual throughput, despite sync speed being lower.

However, as gamers tend to require very low ping times to avoid being killed in an online game etc.
High levels of delay & INP as applied with interleaving aren't very helpful.

It is often 'better' for gamers to have lower sync speeds & thus lower error counts that tend to maintain fastpath connections.


Here endeth lesson #1.

I can't explain ALL the other stats, but let me know if you have any other queries.
I'll do my best to explain wherever I can.

I think I've seen your name in the Plusnet and/or TBB forums.
WWWombat occasionally visits those forums & he could give you a very detailed technical explanation behind all the stats, but the above might help with a basic understanding for now.


See the attached ongoing montage for how the error counts have changed since my connection reverted to fastpath.

TBH, I expect it won't be too long before interleaving is applied by DLM again.


Title: Re: VDSL2 Connection Stats
Post by: Jaggies on July 05, 2014, 01:15:24 PM
Right - my fault the firmware upgrade didn't complete, I just logged in to the GUI via my browser and used the option within the GUI to upgrade it, I didn't do the factory reset first.

I'll have another go later, but I'm off out for lunch just now.

And yes, you will have seen me on the PN forums.  8)
Title: Re: VDSL2 Connection Stats
Post by: burakkucat on July 05, 2014, 03:56:00 PM
This has been said (by me and A.N.Other) before now but it seems to have been forgotten . . .

There are two separate ways of upgrading the firmware on a Huawei HG6xx device --
Each of those methods requires the firmware to be in a different format.

All available firmware images are in the Broadcom boot-loader format.

Any attempt to perform a firmware upgrade via the GUI will fail. There will be no indication that the upgrade has failed as the incorrect format firmware image is just silently ignored.
Title: Re: VDSL2 Connection Stats
Post by: Jaggies on July 05, 2014, 06:51:45 PM
@burakkucat - thanks for that. Now done properly and graphs showing somewhat differently. This is what it looks like on resynch. Don't have a Full Monty graph yet, but once it's been back on for a bit longer we'll see...
Title: Re: VDSL2 Connection Stats
Post by: burakkucat on July 05, 2014, 07:32:05 PM
Quote from: Jaggies on July 05, 2014, 06:51:45 PM
@burakkucat - thanks for that. Now done properly and graphs showing somewhat differently. This is what it looks like on resynch. Don't have a Full Monty graph yet, but once it's been back on for a bit longer we'll see...

:thumbs:  Aim for a full 24 hours worth of data capturing before producing the new graphs.  ;)

To me, your snapshot graphs indicate a good line. But then I do not have an eagle eye . . .
Title: Re: VDSL2 Connection Stats
Post by: Jaggies on July 07, 2014, 12:20:29 AM
Hokeydokey, here's the graphs after 29½ hours...

Just looking for guidance on why the downstream synch rate is so far below the maximum attainable rate, and if the FEC error count is excessive at almost 180 million.

Thanks!
Title: Re: VDSL2 Connection Stats
Post by: burakkucat on July 07, 2014, 01:02:21 AM
b*cat attempts to "whistle up" an analytical Eagle (type bald). (https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.centos.toracat.org%2Fajb%2Ftmp%2Fwhistling.gif&hash=49d306bbfb8d35e3e1ad0bd9933b01750a81d0eb)
Title: Re: VDSL2 Connection Stats
Post by: Jaggies on July 10, 2014, 06:54:52 PM
Obviously a busy chap...

I might just take this question over to the PN forum - perhaps one of the DCT might be persuaded to run a line test for me...  8)
Title: Re: VDSL2 Connection Stats
Post by: burakkucat on July 10, 2014, 07:07:16 PM
Using my inbuilt climbing spikes, I proceeded up the tree that was nearest to the Eagle's Nest and vocalised . . .  ;)

There was some flapping about, followed by the ejection of a small quantity of feathers. I didn't stay around to see what happened next!  :no:
Title: Re: VDSL2 Connection Stats
Post by: Jaggies on July 10, 2014, 07:44:23 PM
No problem - I know that anything B_E does on here and elsewhere is voluntary, and presumably we users take up considerable amounts of valuable time which could be better spent elsewhere.

I've started a thread on the PN forums, but I'll keep an eye open here as well. Up-to-date stats can be provided on request...  :)
Title: Re: VDSL2 Connection Stats
Post by: NewtronStar on July 10, 2014, 08:02:12 PM
Quote from: burakkucat on July 10, 2014, 07:07:16 PM
Using my inbuilt climbing spikes, I proceeded up the tree that was nearest to the Eagle's Nest and vocalised . . .  ;)

There was some flapping about, followed by the ejection of a small quantity of feathers. I didn't stay around to see what happened next!  :no:

I'll give you my pounds worth until the Eagle has landed, there is a lot of noise at the end of your signal to noise ratio in the Downstream D3 band and it's also getting close to the high side with a line attenuation of 66.3, those two togeather is the reason why your DS band 3 bitloading is small or due to power cutbacks due to crosstalk.
Title: Re: VDSL2 Connection Stats
Post by: Jaggies on July 10, 2014, 10:06:19 PM
OK. That whooshing noise behind me is what you just posted flying right over my head...  :'(

I get the meaning of crosstalk, and I'm aware its quite possible that my cabinet has a few more users on it than previously - according to the installer I was the first.

I've asked for a GEA test on the Plusnet forum, but I won't get a response to that until the DCT are back at work tomorrow.
Title: Re: VDSL2 Connection Stats
Post by: NewtronStar on July 10, 2014, 10:36:30 PM
Quote from: Jaggies on July 10, 2014, 10:06:19 PM
OK. That whooshing noise behind me is what you just posted flying right over my head...  :'(

No worrys Jaggies

You well get a better in depth explanation into how your stats are effecting your BB line with BE1.

I don't know anyone on Plusnet or ThinkBroadBand that could examine your graphs and see where the possible issue may lay other than Mr BaldEagle1.
Title: Re: VDSL2 Connection Stats
Post by: Bald_Eagle1 on July 11, 2014, 12:01:23 AM
The jaggedness of Jaggies' SNRM graphs indicate quite a bit of interference.

Without seeing a few days worth of ongoing stats, it's impossible to see if this pattern always occurs at certain times of day or it is continual.

That 'interference' (whatever it is) could be the cause of the high(ish) DS interleaving depth of 1099 & the continually heavy block of DS FEC errors, resulting in sync speed being quite a bit lower than attainable rate.

v 3.0.0.1 of graphpd.exe will now state the total number of errors in the ongoing graphs/montage for any specified period, along with averages per minute, hour & day for the same period.


Title: Re: VDSL2 Connection Stats
Post by: Jaggies on July 12, 2014, 10:31:26 AM
OK. Last night I took a snapshot graph of 5 days, but the PC hasn't been on continuously, so presumably there are gaps where nothing is recorded. Clearly I don't know if it's worth anything, but I attach the Full Monty for your perusal.

Thanks for your interest.
Title: Re: VDSL2 Connection Stats
Post by: Jaggies on August 23, 2014, 12:24:04 PM
OK, I know there's been no movement on this thread for a few weeks, however I think an update from me is now in order...

I'm still not getting any BTW speed tests that aren't red, still seeing huge amounts of FEC errors on the line. Last weekend I tried the modem directly in to the VDSL faceplate - it is currently connected via a data extension kit that BT fitted in 2001 when I had ADSL installed for the first time - there was no noticeable improvement to the synch rate, so I'm going to assume the data extension is not the cause of my problem.

Looking at the modem stats, the FEC error count is ridiculous, working out at around 1300 FEC errors per second. Is this even possible? Could the HG612 be misreporting?

I'm using Version 3.0.5306.33566 of the HG612 Modem logs stats viewer & settings editor and Device Information from my modem shows this:

Product type      EchoLife HG612  
Device ID         1C1D67-21530315408K18040672
Hardware version  VER.B
Software version  V100R001C01B030SP06
Firmware version  A2pv6C038m.d24j
Batch number      BC1P6.030.A2pv6C038m.d24j
System up time    5 days 20 hours 59 minutes 51 seconds


I have an engineer booked for Monday 1st September, and let's hope he can actually fix this!
Title: Re: VDSL2 Connection Stats
Post by: loonylion on August 23, 2014, 12:39:50 PM
FEC errors don't actually matter, because they're errors that have been recovered. A high FEC count means the error correction is doing its job.

What matters are CRC errors, uncorrected errors, errored seconds (ES) and sever errored seconds (SES). Those errors are not corrected.
Title: Re: VDSL2 Connection Stats
Post by: Jaggies on August 23, 2014, 12:48:42 PM
OK, I get that they are being corrected, and indeed in general the connection stays up just fine, but surely the time spent correcting errors (is it the modem that does this, or is it further down the line?) could be better spent getting me better speeds and no stuttering on streaming video...

Anyway, full stats screen-shot attached.
Title: Re: VDSL2 Connection Stats
Post by: Bald_Eagle1 on August 23, 2014, 02:20:52 PM
Quote from: Jaggies on August 23, 2014, 12:24:04 PM
OK, I know there's been no movement on this thread for a few weeks, however I think an update from me is now in order...

I'm still not getting any BTW speed tests that aren't red, still seeing huge amounts of FEC errors on the line.


I wouln't worry too much about the BTW speed test showing red.
A lot of users are seeing that at the moment.



Quote
Last weekend I tried the modem directly in to the VDSL faceplate - it is currently connected via a data extension kit that BT fitted in 2001 when I had ADSL installed for the first time - there was no noticeable improvement to the synch rate, so I'm going to assume the data extension is not the cause of my problem.


As you have a fairly high DS Interleaving depth, you would be unlikely to see an instant improvement in sync speeds.
It can often take many days for DLM to relent whenever there is a reduction in error counts, but it does react far quicker when a previously clean connection starts to see large increases in errors.

The deciding factor would be if error counts reduced dramatically when running directly from the faceplate (preferably via a microfilter plugged into the main test socket).


Sustained error count reductions could eventually lead to increased sync speeds.


Quote
Looking at the modem stats, the FEC error count is ridiculous, working out at around 1300 FEC errors per second. Is this even possible? Could the HG612 be misreporting?


That doesn't look too bad for your current Interleaving depth.

Do you have any graphs from when connected directly to the faceplate & are the error counts you do see fairly consistent 24/7 or are there any patterns to when they increase/decrease



Quote
I'm using Version 3.0.5306.33566 of the HG612 Modem logs stats viewer & settings editor and Device Information from my modem shows this:

Product type      EchoLife HG612  
Device ID         1C1D67-21530315408K18040672
Hardware version  VER.B
Software version  V100R001C01B030SP06
Firmware version  A2pv6C038m.d24j
Batch number      BC1P6.030.A2pv6C038m.d24j
System up time    5 days 20 hours 59 minutes 51 seconds


I have an engineer booked for Monday 1st September, and let's hope he can actually fix this!


 :fingers: for 1st September.


It may be useful to harvest/graph your stats 24/7 for a few days if possible.

As happened during engineer visits over many months of trying to track down my connection's intermittent fault, the connection may be fine when tested, resulting in LTOK (Line Tests O.K.), in which case the 'fault' (if indeed there is one) will be closed and/or there is some risk that you will be charged for the visit.



Graphical evidence of genuine 'faults' may assist in ensuring BTOR, via Plusnet, actually pursue a resolution.


As your connection appears fairly stable, i.e. it doesn't resync numerous times on a daily basis, the 'fault' may simply be interference somehwere in the 'D' side cable from the cabinet or even from within your house (Plasma TV, fridge, LED or flourescent lighting, mains power cables etc. etc. etc.




There's not much difference between Line & Signal attenuation values for your connection, so although it can't be ruled out, it doesn't appear to be due to particularly high levels of crosstalk.


My connection now suffers from increased crosstalk over its 1100m or so of D side cable & these are my stats:-

xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason:   1
Last initialization procedure status:   0
Max:   Upstream rate = 4131 Kbps, Downstream rate = 21412 Kbps
Bearer:   0, Upstream rate = 3977 Kbps, Downstream rate = 18678 Kbps

Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3970)
Medley Phase (Final) Band Plan
US: (7,32) (871,1190)
DS: (33,859) (1216,1605)
     VDSL Port Details        Upstream        Downstream
Attainable Net Data Rate:        4131 kbps          21412 kbps
Actual Aggregate Tx Power:          6.9 dBm           12.3 dBm
====================================================================================
      VDSL Band Status     U0     U1      U2      U3      U4      D1      D2      D3
  Line Attenuation(dB):    8.3    55.7     N/A     N/A     N/A    22.1    68.4     N/A   
Signal Attenuation(dB):    8.3    54.9     N/A     N/A     N/A    31.4    68.4     N/A   
        SNR Margin(dB):    6.7    6.6      N/A     N/A     N/A    6.3     6.3      N/A   
         TX Power(dBm):    0.6    5.8      N/A     N/A     N/A    11.4    5.1      N/A
Title: Re: VDSL2 Connection Stats
Post by: Jaggies on August 23, 2014, 09:38:35 PM
Unfortunately, I can't leave the modem connected at the master socket for any length of time, as there is no power socket close enough, so I had to run an extension from another room and along the hallway. If it had shown a noticeable improvement (and I see now I didn't really give it a chance) I'd have arranged to have a power source there, and used the modem at the master and changed one end of the data extension kit to be a RJ45 plug like the other end that's connected to the VDSL plate.

Just to clarify the set-up I'm currently running, the attached diagram should hopefully show the problems with getting modem/phone line/power side-by-side. The red line is the data extension (Cat 5) - at the phone socket end it terminates in a RJ45 plug connected to the top port of the VDSL socket. At the other end is a RJ11 socket, fitted by the BT engineer who did the ADSL installation all those years ago, and the modem cable connects to that.
Title: Re: VDSL2 Connection Stats
Post by: WWWombat on September 08, 2014, 02:03:55 PM
Quote from: Jaggies on July 07, 2014, 12:20:29 AM
Just looking for guidance on why the downstream synch rate is so far below the maximum attainable rate

A late reply to this, but the answer to this question is fairly simple:

DLM has intervened, and asked for interleaving and error correction to be turned on. This has three noticeable effects on the link:
- Interleaving causes additional latency, so ping times are higher. DLM's first choice of intervention usually adds 8ms, but you usually see slightly higher increases in ping times.
- Error Correction (aka FEC) steals some of your bandwidth, and re-uses it to help correct errors on the line, so you see your sync speed drop. On the statistics output, the modem shows us the sync speed *after* the FEC overhead has already been removed. However, the "max attainable" value is calculated *before* reduction of the FEC overhead.
- There is a second curious side-effect when FEC is turned on: The "max attainable" value actually goes up, and usually by about the same amount as the sync speed went down.

The overall impact of DLM is usually that you see the sync speed drop by about 10%, and the max attainable rise by about the same amount.

As an example, my line recently had DLM intervene for 2 months. During that time, I could see
- Sync speed dropped by around 6Mbps
- Max Attainable increased by 6Mbps
- The error-correction overhead used about 18% of the bandwidth, which adds up to about 15Mbps.

When DLM removed the intervention, the sync speed went back up by 6Mbps, and the max attainable came down by 6Mbps again.

Quote
and if the FEC error count is excessive at almost 180 million.
It sounds high, doesn't it?

When DLM intervened, and turned error-correction on, the modems respond by splitting your data down into smaller blocks, and adding protective data into the blocks (to allow the correction process to work at the other end). Because the blocks are smaller (in your case, one-thirtieth of the size), the counts can mount up quickly - so large numbers are, by themselves, not scary.

What the other figures show is this:
- The modems have transferred 1.5bn of these smaller RS blocks.
- 180m of the blocks had a fault that could be fixed. That is about 12% of the blocks.
- Just under 100k of the blocks had faults that could not be fixed. That is 0.01% of the blocks.

That 12% suggests that you really do need the error correction process to be in place. There is plenty of noise in the environment that needs to be dealt with somehow. But the 0.01% figure means that the error correction is working effectively with the current settings. In addition the graph of ES (Errored seconds) showed that you had accumulated around 150 ES's within 24 hours - that too suggests DLM will continue at this level of intervention.
Title: Re: VDSL2 Connection Stats
Post by: Jaggies on September 10, 2014, 12:13:43 AM
Thanks for that. I'm kind of busy this week and away to the US for a week from next Wednesday so won't be around much, but I think before I go I'll stick the ECI modem back on - no-one else will care about the stats... 8)