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

Login with username, password and session length
Advanced search  

News:

Pages: [1] 2 3 ... 6

Author Topic: CRC, FEC, HEC Error count  (Read 46540 times)

Bald_Eagle1

  • Helpful
  • Kitizen
  • *
  • Posts: 2721
CRC, FEC, HEC Error count
« on: November 01, 2011, 09:00:37 AM »

Hi All,

I have recently been keeping an eye on the error count for my FTTC connection.

e.g. My connection has been up for 1 day, 2 hours, 45 minutes.

This is the error count:-

                         Path 0                           Path 1 
                         Downstream   Upstream      Downstream   Upstream
Line rate (kbit/s)   25613            4699            0                  0 
CRC errors           1238192         0                 0                  0 
FEC errors           13746            73                0                  0 
HEC errors           370523          0                  0                  0 

From a re-sync / reboot, where SNRM is around 6dB during daylight hours, I see very few errors being reported.
However, from around 4:00pm onward, SNRM starts to drop & the error count starts to rise.

From around 8:00 am, the SNRM starts to rise again, & the increase in error count slows down again.

My questions are:-

1) Does the above error count look "normal" for the duration of my connection?

2) If the error count is indeed high, what sort of things could cause it?

3) I don't notice any deterioration in my internet usage, other than what I consider to be too low a speed for FTTC generally, as extensively documented in my other thread.
Is the error count shown above anything to be concerned about?

4) Could a high error count be a contributory factor in my current inability to sync at a higher speed?

I have only really noticed these errors since the switch to the new FTTC 17a profile, with my connection attempting to use higher frequencies on an already highly attenuated connection, but they MAY have been similar before the profile switch.

I don't currently have any way of monitoring/recording timed SNRM/error count fluctuations (Routerstats etc.), but that is being looked into.


Paul.
Logged

GunJack

  • Reg Member
  • ***
  • Posts: 484
Re: CRC, FEC, HEC Error count
« Reply #1 on: November 01, 2011, 02:46:53 PM »

that type of sinusoidal behaviour with rising/falling snrm and error rates is pretty normal. They may be a bit on the high side for the uptime, but any form of bad weather, local interference, etc. could bump it up lots in a given time period. Without monitoring over a longer time period it's impossible to tell if it's a one-off "event" or a longer-term trend.
Logged
8)..........Gettin' There, Wherever There is..........8)

jeffbb

  • Kitizen
  • ****
  • Posts: 2329
Re: CRC, FEC, HEC Error count
« Reply #2 on: November 01, 2011, 11:30:03 PM »

Hi
~ 12 CRCs a second a little surprised as most of the errors are being generated over a very short distance (only from cabinet). An average of 12 per second is one thing but importantly  how much of an increase is there during peak periods .

The CRC will not affect your synch directly ,if they are too bad then your SNR margin will go up . With normal ADSL there is a limit of 15db. With VDSL I am not sure but I seem to have read it is similar.If you stay connected at a given synch rate with High CRCs then of course this will have an adverse affect on your throughput .

On my adsl line with an uptime of nearly 6 days I have a total of 1crc ,2.2 Km from the exchange .

Regards Jeff

 
Logged
zen user

Bald_Eagle1

  • Helpful
  • Kitizen
  • *
  • Posts: 2721
Re: CRC, FEC, HEC Error count
« Reply #3 on: November 02, 2011, 08:45:42 AM »

Hi
~ 12 CRCs a second a little surprised as most of the errors are being generated over a very short distance (only from cabinet). An average of 12 per second is one thing but importantly  how much of an increase is there during peak periods .

The CRC will not affect your synch directly ,if they are too bad then your SNR margin will go up . With normal ADSL there is a limit of 15db. With VDSL I am not sure but I seem to have read it is similar.If you stay connected at a given synch rate with High CRCs then of course this will have an adverse affect on your throughput .

On my adsl line with an uptime of nearly 6 days I have a total of 1crc ,2.2 Km from the exchange .

Regards Jeff

 


Thanks Fellas,

As reported elsewhere, I believe my connection is currently highly attenuated, compared to what it must have been when I achieved much higher speeds, & also compared to other users' stats for their good connections.

No matter how much I ask, I can't get BT, via Plusnet, to confirm whether it has been intentionally manually speed capped to provide stability or not.

I just get the response that DLM does all that automagically.

Assuming DLM is actually operating correctly based on the current condition of my D-side, it would appear that some sort of physical resistance or other "fault" is causing the high attenuation.

I would assume that other factors such as electrical "interference" could cause increased noise levels, but would not affect attenuation?

Nobody has been willing/able to confirm my D-side's actual length, so I have no idea what my attenuation levels SHOULD be, assuming a "typical" D-side condition.
I THINK my D-side could be anywhere between 600m & 850m.

So, could the resistance "fault" be the cause of the high error count, especially when reported SNRM levels drop at peak/night time periods?

My connection now appears quite stable otherwise, albeit at reduced speeds, & doesn't appear to lose any throughput speed (even at peak periods), which leads me to think there cannot be too many FTTC connections from my cabinet.

My reported SNRM level was 3.9dB at around 6:30 this morning & now at 08:25 it is 5dB

Now connected for 2 days, 2 hours, 42 minutes, the error count is:-

                  DS         US   
CRC errors    3369943  0   
FEC errors    34398     130 
HEC errors    996619    0 

As soon as I can monitor error counts & SNRM overnight (with something quite similar to Routerstats), I will have a better indication of when things worsen.

I also hope to be able to test/measure my D-side length "unofficially" in the not too distant future.

Of course, all of this could be a complete waste of time, as even if I "prove" there is a fault on my D-side, my connection is still performing at "acceptable" levels for an "up to" 40Mb service (according to Plusnet), so convincing them/BT to do anything about it will be another uphill struggle.

Just a final thought (anyone?), I am not aware that the master socket (replaced & repositioned by the FTTC installing engineer) has been tested.
Could a filtering or other "fault" there cause such issues, & how could I test it?
The phone is always nice & quiet now when I do the quiet line test.

Paul.
Logged

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5369
Re: CRC, FEC, HEC Error count
« Reply #4 on: November 02, 2011, 09:59:39 AM »

Your CRC error count looks alarming at first sight.  It looks like it's of the order of 1 million a day, which is about 10 a second.   With that error rate on a conventional DSL connection, over TCP, you'd be soliciting data end-to-end retransmissions ten times a second, each one causing a delay of perhaps a few hundred milliseconds, the overall throughout would be near zero and completely useless.

So, assuming your line provides a useable service, it seems fair to assume the CRC counter does not have the same significance to which we are accustomed with old-style ADSL. 

I'm not sure what technologies BT deploy for FTTC ... VDSL? VDSL2?  I know that some of the VDSL technologies support PhyR (Physical layer retransmission), whereby corrupted data only has to be retransmitted from the remote end of the phone line, compared to TCP retransmissions which may have to be resent  from across the world.   I'm therefor guessing your CRC errors may perhaps relate to PhyR requests rather than failed IP checksums, which makes them a lot less alarming.  It still seems a lot to me but  I've no idea is to what is 'normal', or 'tolerable' for PhyR retransmissions.  If your connection is working OK, with decent throughput and no 'pauses' then there may be no need to worry too much.
« Last Edit: November 02, 2011, 10:01:40 AM by sevenlayermuddle »
Logged

Bald_Eagle1

  • Helpful
  • Kitizen
  • *
  • Posts: 2721
Re: CRC, FEC, HEC Error count
« Reply #5 on: November 02, 2011, 10:10:45 AM »


So, assuming your line provides a useable service, it seems fair to assume the CRC counter does not have the same significance to which we are accustomed with old-style ADSL. 

I'm not sure what technologies BT deploy for FTTC ... VDSL? VDSL2?  I know that some of the VDSL technologies support PhyR (Physical layer retransmission), whereby corrupted data only has to be retransmitted from the remote end of the phone line, compared to TCP retransmissions which may have to be resent  from across the world.   I'm therefor guessing your CRC errors may perhaps relate to PhyR requests rather than failed IP checksums, which makes them a lot less alarming.  It still seems a lot to me but  I've no idea is to what is 'normal', or 'tolerable' for PhyR retransmissions.  If your connection is working OK, with decent throughput and no 'pauses' then there may be no need to worry too much.


Hi sevenlayermuddle,

BT uses VDSL2, originally profile 8c, gradually being switched to the higher frequency profile 17a, in readiness for next year's speed "doubling" to 80Mb.

I was switched to profile 17a quite recently, & the high error count may have started then. I didn't really notice a high count when I was on profile 8c.

It does work O.K., apart from the much lower speeds than I achieved what now seems such a long, long time ago.

I'll go & have a read up on PhyR requests as I haven't heard that term previously.


Paul.
Logged

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5369
Re: CRC, FEC, HEC Error count
« Reply #6 on: November 02, 2011, 10:28:17 AM »

I'll go & have a read up on PhyR requests.

Me too, I've got me interested  :D

But I'm actually just about to be away on travels for a few days, so don't expect much more dialogue from me in the next few days.  I'll add read up on VDSL & PhyR to the wishlist of things to do when I get back.
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: CRC, FEC, HEC Error count
« Reply #7 on: November 02, 2011, 03:57:00 PM »

I also hope to be able to test/measure my D-side length "unofficially" in the not too distant future.

<snip>

Just a final thought (anyone?), I am not aware that the master socket (replaced & repositioned by the FTTC installing engineer) has been tested.
Could a filtering or other "fault" there cause such issues, & how could I test it?
The phone is always nice & quiet now when I do the quiet line test.

Hi Baldy_Bird,

(I think I can get away with that greeting as "The Cattery" is a number of counties away from Lancashire and, thus, my tail is out of pecking range . . .  :P  )

Your hope, quoted above, is interesting and on behalf of all of us who inhabit these fora, please let us know your findings and the method you used -- in due course.

With regards to your final thought, although I believe I have a good "overview" of your connection, I am still a little unclear on the intimate most details. For example, by inputting some data into Google Maps (and not getting distracted by some magnificent views of the countryside), a "street view" shows me a pair of semi-detached houses. I assume "The Aeire" is the right-hand one of the pair when viewed from the road. Unfortunately GM street view does not show me a clear image of where the drop-wire from the pole is attached to your house. I would be very interested to see clear photographs starting from that point and including the junction where the drop-wire transitions to the service cable, where the service cable is extended (the old location of the NTE5/A) to your office, the new location of the NTE5/A in your office and any extensions that may be run from there. I'm sure you know the sort of details that I like to see in photographs -- the colours of the wire cores that emanate from each cable and which coloured wire is connected to what-not, etc. As for "testing" of your relocated NTE5/A, the best method is a direct swap for a known, good device. Let me contemplate my last statement some more, once I have seen your photographs . . .  :-\
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

Bald_Eagle1

  • Helpful
  • Kitizen
  • *
  • Posts: 2721
Re: CRC, FEC, HEC Error count
« Reply #8 on: November 02, 2011, 06:38:14 PM »

Hi Baldy_Bird,

(I think I can get away with that greeting as "The Cattery" is a number of counties away from Lancashire and, thus, my tail is out of pecking range . . .  :P  )

Your hope, quoted above, is interesting and on behalf of all of us who inhabit these fora, please let us know your findings and the method you used -- in due course.

With regards to your final thought, although I believe I have a good "overview" of your connection, I am still a little unclear on the intimate most details. For example, by inputting some data into Google Maps (and not getting distracted by some magnificent views of the countryside), a "street view" shows me a pair of semi-detached houses. I assume "The Aeire" is the right-hand one of the pair when viewed from the road. Unfortunately GM street view does not show me a clear image of where the drop-wire from the pole is attached to your house. I would be very interested to see clear photographs starting from that point and including the junction where the drop-wire transitions to the service cable, where the service cable is extended (the old location of the NTE5/A) to your office, the new location of the NTE5/A in your office and any extensions that may be run from there. I'm sure you know the sort of details that I like to see in photographs -- the colours of the wire cores that emanate from each cable and which coloured wire is connected to what-not, etc. As for "testing" of your relocated NTE5/A, the best method is a direct swap for a known, good device. Let me contemplate my last statement some more, once I have seen your photographs . . .  :-\


Hi b*cat,

In the same order as your catawaling, I respond as follows:-

Bald Eagles are rather large birds of prey & can fly a long way, getting hungrier & hungrier on their journey, a large black cat would simply suffice as an aperatif.

"The Aerie" is actually the left-hand one of the pair. The lead flashing to the porch is no longer an issue as some poor soul helped themself to it quite a while ago.
The drop wire can be seen by zooming in to the right-hand side of the furthermost left-hand upstairs window.
It enters at just above window cill level.
Dependent upon zoom level, the cable can be seen going off to the pole to the right of the semi, then across the road to another pole.
From there, it either goes underground down the road, past the front of the Filling Station toward the cabinet, or takes a detour up the path, overhead to near the row of houses, & then behind the Filling Station.

Whichever route it takes, it appears to go to the pole just past the white(ish) property that is being advertised "To Let" by someone who could be my father's brother's son.

Are you still with me on this?

From there, the engineer that allowed me to photograph his laptop display, (recall the map with the almost invisible dotted line, that turned out NOT to be a BT Network Record after all), thought it MUST continue down the same main road (H Road) to the Lane on which the cabinet is located (H Lane).
This would be the longer of 2 possible routes (820m apparently).

The FTTC installing engineer thought it MAY go down L T Lane (opposite the aforementioned white(ish) property), to the cabinet on H Lane (the shorter route).

Prior to the FTTC installation, the master socket (ADSL v1.0) was on the internal reveal of the upstairs window, with various hard-wired & plug in telephone extension cables bought from B & Q.
I had plugged into the DSL socket a 20m high quality, shielded, high speed data cable, bought from Maplins.
This went along the upstairs, through the house, & through the ceiling to the downstairs office (difficult to photograph).

The installing engineer cut off the male plug of my shielded cable at the old master socket & crimped a pair from the shielded cable to the incoming cable.

He then cut off the male plug at the other end of the shielded cable (downstairs) & hard-wired it into the new master socket downstairs.

He then connected a spare pair from the shielded cable into the new master socket which then ran back upstairs to what WAS the old master socket, converting the old master socket to a telephone only extension, with further extensions hard-wired & plugged in.

That may appear somewhat unconventional, but it worked perfectly.

On seeing the cabling, each visiting engineer has scratched his head & thought about it, (some have even disconnected the crimps & checked for moisture etc), thought about it some more & then commented with words such as "Well, that's not how I would have done it, but it is much better quality cable than we (BT) would have given you".

I had a fax machine, various telephones, sky box, connected via the various extensions from day 1.
Everything worked perfectly for the first month. I even disconnected everything apart from the broadband for a full week to check for "interference".
That produced no changes - still perfect, & at at the same broadband speeds.

Are you still with me?

I have telephone extensions all over the place; under floors, inside studded partitions, extensions plugged into extensions, double adapters etc. etc. etc.
All have been checked by engineers as O.K.
During the "troubles", I again disconnected the whole lot for a full week. This made absolutely no difference whatsoever.

Various photos are attached, but I could forward full resolution photos if required.
Images 004, 005, 006 show the new master socket.

Also see the next post for more photos.

Well, you did ask.............


Paul.


[attachment deleted by admin]
« Last Edit: November 02, 2011, 07:17:17 PM by Bald_Eagle1 »
Logged

Bald_Eagle1

  • Helpful
  • Kitizen
  • *
  • Posts: 2721
Re: CRC, FEC, HEC Error count
« Reply #9 on: November 02, 2011, 06:43:09 PM »


The other photos.....
(after losing a couple of Mb through disconnecting at a silly time of day) ;D

I hope the previous message was clear enough.
I lost myself a couple of times while composing it.
I had better read through it again to check  ;)

Images 007,008,002 show the old master socket (now an extension)

Paul.

[attachment deleted by admin]
« Last Edit: November 02, 2011, 07:12:21 PM by Bald_Eagle1 »
Logged

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 33879
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: CRC, FEC, HEC Error count
« Reply #10 on: November 02, 2011, 09:02:25 PM »

Your CRC error count looks alarming at first sight.  It looks like it's of the order of 1 million a day, which is about 10 a second.   With that error rate on a conventional DSL connection, over TCP, you'd be soliciting data end-to-end retransmissions ten times a second, each one causing a delay of perhaps a few hundred milliseconds, the overall throughout would be near zero and completely useless.

So, assuming your line provides a useable service, it seems fair to assume the CRC counter does not have the same significance to which we are accustomed with old-style ADSL. 

I'm not sure what technologies BT deploy for FTTC ... VDSL? VDSL2?  I know that some of the VDSL technologies support PhyR (Physical layer retransmission), whereby corrupted data only has to be retransmitted from the remote end of the phone line, compared to TCP retransmissions which may have to be resent  from across the world.   I'm therefor guessing your CRC errors may perhaps relate to PhyR requests rather than failed IP checksums, which makes them a lot less alarming.  It still seems a lot to me but  I've no idea is to what is 'normal', or 'tolerable' for PhyR retransmissions.  If your connection is working OK, with decent throughput and no 'pauses' then there may be no need to worry too much.

Does anyone else find the high count of CRCs when compared to FEC's unusual?
Youd normally expect the FEC's to outnumber CRCs?
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5369
Re: CRC, FEC, HEC Error count
« Reply #11 on: November 02, 2011, 11:32:24 PM »

Does anyone else find the high count of CRCs when compared to FEC's unusual?
Youd normally expect the FEC's to outnumber CRCs?

Apologies, this response replaces another one that I just deleted it as I think I'm maybe confused.

My comments about CRC errors crippling the connection really refer to IP checksum errors.

Can we clarify the expected relationships, though...?

If CRC errors relate  to ATM cells then surely they shuld outnumber FECs, yet they usually don't.
If they are IP header errors then surely HECs should outnumber CRCs, but I think they often don't.

I'm sure I once kew the answers to questions like that.   :-[

My gut feeling remains that the high CRC count is in some way related to PhyR, but I'm further than I thought from adding any substance to the theory.   ???

Anyway, I'm meant to be 'home' on holiday, must learn to shut up.   :D
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: CRC, FEC, HEC Error count
« Reply #12 on: November 03, 2011, 02:24:50 AM »

Hailing the Big Bird with not too many feathers "up top",

Quote
Are you still with me on this?

Yes. Your father's brother's son is your cousin!  ::)

I've now studied your internal wiring photographs, thank you. I am surprised that the installing engineer left the original NTE5/A in situ, rather than swapping it out for an LJU3/3A or even an LJU5/3A -- both of which would have fitted the existing backing box of the old NTE5/A. (See the BT Phone Sockets page for details.) Perhaps he didn't have either of those sockets in his van? Do you know if he removed the surge suppressor, resistor and capacitor from the old NTE5/A? If he didn't, then the incoming pair is now doubly terminated.  :-X  I assume the new NTE5/A is situated in that location as being ideal for the HG612 and your Netgear router? That "wiring closet" is in your office, I assume. My other surprise is that the installing engineer did not fix the new NTE5/A backing box to a suitable surface but "left it floating". :-\  I'll echo what subsequent visiting engineers have said: "That's not how I would have done it."

Looking back to your post where you commented and asked --

Quote
Just a final thought (anyone?), I am not aware that the master socket (replaced & repositioned by the FTTC installing engineer) has been tested.
Could a filtering or other "fault" there cause such issues, & how could I test it?

-- we see that statement isn't strictly correct. The original NTE5/A has been left in situ and a new NTE5/A has been fitted downstairs in your office's "wiring closet". So you can test to see if the original NTE5/A is having any influence by removing the lower front half face-plate from the SSFP which is fitted to the new NTE5/A. By doing that, you will have disconnected all telephony sockets. (Almost a veritable rats nest, I shall say.  :tongue:  )

As I feel the need for a quick nap overwhelming me, I'll study the external aspect of "The Aeire" and the possible routes to the PCP + Fibre Cabinet tomorrow.
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: CRC, FEC, HEC Error count
« Reply #13 on: November 03, 2011, 02:34:16 AM »

Quote
. . . as I think I'm maybe confused.

7LM is confused? With such a forum identity, I am very surprised!  ;)

Now I'm going to throw a comment up into the air and see how it lands. Unlike the ADSL[2+] service with which we are all familiar, the VDSL2 service between the FTTC DSLAM and the active CPE (the HG612 modem) uses PPPoE, not PPPoA. Hence ATM cells are not part of the picture . . .

(I hope I've got that right.)
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

Bald_Eagle1

  • Helpful
  • Kitizen
  • *
  • Posts: 2721
Re: CRC, FEC, HEC Error count
« Reply #14 on: November 03, 2011, 07:20:48 AM »

Hi b*cat,


Looking back to your post where you commented and asked --

Quote
Just a final thought (anyone?), I am not aware that the master socket (replaced & repositioned by the FTTC installing engineer) has been tested.
Could a filtering or other "fault" there cause such issues, & how could I test it?

-- we see that statement isn't strictly correct. The original NTE5/A has been left in situ and a new NTE5/A has been fitted downstairs in your office's "wiring closet". So you can test to see if the original NTE5/A is having any influence by removing the lower front half face-plate from the SSFP which is fitted to the new NTE5/A. By doing that, you will have disconnected all telephony sockets. (Almost a veritable rats nest, I shall say.  :tongue:  )


Just to clarify, that's what I meant I had done when I said I disconnected everything for a week during the "troubles".

TBH, I haven't tried it again since my line appears to have become stable, but I will do so.

The installation engineer was going to fix the new NTE5/A backing box to the wall, or the side of the built-in cupboard in my office, but I asked him not to do so.
He wasn't really happy about leaving it floating, but I convinced him that I would be removing the cupboard & repositioning everything on the wall (including the new NTE5/A) as part of my refurbishment works & that I would take all responsibility for anything that might happen due to leaving a floating socket.

I don't know if he removed the surge suppressor, resistor and capacitor from the old NTE5/A, but I could check later on.

Regardless of whether other engineers would have done it differently or not, it all worked perfectly for the 1st month, & none of the engineers have suggested it needs altering.


Paul.
Logged
Pages: [1] 2 3 ... 6