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 [2]

Author Topic: VDSL2 Connection Stats  (Read 7499 times)

NewtronStar

  • Kitizen
  • ****
  • Posts: 4898
Re: VDSL2 Connection Stats
« Reply #15 on: July 10, 2014, 08:02:12 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.
Logged

Jaggies

  • Member
  • **
  • Posts: 92
Re: VDSL2 Connection Stats
« Reply #16 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.
Logged

NewtronStar

  • Kitizen
  • ****
  • Posts: 4898
Re: VDSL2 Connection Stats
« Reply #17 on: July 10, 2014, 10:36:30 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.
« Last Edit: July 10, 2014, 10:39:04 PM by NewtronStar »
Logged

Bald_Eagle1

  • Helpful
  • Kitizen
  • *
  • Posts: 2721
Re: VDSL2 Connection Stats
« Reply #18 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.


Logged

Jaggies

  • Member
  • **
  • Posts: 92
Re: VDSL2 Connection Stats
« Reply #19 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.
Logged

Jaggies

  • Member
  • **
  • Posts: 92
Re: VDSL2 Connection Stats
« Reply #20 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!
Logged

loonylion

  • Reg Member
  • ***
  • Posts: 723
Re: VDSL2 Connection Stats
« Reply #21 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.
Logged

Jaggies

  • Member
  • **
  • Posts: 92
Re: VDSL2 Connection Stats
« Reply #22 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.
« Last Edit: August 23, 2014, 12:51:32 PM by Jaggies »
Logged

Bald_Eagle1

  • Helpful
  • Kitizen
  • *
  • Posts: 2721
Re: VDSL2 Connection Stats
« Reply #23 on: August 23, 2014, 02:20:52 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
« Last Edit: August 23, 2014, 03:59:59 PM by Bald_Eagle1 »
Logged

Jaggies

  • Member
  • **
  • Posts: 92
Re: VDSL2 Connection Stats
« Reply #24 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.
« Last Edit: August 23, 2014, 09:41:57 PM by Jaggies »
Logged

WWWombat

  • Kitizen
  • ****
  • Posts: 1674
Re: VDSL2 Connection Stats
« Reply #25 on: September 08, 2014, 02:03:55 PM »

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.
Logged

Jaggies

  • Member
  • **
  • Posts: 92
Re: VDSL2 Connection Stats
« Reply #26 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)
Logged
Pages: 1 [2]