how-to block ads
|
klui
join:2001-11-08
San Jose, CA
|  VCC-1 Rx errors
Hi:
I have SBC DSL in the SF Bay Area (San Jose). I have filters installed on 4 telephones. Current speed as indicated by the Netopia Cayman 3546 router:
Cayman 3546 WAN: ADSL LAN: 4-port Switch
Running Cayman OS version 6.4.0 (build R2)
.
.
.
DSL Statistics:
Type : ALC MULTI-MODE CP
Datapump HW Rev : ff
Datapump FW Rev : 3.9.16
Datapump Vendor ID : ffff
Current Status : LINK UP
Operating Mode : G.DMT
Data Path : Fast
Downstream Upstream
Current Rate : 3008 Kbps 416 Kbps
Maximum Rate : 5013 Kbps 832 Kbps
Noise Margin : 16.5 dB 21.0 dB
Attenuation : 28.5 dB 12.5 dB
Out Power : 16.0 dB 10.0 dB
Near Far
FEC Counts Fast : 0 0
CRC Counts Fast : 316 0
HEC Counts Fast : 245 1
ATM port status : Cell delineation achieved
Rx data rate (bps) : 3008000
Tx data rate (bps) : 416000
ATM Virtual Circuits:
VCC # Type VPI VCI Bound Encapsulation
----- ---- --- ----- ----- --------------------------
1 PVC 0 35 Yes PPP over Ethernet (LLC/SNAP encapsulation)
I am noticing that there are receive errors further down in the status page.
ATM Traffic Parameters:
VCC # Tx Priority Tx Rate Limit
----- ----------- -------------
1 High None
ATM Port Statistics:
Cell lock lost : 0
PHY down : 0
ATM Circuit Statistics:
VCC-1
------
Rx Frames : 109771 Tx Frames : 81907
Rx Octets : 76246532 Tx Octets : 29527301
Rx Errors : 44 Tx Errors : 0
Rx Discards : 0 Tx Discards : 0
No Rx Buffers : 0 Tx Queue Full : 0
Rx Errors creeps up and I get around 3 or 4 errors each time I do a DSL speed test with no other traffic. When I generate a good amount of traffic (probably not maxed out) the stat also goes up. Should I be concerned? My speed test is roughly 2.3-2.4Mbps down (overhead goes up to 2.7Mbps), 340Kbps up.
I have posted this to the SBC Direct forum and the replier thinks that this is OK, as long as the discards are 0. Probably the RT is transmitting them at the ATM level.
Thanks for any insights. | |
dgilbert
Good Bye My Friend
Premium,MVM
join:2002-06-15
none
clubs:
| i would not worry about it unless you start seeing a problem. a few errors are to be expected at higher data rates. as long as it does not increment rapidly and constantly, ignore it.
--
If you can read this, thank a teacher..........and since it's in English, thank a soldier. | |
klui
join:2001-11-08
San Jose, CA | Thanks for the reply. My concern now is more towards the Cayman decaying noise margin that people have been experiencing. | |
d_l
Barsoom
Premium,MVM
join:2002-12-08
Reno, NV
| reply to klui
If you don't see any drop in your noise margin after say maybe six or seven days continuous sync, then you probably don't have anything to worry about.  For the most part, people who have had the noise margin decay notice the drop starting within a couple of days. | |
klui
join:2001-11-08
San Jose, CA
| I don't have a decaying margin, but I have creeping CRC and HEC counts (based on your Cayman logging script):
1089434407,3008,416,5469,832,16.5,21.0,29.5,12.5,16.0,12.0,0,65,28927,36,21184,
1089434708,3008,416,5469,832,16.5,21.0,29.5,12.5,16.0,12.0,0,65,29124,36,21338,
1089435008,3008,416,5469,832,16.5,21.0,29.5,12.5,16.0,12.0,0,65,29285,36,21460,
1089435309,3008,416,5469,832,16.5,21.0,29.5,12.5,16.0,12.0,0,65,29462,36,21601,
1089435609,3008,416,5469,832,16.5,21.0,29.5,12.5,16.0,12.0,0,65,29657,36,21741,
1089435910,3008,416,5469,832,16.5,21.0,29.5,12.5,16.0,12.0,0,68,29839,36,21893,
1089436210,3008,416,5469,832,17.0,21.0,28.5,12.5,16.0,10.0,0,0,17,0,15,
1089436511,3008,416,5469,832,17.0,21.0,28.5,12.5,16.0,10.0,0,0,58,0,45,
1089436811,3008,416,5469,832,17.0,21.0,28.5,12.5,16.0,10.0,0,0,94,0,71,
| |
d_l
Barsoom
Premium,MVM
join:2002-12-08
Reno, NV
| reply to klui
This is interesting. Those CRC and HEC errors are "far", right? I've not seen situations where the far counts increase so much faster than the near. I think that means the errors are being injected near/at your RT on its receiving end rather than near/in your residence on the download side (I'm guessing that you have an RT connection from your download output power). Another interesting thing is that your upload output power dropped after that re-train (the Link Loss Of Sync failure). I've only seen power outputs fluctuate by 0.5 dBm on the upload side.
The CRC rate is about 200 or less per five minute sample interval. I think that would only amount to about 2% or so loss of upload throughput, but you also have a HEC error rate of about 150 per five minutes. I don't know how that rate would affect throughput. I don't think these errors would be serious unless they cause frequent retrains. Are you re-training often?
You could collect the stats for a few days and plot the results to see if there is any change over time or if these error rates seem constant. I'd be happy to plot them for you if you would post your stats data file here. | |
klui
join:2001-11-08
San Jose, CA
| Hi d_l:
Thanks for your insights. The script for some reason is not writing HEC counts far (running in -runonce works fine). The high numbers are "Near"s. Last 5 statistics are:
FEC counts near
FEC counts far
CRC counts near
CRC counts far
HEC counts near
Right now my numbers are
1089490592,3008,416,5469,832,17.0,21.0,28.5,12.5,16.0,10.0,0,12,8608,4,6252,
This is roughly 15 hours since the last LOS failure.
Yes, I'm on an RT. The retrains have happened about once per day, although I believe yesterday it happened more often--perhaps 2 times. I cannot recall now because the script injects admin login and my stats for the retrains have scrolled off.
My throughput is not too negatively affected although I'm sure that it isn't what it could potentially be. By the way, I got a Link LOF Failure in the past. Do you know does that means? Could it say that if I manually disconnect the DSL line? I did that to switch a cable thinking i have a bad cable.
I will keep on collecting and will post after a week or so.
Thanks again. | |
d_l
Barsoom
Premium,MVM
join:2002-12-08
Reno, NV
| reply to klui
There is probably a bug in the script or maybe in the caymanrc file to drop that last HEC count far.  Yeah, the "flooding" of the router logs with those admin logins is one draw back of running it. Whenever you retrain, at least the stats collection will record it because the error counters will be reset, but you won't know the cause.
Just replace everything I mentioned before about uploads with downloads. Maybe you have some RFI source at or near your residence that is generating those errors. From that little snippet of stats you posted it seems a fairly continuous source, something like a continuously running motor or a light on a dimmer switch perhaps. The modems are supposed to retrain if the errored seconds or severe errored seconds exceed some rate. Errored seconds are one CRC error or one of several other type of errors per time interval.
Just guessing but LOF may be Loss of Framing (or Frame). | |
klui
join:2001-11-08
San Jose, CA
| Hi:
Your comment made me review all my telephone lines. I disconnected all phone lines and the router retrained. Then I was greeted w/ the following stats:
1089532355,3008,416,8847,832,21.5,21.0,20.5,10.5,5.0,10.5,0,0,0,0,0,
1089532655,3008,416,8847,832,21.5,21.0,20.5,10.5,5.0,10.5,0,0,0,0,0,
1089532956,3008,416,8847,832,21.5,21.0,20.5,10.5,5.0,10.5,0,0,0,0,0,
1089533256,3008,416,8847,832,21.5,21.0,20.5,10.5,5.0,10.5,0,0,0,0,0,
Connection has been up for around 3 hours and the stats are:
1089533857,3008,416,8847,832,21.0,21.0,21.5,10.5,5.0,9.5,0,0,0,0,0,
1089534161,3008,416,7161,832,18.5,21.0,28.5,12.0,6.5,10.5,0,0,0,0,0,
1089534464,3008,416,7161,832,18.5,21.0,28.5,12.0,6.5,11.0,0,0,0,0,0,
1089534767,3008,416,7161,832,18.0,21.0,28.5,12.0,6.5,11.0,0,0,0,0,0,
1089535068,3008,416,7161,832,18.0,21.0,28.5,12.0,6.5,11.0,0,0,0,0,0,
1089535368,3008,416,7161,832,18.0,21.0,28.5,12.0,6.5,11.0,0,0,0,0,0,
1089535669,3008,416,7161,832,18.0,21.0,28.5,12.0,6.5,11.0,0,0,0,0,0,
1089535970,3008,416,7161,832,18.0,21.0,28.5,12.0,6.5,11.0,0,0,0,0,0,
1089536270,3008,416,7161,832,18.0,21.0,28.5,12.0,6.5,11.0,0,0,0,0,0,
1089536571,3008,416,7161,832,18.0,21.0,28.5,12.0,6.5,11.0,0,0,0,0,0,
1089536871,3008,416,7161,832,18.0,21.0,28.5,12.0,6.5,11.0,0,0,0,0,0,
1089537172,3008,416,7161,832,18.0,21.0,28.5,12.0,6.5,11.0,0,0,0,0,0,
1089537472,3008,416,7161,832,18.0,21.0,28.5,12.0,6.5,11.0,0,0,0,0,0,
1089537772,3008,416,7161,832,18.0,21.0,28.5,12.0,6.5,11.0,0,0,0,0,0,
1089538073,3008,416,7161,832,18.0,21.0,28.5,12.0,6.5,11.0,0,0,0,0,0,
1089538373,3008,416,7161,832,18.0,21.0,28.5,12.0,6.5,11.0,0,0,0,0,0,
1089538674,3008,416,7161,832,18.5,21.0,28.5,12.0,6.5,11.0,0,0,0,0,0,
1089538974,3008,416,7161,832,18.0,21.0,28.5,12.0,6.5,11.0,0,0,0,0,0,
1089539275,3008,416,7161,832,18.0,21.0,28.5,12.0,6.5,11.0,0,0,0,0,0,
1089539575,3008,416,7161,832,18.0,21.0,28.5,12.0,6.5,11.0,0,0,0,0,0,
1089539876,3008,416,7161,832,18.5,21.0,28.5,12.0,6.5,11.0,0,0,0,0,0,
1089540176,3008,416,7161,832,18.0,21.0,28.5,12.0,6.5,11.0,0,0,0,0,0,
1089540476,3008,416,7161,832,18.0,21.0,28.5,12.0,6.5,11.0,0,0,0,0,0,
1089540777,3008,416,7161,832,18.0,21.0,28.5,12.0,6.5,11.0,0,0,0,0,0,
1089541077,3008,416,7161,832,18.0,21.0,28.5,12.0,7.0,11.0,0,0,0,0,0,
1089541378,3008,416,7161,832,18.0,21.0,28.5,12.0,7.0,11.0,0,0,0,0,0,
1089541678,3008,416,7161,832,18.0,21.0,28.5,12.0,6.5,11.0,0,0,0,0,0,
1089541979,3008,416,7161,832,18.0,21.0,28.5,12.0,7.0,11.0,0,0,0,0,0,
1089542279,3008,416,7161,832,18.0,21.0,28.5,12.0,7.0,11.0,0,0,0,0,0,
1089542580,3008,416,7161,832,18.0,21.0,28.5,12.0,7.0,11.0,0,0,0,0,0,
1089542880,3008,416,7161,832,18.0,21.0,28.5,12.0,7.0,11.0,0,0,0,0,0,
1089543180,3008,416,7161,832,18.5,21.0,28.5,12.0,7.0,11.0,0,0,0,0,0,
1089543481,3008,416,7161,832,18.5,21.0,28.5,12.0,6.5,11.0,0,0,0,0,0,
1089543781,3008,416,7161,832,18.0,21.0,28.5,12.0,6.5,11.0,0,0,0,0,0,
1089544082,3008,416,7161,832,18.0,21.0,28.5,12.0,6.5,11.0,0,0,0,0,0,
1089544382,3008,416,7161,832,18.0,21.0,28.5,12.0,6.5,11.0,0,0,0,0,0,
1089544683,3008,416,7161,832,18.0,21.0,28.5,12.0,6.5,11.0,0,0,0,0,0,
1089544983,3008,416,7161,832,18.0,21.0,28.5,12.0,6.5,11.0,0,0,0,0,0,
1089545284,3008,416,7161,832,18.0,21.0,28.5,12.0,6.5,11.0,0,0,0,0,0,
1089545584,3008,416,7161,832,18.0,21.0,28.5,12.0,6.5,11.0,0,0,0,0,0,
The other thing about the script injecting logs is would it be possible to not log off? As long as the commands are sent before the telnet session times out, the connection should stay alive. You can have multiple connections into the admin account so you won't have to worry about tying up the "console."
Thanks for your help! | |
d_l
Barsoom
Premium,MVM
join:2002-12-08
Reno, NV
| reply to klui
Other Cayman users have shown the CRC counter "wraps" at 65535 and resets to zero without a re-train. I wonder why yours would have that 30K limit.
Actually the script doesn't log off with "quit". It just keeps logging in repeatedly to keep its programming simple. Do you have any idea what the time out duration is for Cayman telnet sessions? | |
klui
join:2001-11-08
San Jose, CA
| Only way to check the timeout is to test it. I'll check it out.
If the counters wrap, then it may be due to the unfiltered phone. I found that if I plug/unplug the phones, sometimes I would get a re-train. Those errors definitely increase as I plug/unplug. | |
klui
join:2001-11-08
San Jose, CA |  reply to d_l
Looks like the timeout is 15 minutes. Unfortunately, there's no way to change it from the cli. | |
klui
join:2001-11-08
San Jose, CA
3 edits | reply to klui
The reason why the script didn't print hec_counts_far is because the default caymanrc didn't have a , at the end of the stats line. I have patched the script to not relogin if the interval is less than 15 minutes. Will post followup in d_l's original thread. | |
d_l
Barsoom
Premium,MVM
join:2002-12-08
Reno, NV
| reply to klui
Are you using Cygwin? The default caymanrc collected all the stats for me without the trailing "," when I used it with the Cygwin Perl, but perhaps it works a little differently with a true Linux version. I'm glad that you were able to get all the stats collected.
Unplugging the DSL modem and breaking the circuit to it for just a brief instant will force a re-train. Maybe if your inside wiring is daisy chained, the unplugging/replugging of a phone sometimes breaks the circuit to the modem "on down the line". So you are not getting the continuous CRC and HEC errors now that you have filtered the one previously unfiltered phone? | |
klui
join:2001-11-08
San Jose, CA
| Actually, I'm using cygwin, but have updated my installation just before I started running your script because I didn't have Perl installed. My config uses UNIX text file format instead of MS-DOS. Maybe it has something to do with that.
Yes, my errors are now minimal. I also redid my splitter jack (long irrelevant story) configuration. Perhaps the two helped. I'm sure the filter to the phone helped the most. I do get some errors, but it's once/twice per 14 hours.
1089581921,3008,416,7161,832,18.5,21.0,28.5,12.0,8.0,12.0,0,0,2,0,1,0,
1089582058,3008,416,7161,832,18.5,21.0,28.5,12.0,8.0,12.0,0,0,2,0,1,0,
1089582358,3008,416,7161,832,18.5,21.0,28.5,12.0,8.0,12.0,0,0,2,0,1,0,
1089582659,3008,416,7161,832,18.5,21.0,28.5,12.0,8.0,12.0,0,0,2,0,1,0,
1089582959,3008,416,7161,832,18.5,21.0,28.5,12.0,8.0,12.0,0,0,2,0,1,0,
1089583259,3008,416,7161,832,18.0,21.0,28.5,12.0,8.0,12.0,0,0,2,0,1,0,
1089583559,3008,416,7161,832,18.5,21.0,28.5,12.0,8.0,12.0,0,0,2,0,1,0,
1089583860,3008,416,7161,832,18.0,21.0,28.5,12.0,8.5,12.0,0,0,2,0,1,0,
1089584160,3008,416,7161,832,18.5,21.0,28.5,12.0,8.0,12.0,0,0,2,0,1,0,
1089584460,3008,416,7161,832,18.5,21.0,28.5,12.0,8.0,12.0,0,0,2,0,1,0,
1089584760,3008,416,7161,832,18.5,21.0,28.5,12.0,8.0,12.0,0,0,2,0,1,0,
| |
d_l
Barsoom
Premium,MVM
join:2002-12-08
Reno, NV
|  reply to klui
Well cool. So I take it without the error build up you aren't re-training. The data collection script helped a little bit here by showing that you had a relatively constant CRC error rate even though you didn't have a noise margin decay. | |
klui
join:2001-11-08
San Jose, CA | Yes, the script definitely helped.
I won't know until my IP doesn't change after 48 or 72 hours. But so far, the numbers look good.
This goes to prove, even if you're not having trouble others are experiencing, it pays to keep track. | |
|
