Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[roseway]

Thanks for the comments. I'll see if I can fit the interleave status into the status bar, but in the meantime you can see the interleave depth values on the Stats tab.

[les-70]

  The behavior with standby is much better but I think there is an odd glitch- see day1 traces. It is probably not worth more than light investigation (it is definitely not a resync).  day2 looks better.  I assume the value of crc error during a standby interval corresponds to the first value on resuming or last value before standby.  The result looks odd with low error rates but the bitswap traces show it is probably best. 

  Just one suggestion.  Might it be possible put the error second rate/min on display the status bar along with speeds and snrs.  There is not room for much but I think the es/min is fair summary of error rates which works for fast path and I think on  interleaved?

[roseway]

I assume the value of crc error during a standby interval corresponds to the first value on resuming or last value before standby.  The result looks odd with low error rates but the bitswap traces show it is probably best.

The standby period is handled in the same way as a recording pause: at the end of the pause/standby period, the last recorded value is repeated to fill in the gap, and it's supposed to be plotted in dotted lines.

Just one suggestion.  Might it be possible put the error second rate/min on display the status bar along with speeds and snrs.

I'll see what I can do. As you say, there's not much room, but maybe I can jiggle things around to fit.

[ColinS]

As we're not entirely sure what the router is reporting, I'm going to offer two alternative ways of dealing with the situation of the reported CRC total in a sample being less than in the previous sample:

1. Zero values will be plotted instead of negative values (the default option)
2. Negative values will be converted to positive values

There will be an extra option on the Graphs configuration page to make this choice.

Eric,

I can't give you conclusive proof of this, other than the obvious, but I believe that I saw a similar issue with the Bitswap/min graph having -ve values on the y axis in 2.7.3.  In 2.8, they are flat-lined zero.  The Bitswap/tone graph, and common sense, suggest that it's (almost) never zero, so is this another example of receiving bad data on the sampling intervals?   Cetainly the bitswap (total) counts from xdslcmd are not zero.

It's not a big deal at all, more of a minor inconvenience.  And sorry to be a party-pooper, but I'm using the RSW version. 

[c6em]

OK I can reproduce the floating point error I mentioned earlier:

Win XP 32 bit, Dell Dimension 5000 PC, D-link 2740B router, ADSL2+ line.
RS-W running for say 10 minutes, sample rate 30 seconds
Swap to displaying the FEC errors graph tab (Log Y axis scale)
Error occurs after a period of a few minutes.
Error given as  “Invalid floating point operation”
Options are to click “accept and ignore and risk data corruption” or “cancel to exit program”
So I do nothing and wait.
At next sample point ( as shown on top right of window) – program appears to auto-close and exits without me doing anything……..
If instead at this point I rapidly press “accept” before the next sampling then -----it won’t do anything when I click it. ie it just asks me the same question over and over again:  I’m in an endless loop. So I leave it, and then it auto-exits as above at the next sample point.

I don’t get it – it only seems to happen when it’s displaying the FEC graph tab.
I haven’t left it running on all the tabs individually to check everything but say leave it on the SNR margin graph tab and it runs OK for hours…..now swap display to the FEC graph tab and it will fail shortly after.
Snag is you need to be watching it as the nature of the failure and it subsequent auto exit means that if you go away and it fails – all you come back to is a non running program with no evidence as to what happened.

Just now after having had it run for several hours it failed the immediate instant I swapped to the FEC graph tab giving the usual floating point error.

This suggests some problem with plotting the results on the FEC graph tab live on screen as they being sampled. (I think my D/S FEC’s are around 2000/min, U/S are zero)

Can anyone else replicate this?
and goodness knows how you find that one!

[roseway]

Thanks for that detailed description. I've got a glimmer of an idea about this, but I'm not able to test it at this moment. Does the same error occur if the FEC graph is in linear Y axis mode?

[les-70]

  Eric,

     I am puzzled over upstream (green) crc errors in 2.8.  In all previous rs these were rare but now many are reported and I can't see that the graphs match what is reported and the value is always a fixed value or zero!. Before I look harder can you say if anything should have changed?   I attach an example below.  I am running with low downstream snrm today but of course the upstream margin is always about 6.

   Les

[roseway]

Yes Les, I did make a change in v2.8, but I don't know if it explains your result. I realised that there are several routers which don't explicitly report CRC totals, whereas all Broadcom based routers (I think) report SFErr or OHFErr values, which are CRCs under a different name. So that's what I use for the source of the CRC data now. Perhaps I made a false assumption about these values.

At the moment I'm testing a different sort of router, so I can't check this out, but I'll come back to it as soon as I can.

[les-70]

   I have checked and yes they do seem correct c.f. SFErr.      I attach a copy of the telnet stats, it is an Hg622.  If I run 2.73 in parallel started out of phase with 2.8 I just get zero upstream with an odd error so 2.73 is using something else.  I wonder what is correct? It seems strange to see busts of errors with each successive one always bigger.   The values obtained just don't look right for errors.  Some look the same as the one before but they may always be increasing.  I wonder if Broadcom is adding the actual number of errors up to that time to the supposed total when an error occurs.  Looking at the stats for today (see the telenet file or the numbers below) I would have expected upstream CRC to be about ~100 which looking at the snapshot is close to current value.

 CRC:      389      2398
 ES:      333      89

p.s I am now going to reboot the HG622 to check the theory.

[c6em]

Re: The FEC/floating point error situation.

Yes, I think you are on to something there.
I unticked the log Y axis - and obviously unticked the enable clipping box
Now it seems OK in that it works when displaying/runnning the FEC graph tab continuously and does not fail.
So it's something to do with the log calcs in certain circumstances. Indeed if I now tick the 'log box' it leads to instant failure.

However:
Look at the attached plot and you will see the upstream FEC's are recorded as constant -880/min so something very odd is going on there.
The actual current value from the averages tab for U/S FEC is 0.02/min, 1.04 per hour.
Sorry to load problems onto you...............

[roseway]

Sorry to load problems onto you...............

Don't bother about that. If it's not working correctly then I want to fix it. I won't be able to give it any attention for a couple of days, but I will come back to it then.

[les-70]

  Well after running for 4 hours after a reboot I am not much wiser apart from not believing the numbers reported by the modem.  The upstream CRC values in the snapshots don't uniformly ascend but I wonder if that is due to an odd double length sample. They start low and mainly rise with time like they did before.  Looking at the stats the reported upstream HEC (13 in the stats) seem to me to be more like the expected number of CRC.   I will try my DG834G tomorrow to see what that gives! Maybe it is the error reporting in the HG622.

 Do others get unusual upstream CRC with rsw v2.8?

[roseway]

On the status lines at the bottom of the screen where you list DS and US sync & margin maybe at the end you can put if the Channel path is "Fast" or "Interleaved"

I've added the interleave status to the status bar.

I did get a one-off crash event when I swaped the view to the FEC's graph.
It said as I recall floating point error and gave me the option to accept or cancel to end program
I accepted and it exited anyway
Haven't yet repeated it so ignore/store away for future if it rears its head again.
If it happens again I'll be better forwarned to record the exact sequence which led to the occurance.
(This is using the latest edition)

I'm fairly certain that the floating point error is the result of trying to take the log of a negative number. As we discussed, there shouldn't be negative numbers here, because the error totals are cumulative, so it's either misreporting by the router or some intended behaviour which is different from most Broadcom-based routers. As you only seem to get negative numbers occasionally, I suspect that it's a router bug. I've dealt with it by filtering out negative numbers and giving you the option to convert them to zeros or to equivalent positive values. This is of course, the same solution as for rhohne's issue discussed earlier.

By the way, the reason this bug only manifests itself when the FEC graph is visible is most likely a result of the way the OS handles re-draws. The redrawing of the graphs will only happen when the rectangle in question is visible.

[roseway]

Just one suggestion.  Might it be possible put the error second rate/min on display the status bar along with speeds and snrs.  There is not room for much but I think the es/min is fair summary of error rates which works for fast path and I think on  interleaved?

I've managed to squeeze it in.

[snadge]

hey ive just discovered this RS-W program... wished id known about it when i had my HG612..

did you create this program Eric?