Bicephale
join:2005-09-24
 ·TekSavvy Solutions..
| reply to Bicephale
Re: From the ground up!
'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?!...
 |
|
Bicephale
join:2005-09-24
·TekSavvy Solutions..
1 edit | reply to Bicephale
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...
 |
|
Bicephale
join:2005-09-24
·TekSavvy Solutions..
| reply to Bicephale
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 |
|
Bicephale
join:2005-09-24
·TekSavvy Solutions..
| reply to Bicephale
%20.GIF "82399 bytes")
VelCom - Thomson ST516v6-2 (2008, Nov-30 to Dec-10) | 
VelCom - Thomson ST516v6-2 vs SS4200 |
|
|
Bicephale
join:2005-09-24
·TekSavvy Solutions..
| reply to Bicephale
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) |
|
Bicephale
join:2005-09-24
·TekSavvy Solutions..
| reply to tertech
%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.
 |
|
tertech
join:2008-04-12
Ottawa, ON
| reply to Bicephale
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? |
|
Bicephale
join:2005-09-24
·TekSavvy Solutions..
1 edit | reply to Bicephale
%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. |
|
Bicephale
join:2005-09-24
·TekSavvy Solutions..
| reply to Bicephale
%20.GIF "23122 bytes")
VelCom - Cooking Hour Syndrome 2 (2008-Nov, 9-17) | 
VelCom - Noise Induction Path |
1) SNR Margin is still relatively clueless
2) Noise Induction Path now confirmed
3) Cooking Hour Syndrome is revealed!
The Noise Induction Path was ten feet
long and it's now practically reduced to
zero by moving the line away from that
nasty PVC power conduit. The old wire
with paint on it is mine, at least i didn't
get the one with a loop... Oh lucky me!
If one must trouble-shoot i recommend
using long-term noise curve averaging.
 |
|
Bicephale
join:2005-09-24
·TekSavvy Solutions..
| reply to Bicephale
 .GIF/thumb.jpg "130631 bytes")
Click here to zoom in! |
This six days .GIF animation shows how clueless SNR Margin curves
can be. It's also demonstrating the power of long-term averaging...
|
|
Bicephale
join:2005-09-24
·TekSavvy Solutions..
| reply to Bicephale
Linux solutions: 'OpenOffice Calc' vs 'GNUmeric' |
|
|
Bicephale
join:2005-09-24
·TekSavvy Solutions..
| reply to Bicephale
'Scientific Linux DVD v5.2' vs SS4200+'DMT v9.01' |
'OpenOffice Calc v2.3.0' from 'Scientific Linux Live DVD v5.2'
didn't display the same bug as that which i observed using its
late Windows version: i can add/fill the required columns and
produce a suitable graphic representation under this Live DVD,
including the DSsnr column which was being corrupted before. |
|
Bicephale
join:2005-09-24
·TekSavvy Solutions..
| reply to corkyy
Hi Corkyy,
I've tried 'KSpread' (the 'KOffice' SpreadSheet application) on
three different Linux Live CDs including 'KOffice v1.6 Live CD'
and it's consistently slow: each column filling would make it
too busy to respond for the next twenty minutes or so at max.
resolution (a fifteen seconds interval means over five thousand
samples per day)! The Linux flavours were KUbuntu, Fedora and
SlackWare so the environment isn't really a determining factor.
I found 'GNUmeric' installed on the 'PureOS-Light' Live CD but
this one got a French-European keyboard layout which was a
pure nightmare... I'd hate having to install MicroSoft's 'Excel'!
Maybe i need to reduce the file size by cutting a few columns. |
|
Bicephale
join:2005-09-24 | reply to corkyy
Hi Corkyy,
Thanks! It must be possible to find a 'KOffice' module
for the Slax Linux Live CD so i'll check with that one.
|
|
corkyy
join:2008-06-01
Laval, QC
·TekSavvy Solutions..
·ELECTRONICBOX
·Bell Sympatico
| reply to Bicephale
»www.koffice.org/releases/2.0beta···ease.php
Maybe koffice, but I never done the setup in windows...
»www.gnome.org/projects/gnumeric/···ds.shtml
Same for this one |
|
Bicephale
join:2005-09-24
·TekSavvy Solutions..
| reply to Bicephale
Bug exposed in 'OpenOffice v2.4.1' and more!
My partial representation of a recent 'DMT' capture reveals
some flawed logic in 'OpenOffice Calc': quite clearly, there
are errors in the "DSsnr" column which seem to affect the
"txHEC" column as well. This doesn't explain the odd value
found in the "txHEC" column (time index 1222864053): the
counter went backwards, which points either at a problem
in the Siemens SS4200 MoDem/Router, 'DMT v9.01' itself
or a combination of both (corrupted exchange via TelNet).
In one case the errors are generated in 'OO Calc' alone but
in the other its originating from the "Diagnosis" capture file.
Can anyone suggest alternative FreeWare SpreadSheets!?
|
|
Bicephale
join:2005-09-24
·TekSavvy Solutions..
1 edit | reply to Bicephale
%20.GIF "319854 bytes")
VelCom - DSL Reports Test Results (2008-Sep-23) |  .GIF/thumb.jpg "19226 bytes")
VelCom - Bell's portal (ST546, 2008-Sep-18 20h33) | %20.GIF "46552 bytes")
VelCom - Latency & Speed (FW v6.1.0.5-AA, #C0h) |  .GIF/thumb.jpg "19169 bytes")
VelCom - Bell's portal (ST546, 2008-Sep-18 21h54) | %20.GIF "46748 bytes")
VelCom - Latency & Speed (FW v6.1.0.5-AA, #C8h) |  .GIF/thumb.jpg "19172 bytes")
VelCom - Bell's portal (ST546, 2008-Sep-18 23h45) | %20.GIF "47001 bytes")
VelCom - Latency & Speed (FW v6.1.0.5-AA, #40h) |
These additions end what i consider to be the
preliminary phase of this thread, which was to
establish an acceptable test-bench for future
evaluations... The present set is particularily
puzzling because of the paradoxal relationship
between the connection's rate and the browser
(final) speed, not to mention the way a lower
CRC Error rate fits into the overall picture.
Here's a perfect opportunity to refer to this:
Speed slower than expected (Elite), d_l, 2007-Sep-16
I'm confident this graphic is right on topic here.
As a conclusion about the "rescue" tweaks, i'm
tempted to declare that the Thomson SpeedTouch
5x6v6 device displayed a superior potential if
compared to GNet's BB0060B/GBB2060-Xi units.
Most unfortunately, i was forced to DownGrade
my ST's FirmWare for a total of eleven levels just
to find one which is 'DMT'-friendly enough to
support the required MoDemOption feature! No
MoDem including my Siemens SpeedStream 4200
has been able to fall-back gracefully down to the
required connection speed; it appears all of those
products are targeting an SNR Margin level instead
of some tolerable amount of noise. I guess that
this could be corrected but lets not count on it...
In any case, the ST5x6v6 owners in a similar
situation should consider these few options:
1) Fix the noise problem at the source
2) Move the DSL device away from noise
2) Simply switch to an inferior profile
4) Tweak using 'DMT' + FW v6.1.0.5-AA
Finally, trouble-shooting being essential for
people experiencing hard-to-solve issues such
as this one, i wish to point at a useful link:
%20Diagnosis%20feature%20.GIF)
Use DMT Tool to log your Line Stats
This fine article describes how to unleash the
professional-grade trouble-shooting power
which happens to be hidden within 'DMT'...
Enjoy your reading!
|
|
Bicephale
join:2005-09-24
·TekSavvy Solutions..
| reply to Bicephale
%20.GIF "57823 bytes")
VelCom - Hybrid Stats (FW v6.1.0.5-AA, #D8h) | %20.GIF "57291 bytes")
VelCom - Hybrid Stats (FW v6.1.0.5-AA, #C8h) | %20.GIF "57337 bytes")
VelCom - Hybrid Stats (FW v6.1.0.5-AA, #B8h) |
Well, here are three easy to compare blocs
of concatenated statistics, the tests were
conducted on September 16 during one of
many crisis periods where noise was severe
enough to totally disrupt my DSL connection
unless i used some tweak trick. This noise
issue was finally solved when i understood
the true nature of the noise source, after
two months of trouble-shooting: i live on
the 2nd floor and i had installed the MoDem
on the kitchen countertop, most likely just
a few feet right above a dimmer-controlled
lamp in my neighbour's kitchen, downstairs.
I figure this light bulb was turned on when
dawn arrived (apparently once a TV program
started) and it usually went off before 0 h
but not always. With this in mind, i moved
my DSL unit to a higher location which is a
few feet away from the previous point and
this reduced noise to a manageable level...
In any case, my three samples are far from
sufficient to draw definitive conclusions
but they point at some interesting problem:
what influence does noise have over final
"browser" speed? Hummm... My middle tweak
was the worst in terms of CRC Errors and it
only displayed a marginal advantage over my
lowest JAVA speed test so i'd say this must
confirm there are two elements to trade-off
(read optimize). A higher connection rate
may compensate for noise up to a point, it
must be a bell-shaped relation and i wonder
which tweak corresponds to the sweet-spot.
Lets not forget that noise may vary through
time. Perhaps dimmed-lamp originated noise
is roughly constant but not necessarily the
other sources... The dimmer noise probably
raised the noise floor every single evening
and yet this middle sample may have simply
happened to record a noise burst of different
origin. In short, multiple samples should be
used to null-out marginal events, ideally...
Plenty of fun to have on rainy evenings!
|
|
Bicephale
join:2005-09-24
·TekSavvy Solutions..
| reply to Bicephale
%20.GIF "78511 bytes")
VelCom - Thomson ST546v6 (RSL v3.6, 2008-Sep-23) | %20.GIF "5002 bytes")
VelCom - ST546v6 (DMT & OpenOffice Calc, 2008-Sep-23) | %20.GIF "37104 bytes")
VelCom - Test Results (Thomson ST546v6 FW v6.1.0.5-AA) | |  .GIF/thumb.jpg "19116 bytes")
VelCom - Bell's portal (ST546, 2008-Sep-23 20h59) |
More details available here:
»/testhistory/1267354/b1adc |
|
Bicephale
join:2005-09-24
·TekSavvy Solutions..
1 edit | reply to Bicephale
 .GIF/thumb.jpg "87210 bytes")
VelCom - GNet GBB2060-Xi (Major Failure, 2008-Sep-3) |  .GIF/thumb.jpg "86439 bytes")
VelCom - GNet GBB2060-Xi (Rescue Tweak, 2008-Sep-5) |
These two graphics should provide a more complete
perspective about some variations i observed during
the normal vs tweaked periods. For example, there's
been a lot of noise past midnight on September 2 (a
previous post) and 3 when compared to September
5; as for the tweaks, maybe that's pure coincidence
but i've recorded an average error rate of 67756 CRC
Errors/Day for the later tweak while i had 308324 (a
variation which is over 400 %) three days before! It
could result from the connection speed - or possibly
different Bits/Bin settings. I'm forced to wonder!...
In any case, my impression is that this corresponds
to human activity and that some person's activities
happen to be strongly influenced by T.V. schedules!
|
|
%20.GIF)
%20.GIF "25546 bytes")