| reply to Bicephale
Re: From the ground up! .GIF/thumb.jpg "46917 bytes")
VelCom - DMT (GNet GBB2060-Xi, 2008-Jul-30) |
|
|
|
|
| For the purpose of making comparisons:
%20.PNG)
Tweaks, Bicephale, 2007-Nov-30
Tweaks, Bicephale, 2008-Mar-6
%20.GIF)
Tweaks, Bicephale, 2008-Jul-7
In my present situation the DownStream RCO number
appears to be too high and the rate of "Far CRC" errors
(presently in Interleaved mode) tells me there could be
something wrong. In any case, my previous phone line
generated millions of "Near FEC" errors before and yet
both my GNet MoDems easily handled it so that's why i
think this profile setting is exageratly "conservative"...
Unfortunately, the only way to find out for sure may be
to evaluate multiple profiles until satisfaction is reached. |
|
|  .GIF/thumb.jpg "46651 bytes")
VelCom - DMT Tweak (2008-Jul-31 11h00) |  .GIF/thumb.jpg "19090 bytes")
VelCom - Bell's Portal (GNet GBB2060-Xi, 2008-Jul-31 11h07) |
This 'DMT' capture was taken after the MoDem
settled for one hour, notice the discrepancy in
terms of UpStream Attenuation (caused by my
tweaking, most likely)... This sort of Spectral
Shaping implementation appears to allow a gain
of one (maybe two) dB on the DownStream SNR
Margin side and this tends to confirm an issue
with some UpStream bottleneck, IMHO... Can a
power transformer at the top of Hydro's pole
cause such a problem? I'm afraid it just might. |
|
|  .GIF/thumb.jpg "19070 bytes")
VelCom - ST546v6 FW v7.4.4.7-iA (2008-Jul-31 23h26) |
to observe that everything seems to be OKay by now!
Settle time for this capture was only about two hours,
(it's just for preliminaries), i'll post more details later... |
|
|  .GIF/thumb.jpg "19211 bytes")
VelCom - GNet GBB2060-Xi (Tweak, 2008-Aug-3 11h53) |
such as rain and lightnings have become the norm here!
Perhaps i'll be able to publish one 24 h curve tomorrow... |
|
1 edit |  .GIF/thumb.jpg "99359 bytes")
VelCom - GNet BB0060B (Tweak, 2008-Aug-5) |  .GIF/thumb.jpg "19224 bytes")
VelCom - Bell's portal (GNet BB0060B, 2008-Aug-5 16h26) | %20.GIF "37746 bytes")
VelCom - Test Results (GNet BB0060B, Twin PPP & Tweak) | |
changed). The tweak was to raise SNR Margins
but i'm not sure it helped my error rate (noise).
At least it was a full day without rain/lightnings!
Addendum:
Speed Tests |
|
| Time for an update...
Here is an approximation of the phone line's spectral response
while it's still not completely optimized... Areas where colours
are fully saturated represent high probability levels. Take note
that my samples were taken at random intervals between July
31, August 1st, August 2, August 11, August 12 and August
13 via either a Thomson SpeedTouch 546v6 (FW v7.4.3.2-AA)
or my newer Thomson SpeedTouch 516v6 (FW v6.2.29.2-GE). |
|
| %20.GIF "23059 bytes")
VelCom - Thomson ST516v6-2 (2008-Aug-16 19h) | %20.GIF "30532 bytes")
VelCom - Thomson ST516v6-2 (2008-Aug-16 21h) |
I thought that the 1st set of samples was bad
news enough but i find the 2nd one devastating.
Take note that the vetical scale numbers must
be multiplied by ten. Also, the 2nd capture has
two scale versions included in order to make the
transitions more obvious: it's just like flipping a
switch, actually!... In my opinion, this is noise
of industrial origin and Bell would never manage
to clean my phone line even if they wanted to!
I really doubt my little tricks will work this time.
 |
|
| %20.GIF "42638 bytes")
VelCom - Thomson ST546v6 (2008-Aug-17 19h) | %20.GIF "41637 bytes")
VelCom - Thomson ST546v6 (2008-Aug-17 21h) |
I used a different MoDem with a variant of the
FirmWare installed on my newer ST516. Sunday
has been dry (which was a rare event lately) so
maybe it may explain the lower peek magnitudes.
Hummm... I guess i should keep track of the RH
factor too! Humidity would hardly account for
the steep noise burst transitions, nonetheless.
Today's 1st sample shows that it was taken only
23 minutes after rebooting the DSL unit and the
2nd one is a reminder that it's not possible to
refresh 'STMT' until the testing is complete (yet
is IS possible to generate multiple captures)...
If i had refreshed 'STMT' before creating those
captures then the "DSL-Link Utime" fields would
read as "2:23:36" and "4:24:17", respectively.
This ambiguity is avoided by taking screenshots
before the test cycle is over since the [Refresh
Data] button happens to be greyed-out then. |
|
| %20.GIF "7808 bytes")
VelCom - ST546v6 Static Numbers (2008-Aug-17) |
This is to confirm with numbers that the 1st two hours (and a half) were noisier...
That's also a reminder: it's OKay to click the [Modem Statistic] button (top left)!
 |
|
|  .GIF/thumb.jpg "78349 bytes")
VelCom - Siemens SS4200 (2008-Aug-20 20h) |
This set of curves demonstrates how misleading it
might be to trust the SNRM curve alone - imagine if
using "static" numbers only!... I don't recall what's
the exact timing but i sure remember that i turned
on the 3 fans (Intec's XBox 360 'Air Cooler', item#
G8648C) late after midnight. That's a "green" device
(environmentally friendly) using a small switching-
mode power supply and it was found at Zellers, it's
installed right below my MoDem (or in front of it for
the old GNet) since i arrived here in Quebec city. I
suspect there's noise comming from the fans, their
PSU or both so it's something i must investigate!...
But right now, my point is this: the SNR Margin data
which was captured at 20 h simply didn't allow me to
foresee what would happen in the next few minutes:
SNRM was 5 dB for the most part of the day and it
was even lower during the period between midnight
and 5h30, actually. Yet, a major disruption occured
after 20 h which even twenty hours worth of curves
couldn't help to predict, nonetheless! Put shortly, a
24 h set of curves is nice to have but it's even nicer
to collect many of those so that a pattern emerges.
Back to the SNR Margins, we'd find it most impractical
to watch the numbers every fifteen minutes so that's
why i prefer 'STMT' over 'DMT' if using a SpeedTouch:
the curves are much more informative than a pair of
numbers which may be great for a SpeedStream 4200
while the very same figures appear to be dangerously
marginal (at best!) for a typical SpeedTouch 5x6v6...
By the way, looking at SNR Margins one can't tell when
i turned off my fans but it seems the CRC curve helps.
So, i invite the readers to draw their own conclusions!
 |
|
| %20.GIF "42965 bytes")
VelCom - ST516v6-2 (2008-Aug-22 17 h) | %20.GIF "59359 bytes")
VelCom - ST516v6-2 (2008-Aug-22 19 h) | %20.GIF "63929 bytes")
VelCom - ST516v6-2 (2008-Aug-22 21 h) | %20.GIF "49765 bytes")
VelCom - ST516v6-2 (2008-Aug-22 23 h) |
|
|
| Hummm...
Interesting: i recorded jumpy SNR Margin curves
when i lived in the country-side and had a 6016/
800 Kbps FastPath profile. There was more noise
on the evenings too but nothing severe enough to
cause major disruptions. My present location is
about 170 Kilo-meters away from the previous one
and yet i find the similitudes puzzling, not to
mention that now i reside in a city with at least
ten times the population compared to Louiseville.
Here are SNRM transitions from my old rural area:
%20.GIF)
Tweaks, Bicephale, 2008-Jul-18
%20.GIF)
Tweaks, Bicephale, 2008-Jul-18
This sample shows a raise of noise in the evening:
%20.GIF)
Tweaks, Bicephale, 2008-Jul-18 |
|
| %20.GIF "64587 bytes")
VelCom - ST516v6-2 (2008-Aug-23) |
This set of captures was taken during a moist day
(with the RH index beyond 65 %), that's radically
different from the previous two which felt quite
comfortable (and really dry at last!)... The noise
bursts which occured a couple minutes before 20 h
affected scale magnitudes so much i had to include
alternate curves with moderate scales again: the
details showing a possible "Cooking Hour Syndrome"
would just have disapeared behind the floor level,
otherwise. The evening curves are suggesting that
my connection was severely disrupted in that time
period - which is now customary but wasn't at all
the case, initially, when i got my profile switched
to 5056/800 Kbps FastPath (as a consequence of
past observations). It's not likely i can do anything
about it and i wouldn't bet on the phone company
neither unless the cause which triggered this radical
change is identified someday. I'm considering having
the profile modified to allow me to finish my project,
then the only reasonable option would be cable...
|
|
| %20.GIF "45932 bytes")
VelCom - ST546v6 (2008-Jul-31 22 h) | %20.GIF "45487 bytes")
VelCom - ST546v6 (2008-Aug-1st 11 h) |  .GIF/thumb.jpg "43010 bytes")
VelCom - GNet BB0060B (2008-Aug-2 9h01) |
Here are captures which i didn't retain for publication
(due to frequent rain/storms events, i guess). There
were no noticeable disruptions back then, as i recall.
Apparently, a major change occured between August
2nd and August 5 and i have no idea what caused it. |
|
|  .GIF/thumb.jpg "64926 bytes")
VelCom - GNet BB0060B (2008-Aug-24 past 19h50) |  .GIF/thumb.jpg "19235 bytes")
VelCom - Bell's portal (GNet BB0060B, 2008-Aug-24 23h10) |
System Log:
19:50:55 EST Sun Aug 24 2008
STATUS ALARM : PPP Interface Up : Interface - ppp-1
19:50:55 EST Sun Aug 24 2008
STATUS ALARM : IPCP Successful : Interface - ppp-1, Local IP Address - 10.8.xxx.xxx, Gateway IP Address - 10.8.xxx.xxx
19:50:53 EST Sun Aug 24 2008
STATUS ALARM : PPP Interface Up : Interface - ppp-0
19:50:53 EST Sun Aug 24 2008
STATUS ALARM : IPCP Successful : Interface - ppp-0, Local IP Address - 98.124.xxx.xxx, Gateway IP Address - 64.213.xxx.xxx
19:50:53 EST Sun Aug 24 2008
STATUS ALARM: PPP Authorization Successful : Interface - ppp-0
19:50:52 EST Sun Aug 24 2008
STATUS ALARM: PPP Authorization Successful : Interface - ppp-1
19:50:52 EST Sun Aug 24 2008
STATUS ALARM : PPPoE Up : Interface - ppp-1
19:50:52 EST Sun Aug 24 2008
STATUS ALARM : PPPoE Up : Interface - ppp-0
19:50:42 EST Sun Aug 24 2008
ADET: Auto Detection Failed
19:50:41 EST Sun Aug 24 2008
ADET: User created VC with VPI/VCI 0/35, no detection on this VC
19:50:41 EST Sun Aug 24 2008
ADET: Reading VPI/VCI entries from autocfg.txt
19:50:39 EST Sun Aug 24 2008
ADET: Verification failed, starting detection again
19:50:39 EST Sun Aug 24 2008
ADET: Last detected VPI/VCI 0/35 protocol LLC MUX
19:50:39 EST Sun Aug 24 2008
ADET: Auto Detection Started on boot-up in bridge-router mode
Alarm:
Sun Aug 24 19:50:06 2008 : STATUS ALARM : PPP Interface Up : Interface - ppp-1
Sun Aug 24 19:50:04 2008 : STATUS ALARM : PPP Interface Up : Interface - ppp-0
Sun Aug 24 19:50:04 2008 : STATUS ALARM: PPP Authorization Successful : Interface - ppp-0
Sun Aug 24 19:50:03 2008 : STATUS ALARM: PPP Authorization Successful : Interface - ppp-1
Sun Aug 24 19:50:03 2008 : STATUS ALARM : PPPoE Up : Interface - ppp-1
Sun Aug 24 19:50:03 2008 : STATUS ALARM : PPPoE Up : Interface - ppp-0
Sun Aug 24 19:50:02 2008 : STATUS ALARM : ATM VC Up : Interface - aal5-7, PortId=7, Vpi=0, Vci=35
Sun Aug 24 19:50:02 2008 : STATUS ALARM : ATM Interface Up : Interface - atm-0
Sun Aug 24 19:50:02 2008 : STATUS ALARM : DSL Interface Up
Sun Aug 24 19:49:53 2008 : CRITICAL ALARM : Auto Detection Failed
Sun Aug 24 19:49:50 2008 : STATUS ALARM : Auto Detection Started
Sun Aug 24 19:49:50 2008 : STATUS ALARM : System Up
Sun Aug 24 19:48:27 2008 : CRITICAL ALARM : Auto Detection Failed
Not one single PPP event for the duration of that connection,
browsing almost seemed to be normal but for complex pages.
Try this on other brands/models (if that's supported at all)!... |
|
| Euh...
By "PPP event" i mean major disruption...
|
|
| Playing with MoDemOptions late at night...
N.B.:
The 'STMT' curves are not available when using FirmWare 6.1.4.6! |
|
1 edit | No graphics for today, lets just mention that my ST516
loaded with FirmWare v6.2.29.2-GE is unable to provide
a connection around 21 h each day while my ST546 with
FirmWare v6.1.4.6 (UK) works reasonably well for tasks
such as browsing and even listening to pseudo-streamed
radio (Pandora)... All of this being made accessible and
easy for anyone to try, thanks to 'DMT v7.35'! In my own
case, MoDemOption register 0 is set to #A8h, this lowers
the speed to 3072/800 Kbps FastPath and the transfers
are reduced but i still obtain a connection, at least!... |
|
|  .GIF/thumb.jpg "19178 bytes")
VelCom - Bell's portal (Siemens SS4200, 2008-Aug-29 15h06) |
Rate of 4095 per day at 15 h this afternoon comparatively
to over 4840 an hour later. Perhaps the phone-line quality is
starting to degrade earlier than what i suspected previously. |
|
%20.GIF "4144 bytes")
