Print

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

[renluop]

Sorry to confuse, but they were taken from the CRC HTML data.

[roseway]

The result of a short burst of interference from somewhere, probably. Really, those levels of CRCs for a brief period are nothing to be concerned about.

[renluop]

Thank you!

[renluop]

In end went for interleaving ( which has been set at depth 64, wahtever  that means).

I don't know if it's a glitch in Dslstats, but I reset the error summary only minutes ago, but the averages (att'd) look a little odd.

[rhohne]

High averages can be due to a negative delta in either the upstream or downstream counter, the side effect of this is that  <average>*<time since averages reset> = <counter value> and not the value expected.

[renluop]

The only deltas I know are those I got for sport and PE and that at the Nile's mouth . It's renluops education time again.

[rhohne]

<delta> = <new value> - <old value>.

I had a blip on the upstream RSUncorr counter where the counter contained a number for several minutes then returned to zero.
The averages displayed were correct until the counter returned to zero and then from that point were miles to high.

Modem: DG834GT with DGTeam Rev. 1018 , driver version 026. Reverted to 023o driver and haven't seen the problem since.

[renluop]

TG 582N here v10.2.2.B, so is it the router causing the problem, or can I do anything within Dslstats to clear the erroneous readings? I have no desire to wind back the router. 10.2.2.B is good.

[roseway]

TG 582N here v10.2.2.B, so is it the router causing the problem, or can I do anything within Dslstats to clear the erroneous readings? I have no desire to wind back the router. 10.2.2.B is good.

The current version of DSLstats doesn't handle average error rates very well when things happen which are outside the normal progression. I'll be uploading a new version soon, and this has much improved handling of errors, and will hopefully deal with this issue.

[renluop]

Thanks! That it's not me, is a wonder!

[renluop]

Looks too that the change has affected the bit loadings. What would be effect of that?

[roseway]

You can't read too much into that, because bitloading changes continuously. However the new values look 'better' in that there are fewer gaps, but I doubt that this is the result of interleaving (although I could be wrong). The effect of improved bitloading would be slightly better performance (higher SNRM or higher connection speed).

[kitz]

The improved bit loading is very likely to have been a result of a resync.

As eric says bitswapping occurs continuously.   Sometimes if a fair bit of bitswapping has been going on then the bitloading table looks less smooth.     Noise spikes at a particular frequency can clear  any bits loaded into that subchannel as they are swapped out to another subchannel.

Interleaving and Error Correction is a separate process, but if anything, with interleaving you will let slightly less overall bits allocated.  Again as eric infers -  improved bitloading is a result of better physical line conditions.