1 edit | reply to Bicephale
Re: From the ground up!%20.GIF "44068 bytes")
VelCom - Thomson ST5x6 9 Days Average Curve (2008-Nov, 9-17) | 
VelCom - Siemens SS4200 10 Days Averaged Curves | %20.GIF "118531 bytes")
VelCom - Thomson ST546 vs Siemens SS4200 (2008-Nov) | %20.GIF "83016 bytes")
VelCom - SS4200 Cooking Hour Syndrome (2008-Nov, 19-28) |  Siemens vs T···ov) .ZIP 485,882 bytes
Siemens vs Thomson (2008-Nov) | | |
I'm posting a revised version of a previous
graphic to account for its error rate scale;
resolution being fifteen seconds it means a
level equal to 15 is equivalent to one error
per second... The three other illustrations
are resulting from an analysis of my lastest
'DMT' "Diagnosis" log file with the Siemens
SpeedStream 4200 on-line. The 3rd set of
curves is particularily interesting because
it compares it with my SpeedTouch 546v6.
The 4th picture is to shead light on what i
call the "Cooking Hour Syndrome", i've used
graphic editing tricks to bring focus on the
most significant part of the curves, mainly
the Rx (middle) section. I would have liked
to include daily error rates on the graphics
but it appears static numbers are misleading
at best: MoDems react differently to resets
and the false error counter readings upset
the daily error rates quite unpredictably...
I conclude that the best method to compare
DSL devices is through curve supperposition
considering that static numbers alone might
prove to be relatively useless. A set of 'DMT'
captures is provided to the attention of any
reader who's curious enough to attempt his
own separate analysis. |
|
| said by Bicephale:I conclude that the best method to compare DSL devices is through curve supperposition considering that static numbers alone might prove to be relatively useless. A set of 'DMT' captures is provided to the attention of any reader who's curious enough to attempt his own separate analysis. I've found it difficult to use any captured statistics to compare two modems or even to compare different firmware versions on the same modem. Noise tends to be random for me. Sure, there's the predictable 'cooking hour' noise surge; but I've also seen the 'morning shower hour' noise surge and even the 'midnight madness' noise surge. Some weeks the stats are worse than average, some weeks they are better. I believe that even the weather plays a part in the performance of the modem. Unless there were a way to hook up two modems to the same line at the same time - how can we be sure that the statistics we collect for each unit under test were taken under the exact same conditions? |
|
| %20.GIF "63056 bytes")
VelCom - SS4200 Long-Term Analysis (2008-Nov, 19-28) | 
VelCom - Siemens SpeedStream 4200 MoDem Reset | 
VelCom - 'DMT v9.01' Capture (End of Test) |
Oh... I didn't think of the MidNight MadNess Syndrome
but most people would use batteries for that, after all!
Well, i do remember that your error rate was significant
(if not severe) so maybe when you observe instabilities
it just might be the case, actually. I wouldn't pretend i
follow laboratory-grade methodology here but i feel that
averaging fifty-thousand-six-hundred samples (one per
fifteen seconds for ten days) as i've done lately should
help to reject marginal events... The most potent ones
can still be equivalent to millions of CRC errors per day
so a few of these will contaminate a curve all right but
they tend to be quite brief and they're easy enough to
recognize anyway. The animated .GIF shown above was
made after marginal events were removed as 'GNUmeric'
won't display the curve's most significant part otherwise:
large numbers completely upset its auto-scale feature as
i explained in a previous post. The rest was done using a
graphic editor (no fancy trick)... My 2nd illustration isn't
well detailed but we can see the counter values may fall
in the four digits range if a MoDem Reset event occurs...
There must be a way to filter out contaminating events
in a spreadsheet but i don't know how to do that. What
we have here is a simple approximation, some educated
guess one might say. The 'DMT' capture was suggesting
an error rate of about 1978 CRC Errors per Day, which is
37 % higher than my estimated 1238 CRC Errors per day,
possibly because of contamination. This pleads in favour
of long-term averaging curves instead of static numbers
once again, in my opinion.
 |
|
| N.B.:
The 'PureOS-Light' Live CD with 'GNUmeric'
installed on it is available as an English CD:
'PureOSlight 0.3 beta 1 EN' (Torrent) |
|
|
|
| %20.GIF "82399 bytes")
VelCom - Thomson ST516v6-2 (2008, Nov-30 to Dec-10) | 
VelCom - Thomson ST516v6-2 vs SS4200 |
|
|
|
Here's the original 'DSL_StatScope' data with a graphic capture:
%20.GIF)
Click here to enlarge!
The picture is from this thread:
TekSavvy Forum, Yet Another Modem Statistics tool, Bicephale, 2008-Dec-14 |
|
1 edit | Have a nice 2009 year everyone...
Looking at this old post i just noticed how the "Sweet Spots" differ:
%20Gif%20Animation%20.GIF)
From the ground up!, Bicephale, 2008-Aug-26
Tones: Register '00' = #40)h
DownStream Bitrate & RCO: Register '00' = #80)h
DownStream SNRM: Register '00' = #C0)h
Of course, the absolute values for Register '00' depend on local conditions...
 |
|
| 
'RouterStats v4.8' Setup for GNet GBB2060-Xi (real-life tutorial example) |
I revisited 'RouterStats' lately, it's most regrettable
we don't see it being more popular and especially in
the cases where the MoDem seems to be orphaned
by all of the other 3rd-party trouble-shooting tools!
Isn't it?!...
 |
|
%20.GIF)