Bicephale
join:2005-09-24
 ·TekSavvy Solutions..
| reply to Bicephale
Re: From the ground up!
%20.GIF "46465 bytes")
ST516v6 - Averaged Analysis (2009-Oct, 4-8, 16-19) | %20.GIF "457119 bytes")
ST516v6 - Daily Records - RF Choked (2009-Oct, 2-19) | %20.GIF "35455 bytes")
ST516v6 - Events (2009-Oct, 7-8, 20) | %20.GIF "29647 bytes")
ST516v6 - Grouping Pre-Analysis (2009-Oct, 2-21) |  ST516v6 FW v···20) .ZIP 425,275 bytes
SpreadSheet-ready .CSV Formatted Data | | |
Today's post reveals some significant changes/differences.
1st of all, the SNR Margin "bleeding syndrome" is much less
severe but this could be a result of the phone-line being a
lot more stable instead of the FirmWare's quality, go figure!
The marginal events revealing a 3+ dB SNR Margin boost of
at least twenty minutes each are still as puzzling as ever...
Analysis of "look-alike" daily records has been made: 1) by
grouping the records in respect to their slope (see the last
graph); 2) by keeping only those that were "in sync" (e. g.
with the expected number of samples)... Two main groups
emerged, each was 5 (Oct. 4-8) and 4 (Oct. 16-19) days
respectively. The top graph which compares them reveals
a tremendous improvement relatively to the records taken
in the previous months. The cause could be better phone-
line conditions, a more suitable FirmWare or a mix of both.
Take note how a manual reset took care of the SNR Margin
"bleeding syndrome"... |
|
Bicephale
join:2005-09-24
·TekSavvy Solutions..
| reply to Bicephale
Oups! There's been a problem with the previous archived log-file...
 |
|
Bicephale
join:2005-09-24
·TekSavvy Solutions..
| reply to Bicephale
%20.GIF "48401 bytes")
ST516v6 Long-Term Averaged Curves (2009-Sep, 12-18, 22-30) | %20.GIF "353985 bytes")
Groups (5) of individual daily records (DS SNRM is Green, Rx CRC/HEC are Blue, DS BitRate is Yellow | %20.GIF "92299 bytes")
ST516v6 Averaged RxCRC Groups (2009-Sep, 12-18, 22-30) | %20.GIF "152955 bytes")
MoDem Comparisons - SS4200 vs GBB2060 vs ST516v6 (2009-Sep, 12-18, 22-30) | ST516v6 FW v···-18,.zip 753,970 bytes
(ST516v6 FW v6.1 - Analysis & MoDem Comparisons (2009-Sep, 12-18, 22-30) .ZIP) | | |
This late data harvest was done using the same Thomson
ST516v6 as before, my experimenting setup was identical
except for its FirmWare (which i've changed to v6.1.0.5).
MoDem comparisons weren't straightforward to make this
time: i could hardly expose any daily 24 h sinuosidal noise
floor from the long-term curves as i did before, except for
the noisiest averaged group-curve (Sep. 15, 17 & 27)!
It's not clear if this was due to my change of FirmWare or
some radical modification in the phone-line behaviour as a
consequence of some seasonal influence but my Thomson
now compares reasonably well with the other DSL units...
It's still noisier once the aberrations have been rejected,
in my opinion, but this represents a definite improvement!
One feature of my ST hasn't changed a bit after i flashed
it with another FirmWare, though:
%20.GIF)
ST516 - Speeds Degrade over time, Bicephale, 2009-Oct-4
The DS SNR Margin Bleeding Syndrome remains as obvious
as ever!
 |
|
Bicephale
join:2005-09-24
·TekSavvy Solutions..
| reply to Bicephale
%20.GIF "134973 bytes")
GNet GBB2060-Xi SNRM vs RCO vs Err Rate (Summer '09) |
This animation shows 'DMT' captures taken at midnight,
RCO information was obtained a few minutes later from
Bell via VelCom... The numbers are only representative
of a very short time-slice compared to the 24 h graph,
as those numbers varied throughout the day.
While looking at it, try not to pay as much attention to
the error rate bursts as to the overall error rate "floor";
just observe how it's correlated to the "static" numbers,
despite the warning i've expressed right above.
Intuitively, my little animated .GIF here tends to confirm
that the Error Rate & RCO figures went up when the DS
SNR Margin went down but it does't tell which came 1st.
Was it DS SNR Margin drops which caused my Error Rate
and RCO to increase or was it Error Rate bursts instead
which caused the RCO to increase while the SNR Margin
plumetted?...
Better be safe than sorry, in my opinion, so if i'm asked
what lesson can be drawn from this at all then i'll say it
must be to search for a DSL device with the best SNRM
possible, the next step being to use some RF Choking if
suitable. |
|
Bicephale
join:2005-09-24
·TekSavvy Solutions..
| reply to Bicephale
%20.GIF "154000 bytes")
Siemens SS4200 vs GNet GBB2060-Xi vs Thomson ST516v6 (Summer 2009) |
Finally, here's something i waited for patiently... It still
tells me the same old story as when i was in Louiseville.
|
|
Bicephale
join:2005-09-24
·TekSavvy Solutions..
| reply to Bicephale
%20.GIF "94499 bytes")
ST516v6 - Rx CRC - Ovl vs Avg (2009, Aug 22-27, Sep 3) | %20.GIF "70506 bytes")
ST516v6 - Rx CRC (2009, Aug 16-17, 20-31, Sep 1-4) | %20-%20(2009,%20Aug%2016-17,%2020-31,%20Sep%201-4)%20.GIF "36647 bytes")
ST516v6 - ln(Rx CRC) - (2009, Aug 16-17, 20-31, Sep 1-4) | 
ST516v6 FW v6 - Seasonal Transition? | ST516v6 - An···-4) .ZIP 3,403,954 bytes
.CSV SpreadSheet-Ready File + SnapShots (2009, Aug 16-17, 20-31, Sep 1-4) | | |
I've really got some "fun" with that one... Finally, here's
a clear illustration of what "SNR Bleeding" looks like: we
can see it droping gradually as a few bins are being lost
to noise and then the link gets eventually renegotiated.
 |
|
Farchord
Lost somewhere.
join:2004-08-28
Shawinigan, QC | reply to Bicephale
Bicephale, update your 585v7's firmware with the one I posted on the TSI forums  IT'll fix your DMT's problems. |
|
Bicephale
join:2005-09-24
·TekSavvy Solutions..
| reply to Bicephale
The graphic for this later addition used only seven daily samples
out of seventeen... The rest of those samples differed so much i
decided to divide the whole set into seven groups. I believe the
present averaged curves are more representative of reality but i
included all samples into my accompanying SpreadSheet anyway
so that the reader gets the opportunity to play with a few more
scenarios, like i have. The graph from above corresponds to my
3rd group of sample, i tagged those the "look alikes"...
|
|
Bicephale
join:2005-09-24
·TekSavvy Solutions..
| reply to Bicephale
%20.GIF "209968 bytes")
VelCom - DSL Reports Test Results (2009-Aug-8) |
Time to immortalize test results, while i think of it...
Those are the test sites i use (1 out of 3 tries each):
http://testvitesse.videotron.ca/
http://speedtest.cogeco.net/
http://www.mountaincable.net/index.php?id=3,114,0,0,1,0
Here's a link to the page where such results are shown:
http://www.dslreports.com/testhistory/1267354/b1adc
...and this is a link to the RF Choking experiment (top):
%20.GIF)
RF Choking (on the WAN side), Bicephale, 2009-Jul-18 |
|
Bicephale
join:2005-09-24 | reply to Bicephale
Thank you everyone for your contributions!
 |
|
my case
@videotron.ca | reply to Bicephale
In my case both SNR and occupancy were jumping.
Occupancy would jump like 2 points or more that I noticed. That value should be very stable. Yours is already high.
no other clue i can offer. |
|
Bicephale
join:2005-09-24 | reply to Bicephale
All right. What i meant was what parameter i should try to monitor?
• Attenuation
• Voltage
• Etc... |
|
great question
@videotron.ca
| reply to Bicephale
Evidence?
Unless you can measure voltage cross, or find a tech willing to check it out, or get an "honest" test center person at bell to monitor your line and communicate with you (maybe privately), no clue.
I will be very impressed if you find a way to do this (provide evidence) Bicephale.
Maybe a couple of electro-engineers/techs could help you find the answer, or some uni-prof (maybe some forum with these experts)? |
|
ex bell
@cgocable.net
| reply to Bicephale
said by Bicephale  :What do i need to monitor in order to capture positive evidence? There are current telco techs with more dsl training than I in this forum »AT&T Southeast that could probably answer that. Try a thread there. |
|
Bicephale
join:2005-09-24 |  reply to Bicephale
What do i need to monitor in order to capture positive evidence? |
|
best guess
@videotron.ca
| reply to Bicephale
said by Bicephale :Now will someone care to explain the "voltage cross" concept? Hmm while looking up "stary current" I came across this:
"Stray Voltage"
»en.wikipedia.org/wiki/Stray_voltage
It *appears* to fit in with what "ex bell" said. But the article is more geared to heavy power lines.
But it should be similar, *I think*.
I never was able to find something telco-related on this.
"ex bell" should add this info to a one of the wiki sites on DSL (along with "cut-ahead").
It's something ignored a lot (both terms) and kind of hidden from the user since it's a sign on the quality, age and neglict on part of the telco's. |
|
ex bell
@cgocable.net | reply to U got it
said by U got it :
Don't get me going now...
No, you've got some reading on the new Cogeco AUP to get done. |
|
U got it
@videotron.ca | reply to ex bell
said by ex bell :
(well should).
Bingo again.
"should" is the operational word.
Don't get me going now... |
|
U got it
@videotron.ca
| reply to ex bell
said by ex bell :
He cut ahead, techs are instructed not to do this. After your terminal your F2 or F3 pair may travel quite a distance.
This shortens the loop, removes potential imbalances and metallic issues. Drop cuts are when crews replace drops wires.
Bingo, that's it.
ty for correcting it.
Wish I could explain it Bicephale, I look at it like a short (or stray current).
My line, on a good day, had a 14-volt voltage cross (when everything was good). 14 volts or so caused some static on the phone.
2 or 3 tech's measured the same thing and they called it a voltage cross which they say is different than a short.
On semi-good days, everything was down and non-functional (no clue what the voltage cross reading was on those days).
What you have is a little less than what I had, but no different from what I see. In my belief you will have to cause a bigger problem as stated above to get anywhere.
But I see no difference.
Must be stray current between pairs?
I couldn't tell you. I too would like to know what this mysterious voltage cross is that isn't a short.
You need a good tech (which isn't standard with bell), all I can truly say.
My fix took 6-weeks with lots of bitching and calls/emails to Crull/executive office. The first time I had this it was 2.5 to 3-month to repair.
So like I said, with you not being a Bell customer, you are going to be left to rot unless you pull some dirty tricks. |
|
ex bell
@cgocable.net
| reply to Bicephale
said by Bicephale :Now will someone care to explain the "voltage cross" concept? Just means a there is metallic to another pair. You are getting voltage conducted from one or more conductors in a cable to your pair.
Very common. Most often in your F1 or F2 pair. Can occur in multi pair drop and bsw.
Test board will catch this right away as well as dispatched tech. on a repair ticket (well should). |
|
%20.GIF "35061 bytes")