General Discussion
  >> Fibre Broadband


Register (or login) on our website and you will not see this ad.


Pages in this thread: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | (show all)   Print Thread
Standard User Bald_Eagle1
(learned) Tue 06-Dec-11 12:00:00
Print Post

SNRM & Error levels


[link to this post]
 
Hi All,

Due to some quite recent work carried out by a BT engineer, my FTTC connection appears to have become stable (regarding SNRM levels & disconnections).

However, I believe I still have quite high error levels, that may suggest there is still a problem somewhere in the D-side cabling from the cabinet.

My D-side is supposedly anywhere between 800m & 1000m in length.

From the unlocked HG612 modem's GUI, these are my current details:-


Text
1
23
45
67
89
10
DSL Up time     - 588866 (seconds)  approx 163.6 hours 
  
                DS              US 
SNRM            4.9             6.7      
CRC errors      387853          0FEC errors      7167            396     
HEC errors      117021          0



As a comparison, would you mind posting the DSL Up time, SNRM, & error levels as reported for your own connections, along with an estimation of your D-side line length?


Paul.

Edited by Bald_Eagle1 (Tue 06-Dec-11 12:34:56)

Standard User XRaySpeX
(eat-sleep-adslguide) Tue 06-Dec-11 13:51:12
Print Post

Re: SNRM & Error levels


[re: Bald_Eagle1] [link to this post]
 
Does it report Error Seconds? To get a feel for the errors you quoted I think you need to know how much data has passed.

1999: Freeserve 48K Dial-Up => 2005: Wanadoo 1 Meg BB => 2007: Orange 2 Meg BB => 2008: Orange 8 Meg LLU => 2010: Orange 16 Meg LLU => 2011: Orange 19 Meg WBC
Standard User Bald_Eagle1
(learned) Tue 06-Dec-11 20:06:26
Print Post

Re: SNRM & Error levels


[re: XRaySpeX] [link to this post]
 
In reply to a post by XRaySpeX:
Does it report Error Seconds? To get a feel for the errors you quoted I think you need to know how much data has passed.


It does report error seconds (somewhere else), but I was simply trying to obtain a general overall feel for TYPICAL connections.

e.g. for my connection:-
Line length 800m to 1000m.
DS SNRM = 4.6 dB, US SNRM = 6.8 dB.
DSL up time of 610696 seconds is roughly 169.64 hours.
389814 DS CRC errors in that period AVERAGES at 2298 CRC errors per hour.

From another user:-
Line length ????
DS SNRM = 22.4 dB, US SNRM = 21.9 dB.
DSL up time of 6231232 seconds is roughly 1731 hours.
144 DS CRC errors in that period AVERAGES at only 0.08 CRC errors per hour.

A massive difference between the 2 connections is clearly seen.

That's basically what I'm trying to establish, in simplistic terms, to help confirm what a typical connection, over typical line lengths could be expected to achieve (or not achieve).


Paul.

P.S. Quite a lot of the errors being reported for my connection occur overnight, while I'm tucked up in bed & the PC is not being used (apart from the occasional programmed software updates.
The errors don't really coincide with these events.


Register (or login) on our website and you will not see this ad.

Standard User XRaySpeX
(eat-sleep-adslguide) Tue 06-Dec-11 20:32:11
Print Post

Re: SNRM & Error levels


[re: Bald_Eagle1] [link to this post]
 
That's an invalid comparison with another line that has massive noise issues, witnessed by:
DS SNRM = 22.4 dB
Anyway you can't average errors over time, only over quantity of data.

1999: Freeserve 48K Dial-Up => 2005: Wanadoo 1 Meg BB => 2007: Orange 2 Meg BB => 2008: Orange 8 Meg LLU => 2010: Orange 16 Meg LLU => 2011: Orange 19 Meg WBC
Standard User smurf46
(member) Tue 06-Dec-11 20:53:43
Print Post

Re: SNRM & Error levels


[re: Bald_Eagle1] [link to this post]
 
Mine's been up for about 10 days (246 hours) since last modem reboot. Sadly its a Fritz so doesn't show the same detail, but I think of it as a poor line (600m+ with something like over 50 repair joints between me and the cab!), and, of course, heavily interleaved::

Receive Direction / Send Direction
Max. DSLAM throughput kbit/s 40000 / 7200
Min. DSLAM throughput kbit/s 20000 / 3600
Attainable throughput kbit/s 42060 / 5611
Current throughput kbit/s 39992 / 5608

Latency 8 ms / 0 ms
Bitswap on / on
Impulse Noise Protection 3.0 / 0.0

Signal-to-noise ratio dB 7 / 6
Line attenuation dB 20 / -
Carrier record A43 / A43
Profile 17a

FRITZ!Box:
Error seconds 2295
Many ES 1
Remediable Errors (FEC) per minute 2344
Last15 minutes 8467540
Not Remediable Errors (CRC) per minute 0.47
Not Remediable Errors (CRC) last 15 minutes 8

DSL central exchange
Error seconds 784
Many ES 0
Remediable Errors (FEC) per minute 1
Last15 minutes 2
Not Remediable Errors (CRC) per minute 0.05
Not Remediable Errors (CRC) last 15 minutes 0

On a typical day the unrecoverable errors seem to jump between 2 and 4 x the usual for an hour once in the early morning and once late afternoon to 124, strangely when I'm not using the connection. EDIT: I've not noted any significant change in the reported errors on heavy downloading (up to 35Mbps) but I can see the upload band is restricted.

We see things not as they are, but as we are .
- Anais Nin

Edited by smurf46 (Tue 06-Dec-11 21:17:20)

Standard User RobertoS
(sensei) Tue 06-Dec-11 20:56:32
Print Post

Re: SNRM & Error levels


[re: XRaySpeX] [link to this post]
 
Couldn't the premises be very close to the cabinets? That would send the margin high.

My broadband basic info/help site - www.robertos.me.uk
My domains,website and mail hosting - Tsohost. Internet connection - IDNet Home Starter Fibre. Live BQM.

"Where talent is a dwarf, self-esteem is a giant." - Jean-Antoine Petit-Senn.
Standard User burakkucat
(committed) Tue 06-Dec-11 21:44:17
Print Post

Re: SNRM & Error levels


[re: XRaySpeX] [link to this post]
 
In reply to a post by XRaySpeX:
Anyway you can't average errors over time, only over quantity of data.
That is an interesting comment, XRay. How would you (assuming possession of equipment that provides basic statistics on everything) quantify errors in such a way that they may be plotted on a graph, for instance?

-----------------------------------------------------

100% Linux and, previously, Unix.

Edited by burakkucat (Tue 06-Dec-11 21:44:58)

Standard User Bald_Eagle1
(regular) Tue 06-Dec-11 22:58:36
Print Post

Re: SNRM & Error levels


[re: XRaySpeX] [link to this post]
 
In reply to a post by XRaySpeX:
That's an invalid comparison with another line that has massive noise issues, witnessed by:
DS SNRM = 22.4 dB
Anyway you can't average errors over time, only over quantity of data.


Hmm,

The line with the massive noise issues & hardly any errors in comparison with mine syncs at 39999 K & 10000 K.
Its attainable rates are 95252 K & 33134 K.

Mine, with a very low SNRM but thousands more errors in comparison, syncs at only 27942 K & 5679 K.
My attainable rates are only 30756 K & 5961 K

Currently, the maximum speed I can actually download at is just over 26000K

I also believe I did average the errors over time.
A few thousand errors per hour for my connection, compared to much less than 1 error per hour for the other user's connection.

I concede these are only averages as I often get much less per hour, but by the same token, I occasionally get many, many more per hour.

I am no doubt further from the cabinet than the other user as my attenuation is also incredibly high, but I wasn't really discussing that aspect at this time.

Have you any explanation as to why my connection occasionally experiences up to 90000 DS CRC errors within a 2 minute period, especially when it is unattended & not downloading/uploading anything that I am aware of? I haven't.

I'm also not 100% sure that programs such as RouterStats compare errors against the quantity of data either.

Just as an experiment, I have repeatedly downloded a 15 Mb test file - no errors whatsoever, yet 1/2 hour ago, while I wasn't even at the PC, my records show over 300 DS CRC errors within a 2 minute period.

I can't explain that either. Can you?

To help me understand your comment a little better, is there any chance of you humouring me by providing your error counts & SNRM levels over whatever duration your FTTC connection has been up, also confirming the quantity of data you have downloaded/uploaded during that period?

EDIT:
Do these figures mean anything to you?
I have to admit they don't mean a lot to me:-
Text
1
23
4
ES:             1019            271
SES:            11              0UAS:            15              15
AS:             631461

Edited by Bald_Eagle1 (Tue 06-Dec-11 23:03:26)

Standard User XRaySpeX
(eat-sleep-adslguide) Tue 06-Dec-11 23:06:19
Print Post

Re: SNRM & Error levels


[re: burakkucat] [link to this post]
 
If I had to think about it, I would plot "SFErr/SF" (%CRC), "HEC/Total Cells" and "RSUnCorr/RS" (%FEC) against time, using the terminology of Netgear (ignoring diff error terminology for diff routers which others more knowledgeable than me can translate).

1999: Freeserve 48K Dial-Up => 2005: Wanadoo 1 Meg BB => 2007: Orange 2 Meg BB => 2008: Orange 8 Meg LLU => 2010: Orange 16 Meg LLU => 2011: Orange 19 Meg WBC
Standard User woodyblade
(newbie) Tue 06-Dec-11 23:35:31
Print Post

Re: SNRM & Error levels


[re: Bald_Eagle1] [link to this post]
 
Don't know how much help it will be, probably just some more data to compare.

These are the errors after about 45 minutes (rebooted it earlier), roughly it ends up being about 200 - 100 on both FEC and HEC errors after a day or so.

Never seen any CRC errors on the line in the 2 weeks I've had access to the modem and the line length is approximately 600m.

Downstream Upstream
Line rate (kbit/s) 39998 10000
CRC errors 0 0
FEC errors 4 2
HEC errors 4 0
Standard User XRaySpeX
(eat-sleep-adslguide) Tue 06-Dec-11 23:49:53
Print Post

Re: SNRM & Error levels


[re: Bald_Eagle1] [link to this post]
 
In reply to a post by Bald_Eagle1:
Do these figures mean anything to you?
I have to admit they don't mean a lot to me:-
Text
1
23
4
ES:             1019            271
SES:            11              0UAS:            15              15
AS:             631461
Yes! AS is the (approx) Uptime in secs. You have extremely good low Error Secs of over 10 mins between each. From my experience about 5 mins per ES is good on Interleaved and about 1-2 mins per ES on Fast Path.

I'm not on FTTC, but I withdraw my comment about massive noise on the other line, now that you have given me more stats, as I see its DS SNRM has been raised in order to cap the sync to the max. 40 Meg.

I note that the FRITZ!Box does average errors over time, but I'm not convinced as more errors are likely during a period of heavy usage than the same period of idleness.

1999: Freeserve 48K Dial-Up => 2005: Wanadoo 1 Meg BB => 2007: Orange 2 Meg BB => 2008: Orange 8 Meg LLU => 2010: Orange 16 Meg LLU => 2011: Orange 19 Meg WBC
Standard User burakkucat
(committed) Tue 06-Dec-11 23:55:24
Print Post

Re: SNRM & Error levels


[re: XRaySpeX] [link to this post]
 
Thank you. That's something for me to consider . . . smile

-----------------------------------------------------

100% Linux and, previously, Unix.
Standard User mikecrawford80
(regular) Wed 07-Dec-11 00:22:45
Print Post

Re: SNRM & Error levels


[re: Bald_Eagle1] [link to this post]
 
Hi, my stats are as follows;

DSL Up time - 1692005 (seconds) approx 470 hours


DS US

SNRM 5.4 15.1

CRC errors 0 0
FEC errors 36754 8
HEC errors 71524 0


I estimate my d-side at 950m.

Plusnet Extra Fibre
September 2011 Speedtest ...
Standard User RobertoS
(sensei) Wed 07-Dec-11 01:19:22
Print Post

Re: SNRM & Error levels


[re: XRaySpeX] [link to this post]
 
In reply to a post by XRaySpeX:
Anyway you can't average errors over time, only over quantity of data.
I don't agree with this statement.

While an ADSLx line is in sync there is a constant stream of ATM packets, which may or may not contain data in the way most of us understand it. Downloading a film or leaving the connection idle makes little if any difference.

So if you mean user data in the sense of something downloaded by the user, then you are wrong. If you mean data in the sense of the number of ATM packets on ADSLx, times 53, divided by the sync rate, then that is the same as using time.

VDSL2 which is used in FTTC does not use ATM anyway, and no relevant "data" stats are available, in terms of user data or ethernet frame count, so a somewhat tricky calculation. Connection time is the correct, and only, thing to use when analysing downstream error rates.

Incidentally this explains why some posters are seeing errors even when the line is idle. This is to be expected on VDSL2 in the same way as it always was on ADSLx.

My broadband basic info/help site - www.robertos.me.uk
My domains,website and mail hosting - Tsohost. Internet connection - IDNet Home Starter Fibre. Live BQM.

"Where talent is a dwarf, self-esteem is a giant." - Jean-Antoine Petit-Senn.
Standard User Bald_Eagle1
(regular) Wed 07-Dec-11 07:06:53
Print Post

Re: SNRM & Error levels


[re: woodyblade] [link to this post]
 
Thanks woodyblade,

It could be really useful if you could repost the details after a few days of up time (including SNRM values).


I'll post the results of all this once I have a bit more data to report.


Paul.

Edited by Bald_Eagle1 (Wed 07-Dec-11 07:12:48)

Standard User Bald_Eagle1
(regular) Wed 07-Dec-11 07:27:49
Print Post

Re: SNRM & Error levels


[re: XRaySpeX] [link to this post]
 
In reply to a post by XRaySpeX:
Yes! AS is the (approx) Uptime in secs. You have extremely good low Error Secs of over 10 mins between each. From my experience about 5 mins per ES is good on Interleaved and about 1-2 mins per ES on Fast Path.

I'm not on FTTC, but I withdraw my comment about massive noise on the other line, now that you have given me more stats, as I see its DS SNRM has been raised in order to cap the sync to the max. 40 Meg.

I note that the FRITZ!Box does average errors over time, but I'm not convinced as more errors are likely during a period of heavy usage than the same period of idleness.


Thanks XRaySpex,

There may be quite a gap between my errors, but when I do get them, they appear quite substantial on some occasions.

I notice I had over 50000 CRC errors in one burst at around 1:15 this morning.
Again, this was while I was in bed with the PC unattended.

My PC updates its virus database/program at around 3:00 each morning.
This is occasionally quite a sizeable full program update, but it never seems to generate too many errors.

The limited information I have so far appears to suggest that my connection still has a bit of a problem somewhere.
It could be these regular & substantial bursts of errors that is causing DLM to restrict my sync speeds.

I was able to download at 33 Mb for a while on the old 8c profile, which if other users' stats are anything to go by should have increased substantially following the fairly recent switch to the 17a profile.

My connection has quite a history of genuine line faults.
Each time, it has been passed as LTOK by both my ISP & BT, needing much mithering from me to get them to send engineers out.

Each time an engineer has visited though, definite faults have been tracked down & repaired.

I woinder how many users are in the same position, but just end up "putting up with it".

Building up some data on other "typical" connections may help me/others as evidence when trying to get faults rectified.


Paul.
Standard User Bald_Eagle1
(regular) Wed 07-Dec-11 07:35:38
Print Post

Re: SNRM & Error levels


[re: RobertoS] [link to this post]
 
In reply to a post by RobertoS:
VDSL2 which is used in FTTC does not use ATM anyway, and no relevant "data" stats are available, in terms of user data or ethernet frame count, so a somewhat tricky calculation. Connection time is the correct, and only, thing to use when analysing downstream error rates.

Incidentally this explains why some posters are seeing errors even when the line is idle. This is to be expected on VDSL2 in the same way as it always was on ADSLx.


Thanks for that explanation RobertoS.

I think my connection stats confirm your comment, in that I do see many errors when my line is "idle".

I am trying to determine whether or not these error counts can be classed as "normal", or excessive - requiring an engineer's visit.

From what I have seen so far they appear excessive to me, but I would like to build up a bit more user data before I go on yet another mission to have my connection restored to its previous excellent performance levels.


Paul.
Standard User Bald_Eagle1
(regular) Wed 07-Dec-11 08:09:47
Print Post

Re: SNRM & Error levels


[re: mikecrawford80] [link to this post]
 
Hi mikecrawford80,


In reply to a post by mikecrawford80:
Hi, my stats are as follows;

DSL Up time - 1692005 (seconds) approx 470 hours


DS US

SNRM 5.4 15.1

CRC errors 0 0
FEC errors 36754 8
HEC errors 71524 0


I estimate my d-side at 950m.



That's really interesting information for a number of reasons:-

a) Your line at 950m in length is similar to mine. How certain are you about the actual length?

b) Your error count is much lower than mine (especially Zero CRC errors).
I have always been led to believe that CRC errors are the really "naughty" ones to avoid.

c) Your SNRM, especially US is much higher than mine.

d) I am also with Plusnet (Value Fibre - Plusnet profile supposedly 37 Mb).
Have you experienced many connection issues, & if so, how have Plusnet dealt with them?
(Please also see the PM that I have sent to you).

I'd be very interested to see your pbParams details, (especially attenuation levels) ideally from both your 8c profile & your current (assumed) 17a profile.

These are mine:-


8c Profile:-

Text
1
23
45
67
89
1011
1213
1415
1617
1819
2021
22
# xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY statusStatus: Showtime
Retrain Reason: 0Max:    Upstream rate = 7007 Kbps, Downstream rate = 25548 Kbps
Path:   0, Upstream rate = 1997 Kbps, Downstream rate = 25067 Kbps 
Discovery Phase (Initial) Band PlanUS: (0,95) (696,1183) 
DS: (32,687) (1192,1627) Medley Phase (Final) Band Plan
US: (0,95) (696,1183) DS: (32,687) (1192,1627) 
       VDSL Port Details       Upstream        DownstreamAttainable Net Data Rate:       7007 kbps         25548 kbps
Actual Aggregate Tx Power:        1.3 dBm           9.6 dBm============================================================================
  VDSL Band Status        U0      U1      U2      U3      D1      D2      D3  Line Attenuation(dB):  8.4     52.5     N/A     N/A    21.4    65.5     N/A   
Signal Attenuation(dB):  14.4    51.1     N/A     N/A    21.4    65.5     N/A           SNR Margin(dB):  14.5    14.3     N/A     N/A    6.5     6.5      N/A   
         TX Power(dBm): -9.3     0.9      N/A     N/A    9.3    -1.0      N/A



17a Profile:-

Text
1
23
45
67
89
1011
1213
1415
1617
1819
2021
22
# xdslcmd info --pbParams 
xdslcmd: ADSL driver and PHY statusStatus: Showtime
Retrain Reason: 0Max:    Upstream rate = 5965 Kbps, Downstream rate = 30832 Kbps
Path:   0, Upstream rate = 5679 Kbps, Downstream rate = 27942 Kbps 
Discovery Phase (Initial) Band PlanUS: (0,95) (868,1207) (1972,2783) 
DS: (32,859) (1216,1963) (2792,3939) Medley Phase (Final) Band Plan
US: (0,95) (868,1207) DS: (32,859) (1216,1963) 
       VDSL Port Details       Upstream        DownstreamAttainable Net Data Rate:       5965 kbps         30832 kbps
Actual Aggregate Tx Power:        6.3 dBm          12.1 dBm============================================================================
  VDSL Band Status        U0      U1      U2      U3      D1      D2      D3  Line Attenuation(dB):  8.2     53.5    64.1     N/A    21.9    63.8    70.0   
Signal Attenuation(dB):  14.3    52.2     N/A     N/A    21.9    63.8     N/A           SNR Margin(dB):  6.7     6.8      N/A     N/A    4.6     4.5      N/A   
         TX Power(dBm): -4.4     5.9      N/A     N/A    11.1    5.3      N/A
Standard User bhawkes
(newbie) Wed 07-Dec-11 08:45:46
Print Post

Re: SNRM & Error levels


[re: Bald_Eagle1] [link to this post]
 
Bald_Eagle1,

I recognise the 'other users' figures as my own. In which case I can fill in the missing distance figure as being apprx 300m from the cabinet.

The reported massive noise problems DS SNR = 22.4 are significantly different now on profile 17a than they were on 8c when DS SNR was reported as 10.9. This lower figure was also strangely accompanied by much higher error figures than are reported now.

I begin to doubt the figures and am just happy that I appear to have a stable connection with good real d'ld and u'ld figures
Standard User Bald_Eagle1
(regular) Wed 07-Dec-11 09:05:14
Print Post

Re: SNRM & Error levels


[re: bhawkes] [link to this post]
 
Hi bhawkes,

In reply to a post by bhawkes:
Bald_Eagle1,

I recognise the 'other users' figures as my own. In which case I can fill in the missing distance figure as being apprx 300m from the cabinet.

The reported massive noise problems DS SNR = 22.4 are significantly different now on profile 17a than they were on 8c when DS SNR was reported as 10.9. This lower figure was also strangely accompanied by much higher error figures than are reported now.

I begin to doubt the figures and am just happy that I appear to have a stable connection with good real d'ld and u'ld figures


Thanks for line length detail.

As mentioned elsewhere, my connection appears to exhibit completely opposite error performance to yours, in that although I wasn't actually logging SNRM & errors on the 8c profile, I don't recall them as looking "excessive".

Perhaps that was simply due to the fact that until the latest engineer's visit, I couldn't maintain a connection long enough to build up a sizeable error count smile

Again, as mentioned elswhere, a couple of us that are messing about with things have noticed some apparent "discrepancies" in the manner that the modem reports its stats.
However, as all the HG612 modems operate identically, at least there is a level of consistency in order to compare one connection against another.


Paul.
Standard User mikecrawford80
(regular) Wed 07-Dec-11 11:24:04
Print Post

Re: SNRM & Error levels


[re: Bald_Eagle1] [link to this post]
 
Hi Bald_Eagle1,

a) Not certain, but we bought house from new so know how the estate and roads were built. Have plotted distance from cab to house on Google earth and also get a similar result from car tripometer.

b) Think the same as you, pleased that CRC's are zero, can only assume I have a good line.

c) Think US SNRM is higher for me cos I'm on the package capped at 2M upload with Plusnet.

d) Just a couple of connection issues (like PN setting speed down to 17M, I had a profile drop from my original 32, down to about 19, then its stabilised now at 27). But I raised cases, then chased on Twitter and got pretty good responses, so far nothing for me to gripe about with PN support and their offerings (although 120GB on Extra could do with a wee uplift (but I'm sure that will come at some point).

I did not get a pbParams at 8c (I think I flashed my modem after I was put on 17a), but here's my 17 values;

# xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 6209 Kbps, Downstream rate = 26616 Kbps
Path: 0, Upstream rate = 1999 Kbps, Downstream rate = 27399 Kbps

Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3939)
Medley Phase (Final) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 6209 kbps 26616 kbps
Actual Aggregate Tx Power: - 1.8 dBm 12.5 dBm
============================================================================
VDSL Band Status U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 7.6 39.2 57.6 N/A 18.6 48.5 69.2
Signal Attenuation(dB): 12.1 38.4 N/A N/A 18.6 48.5 N/A
SNR Margin(dB): 15.3 15.1 N/A N/A 5.4 5.4 N/A
TX Power(dBm): -3.9 -5.6 -128.0 N/A 10.6 7.8 N/A


I like your Text boxes, but can't see how you do them?

Plusnet Extra Fibre
September 2011 Speedtest ...

Edited by mikecrawford80 (Wed 07-Dec-11 11:25:03)

Standard User Bald_Eagle1
(regular) Wed 07-Dec-11 11:27:01
Print Post

Re: SNRM & Error levels


[re: Bald_Eagle1] [link to this post]
 
Hi All,

If it is of any interest to Windows only users, I will shortly be releasing some Windows batch files that enable automated generation of HG612 modem logs & graphs (no more need to manually log in to PuTTy with username & password).

Also, apart from downloading a few free Windows versions of Linux-type utilities & the graph generating program, there will be no need to install a Linux shell program to run them.

FYI, these are just some of the graphs for the latest 24 days of my own connection. You should be able to clearly see the state of my SNRM, re-syncs, & error levels prior to the engineer's visit 15th November, & its stability, but still quite high error levels since:-

24 day connection graphs

It was only these stats graphs that convinced my ISP to arrange yet another engineer to look at my connection.
Prior to me providing these (& other types of graphs), they were convinced that my connection was stable, & as good as it ever could be.

When fully tested/finally tweaked, the Windows batch files will be released into the same location as the current Linux scripts.

Due to the intentional "secrecy" of the locked modems, I'm sure that BT & ISPs won't really appreciate some users seeing the evidence of just how poor their connections are, but by the same token, some of us users don't appreciate being fobbed off with "Your line tests as LTOK, therefore no action is necessary" responses.

Paul.
Standard User Bald_Eagle1
(regular) Wed 07-Dec-11 12:03:16
Print Post

Re: SNRM & Error levels


[re: mikecrawford80] [link to this post]
 
Hi mikecrawford80,

Thanks for that info.
It's quite surprising though.

Your attenuation levels are a bit lower than mine (suggesting a "better" connection), yet your sync & attainable rates are lower than mine.

I see your SNRM levels are much higher though, which MAY suggest your connection is being speed capped by Plusnet and/or BT (intentionally or not).
That's understandable for the US being capped at 2 Mb, but it doesn't really explain the high SNRM level for your DS.

I am aware of an ongoing Plusnet investigation into how successful (or not) their own profiling system is in actual operation. Some users have been moved back up to a Plusnet profile of 37 Mb, & their actual sync & download speeds have suffered as a consequence.
Mine is 37 Mb, but I achieve nowhere near that.
I am actually achieving a similar DS sync rate to you, but your Plusnet profile appears to be 10 Mb lower than mine.

I also see that neither of us achieve anything at all from the highest frequency band plan at Medley Phase (Final) Band Plan, although it is "discovered" at Discovery Phase (Initial) Band Plan.

Actual bits loaded data for the higher frequency DS band (D3) can be seen in graphs for users with faster connections.
Our attenuation appears too high for us to achieve anything in that band (Signal Attenuation being N/A).

I agree that Plusnet are a pretty good ISP, but it IS very much dependant on users having to provide the "evidence" that Plusnet's own systems do not report.

Just for ease of viewing, I include both your & my pbParams data together.
I have only just sussed how to put it in a text box myself.

It works for me if I start of by typing "[c o d e]" then pasting in the text, & finishing it off with "[/ c o d e]" (omitting the spaces & speech marks, but retaining the square brackets).

Text
1
23
45
67
89
1011
1213
1415
1617
1819
2021
2223
2425
2627
2829
3031
3233
3435
3637
3839
4041
4243
4445
4647
4849
5051
mikecrawford80:-
 # xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY statusStatus: Showtime
Retrain Reason: 0Max: Upstream rate = 6209 Kbps, Downstream rate = 26616 Kbps
Path: 0, Upstream rate = 1999 Kbps, Downstream rate = 27399 Kbps 
Discovery Phase (Initial) Band PlanUS: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3939)Medley Phase (Final) Band Plan
US: (0,95) (868,1207) (1972,2783)DS: (32,859) (1216,1963)
VDSL Port Details Upstream DownstreamAttainable Net Data Rate: 6209 kbps 26616 kbps
Actual Aggregate Tx Power: - 1.8 dBm 12.5 dBm============================================================================
VDSL Band Status        U0      U1      U2      U3      D1      D2      D3Line Attenuation(dB):   7.6     39.2    57.6    N/A     18.6    48.5    69.2
Signal Attenuation(dB): 12.1    38.4    N/A     N/A     18.6    48.5    N/ASNR Margin(dB):         15.3    15.1    N/A     N/A     5.4     5.4     N/A
TX Power(dBm):          -3.9    -5.6    -128.0  N/A     10.6    7.8     N/A 
  
Bald_Eagle1:- 
# xdslcmd info --pbParams xdslcmd: ADSL driver and PHY status
Status: ShowtimeRetrain Reason: 0
Max:    Upstream rate = 5961 Kbps, Downstream rate = 31052 KbpsPath:   0, Upstream rate = 5679 Kbps, Downstream rate = 27942 Kbps
 Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783) DS: (32,859) (1216,1963) (2792,3939) 
Medley Phase (Final) Band PlanUS: (0,95) (868,1207) 
DS: (32,859) (1216,1963)        VDSL Port Details       Upstream        Downstream
Attainable Net Data Rate:       5961 kbps         31052 kbpsActual Aggregate Tx Power:        6.3 dBm          12.1 dBm
============================================================================  VDSL Band Status        U0      U1      U2      U3      D1      D2      D3
  Line Attenuation(dB):  8.2     53.5    64.1     N/A    21.9    63.8    70.0   Signal Attenuation(dB):  14.2    52.2     N/A     N/A    21.9    63.8     N/A   
        SNR Margin(dB):  6.6     6.8      N/A     N/A    4.8     4.8      N/A            TX Power(dBm): -4.4     5.9      N/A     N/A    11.1    5.3      N/A



Paul

EDIT:
I just realised that I mis-read your stats as I can see that your DS SNRM is not that much higher than mine after all.


http://www.speedtest.net/result/1634854999.png

Edited by Bald_Eagle1 (Wed 07-Dec-11 12:27:01)

Standard User reddev86
(regular) Wed 07-Dec-11 12:23:10
Print Post

Re: SNRM & Error levels


[re: Bald_Eagle1] [link to this post]
 
In reply to a post by Bald_Eagle1:
I see your SNRM levels are much higher though, which MAY suggest your connection is being speed capped by Plusnet and/or BT (intentionally or not).
That's understandable for the US being capped at 2 Mb, but it doesn't really explain the high SNRM level for your DS.


Maybe i've read his stats wrong, but I see a SNRM of 5.4dB for his DS, which is close enough to the target margin of 6dB. His US SNRM is high because it is capped to 2Meg sync on Plusnet, when attainable is 6meg. Both my US and DS SNRMs are very high, because upload sync is capped to 2meg, and download is still capped to the 40, when my attainable is around 10 meg up and 55 down.

Edit: I see you discovered your error tongue

In reply to a post by Bald_Eagle1:
I am aware of an ongoing Plusnet investigation into how successful (or not) their own profiling system is in actual operation. Some users have been moved back up to a Plusnet profile of 37 Mb, & their actual sync & download speeds have suffered as a consequence.


I am one of those people. My IP profile is 38717, syncing at the full 39999k. Plusnet profile is 37Meg. I don't know why they use 37meg, when i've seen plenty of people (including myself) getting more than that on the 38717 profile.

My throughput is actually closer to 34.5Meg, yet when my PN profile was incorrect, I achieved 37.5Meg constantly. I think they are still investigating the issue.

FTTC via Plusnet Fibre Extra Pro
DS: 39999 US: capped to 2000
NILN exchange - 550m from cabinet
Netgear WNR1000

Edited by reddev86 (Wed 07-Dec-11 12:24:09)

Standard User Bald_Eagle1
(regular) Wed 07-Dec-11 12:41:28
Print Post

Re: SNRM & Error levels


[re: reddev86] [link to this post]
 
In reply to a post by reddev86:
Edit: I see you discovered your error tongue


Speaking of errors:-

"As a comparison, would you mind posting the DSL Up time, SNRM, & error levels as reported for your own connections, along with an estimation of your D-side line length?"

I'm building up a mini database of Errors vs Connection up time, SNRM & line length stats.
It may be a complete waste of time, although it COULD just be useful for me (& others) in prompting investigations via BT and/or ISPs, using data they apparently don't otherwise see.


Paul.
Standard User RobertoS
(sensei) Wed 07-Dec-11 12:59:36
Print Post

Re: SNRM & Error levels


[re: Bald_Eagle1] [link to this post]
 
It works for me if I start of by typing "[c o d e]" then pasting in the text, & finishing it off with "[/ c o d e]" (omitting the spaces & speech marks, but retaining the square brackets).
I use "pre" as I discovered it before "code".

Tip to Mike smile. Any posting method you don't know how it is done, if you click the Quote button of the post containing it you get to see what was actually typed to achieve it smile. More usefully, that is also the way to copy a link from a post, as the full link is there whereas the visible bit in the post itself is a truncated "text" for the link so doesn't work.

My broadband basic info/help site - www.robertos.me.uk
My domains,website and mail hosting - Tsohost. Internet connection - IDNet Home Starter Fibre. Live BQM.

"Where talent is a dwarf, self-esteem is a giant." - Jean-Antoine Petit-Senn.
Standard User mikecrawford80
(regular) Wed 07-Dec-11 13:35:14
Print Post

Re: SNRM & Error levels


[re: RobertoS] [link to this post]
 
Ahh, thanks for the tips, you're never to old to learn something every day smile

Plusnet Extra Fibre
September 2011 Speedtest ...
Standard User griff_90
(fountain of knowledge) Wed 07-Dec-11 18:46:16
Print Post

Re: SNRM & Error levels


[re: XRaySpeX] [link to this post]
 
In reply to a post by XRaySpeX:
That's an invalid comparison with another line that has massive noise issues, witnessed by:
DS SNRM = 22.4 dB


The SNR isn't high because of "massive noise issues" it's high because that line is now on 17a and the attainable rate has increased while the actual line rate remains capped at 40Mbps. Obviously the SNR is going to increase as a result.

My own SNR margin has gone from 6.4dB on 8c to 22.7dB on 17a. Once the 80/20 product launches (and the artificial 40Mbps rate is lifted) then line rates will increase and the SNRM will decrease accordingly.

Edited by griff_90 (Wed 07-Dec-11 18:50:59)

Standard User XRaySpeX
(eat-sleep-adslguide) Wed 07-Dec-11 23:43:35
Print Post

Re: SNRM & Error levels


[re: griff_90] [link to this post]
 
If you scroll back you will see that I subsequently realised this fact once I had been given the relevant data.

GIGO grin!

1999: Freeserve 48K Dial-Up => 2005: Wanadoo 1 Meg BB => 2007: Orange 2 Meg BB => 2008: Orange 8 Meg LLU => 2010: Orange 16 Meg LLU => 2011: Orange 19 Meg WBC
Standard User BatBoy
(legend) Wed 07-Dec-11 23:59:43
Print Post

Re: SNRM & Error levels


[re: XRaySpeX] [link to this post]
 
It should be obvious the SNR will be high when the signal is high, and low when the noise is high.



______________________________________________________________________________. __________________
Standard User XRaySpeX
(eat-sleep-adslguide) Thu 08-Dec-11 00:11:54
Print Post

Re: SNRM & Error levels


[re: BatBoy] [link to this post]
 
What high signal?

1999: Freeserve 48K Dial-Up => 2005: Wanadoo 1 Meg BB => 2007: Orange 2 Meg BB => 2008: Orange 8 Meg LLU => 2010: Orange 16 Meg LLU => 2011: Orange 19 Meg WBC
Standard User RobertoS
(sensei) Thu 08-Dec-11 00:14:24
Print Post

Re: SNRM & Error levels


[re: BatBoy] [link to this post]
 
In reply to a post by BatBoy:
It should be obvious the SNR will be high when the signal is high, and low when the noise is high.
Ummmm. Something of a lack of clarity there.

Definitions of "signal" and "noise" and even "SNR" for this context might help. A simplistic view could be that if the signal is doubled and the noise is doubled, the SNR will be unchanged. The same could be said of the SNRM.

My broadband basic info/help site - www.robertos.me.uk
My domains,website and mail hosting - Tsohost. Internet connection - IDNet Home Starter Fibre. Live BQM.

"Where talent is a dwarf, self-esteem is a giant." - Jean-Antoine Petit-Senn.
Standard User BatBoy
(legend) Thu 08-Dec-11 00:29:20
Print Post

Re: SNRM & Error levels


[re: RobertoS] [link to this post]
 
It's a ratio.



______________________________________________________________________________. __________________
Standard User XRaySpeX
(eat-sleep-adslguide) Thu 08-Dec-11 01:01:24
Print Post

Re: SNRM & Error levels


[re: RobertoS] [link to this post]
 
Clarity! Context! Getting blood out of a stone?

1999: Freeserve 48K Dial-Up => 2005: Wanadoo 1 Meg BB => 2007: Orange 2 Meg BB => 2008: Orange 8 Meg LLU => 2010: Orange 16 Meg LLU => 2011: Orange 19 Meg WBC
Standard User XRaySpeX
(eat-sleep-adslguide) Thu 08-Dec-11 01:03:01
Print Post

Re: SNRM & Error levels


[re: BatBoy] [link to this post]
 
More's the pity you are not as rational as it.

1999: Freeserve 48K Dial-Up => 2005: Wanadoo 1 Meg BB => 2007: Orange 2 Meg BB => 2008: Orange 8 Meg LLU => 2010: Orange 16 Meg LLU => 2011: Orange 19 Meg WBC
Standard User RobertoS
(sensei) Thu 08-Dec-11 18:59:35
Print Post

Re: SNRM & Error levels


[re: BatBoy] [link to this post]
 
In reply to a post by BatBoy:
It's a ratio.
What is? SNR is. Signal is not, and neither is noise. "It should be obvious the SNR will be high when the signal is high, and low when the noise is high" is junk.

My broadband basic info/help site - www.robertos.me.uk
My domains,website and mail hosting - Tsohost. Internet connection - IDNet Home Starter Fibre. Live BQM.

"Where talent is a dwarf, self-esteem is a giant." - Jean-Antoine Petit-Senn.
Standard User burakkucat
(committed) Thu 08-Dec-11 19:17:30
Print Post

Re: SNRM & Error levels


[re: BatBoy] [link to this post]
 
In reply to a post by BatBoy:
It's a ratio.
Try this.

-----------------------------------------------------

100% Linux and, previously, Unix.
Standard User BatBoy
(legend) Thu 08-Dec-11 19:18:48
Print Post

Re: SNRM & Error levels


[re: RobertoS] [link to this post]
 
It's all explained here http://www.robertos.me.uk/html/noise_margin-snr-snrm...



______________________________________________________________________________. __________________
Standard User BatBoy
(legend) Thu 08-Dec-11 19:22:12
Print Post

Re: SNRM & Error levels


[re: burakkucat] [link to this post]
 
In reply to a post by burakkucat:
In reply to a post by BatBoy:
It's a ratio.
Try this.
Try this.



______________________________________________________________________________. __________________
Standard User XRaySpeX
(eat-sleep-adslguide) Thu 08-Dec-11 20:00:27
Print Post

Re: SNRM & Error levels


[re: burakkucat] [link to this post]
 
He's taken it so often that his immune system is resistant to it.

1999: Freeserve 48K Dial-Up => 2005: Wanadoo 1 Meg BB => 2007: Orange 2 Meg BB => 2008: Orange 8 Meg LLU => 2010: Orange 16 Meg LLU => 2011: Orange 19 Meg WBC
Standard User RobertoS
(sensei) Fri 09-Dec-11 10:07:20
Print Post

Re: SNRM & Error levels


[re: BatBoy] [link to this post]
 
In reply to a post by BatBoy:
It's all explained here http://www.robertos.me.uk/html/noise_margin-snr-snrm...
Exactly smile. Assuming you accept that explanation you inevitably have to accept that your initial statement was junk.

My broadband basic info/help site - www.robertos.me.uk
My domains,website and mail hosting - Tsohost. Internet connection - IDNet Home Starter Fibre. Live BQM.

"Where talent is a dwarf, self-esteem is a giant." - Jean-Antoine Petit-Senn.
Moderator Sadoldman
(moderator) Fri 09-Dec-11 10:41:05
Print Post

Re: SNRM & Error levels


[re: BatBoy] [link to this post]
 
I see this as you trolling and little else.

Not sure why you feel the need to attention seek like this, desist this constant belligerent approach or you will get my attention.

To others...if you see it as trolling...ignore.

Sadoldman

Just a tad sad..a wee bit old...wink

[email protected]
The author of the above post is a thinkbroadband moderator but it does not constitute an official statement on behalf of thinkbroadband.
Standard User BatBoy
(legend) Fri 09-Dec-11 19:22:40
Print Post

Re: SNRM & Error levels


[re: RobertoS] [link to this post]
 
In reply to a post by RobertoS:
In reply to a post by BatBoy:
It's all explained here http://www.robertos.me.uk/html/noise_margin-snr-snrm...
Exactly smile. Assuming you accept that explanation you inevitably have to accept that your initial statement was junk.
No, not at all. I see it as spot-on.



______________________________________________________________________________. __________________
Standard User BatBoy
(legend) Fri 09-Dec-11 19:22:45
Print Post

Re: SNRM & Error levels


[re: Sadoldman] [link to this post]
 
In reply to a post by Sadoldman:
I see this as you trolling and little else.

Not sure why you feel the need to attention seek like this, desist this constant belligerent approach or you will get my attention.

To others...if you see it as trolling...ignore.
Wrong. This is a troll http://forums.thinkbroadband.com/fibre/t/4072351-re-...



______________________________________________________________________________. __________________
Standard User BatBoy
(legend) Fri 09-Dec-11 19:22:53
Print Post

Re: SNRM & Error levels


[re: XRaySpeX] [link to this post]
 
In reply to a post by XRaySpeX:
What high signal?
The signal which is the "S" in SNR. It is high due to the profile change.



______________________________________________________________________________. __________________
Standard User woodyblade
(newbie) Fri 09-Dec-11 19:27:09
Print Post

Re: SNRM & Error levels


[re: Bald_Eagle1] [link to this post]
 
Managed to remember that some results wanted posting, this is after 68 hours uptime, looks like I've had more HEC errors than what I've seen before but less FEC errors.

Works out at 7/1 FEC errors per hour and 20/0 HEC errors per hour

Text
1
23
45
Downstream Upstream     
Line rate (kbit/s)        39998 10000CRC errors                   0      0 
FEC errors                 471     94 HEC errors                1338      0


These are the current SNRM values below, but these can vary between 14.5/22 - 17/23, meaning attainable rates of 68/25mbps - 78/27mbps.
I've even seen/caught the SNRM as high as 19.5/24 before which meant something around 88/29mbps as attainable rates.

Shame the line can't sustain these speeds constantly, or even that 78/27mbps one, mainly stays around that 68/25 range. Though I can't complain when the speed before on ADSL was 3/0.8mbps.

Text
1
23
45
67
89
1011
1213
1415
1617
1819
2021
xdslcmd: ADSL driver and PHY status
Status: ShowtimeRetrain Reason: 0
Max:    Upstream rate = 26974 Kbps, Downstream rate = 78428 KbpsPath:   0, Upstream rate = 10000 Kbps, Downstream rate = 39998 Kbps
 Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783)DS: (32,859) (1216,1963) (2792,3939)
Medley Phase (Final) Band PlanUS: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3939)       VDSL Port Details       Upstream        Downstream
Attainable Net Data Rate:      26974 kbps         78428 kbpsActual Aggregate Tx Power:        6.9 dBm          13.4 dBm
============================================================================  VDSL Band Status        U0      U1      U2      U3      D1      D2      D3
  Line Attenuation(dB):  4.6     21.9    31.4     N/A    11.7    27.0    41.1Signal Attenuation(dB):  8.1     21.4    30.2     N/A    11.7    27.0    41.1
        SNR Margin(dB):  22.4    21.9    22.8     N/A    17.5    17.8    17.6         TX Power(dBm): -4.1    -24.8    6.4      N/A    10.8    7.6     6.0
Standard User XRaySpeX
(eat-sleep-adslguide) Fri 09-Dec-11 19:58:42
Print Post

Re: SNRM & Error levels


[re: BatBoy] [link to this post]
 
In reply to a post by BatBoy:
In reply to a post by XRaySpeX:
What high signal?
The signal which is the "S" in SNR. It is high due to the profile change.
What profile change? If you mean the one mentioned by bhawkes, it was made the day after I made & withdrew my comment about the high SNRM when you had no inkling of any profile change.

It's easy to be "wise" after the event, particularly when you are talking out of your blowhole.

1999: Freeserve 48K Dial-Up => 2005: Wanadoo 1 Meg BB => 2007: Orange 2 Meg BB => 2008: Orange 8 Meg LLU => 2010: Orange 16 Meg LLU => 2011: Orange 19 Meg WBC
Standard User BatBoy
(legend) Fri 09-Dec-11 20:11:29
Print Post

Re: SNRM & Error levels


[re: XRaySpeX] [link to this post]
 
In reply to a post by XRaySpeX:
In reply to a post by BatBoy:
In reply to a post by XRaySpeX:
What high signal?
The signal which is the "S" in SNR. It is high due to the profile change.
What profile change? If you mean the one mentioned by bhawkes, it was made the day after I made & withdrew my comment about the high SNRM when you had no inkling of any profile change.

It's easy to be "wise" after the event, particularly when you are talking out of your blowhole.
Don't worry, I know all about the profile change as I am on Fibre, unlike you who is on ADSL? Dial-up? who knows...



______________________________________________________________________________. __________________
Standard User Bald_Eagle1
(regular) Fri 09-Dec-11 20:55:13
Print Post

Re: SNRM & Error levels


[re: woodyblade] [link to this post]
 
In reply to a post by woodyblade:
Managed to remember that some results wanted posting, this is after 68 hours uptime, looks like I've had more HEC errors than what I've seen before but less FEC errors.

Works out at 7/1 FEC errors per hour and 20/0 HEC errors per hour

Text
1
23
45
Downstream Upstream     
Line rate (kbit/s)        39998 10000CRC errors                   0      0 
FEC errors                 471     94 HEC errors                1338      0


Thanks for that woodyblade


Paul.
Standard User WWWombat
(committed) Sun 11-Dec-11 14:04:29
Print Post

Re: SNRM & Error levels


[re: Bald_Eagle1] [link to this post]
 
In reply to a post by Bald_Eagle1:
From the unlocked HG612 modem's GUI, these are my current details:-


In case anyone is still listening to the real thread, rather than arguing over the meaning of SNR, I've come across something of a hitch...

That is that the HG612 is not reporting error data consistently!

As far as I can make out, the GUI reports CRC, FEC and HEC by taking values from the "xdslcmd info --show" command, extracting the data as follows:

- CRC comes from the "RSUnCorr" field
- FEC comes from the "OHFErr" field (I have no idea what this is. Some kind of framing error?)
- HEC comes from the "HEC" field

However, the "xdslcmd info --stats" command gives different information (but is not quite correct about some of the presentation).

The last section of the "stats" is labelled "Since Link Time" (in my case, currently 14 days), and gives FEC, CRC and ES values that I can believe. These seem to be the statistics since the last synchronisation.

The prior 4 sections of stats give the stats for smaller, more recent periods (days and 15 mins). They too look consistent.

The prior section (labelled "Total Time") also gives statistics that i believe are valid since the modem was last booted. However, it then goes on to display a time that patently *isn't* the total time the the modem has been on - but the corresponding statistics do seem to represent the full set. In my case, the full uptime is just over 16 days, the "total time" is reported as just over a day, but the numbers in the statistics are higher than the later "14 day" numbers. In fact, the numbers I see *do* reflect the burst of errors I got in the 1st 2 days, which cause DLM to resync me with interleaving... which resulted in far fewer CRC errors (and ES) and far higher FEC.

So which numbers should we believe?

Here are my numbers from the different sources:
GUI
Text
1
23
45
67
89
1011
DSL up time                  1229823  (14 days 05:37:03)
 Attainable rate (kbit/s)       59256     16780
SNR margin (dB)                 10.1      11.3Line attenuation (dB)              0         0
Output power (dBmV)             12.3       6.6 
Line rate (kbit/s)             39996     10000 CRC errors                     11155         0
FEC errors                       331       288HEC errors                      2987         0


xdslcmd info --show
Text
1
23
45
67
89
1011
1213
1415
1617
1819
2021
2223
2425
2627
2829
3031
3233
3435
3637
3839
4041
4243
4445
4647
4849
5051
5253
5455
5657
58
# xdslcmd info --show
xdslcmd: ADSL driver and PHY statusStatus: Showtime
Retrain Reason: 2Max:    Upstream rate = 16758 Kbps, Downstream rate = 59256 Kbps
Path:   0, Upstream rate = 10000 Kbps, Downstream rate = 39996 Kbps 
Link Power State:       L0Mode:                   VDSL2 Annex B
VDSL2 Profile:          Profile 17aTPS-TC:                 PTM Mode
Trellis:                U:ON /D:ONLine Status:            No Defect
Training Status:        Showtime                Down            Up
SNR (dB):        10.1            11.3Attn(dB):        0.0             0.0
Pwr(dBm):        12.3            6.6                        VDSL2 framing
                        Path 0B:              57              111
M:              1               2T:              64              50
R:              16              16S:              0.0461          0.7101
L:              12835           2704D:              701             1
I:              74              120N:              74              240
                        Counters                        Path 0
OHF:            553649999               656045OHFErr:         331             288
RS:             3221633228              3957556RSCorr:         6819414         1551
RSUnCorr:       11155           0 
                        Path 0HEC:            2987            0
OCD:            0               0LCD:            0               0
Total Cells:    140396837               0Data Cells:     453789795               0
Drop Cells:     0Bit Errors:     0               0
 ES:             6235            302
SES:            8               0UAS:            35              35
AS:             1230559 
                        Path 0INP:            3.00            0.00
PER:            2.21            8.87delay:          8.00            0.00
OR:             86.72           55.88 
Bitswap:        33420           10345


xdslcmd info --stats
Text
1
23
45
67
89
1011
1213
1415
1617
1819
2021
2223
2425
2627
2829
3031
3233
3435
3637
3839
4041
4243
4445
4647
4849
5051
5253
5455
5657
5859
6061
6263
6465
6667
6869
7071
7273
7475
7677
7879
8081
8283
8485
8687
8889
9091
9293
9495
9697
9899
100101
102103
104105
106107
# xdslcmd info --stats
xdslcmd: ADSL driver and PHY statusStatus: Showtime
Retrain Reason: 2Max:    Upstream rate = 16780 Kbps, Downstream rate = 59256 Kbps
Path:   0, Upstream rate = 10000 Kbps, Downstream rate = 39996 Kbps 
Link Power State:       L0Mode:                   VDSL2 Annex B
VDSL2 Profile:          Profile 17aTPS-TC:                 PTM Mode
Trellis:                U:ON /D:ONLine Status:            No Defect
Training Status:        Showtime                Down            Up
SNR (dB):        10.1            11.3Attn(dB):        0.0             0.0
Pwr(dBm):        12.3            6.6                        VDSL2 framing
                        Path 0B:              57              111
M:              1               2T:              64              50
R:              16              16S:              0.0461          0.7101
L:              12835           2704D:              701             1
I:              74              120N:              74              240
                        Counters                        Path 0
OHF:            553684194               664617OHFErr:         331             288
RS:             3228198526              91119RSCorr:         6819524         1551
RSUnCorr:       11155           0 
                        Path 0HEC:            2987            0
OCD:            0               0LCD:            0               0
Total Cells:    146241308               0Data Cells:     453791806               0
Drop Cells:     0Bit Errors:     0               0
 ES:             6235            302
SES:            8               0UAS:            35              35
AS:             1230635 
                        Path 0INP:            3.00            0.00
PER:            2.21            8.87delay:          8.00            0.00
OR:             86.72           55.88 
Bitswap:        33420           10345 
Total time = 1 days 2 hours 5 min 24 secFEC:            6819524         1703
CRC:            331             329ES:             6235            302
SES:            8               0UAS:            35              35
LOS:            5               0LOF:            5               0
Latest 15 minutes time = 5 min 24 secFEC:            435             0
CRC:            0               0ES:             0               0
SES:            0               0UAS:            0               0
LOS:            0               0LOF:            0               0
Previous 15 minutes time = 15 min 0 secFEC:            1104            1
CRC:            0               1ES:             0               1
SES:            0               0UAS:            0               0
LOS:            0               0LOF:            0               0
Latest 1 day time = 2 hours 5 min 24 secFEC:            11260           12
CRC:            0               3ES:             0               3
SES:            0               0UAS:            0               0
LOS:            0               0LOF:            0               0
Previous 1 day time = 24 hours 0 secFEC:            403855          111
CRC:            35              21ES:             11              21
SES:            0               0UAS:            0               0
LOS:            0               0LOF:            0               0
Since Link time = 14 days 5 hours 50 min 35 secFEC:            6819524         1551
CRC:            331             288ES:             114             263
SES:            0               0UAS:            0               0
LOS:            0               0LOF:            0               0


I always thought "FEC" statistics were the same as "RSCorr". These are the number of RS blocks that could be corrected by the FEC process, so are a count of teh number of correctable errors encountered. In ADSL, FEC is turned off when interleaving is off - so FEC would be zero. I guess FTTC/VDSL2 is the same.

I also always thought that the "RSUncorr" were the errors (uncorrectable by the FEC process) that therefore caused both CRC and HEC. However, RS blocks occur at a far greater rate than the CRC blocks, so you expect RSUnCorr to be the maximum of CRC+HEC. If RSUnCorr errors happen in bursts, then you might even expect 1 CRC (or HEC) per 16 RSUnCorr; if the RSUnCorr occur in a very spread-out fashion, then you'd get 1 CRC (or HEC) per RSUnCorr.

Looking at the overall output, I think the GUI ought to be reporting these values (or something like them):
CRC: 331
FEC: 6819524
HEC: 2987

However, I'm not fully convinced about the "CRC" figure here. I would have to monitor for longer.

I'm a little busy at the moment, so if I don't immediately answer any responses, you'll know why wink
Standard User mikecrawford80
(regular) Sun 11-Dec-11 14:33:20
Print Post

Re: SNRM & Error levels


[re: WWWombat] [link to this post]
 
Hmm, interesting point. Here's my output for contrast and compare;

GUI
Text
1
23
45
67
89
1011
DSL up time     2088000   (24 days 04:00:00)
 Attainable rate (kbit/s)    26420     6169
SNR margin (dB)               5.3     15.1Line attenuation (dB)           0        0
Output power (dBmV)          12.4     -1.9 
Line rate (kbit/s)          27399     1999CRC errors                      0        0
FEC errors                  51550        9HEC errors                  98169        0



xdslcmd info --show
Text
1
23
45
67
89
1011
1213
1415
1617
1819
2021
2223
2425
2627
2829
3031
3233
3435
3637
3839
4041
4243
4445
4647
4849
5051
5253
5455
5657
58
# xdslcmd info --show
xdslcmd: ADSL driver and PHY statusStatus: Showtime
Retrain Reason: 0Max:    Upstream rate = 6183 Kbps, Downstream rate = 26420 Kbps
Path:   0, Upstream rate = 1999 Kbps, Downstream rate = 27399 Kbps 
Link Power State:       L0Mode:                   VDSL2 Annex B
VDSL2 Profile:          Profile 17aTPS-TC:                 PTM Mode
Trellis:                U:ON /D:ONLine Status:            No Defect
Training Status:        Showtime                Down            Up
SNR (dB):        5.3             15.1Attn(dB):        0.0             0.0
Pwr(dBm):        12.5           -1.9                        VDSL2 framing
                        Path 0B:              239             31
M:              1               2T:              64              36
R:              0               16S:              0.2787          0.9922
L:              6889            645D:              1               1
I:              240             80N:              240             80
                        Counters                        Path 0
OHF:            466307980               537260OHFErr:         51542           9
RS:             0               1158332RSCorr:         0               37
RSUnCorr:       0               0 
                        Path 0HEC:            98158           0
OCD:            0               0LCD:            0               0
Total Cells:    2489088163              0Data Cells:     1013536711              0
Drop Cells:     0Bit Errors:     0               0
 ES:             21050           9
SES:            138             0UAS:            17              17
AS:             2087571 
                        Path 0INP:            0.00            0.00
PER:            4.45            13.39delay:          0.00            0.00
OR:             50.23           57.33 
Bitswap:        393769          19555


xdslcmd info --stats
Text
1
23
45
67
89
1011
1213
1415
1617
1819
2021
2223
2425
2627
2829
3031
3233
3435
3637
3839
4041
4243
4445
4647
4849
5051
5253
5455
5657
5859
6061
6263
6465
6667
6869
7071
7273
7475
7677
7879
8081
8283
8485
8687
8889
9091
9293
9495
9697
9899
100101
102103
104105
106107
# xdslcmd info --stats
xdslcmd: ADSL driver and PHY statusStatus: Showtime
Retrain Reason: 0Max:    Upstream rate = 6183 Kbps, Downstream rate = 26420 Kbps
Path:   0, Upstream rate = 1999 Kbps, Downstream rate = 27399 Kbps 
Link Power State:       L0Mode:                   VDSL2 Annex B
VDSL2 Profile:          Profile 17aTPS-TC:                 PTM Mode
Trellis:                U:ON /D:ONLine Status:            No Defect
Training Status:        Showtime                Down            Up
SNR (dB):        5.3             15.1Attn(dB):        0.0             0.0
Pwr(dBm):        12.4           -1.9                        VDSL2 framing
                        Path 0B:              239             31
M:              1               2T:              64              36
R:              0               16S:              0.2787          0.9922
L:              6889            645D:              1               1
I:              240             80N:              240             80
                        Counters                        Path 0
OHF:            466308426               537414OHFErr:         51542           9
RS:             0               1166636RSCorr:         0               37
RSUnCorr:       0               0 
                        Path 0HEC:            98158           0
OCD:            0               0LCD:            0               0
Total Cells:    2489193423              0Data Cells:     1013536737              0
Drop Cells:     0Bit Errors:     0               0
 ES:             21050           9
SES:            138             0UAS:            17              17
AS:             2087573 
                        Path 0INP:            0.00            0.00
PER:            4.45            13.39delay:          0.00            0.00
OR:             50.23           57.33 
Bitswap:        393769          19555 
Total time = 1 days 3 hours 53 min 10 secFEC:            0               0
CRC:            51542           0ES:             21050           9
SES:            138             0UAS:            17              17
LOS:            0               0LOF:            0               0
Latest 15 minutes time = 8 min 10 secFEC:            0               0
CRC:            6               0ES:             6               0
SES:            0               0UAS:            0               0
LOS:            0               0LOF:            0               0
Previous 15 minutes time = 15 min 0 secFEC:            0               0
CRC:            17              0ES:             16              0
SES:            0               0UAS:            0               0
LOS:            0               0LOF:            0               0
Latest 1 day time = 3 hours 53 min 10 secFEC:            0               0
CRC:            933             0ES:             171             0
SES:            4               0UAS:            0               0
LOS:            0               0LOF:            0               0
Previous 1 day time = 24 hours 0 secFEC:            0               0
CRC:            5930            0ES:             1171            0
SES:            28              0UAS:            0               0
LOS:            0               0LOF:            0               0
Since Link time = 24 days 3 hours 52 min 53 secFEC:            0               37
CRC:            51542           9ES:             21050           9
SES:            138             0UAS:            0               0
LOS:            0               0LOF:            0               0


So that means

CRC = 51542
FEC = 0 (interleaving off?)
HEC = 98158

Plusnet Extra Fibre (with PRO add-on)
My Broadband Ping
Standard User Bald_Eagle1
(regular) Sun 11-Dec-11 15:09:02
Print Post

Re: SNRM & Error levels


[re: WWWombat] [link to this post]
 
Hi WWWombat & mikecrawford80,

In reply to a post by WWWombat:
In case anyone is still listening to the real thread, rather than arguing over the meaning of SNR, I've come across something of a hitch...

That is that the HG612 is not reporting error data consistently!

As far as I can make out, the GUI reports CRC, FEC and HEC by taking values from the "xdslcmd info --show" command, extracting the data as follows:


I have very recently been corresponding with asbokid regarding these "discrepancies"

From my own findings, it would appear that the GUI uses the data from the URL
http://192.168.1.1/html/status/xdslStatus.asp

Exactly how it gets there is a little bit of a mystery at this time - possibly via a bit of "secret" Broadcom PHP coding, not revealed in Huawei's recent publication of their "open source licence" code.

This detail in turn (via Javascript) posts it to this URL
http://192.168.1.1/html/status/xdslStatus.gz.html

which is one of the frames displayed in the GUI at the normal user URL of
http://192.168.1.1/html/content.asp



So which numbers should we believe?


That's a really good question, to which there is currently no confirmed answer.

asbo believes there may be a number of bugs in the Broadcom software, the observations above being just some of them.

So to examine the scripts in xdslStatus.asp it appears you would need to get into the Huawei's root file system.
I think you will need Linux here to be able to unsquash the Huawei's root file system on your PC.

I only use Windows, so I don't have access to the required tools.

I too experienced a whole bunch of errors from around 18:30 yesterday, accumulating to over 1.5 Million CRC errors by the early hours of this morning.
I had only been connected for around 47 hours.

At that point, my connection gave up the ghost & re-synced "on the fly".
This "on the fly" event will NOT be seen in my ISP's logs & the dynamically allocated IP address was retained.

The end result for me is that my ever increasing error count has slowed down (a bit), but my SNRM levels have increased & my DS Sync rate has decreased.


Paul.

Edited by Bald_Eagle1 (Sun 11-Dec-11 15:19:08)

Standard User WWWombat
(committed) Sun 11-Dec-11 15:09:35
Print Post

Re: SNRM & Error levels


[re: mikecrawford80] [link to this post]
 
Yes. Seems much more likely that, after 24 days, for you to have zero FEC (because no interleaving) than zero CRC.

Your RS counts seem to be zero, which also goes to confirm that there is no FEC process going on.
Standard User WWWombat
(committed) Sun 11-Dec-11 15:15:33
Print Post

Re: SNRM & Error levels


[re: Bald_Eagle1] [link to this post]
 
I agree - that little ASP scriptlet is probably to blame for the GUI errors.

Are you still using that in your scripts, or have you swapped to getting data from the xdslcmd output?
Standard User Bald_Eagle1
(regular) Sun 11-Dec-11 15:25:03
Print Post

Re: SNRM & Error levels


[re: WWWombat] [link to this post]
 
Hi WWWombat,

In reply to a post by WWWombat:
I agree - that little ASP scriptlet is probably to blame for the GUI errors.

Are you still using that in your scripts, or have you swapped to getting data from the xdslcmd output?



Yes, I'm still using it, but only because it is what is also reported in the GUI (for some sort of consistency), & because we don't yet know for sure which data to use.

Paul.

Edit:
Latest 4 day statswas the FEC or HEC errors, so maybe it is the data as reported in the GUI that is correct after all?


FWIW these are my latest 4 days stats graphs:-

Latest 4 day stats

Edited by Bald_Eagle1 (Sun 11-Dec-11 16:13:32)

Standard User RobertoS
(sensei) Sun 11-Dec-11 17:25:06
Print Post

Re: SNRM & Error levels


[re: WWWombat] [link to this post]
 
In reply to a post by WWWombat:
Yes. Seems much more likely that, after 24 days, for you to have zero FEC (because no interleaving) than zero CRC.

Your RS counts seem to be zero, which also goes to confirm that there is no FEC process going on.
IIRC the interleaving depths are shown on the "D:" line, with 1 meaning Fast Path. (1 means each cell is split across 1 packet - ie not interleaved).

701 in an earlier example is a strange number though.

My broadband basic info/help site - www.robertos.me.uk
My domains,website and mail hosting - Tsohost. Internet connection - IDNet Home Starter Fibre. Live BQM.

"Where talent is a dwarf, self-esteem is a giant." - Jean-Antoine Petit-Senn.
Standard User asbokid
(regular) Sun 11-Dec-11 18:19:34
Print Post

Re: SNRM & Error levels


[re: Bald_Eagle1] [link to this post]
 
Hi guys,

In reply to a post by Bald_Eagle1:
I think you will need Linux here to be able to unsquash the Huawei's root file system on your PC. I only use Windows, so I don't have access to the required tools.

There is a Win32 build [1] of the squashfs-tools developed by Phillip Lougher [2].

The Win32 tools were compiled by Nikolay Pelov. Pelov included the unofficial LZMA patch used by Broadcom to build the root file system in the 6368 firmware.

The unsquashfs tool for win32 appears to work fine.

However, the corresponding mksquashfs tool will not work. It seems that Broadcom changed the mksquashfs tool in the toolchain used to build the squashfs file system in the Huawei. [3]

To date, the Corporation has not released the modifications it made to Lougher's GPL'ed source code for squashfs-tools.

At least it's possible to unsquash and examine the Huawei's root file system in Windows, even if it can't be modified and rebuilt without using Linux.

The embedded web server in the Huawei looks like Jef Poskanzer's mini-http [4].

The mini-httpd web server has been patched to use a packed web image, and to support server-side scripting. The source code for those modules does not seem available.


cheers, a

[1] http://www.slax.org/forum.php?action=view&parentID=2...
[2] http://squashfs.sourceforge.net/
[3] http://code.google.com/p/firmware-mod-kit/issues/det...
[4] http://acme.com/software/mini_httpd/

Edited by asbokid (Sun 11-Dec-11 19:10:54)

Standard User XRaySpeX
(eat-sleep-adslguide) Sun 11-Dec-11 18:22:15
Print Post

Re: SNRM & Error levels - EDITED


[re: WWWombat] [link to this post]
 
In reply to a post by WWWombat:
As far as I can make out, the GUI reports CRC, FEC and HEC by taking values from the "xdslcmd info --show" command, extracting the data as follows:

- CRC comes from the "RSUnCorr" field
- FEC comes from the "OHFErr" field (I have no idea what this is. Some kind of framing error?)
- HEC comes from the "HEC" field
The GUI is confusing the CRC and FEC type errors. They should be obtained as follows:
  • CRC from the "OHFErr" field; often called "SFErr" with many routers
  • FEC from the "RSCorr" field and is 0 when on Fast Path (D=1)
  • HEC from the "HEC" field
Always believe the xdslcmd results.

BTW: The total time since the last reboot, to which all the counts relate, is given by the AS field.

EDIT: You're right! FEC should be the "RSCorr" field. I was forgetting as mine's on Fast Path.

1999: Freeserve 48K Dial-Up => 2005: Wanadoo 1 Meg BB => 2007: Orange 2 Meg BB => 2008: Orange 8 Meg LLU => 2010: Orange 16 Meg LLU => 2011: Orange 19 Meg WBC

Edited by XRaySpeX (Mon 12-Dec-11 05:36:30)

Standard User john2007
(legend) Sun 11-Dec-11 18:32:54
Print Post

Re: SNRM & Error levels


[re: XRaySpeX] [link to this post]
 
I guess RS means Reed-Solomon, the algorithm used in Forward Error Correction.

Most routers seem to use RSCorr for the FEC count (the count of packets with errors which were successfully corrected with the Reed-Solomon algorithm) and RSUnCorr for the CRC count (the packet was too severely damaged to correct and so fails the CRC).
Standard User WWWombat
(committed) Sun 11-Dec-11 20:26:07
Print Post

Re: SNRM & Error levels


[re: XRaySpeX] [link to this post]
 
As an aside, I thought HEC errors were errors detected within the header at an ATM level, while CRC errors were detected from the blocks within the ATM payload. Given there is no ATM here, I'm obviously wrong. Can anyone say what it is?
Standard User Bald_Eagle1
(regular) Sun 11-Dec-11 23:14:55
Print Post

Re: SNRM & Error levels


[re: WWWombat] [link to this post]
 
Right Folks,

To help me try to understand what is what, I needed to put the relevant data into one table. I ran the xdsl info --show & xdslcmd info --stats commands as close to each other as possible & grabbed a GUI screenshot a few seconds later:-

EDIT: I have only shown the DS data in the table as it seems to be the most relevant.

Text
1
23
45
67
89
1011
1213
1415
1617
1819
2021
2223
2425
2627
2829
3031
3233
3435
3637
3839
40
DESCRIPTION     info --show     info --stats    GUI
                        B:              31              31              N/A
M:              1               1               N/AT:              64              64              N/A
R:              12              12              N/AS:              0.0398          0.0398          N/A
L:              8834            8834            N/AD:              1637            1637            N/A
I:              44              44              N/AN:              44              44              N/A
                Counters                Path 0
OHF:            14469179        14469439        N/AOHFErr:         2967            2967            2967 (shown as FEC in the GUI)
RS:             1261294406      1261394391      N/ARSCorr:         35885878        35885879        N/A
RSUnCorr:       118032          118032          118032 (shown as CRC in the GUI) 
                Path 0HEC:            20937           20937           20937 (shown as HEC in the GUI)
OCD:            0               0               N/ALCD:            0               0               N/A
Total Cells:    2726621042      2726670109      N/AData Cells:     4525231         4525231         N/A
Drop Cells:     0               0               N/ABit Errors:     0               0               N/A
 ES:             22179           22179           N/A
SES:            62              62              N/AUAS:            48              48              N/A
AS:             55566           55567           55572 (shown as DSL up time) 
                Path 0INP:            8.50            8.5             N/A
PER:            3.820           3.82            N/Adelay:          16.00           16.00           N/A
OR:             50.19           50.19           N/A 
Bitswap:        11201           11202           N/A




As I only ever really want to know at a quick glance how my connection is performing since its most recent re-sync (NOT REBOOT), I have been referring to the GUI at http://192.168.1.1/html/content.asp

which uses the data as displayed at URL
http://192.168.1.1/html/status/xdslStatus.asp

As mentioned previously, I am currently using the data from this URL in my stats harvesting & graphing scripts.

One of my harvesting scripts maintains an ongoing stats log 24/7, with samples collected every minute, so I can always refer back to previous sync events & reboots if I ever need to.

The values all match exactly.

You will see from the above table that the GUI reports:-

OHFErr: as FEC Errors.
RSUnCorr: as CRC Errors.
HEC: as HEC Errors.

If any of you study the data from lower down the xdslcmd info --stats log, you will notice that Total time = 1 days 15 hours 1 min 40 sec NEVER exceeds 1 day.
I'm not quite sure what this Total time refers to as it doesn't seem to tie up with any other data.

Even lower down the xdslcmd info --stats log is this entry:-
Since Link time = 15 hours 26 min 7 sec.

From my ongoing log, I see that my connection re-synced at 05:43 this morning (to the nearest full minute).

As always, the error counts & the DSL up time as shown in the GUI were reset to ZEROS.

I ran the xdslcmd commands at 21:09 this evening.
Taking one from the other I get 15 hours & 26 minutes.

That's near enough for me to be equivalent to the data reported at the "Since Link time" entry to be the 55572 seconds DSL up time as reported in the GUI.

FYI, according to the Device GUI page, my modem had been connected for 2 days 14 hours 55 minutes & 47 seconds since its last REBOOT around the time I started pulling these details together.
According to my ongoing log & my memory, I rebooted the modem at 06:14 on 9th December.

Adding those timings together gets us to 21:09 this evening again.

So, we can also confirm that AS does NOT equate to the time since the latest REBOOT.


As I understand things (may be wrong though) CRC errors are uncorrectable.
This appears to be the RSUnCorr: data & also the CRC Errors data as reported in the GUI.

I don't know what OHFErr actually means, but it is the data reported as FEC Errors in the GUI.

HEC: exactly matches the HEC Errors as reported in the GUI.


So the question is:-

Is the GUI correctly reporting errrors after all or not?



Paul


EDIT:
RSCorr: for my connection was reported as 35885878.
Does that seem too much for a 15.5 hour connection for it to be FEC errors?

Edited by Bald_Eagle1 (Sun 11-Dec-11 23:22:13)

Standard User XRaySpeX
(eat-sleep-adslguide) Sun 11-Dec-11 23:59:09
Print Post

Re: SNRM & Error levels - EDITED x 2


[re: Bald_Eagle1] [link to this post]
 
In reply to a post by Bald_Eagle1:
This appears to be the RSUnCorr: data & also the CRC Errors data as reported in the GUI.
You will/should notice in the Since Link Time section of the xdslcmd info --stats log, which you didn't post, that CRC equates to the OHFErr field and FEC equates to the RSCorr field. Contradicts GUI interpretation!

Which is more likely to be correct, the primitive i/f or the high-level one?

EDIT: Your AS does indeed look like uptime since last resync. In which case the all the error counts would seem too high for that period, as you pointed out for RSCorr, and so must have been counted since last reboot. Even your ES are high at 1 every 2.5 secs. (confused but you stated error counts were zero at last resync 15 hours ago)

EDIT2: Just remembered, AS is uptime since last RESYNC. But my error counts are not zeroised at same time. So I have to keep remembering to look at GUI LAN uptime when analysing errors.

1999: Freeserve 48K Dial-Up => 2005: Wanadoo 1 Meg BB => 2007: Orange 2 Meg BB => 2008: Orange 8 Meg LLU => 2010: Orange 16 Meg LLU => 2011: Orange 19 Meg WBC

Edited by XRaySpeX (Mon 12-Dec-11 05:21:59)

Standard User Bald_Eagle1
(regular) Mon 12-Dec-11 00:41:08
Print Post

Re: SNRM & Error levels


[re: XRaySpeX] [link to this post]
 
In reply to a post by XRaySpeX:
You will/should notice in the Since Link Time section of the xdslcmd info --stats log, which you didn't post, that CRC equates to the OHFErr field and FEC equates to the RSCorr field. Contradicts GUI interpretation!

Which is more like to be correct, the primitive i/f or the high-level one?



I hadn't noticed the FEC from the Since Link Time section equating to the RSCorr field. Thanks for pointing that out.

However, in various other documents, I have read that RSUncorr is usually reported as CRC errors, not OHFErr.

I have been unable to determine anywhere what OHFErr actually means.

From higher up the log:-
OHFErr: 2967
RSCorr: 35885879
RSUnCorr: 118032

From the Since Link Time section
FEC: 35885879
CRC: 2967

I really don't know which is correct as there appear to be a few discrepancies.

The error counts as reported in the GUI were indeed set to zero.
I have seen them climb during the day.

So, maybe some of the stats from xdslcmd info --stats relate to the connection since re-sync & some of them relate to to the connection since reboot ???

My whole xdslcmd info --stats log:-

Text
1
23
45
67
89
1011
1213
1415
1617
1819
2021
2223
2425
2627
2829
3031
3233
3435
3637
3839
4041
4243
4445
4647
4849
5051
5253
5455
5657
5859
6061
6263
6465
6667
6869
7071
7273
7475
7677
7879
8081
8283
8485
8687
8889
9091
9293
9495
9697
9899
100101
102103
104105
106107
# xdslcmd info --stats 
xdslcmd: ADSL driver and PHY statusStatus: Showtime
Retrain Reason: 2Max:    Upstream rate = 5922 Kbps, Downstream rate = 31616 Kbps
Path:   0, Upstream rate = 5941 Kbps, Downstream rate = 25549 Kbps 
Link Power State:       L0Mode:                   VDSL2 Annex B
VDSL2 Profile:          Profile 17aTPS-TC:                 PTM Mode
Trellis:                U:ON /D:ONLine Status:            No Defect
Training Status:        Showtime                Down            Up
SNR (dB):        5.1             6.0Attn(dB):        0.0             0.0
Pwr(dBm):        12.1            6.3                        VDSL2 framing
                        Path 0B:              31              175
M:              1               1T:              64              40
R:              12              12S:              0.0398          0.9400
L:              8834            1600D:              1637            1
I:              44              94N:              44              188
                        Counters                        Path 0
OHF:            14469439                557050OHFErr:         2967            52
RS:             1261394391              214596RSCorr:         35885879                327
RSUnCorr:       118032          0 
                        Path 0HEC:            20937           0
OCD:            0               0LCD:            0               0
Total Cells:    2726670109              0Data Cells:     4525231         0
Drop Cells:     0Bit Errors:     0               0
 ES:             22179           120
SES:            62              0UAS:            48              48
AS:             55567 
                        Path 0INP:            8.50            0.00
PER:            3.82            9.40delay:          16.00           0.00
OR:             50.19           27.23 
Bitswap:        11202           1053 
Total time = 1 days 15 hours 1 min 40 secFEC:            69259181                671
CRC:            79524           157ES:             22179           120
SES:            62              0UAS:            48              48
LOS:            9               0LOF:            10              0
Latest 15 minutes time = 1 min 40 secFEC:            686             0
CRC:            0               0ES:             0               0
SES:            0               0UAS:            0               0
LOS:            0               0LOF:            0               0
Previous 15 minutes time = 15 min 0 secFEC:            144726          0
CRC:            311             0ES:             7               0
SES:            2               0UAS:            0               0
LOS:            0               0LOF:            0               0
Latest 1 day time = 15 hours 1 min 40 secFEC:            33408666                96
CRC:            2923            42ES:             166             30
SES:            15              0UAS:            0               0
LOS:            0               0LOF:            0               0
Previous 1 day time = 24 hours 0 secFEC:            33644772                451
CRC:            70179           65ES:             21820           46
SES:            22              0UAS:            16              16
LOS:            5               0LOF:            5               0
Since Link time = 15 hours 26 min 7 secFEC:            35885879                327
CRC:            2967            52ES:             193             31
SES:            15              0UAS:            0               0
LOS:            0               0LOF:            0               0
Standard User XRaySpeX
(eat-sleep-adslguide) Mon 12-Dec-11 01:16:51
Print Post

Re: SNRM & Error levels


[re: Bald_Eagle1] [link to this post]
 
In reply to a post by Bald_Eagle1:
The error counts as reported in the GUI were indeed set to zero.
But were they reported as zero at that time by xdslcmd?

Perhaps you should start from a fresh reboot and keep your eye on them.

Even if your error counts are counted since reboot time (2d 15h), your RSCorr, HEC & ES are terribly high, far higher than the last 2 posters to post theirs. Even ES are 1 every 10 secs; I would expect at least 60 sec per ES.

Maybe VADSL is so fast that error mount up more quickly. But I can't believe that; I'm only running at half your speed on ADSL2+ wink

1999: Freeserve 48K Dial-Up => 2005: Wanadoo 1 Meg BB => 2007: Orange 2 Meg BB => 2008: Orange 8 Meg LLU => 2010: Orange 16 Meg LLU => 2011: Orange 19 Meg WBC
Standard User john2007
(legend) Mon 12-Dec-11 08:45:27
Print Post

Re: SNRM & Error levels


[re: Bald_Eagle1] [link to this post]
 
OHF possibly means superframe thus OHFErr would be superframe error.
Standard User Bald_Eagle1
(regular) Mon 12-Dec-11 09:17:18
Print Post

Re: SNRM & Error levels


[re: john2007] [link to this post]
 
In reply to a post by john2007:
OHF possibly means superframe thus OHFErr would be superframe error.



Thanks for that info.
Just as you posted, I noticed from asbokid's blog that the same HG612 modem used on an ADSL2+ connection does report SF & SFErr instead of OHF & OHFError in the same "Counters" section of the xdslcmd info --stats log.

Now, what are SF & SFErr, do they at all relate to FEC errors, & are they worth reporting?

It does indeed appear that the GUI is reporting HEC & CRC errors correctly, the query remaining is what should it actually be reporting for FEC errors?

It appears that it should be reporting either FEC: from the "Since Link time" section, or RSCorr from the "Counters" section (identical values).
The GUI is currently reporting OHFErr as the FEC Errors value.

Edited by Bald_Eagle1 (Mon 12-Dec-11 09:20:36)

Standard User john2007
(legend) Mon 12-Dec-11 11:00:53
Print Post

Re: SNRM & Error levels


[re: Bald_Eagle1] [link to this post]
 
FEC error is a misnomer. They are packets with errors which have been automatically corrected at the receiver.

I would have thought if a superframe is in error you'd have CRC errors reported for the individual frames, so I guess you'd be double reporting errors.
Standard User WWWombat
(committed) Mon 12-Dec-11 12:36:20
Print Post

Re: SNRM & Error levels


[re: Bald_Eagle1] [link to this post]
 
Here's my accumulated knowledge on the errors. It might help!!!


In ADSL, all data is transferred back-and-forth in Frames & SuperFrames. These frames define the layout of data so that the modem can latch onto the real end-user data; to do this it surrounds that data by some "marker" data, some control information, and the CRC checksums.

There are 4000 frames per second (*) - one frame takes 0.25ms. Obviously the size of data within each frame varies according to the overall sync speed achieved.

The specs then define a sequence of frames to be one SuperFrame. The SF takes 17ms, and consists of 69 frames: 68 real data frames and 1 synchronisation frame.

(*) The 4000 frames/sec rate is the rate of real data frames; with the addition of the sync frames, there are actually (69/68)*4000 frames per second = 4058.

One SF every 17ms is almost 59 SF's per second.

So... How does this relate to the errors?

1. If the modem fails to find the sync frame where it expects it (ie every 69th frame), this counts as a Framing Error. If this persists for long period (ie seconds or more), this is counted in the LOF (Loss of Framing) counter.

LOF probably leads to the modem needing to perform a resync.

2. CRCs are transmitted per SF, so it goes to say that SFErr would be very similar to the count of CRC errors.

3. If the modem doesn't receive *anything*, this gets counted (as a number of seconds) in the LOS (Loss of signal) counters

LOS probably leads to the modem needing to perform a resync.

4. ES, SES and UAS are all a count of seconds too: Errored Seconds; Severe Errored Seconds; and UnAvailable Seconds.

UAS looks to be the accumulated time that the modem has been performing Syncs: It tends to start at around 7-10 after the first sync, and goes up in rough multiples.

ES is the number of second-long periods in which 1 or more errors occurred (I take it to mean CRC errors). If you get high CRC counts and low ES, it means the errors come in short sharp bursts (and SES is likely to increment). If CRC and ES go up at the same sort of rate, then the errors are coming in a spread-out fashion.

SES is the number of second-long period where severe error rates occurred (I take it to mean lots of errors within the 1 second, but I don't know how many "lots" are).

5. From (4), I assume that AS would be Available Seconds, but I've never seen it before!

So "uptime" for the device ought to be a total of both AS and UAS.

It isn't clear whether AS is only the time for this most recent sync, or it accumulates over each & every sync.

6. FEC is "Forward Error Correction", where small faults in data are detected & corrected using "Reed Solomon" (RS) blocks, and only apply to interleaved data. When interleaving is present, the data is spread (interleaved) amongst many frames to provide protection.

I assume that FEC & interleaving work *within* a SF, and that CRC verification works on the data block *after* FEC has corrected anything that needed correcting, and re-orders the interleaved blocks. That seems logical, as there's no way that CRC checks would work on uncorrected, unordered data.

7. RSCorr is the count of RS blocks that have been successfully corrected - and presumably don't lead to CRC errors.

8. RSUnCorr is the count of RS blocks that were not successfully corrected, and presumably lead to CRC errors.

However, RSUnCorr are *not* CRC errors directly. There can be both many RS blocks per SF (so many RSUnCorr can lead to a single CRC error) *and* there can be zero RS blocks per SF - any data sent in the fast path (ie is not interleaved) is not part of the RS blocks but can still cause a CRC error.

9. As I mentioned yesterday, I always though that HEC represented errors in the ATM encapsulation (as Framing Errors & CRC counts cover all the data within the ADSL frames themselves).

But I didn't think that ATM applies to FTTC, so I'm really not sure what is being counted here. I note that HEC is reported in a section that mentions "cells", but cells are the method of encapsulation within ATM. Curiouser & curiouser

When I graphed my Netgear's stats for CRC & HEC for ADSL, I noticed that whenever the HEC count incremented, then CRC would also always increment. However, the CRC count could increment on its own too. That means the CRC count was always guaranteed to be >= HEC count. That doesn't happen to my VDSL stats.

So... all that was for ADSL. I don't know how that information maps onto VDSL2 and its use within FTTC, but there are some obvious parallels:

a. It seems the "OHF" is the VDSL equivalent to "SF", and that OHFErr might be the real CRC error count.

b. "OHF" goes up 4,500 every 10 seconds on my modem, suggesting VDSL2 is running at 450 OHF's per second. That suggests you could see up to 450 CRC's per second maximum.

On my 40Mbps connection, it suggests almost 89Kb per OHF.

c. RS goes up 864,000 every 10 seconds on my modem, suggesting 192 RS blocks per OHF.

On the 40Mbps connection, that would be about 460 bytes per RS block.

d. "Cells" goes up 770,000 every 10 seconds.

On 40Mbps, that would be 520 bytes per cell. Real ATM has only 48 data bytes plus 5 header bytes per cell. However, FTTC certainly doesn't suffer from that 5/53 overhead (9.5%), so can't really be based on ATM.

I really don't know how to interpret Cells & HEC here.


Then there is the matter of the "--stats" presentation. This is done in a slightly funny way...

Think of the modem as keeping a few separate "pots" of counters that it increments every time an error occurs.

The "--stats" options causes these pots to be printed out in the following order:

1. Total Time
This pot is reset at reboot, and increments whenever an error is trapped.
The time given ought to be the total time, but looks to be incorrect.
(On my modem, the ES, SES, UAS, LOS and LOF values are higher than those in "Since Link" below, suggesting this pot covers a longer period)

2. Latest 15 minutes
This pot is reset once every 15 minutes, and increments inbetween.
The time shows how long since the last reset (ie will be less than 15 mins)

3. Previous 15 minutes
This pot is created as a copy of (2) just before that one is reset; it does not increment.
The time shows 15 minutes, because (2) is reset at the 15 minute point.

4. Latest 1 day
This pot is reset once every 24 hours, and increments inbetween.
The time shows how long since the last reset (ie will be less than 24 hours)

5. Previous 15 minutes
This pot is created as a copy of (4) just before that one is reset; it does not increment.
The time shows 24 hours, because (4) is reset at the 24 hour point.

6. Since Link
It looks like:
This pot is created at the establishment of the link, and reset at resync.
The time shows the length of time that the link has remained in sycn.
(On my modem, the ES, SES, UAS, LOS and LOF values are lower than those in "Total Time" above, suggesting this pot covers a shorter period. I have zero values for UAS, LOS, LOF which suggest it only counts errors since the line was last shown as available)

To conclude:
The right number for FEC comes from "RSCorr". Logging this lets you know how many tiny, correctable, errors have been introduced on your line. It currently looks like the same number is presented in the "Since Link" FEC counter, but can't be sure.

The right number for CRC is not RSUnCorr, but might be OHFErr. It currently looks like the same number is presented in the "Since Link" CRC counter, but can't be sure. Logging this lets you know the bigger uncorrectable errors encountered by the line.

My experience of HEC means that I'm not convinced the HEC here is the same as it was in ADSL, so I don't know the value of logging it.
Standard User XRaySpeX
(eat-sleep-adslguide) Mon 12-Dec-11 17:30:40
Print Post

Re: SNRM & Error levels - EDITED


[re: WWWombat] [link to this post]
 
A very comprehensive analysis, which comes round to the interpretation of the error types that I posted yesterday.
In reply to a post by WWWombat:
So "uptime" for the device ought to be a total of both AS and UAS.
It looks like you have solved something that has always puzzled me: why AS only approximates to the time in secs since last resync.
In reply to a post by WWWombat:
1. Total Time
This pot is reset at reboot, and increments whenever an error is trapped.
The time given ought to be the total time, but looks to be incorrect.
It always looks like this Total Time is the time since the last reboot, but after discarding all the days from day 2 onwards. E.g. Reboot time 14d 15h 1m 40s ago shows as:
Total time = 1 days 15 hours 1 min 40 sec


1999: Freeserve 48K Dial-Up => 2005: Wanadoo 1 Meg BB => 2007: Orange 2 Meg BB => 2008: Orange 8 Meg LLU => 2010: Orange 16 Meg LLU => 2011: Orange 19 Meg WBC

Edited by XRaySpeX (Mon 12-Dec-11 17:37:22)

Standard User asbokid
(regular) Mon 12-Dec-11 18:18:03
Print Post

Re: SNRM & Error levels


[re: WWWombat] [link to this post]
 
Excellent information from WWWombat. Thank you for posting it!

Hopefully the TBB contributor, JustAnother, will be able to incorporate it into his very useful FAQ for the xdslcmd tool. [1]

Unpacking the server-side scripts used by the web server embedded in the Huawei can also help to identify the 'Anomaly Counters' displayed in the GUI.

We can look a bit closer at the xDSL MIB objects passed in the parameter lists of those server-side scripting functions.

Here is the parameter list for the function call webGetCfgEntry() found in the .asp resource at http://192.168.1.1/html/status/xdslStatus.asp :

Text
1
23
45
67
89
1011
1213
1415
16
var DSLStats =
<%webGetCfgEntry(InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.Stats.Showtime,    HECErrors|
    ATUCHECErrors|    CRCErrors|
    ATUCCRCErrors|    FECErrors|
    ATUCFECErrors|    X_ATP_HECErrors_2|
    X_ATP_ATUCHECErrors_2|    X_ATP_CRCErrors_2|
    X_ATP_ATUCCRCErrors_2|    X_ATP_FECErrors_2|
    X_ATP_ATUCFECErrors_2,stStats);
%>;


Before serving up that .asp resource, the Huawei's scripting engine dynamically populates the parameters to the function:

Text
1
23
45
67
89
1011
1213
14
var DSLStats = new Array(new stStats("InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.Stats.Showtime",
    "292008",    "0",
    "1074551",    "0",
    "42205",    "105",
    "0",    "0",
    "0",    "0",
    "0",    "0"),
null);


In the above example from Paul's line, we can determine the following:

Text
1
23
45
67
89
1011
1213
..
  HECErrors              = 292008  ATUCHECErrors          = 0
  CRCErrors              = 1074551  ATUCCRCErrors          = 0
  FECErrors              = 42205  ATUCFECErrors          = 105
  X_ATP_HECErrors_2      = 0  X_ATP_ATUCHECErrors_2  = 0
  X_ATP_CRCErrors_2      = 0  X_ATP_ATUCCRCErrors_2  = 0
  X_ATP_FECErrors_2|     = 0  X_ATP_ATUCFECErrors_2  = 0



The acronym "ATUC" is jargon for ADSL Transceiver Unit in Central Office [3]. In plainspeak, ATUC means the DSLAM.

Similarly, the xDSL modem in the consumer premises is known by the official acronym ATU-R, where 'R' means Remote.

Just to confuse things further, ATU-C and ATU-R are identified in the Broadcom driver source code as the "Far End" (FE) and the "Near End" (NE) !

So ATUCHECErrors is a count of the HEC Errors measured at the DSLAM.

All of those function parameters shown above, starting with HECErrors and ending with X_ATP_CFECErrors_2, are defined in a XML model of the xDSL MIB for the Huawei.

That MIB model is found in the Huawei's root file system under the filename /etc/t_tree.xml

The full 84kB XML MIB file can be viewed at [2]

Below is an excerpt from that MIB model showing a part of the Stats.Showtime subtree:

Text
1
23
45
67
89
1011
1213
1415
1617
1819
2021
2223
2425
2627
28
<Stats CMO="0x00008A00">
        <Showtime CMO="0x00009000">          <ReceiveBlocks CMO="0x00009001" Type="VALUE_TYPE_ULONG"
          AppName="cms" MaxLength="0" DefaultValue="0xFFFFFFFF" />          <TransmitBlocks CMO="0x00009002" Type="VALUE_TYPE_ULONG"
          AppName="cms" MaxLength="0" DefaultValue="0xFFFFFFFF" />[...]
          <SeverelyErroredSecs CMO="0x00009005"          Type="VALUE_TYPE_ULONG" AppName="cms" MaxLength="0"
          DefaultValue="0xFFFFFFFF" />          <HECErrors CMO="0x00009006" Type="VALUE_TYPE_ULONG"
          AppName="cms" MaxLength="0" DefaultValue="0xFFFFFFFF" />          <ATUCHECErrors CMO="0x00009007" Type="VALUE_TYPE_ULONG"
          AppName="cms" MaxLength="0" DefaultValue="0xFFFFFFFF" />          <CRCErrors CMO="0x00009008" Type="VALUE_TYPE_ULONG"
          AppName="cms" MaxLength="0" DefaultValue="0xFFFFFFFF" />          <ATUCCRCErrors CMO="0x00009009" Type="VALUE_TYPE_ULONG"
          AppName="cms" MaxLength="0" DefaultValue="0xFFFFFFFF" />          <FECErrors CMO="0x0000900A" Type="VALUE_TYPE_ULONG"
          AppName="cms" MaxLength="0" DefaultValue="0xFFFFFFFF" />          <ATUCFECErrors CMO="0x0000900B" Type="VALUE_TYPE_ULONG"
          AppName="cms" MaxLength="0" DefaultValue="0xFFFFFFFF" />[...]
          <X_ATP_ATUCFECErrors_2 CMO="0x00009011"          Type="VALUE_TYPE_ULONG" AppName="cms" MaxLength="0"
          DefaultValue="0xFFFFFFFF" />        </Showtime>
      </Stats>


The XML shows us the MIB OIDs, the datatypes of the elements, and the applications from where their current values are obtained.

In the Huawei, there appears to be a message server (/bin/MidServer) which actually retrieves the statistical data on behalf of the web server. The MidServer proxies all requests for MIB objects and dispatches those requests to the appropriate application {cms|cwmp|cli|tr064| etc.} to obtain an answer.

There is probably enough understood of the xdlscmd binary to reverse-engineer it now. It could be re-written as an open source application.

The xdslcmd tool is found (under a variety of names) in tens of millions of Broadcom 63xx-based broadband access units, so an open source tool would potentially benefit a large number of end-users.

Much of this work has already been done under the auspices of the openwrt.org and the ddwrt open-source firmware projects. [4][5]

cheers, a

[1] http://forum.kitz.co.uk/index.php/topic,10289.0.html
[2] http://pastebin.com/XbDjJC3T
[3] http://www.analytic.ru/articles/lib26.pdf
[4] http://openwrt.org/
[5] http://www.dd-wrt.com/
Standard User BatBoy
(legend) Mon 12-Dec-11 18:49:58
Print Post

Re: SNRM & Error levels


[re: john2007] [link to this post]
 
In reply to a post by john2007:
I guess RS means Reed-Solomon, the algorithm used in Forward Error Correction.

Most routers seem to use RSCorr for the FEC count (the count of packets with errors which were successfully corrected with the Reed-Solomon algorithm) and RSUnCorr for the CRC count (the packet was too severely damaged to correct and so fails the CRC).
No, RS means Regenerator Section as used by SDH. http://en.wikipedia.org/wiki/Synchronous_optical_net...



______________________________________________________________________________. __________________
Standard User asbokid
(regular) Mon 12-Dec-11 20:23:22
Print Post

Re: SNRM & Error levels


[re: BatBoy] [link to this post]
 
That's interesting. Though in this context, RS means Reed-Solomon:

The following excerpt is taken from the source code of the xDSL device driver for Broadcom's 63xx SoCs [1] [2]

Text
1
23
45
67
89
1011
1213
1415
1617
1819
20
/* showtime monitor counters */
 #define kG992ShowtimeRSCodewordsRcved              0 /* number of Reed-Solomon codewords received */
#define kG992ShowtimeRSCodewordsRcvedOK            1 /* number of Reed-Solomon codewords received with all syndromes zero */#define kG992ShowtimeRSCodewordsRcvedCorrectable   2 /* number of Reed-Solomon codewords received with correctable errors */
#define kG992ShowtimeRSCodewordsRcvedUncorrectable 3 /* number of Reed-Solomon codewords received with un-correctable errors */#define kG992ShowtimeSuperFramesRcvd               4 /* number of super frames received */
#define kG992ShowtimeSuperFramesRcvdWrong          5 /* number of super frames received with CRC error */#define kG992ShowtimeLastUncorrectableRSCount      6 /* last recorded value for kG992ShowtimeRSCodewordsRcvedUncorrectable */
#define kG992ShowtimeLastWrongSuperFrameCount      7 /* last recorded value for kG992ShowtimeSuperFramesRcvdWrong */#define kG992ShowtimeNumOfShortResync              8 /* number of short interrupt recoveries by FEQ */
 #define kG992ShowtimeNumOfFEBE                     9 /* number of other side superframe errors */
#define kG992ShowtimeNumOfFECC                    10 /* number of other side superframe FEC errors */#define kG992ShowtimeNumOfFHEC                    11 /* number of far-end ATM header CRC errors */
#define kG992ShowtimeNumOfFOCD                    12 /* number of far-end OCD events */#define kG992ShowtimeNumOfFLCD                    13 /* number of far-end LCD events */
#define kG992ShowtimeNumOfHEC                     14 /* number of ATM header CRC errors */#define kG992ShowtimeNumOfOCD                     15 /* number of OCD events */
#define kG992ShowtimeNumOfLCD                     16 /* number of LCD events */


cheers, a

[1] http://huaweihg612hacking.wordpress.com/2011/07/26/b...

[2] ftp://downloads.netgear.com/files/GPL/DG834GBv4_V5.0...
(see, for example, the file ~/DG834GBv4_V5.01.01_src/bcmdrivers/broadcom/char/adsl/bcm96348/softdsl/SoftDsl.h)

Edited by asbokid (Mon 12-Dec-11 20:39:44)

Standard User BatBoy
(legend) Mon 12-Dec-11 20:46:35
Print Post

Re: SNRM & Error levels


[re: asbokid] [link to this post]
 
Oh dear, they're wrong too wink



______________________________________________________________________________. __________________
Moderator billford
(moderator) Mon 12-Dec-11 21:02:00
Print Post

Re: SNRM & Error levels


[re: BatBoy] [link to this post]
 
You've had several warnings about your aggressive posting style and refusal to admit possible error, take some time to think about it a little.

~~~~~~~~~~~~
Bill

[email protected] __________________Planes and Boats and ... __________________BQM
The author of the above post is a thinkbroadband moderator but it does not constitute an official statement on behalf of thinkbroadband.
Standard User WWWombat
(committed) Mon 12-Dec-11 21:18:48
Print Post

Re: SNRM & Error levels


[re: BatBoy] [link to this post]
 
In reply to a post by BatBoy:
No, RS means Regenerator Section as used by SDH.

BT have SDH coming into my house? Where's the rest of my 40Gbps gone then?

And someone had better tell Fujitsu they don't need to bother installing fibre anywhere... BT have been cunningly doing it already.
Standard User XRaySpeX
(eat-sleep-adslguide) Tue 13-Dec-11 01:02:59
Print Post

Re: SNRM & Error levels


[re: asbokid] [link to this post]
 
Don't worry! Batty is just stirring you up, as is his wont, with false info.

1999: Freeserve 48K Dial-Up => 2005: Wanadoo 1 Meg BB => 2007: Orange 2 Meg BB => 2008: Orange 8 Meg LLU => 2010: Orange 16 Meg LLU => 2011: Orange 19 Meg WBC
Standard User Bald_Eagle1
(regular) Tue 13-Dec-11 08:00:17
Print Post

Re: SNRM & Error levels


[re: asbokid] [link to this post]
 
Hi asbokid,

In reply to a post by asbokid:
Here is the parameter list for the function call webGetCfgEntry() found in the .asp resource at http://192.168.1.1/html/status/xdslStatus.asp :

Text
1
23
45
67
89
1011
1213
1415
16
var DSLStats =
<%webGetCfgEntry(InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.Stats.Showtime,    HECErrors|
    ATUCHECErrors|    CRCErrors|
    ATUCCRCErrors|    FECErrors|
    ATUCFECErrors|    X_ATP_HECErrors_2|
    X_ATP_ATUCHECErrors_2|    X_ATP_CRCErrors_2|
    X_ATP_ATUCCRCErrors_2|    X_ATP_FECErrors_2|
    X_ATP_ATUCFECErrors_2,stStats);
%>;


Before serving up that .asp resource, the Huawei's scripting engine dynamically populates the parameters to the function:

Text
1
23
45
67
89
1011
1213
14
var DSLStats = new Array(new stStats("InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.Stats.Showtime",
    "292008",    "0",
    "1074551",    "0",
    "42205",    "105",
    "0",    "0",
    "0",    "0",
    "0",    "0"),
null);


In the above example from Paul's line, we can determine the following:

Text
1
23
45
67
89
1011
1213
..
  HECErrors              = 292008  ATUCHECErrors          = 0
  CRCErrors              = 1074551  ATUCCRCErrors          = 0
  FECErrors              = 42205  ATUCFECErrors          = 105
  X_ATP_HECErrors_2      = 0  X_ATP_ATUCHECErrors_2  = 0
  X_ATP_CRCErrors_2      = 0  X_ATP_ATUCCRCErrors_2  = 0
  X_ATP_FECErrors_2|     = 0  X_ATP_ATUCFECErrors_2  = 0



The acronym "ATUC" is jargon for ADSL Transceiver Unit in Central Office [3]. In plainspeak, ATUC means the DSLAM.

Similarly, the xDSL modem in the consumer premises is known by the official acronym ATU-R, where 'R' means Remote.

Just to confuse things further, ATU-C and ATU-R are identified in the Broadcom driver source code as the "Far End" (FE) and the "Near End" (NE) !

So ATUCHECErrors is a count of the HEC Errors measured at the DSLAM.



I eventually realised that the example you used from my connection has not been posted in this forum thread, but obtained elsewhere smile


I can confirm that the values shown are indeed the values displayed in the modem's GUI.

e.g.
Text
1
23
..
  FECErrors              = 42205 is displayed as Downstream FEC errors in the GUI  ATUCFECErrors          = 105   is displayed as Upstream   FEC errors in the GUI



Just to be 100% clear what is being said here, are you confirming that the modem's GUI is CORRECTLY reporting CRC, FEC, & HEC errors, or just confirming just how INCORRECTLY it reports them, citing a real-life example?

Unfortunately I don't have the actual xdslcmd info --stats log to go with the example used above, But previous log examples have highlighted the "discrepancies" between the data it contains & the data as displayed in the GUI.


Paul
Standard User asbokid
(regular) Tue 13-Dec-11 21:52:30
Print Post

Re: SNRM & Error levels


[re: XRaySpeX] [link to this post]
 
In reply to a post by XRaySpeX:
Don't worry! Batty is just stirring you up, as is his wont, with false info.


More of a Les Dawson than a Liberace, when it comes to hitting the right notes?!

cheers, a
Standard User asbokid
(regular) Wed 14-Dec-11 00:14:58
Print Post

Re: SNRM & Error levels


[re: Bald_Eagle1] [link to this post]
 
In reply to a post by Bald_Eagle1:
I eventually realised that the example you used from my connection has not been posted in this forum thread, but obtained elsewhere smile

I can confirm that the values shown are indeed the values displayed in the modem's GUI.

e.g.
Text
1
23
..
  FECErrors              = 42205 is displayed as Downstream FEC errors in the GUI  ATUCFECErrors          = 105   is displayed as Upstream   FEC errors in the GUI



Just to be 100% clear what is being said here, are you confirming that the modem's GUI is CORRECTLY reporting CRC, FEC, & HEC errors, or just confirming just how INCORRECTLY it reports them, citing a real-life example?


If only the firmware was open source and then we would know for sure. We could trace the source of the data right back to the kernel driver.

There are several places where Broadcom and/or Huawei could get it wrong. The driver itself presumably records the correct data. That data is directly retrieved from the kernel by xdslcmd using Unix system calls known as ioctls. So xdslcmd is most likely to report the correct data, but even that tool incorrectly reports the attenuation levels in certain places.

Huawei uses a middleware server in between the embedded web server and the xdsl device driver. And then there's that scripting engine in the webserver itself, and then there's some Javascript which actually renders the data on a web page. So there are many places where programming bugs could be introduced. Some of the source code has comments in Chinese, so that was presumably written by or for Huawei rather than by Broadcom. So the problems of language misunderstandings introduce another avenue for bugs.

I kind of think that Broadcom may as well release the driver source code under an open source licence, so that others can work on it. Since the source code has been leaked all over the internet anyway, there is no commercial advantage in keeping that code proprietary.

The DSP code which runs on the second MIPS core in the 6368 CPU is a different kettle of fish, and Broadcom unsurprisingly guards that code with great care. All we have of that code is a 500kByte binary blob.

But the character device driver (accessed through the device node /dev/*dsl) may as well be open source now, so that these bugs can be worked on.

Unfortunately I don't have the actual xdslcmd info --stats log to go with the example used above, But previous log examples have highlighted the "discrepancies" between the data it contains & the data as displayed in the GUI.

Paul


I still don't understood what those discrepancies involve.

EDIT:

Okay, I just looked at JustAnother's post at [1]. The uptime may relate to total DSL uptime accumulated since the last reboot of the Huawei.. Which means if there were multiple DSL sessions, between which the Huawei was _not_ rebooted, then that uptime figure would be a summation of those session durations. Only a suggestion, mind!

As for the (large) figure reported by the web interface for FEC errors... wasn't that solved by john and WWWombat? Since the same figure is reported under the heading "RSCorr" in 'xdslcmd info --stats', isn't it the number of 'correctable' errors that were caught, before the data blocks were passed to the RS code for correction? Those blocks don't need re-sending since Reed-Solomon coding reserves redundant bytes for the purposes of correction. At that stage, the errors were counted as RSCorrectable, rather than as RSCorrected.

It is a very poor web interface in the Huawei. For someone with the enthusiasm, it wouldn't be difficult to patch it though. Between these four walls, there's a security flaw in the Huawei's web server that can be used beneficially to execute arbitrary code on the device. It can be used to retrieve whatever statistics you want from the xDSL kernel driver.


cheers, a

[1] http://forum.kitz.co.uk/index.php/topic,10289.msg205...

Edited by asbokid (Wed 14-Dec-11 00:38:55)

Standard User BatBoy
(legend) Fri 16-Dec-11 22:07:06
Print Post

Re: SNRM & Error levels


[re: asbokid] [link to this post]
 
In reply to a post by asbokid:
In reply to a post by XRaySpeX:
Don't worry! Batty is just stirring you up, as is his wont, with false info.


More of a Les Dawson than a Liberace, when it comes to hitting the right notes?!

cheers, a
Looks like you were suffering a sense of humour breakdown. Don't worry, you weren't alone. Possibly mass hysteria?



______________________________________________________________________________. __________________
Pages in this thread: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | (show all)   Print Thread

Jump to