Last ditch attempt

[#1]

I'm hoping now that my connection seems to be stabler to see if PN can change my IP profile and possibly re-train my line. Plan was to leave it running all last week and ask some one at PN if they had seen any disconnections on my log.
Unfortunately while I was away working for some reason my missus decided for the first time in her life to knock the router off at the mains  Go figure.
Problem though is I keep showing resyncs in router stats but I don't think I'm losing connection  The graph showed it syncing but I was surfing at the time and no sign of lack of connection. The new router isn't very user friendly compared to others I have had and because I'm running routerstats through wine on linux it may be a software bug rather than disconnections.
I know I rebooted a week on Saturday and left it on all week, It was then knocked off sometime mid week (she can't remember  ;D) and then I knocked it on again on Friday night, rebooted Sat morning and then this morning which got me me higher sync back. Could this be checked or am I better off leaving it another week constantly on?
I'm getting weird re-syncs on the graphs but no noise problems like I was with the other router. I've tried deciphering the logs from the router but there a bit complicated for me.
These are the stats from the router...
Broadband Link Type:      Built in modem - ADSL
Connection Type:    PPPoA
User Name:    *******@plusdsl.net
Current Internet Connection:   
IP Address:    212.159.***.**
Subnet Mask:    255.255.255.255
Default Gateway:    195.166.128.***
Primary DNS:    212.159.6.10
Secondary DNS:    212.159.6.9
Host Name:   
Domain:   
MAC Address:    --:--:--:--:--:--
MTU:    1500
DSL Details
Modem Type:    Built in modem - ADSL
DSL Line (Wire Pair):    Line 1 (inner pair)
Current DSL Connection:
    Down    Up
Rate:    4096 kbs    448 kbs
Max Rate:    4096 kbs    1048 kbs
Noise Margin:    15.0 dB    24.0 dB
Attenuation:    47.3 dB    27.0 dB
Output Power:    19.8 dBm    12.2 dBm
Protocol:    G.DMT Annex A
Channel:    Fast
DSLAM Vendor Information    Country: {46336} Vendor: {TSTC} Specific: {0 }
ATM PVC:    0/38
Rate Cap:    4096 kbs
Attenuation @ 300kHz:    47.3 dB
Uncanceled Echo:    -17.1 dB    Ok
VCXO Frequency Offset:    4.6 ppm    Ok
Final Receive Gain:    25.9 dB    Ok
Impulse Noise Comp. Tones:    0    Ok
Excessive Impulse Noise:    0    Ok
Traffic Statistics
IP Traffic    Bytes    Packets    Errors    %
Transmit:    61026    465    0    0
Receive:    226803    415    0    0
ATM Traffic    Cells    Errors    %
Transmit:    1745    0    0
Receive:    5103    0    0
DSL Link Errors
Collected for 0:46:15
    Since    Current    Current    Time Since
    Reset    24-hr int.    15-min int.    Last Event
ATM
Last Event
Cell Header Errors    65    65    0    0:03:23
Loss of cell Delineation    0    0    0    0:00:00
DSL
Link Retrains:    0    0    0    0:00:00
DSL Training Errors:    0    0    0    0:00:00
Training Timeouts:    0    0    0    0:00:00
Loss of Framing Failures:    0    0    0    0:00:00
Loss of Signal Failures:    0    0    0    0:00:00
Loss of Power Failures:    0    0    0    0:00:00
Loss of Margin Failures:    0    0    0    0:00:00
Cum. Seconds w/Errors:    79    79    0    0:03:23
Cum. Sec. w/Severe Errors:    0    0    0    0:00:00
Corrected Blocks:    0    0    0    0:00:00
Uncorrectable Blocks:    101    101    0    0:03:23
DSL Unavailable Seconds:    0    0    0    0:00:00
and here are the graphs generated on re-boot

Uploaded with ImageShack.us
Can anyone tell me please if I am genuinely losing sync again with this router putting me back to square one or routerstats is giving false information? I don't suppose there's any point in asking for a line re-train until I know what's happening.
Cheers 

[#2]

Can someone at PN show my connection logs for the last three days please to check if it's routerstats giving a false report?

[#3]

Hi AWB,
Your connection logs since the 18th:
<img src="http://ccgi.psmith12.plus.com/visradius/generated/image12855819018867.png" />
Hope that helps,

[#4]

Much appreciated Matt, all them disconnections look like my activity.
Sat 18th and Monday 20th was me rebooting, Mrs must have knocked it off Wed night  and I switched back on Friday  when I got back from work. Sat 25th I rebooted but got a slightly less speed so did another Sunday morning which raised it slightly again. The one on Sunday night was when I did a diagnostic test on the router which I'm assuming disconnected me to check the connection status.
Looking at that I have a stable line and routerstats when run under Wine in Linux must be falsely reporting Re-syncs, or can a line re-sync without losing connection?
I'm leaving the router on all week so would appreciate having my connection log at the end of the week if that's at all possible. Should the log show no disconnects for the duration is it possible to try and see if my line can have a re-train or possibly my SNR altered? I have to be honest I don't know exactly how this works but have seen it can be done.
On my old routers I had a SNR of 12db which usually gave me a downstream of 4500kbps with an ip profile of 4000kbps noise possibly from two failing routers I tried kept dropping and lowering my profile  >:(. This new router sets me at 16db and I can just get 4000kbps and 3500 ip profile when re-syncing. I think my noise issues are now sorted and the line could handle it, the snr graph is flat as a pancake whatever time of day.
I'm nearly back to what I used to get, it's been emotional   

[#5]

Quote from: AverageWhiteBloke

Problem though is I keep showing resyncs in router stats but I don't think I'm losing connection  The graph showed it syncing but I was surfing at the time and no sign of lack of connection. The new router isn't very user friendly compared to others I have had and because I'm running routerstats through wine on linux it may be a software bug rather than disconnections.

I'm pretty sure the problem here is in interpreting that graph...
When the graph line drops to zero, it doesn't always mean that it polled the router and got a "zero" as the answer. It sometimes means that it failed to poll the router, and uses the zero as a "no data" indication. This could be a failure to login to the router, or a loss of a packet over ethernet, or perhaps as simple as a timeout.
Routerstats *does* make a distinction of "no data" from a true "zero" reading - and it does so by changing the colour of the line in the graph. You will note that the downlink noise margin line is usually drawn with a dark blue line (it looks like that to me), but when it descends to zero it changes colour to a pinkish colour, and then returns to blue when it ascends to 15 again.
The pinkish colour is used when the line represents a change from a "real" value (in the previous reading) to a "no data" reading in the current data. It will then be drawn as blue when it represents either a change from "no data" to "real", or just a plain "real" to "real".
If you want to see Routerstats logging a "proper" sync loss, where the descending line will be drawn in blue, just pull the phone line out of the router for a while. Of course I wouldn't recommend you do this if you are trying to teach BT that you now have a stable line.
The real place to see whether you have had any resyncs is here:

Quote from: AverageWhiteBloke

DSL Link Retrains:     0     0     0     0:00:00 DSL Training Errors:     0     0     0     0:00:00 Training Timeouts:     0     0     0     0:00:00 Loss of Framing Failures:     0     0     0     0:00:00 Loss of Signal Failures:     0     0     0     0:00:00 Loss of Power Failures:     0     0     0     0:00:00 Loss of Margin Failures:     0     0     0     0:00:00 Cum. Seconds w/Errors:     79     79     0     0:03:23 Cum. Sec. w/Severe Errors:     0     0     0     0:00:00 Corrected Blocks:     0     0     0     0:00:00 Uncorrectable Blocks:     101     101     0     0:03:23 DSL Unavailable Seconds:     0     0     0     0:00:00

You've had no "retrains" which is a good sign - I'm pretty sure that a retrain is a resync.
There are equally no errors of any significance - 101 uncorrectable blocks is pretty low (and with an 8128 connection you have error correction turned off, so you can't get any correctable blocks)
There were 79 seconds with errors - called "errored seconds", which means there were 79 different second-long periods which had 1 or more block errors in them. Given 101 blocks, that seems like a nice wide spread - and the system isn't reporting any "seconds with severe errors" which would be second-long periods with lots of errors in them.
Unfortunately, the stats don't seem to say how long the stats have been collected for, so it is hard to be absolutely sure about those figures Is it a 10 minute value, or a 24 hour period?
I guess you just have to watch over time...
But the final "DSL Unavailable Seconds" figure is useful. You would expect this value to go up each time the line has to resync. A resync here is around 10 seconds, and this "unavailable seconds" figure would go up by that amount of time for each resync.
On my system (similarly at 8128, and very stable), I have the following figures at the moment:

ConnTime:5413312 
ES:14539 
SES:210 
UAS:51 

That's about 1500 hours connection time, or about 2 months, with 15000 errored-seconds - an average of 10 seconds in every hour.
And the UAS figure suggests that I've had 4 or 5 resyncs in that time too.
I've attached a graph of when I've had my "ES" seconds over the last 12 hours, so you can see the spread.
  Mike

[#6]

Thanks Mike for explaining what some of these mean it's bewildering  I reset the stats on Saturday just after the reboot because previously I had been trying different things out and wasn't sure what all the figures meant. Not 100% sure but I'm guessing the bit saying Collected for 0:46:15 would mean that it had been collecting stats for forty six minutes as that sounds like about the time after resetting them that I copied the stats.
At least if I keep it running with no reboots this week the stats will make more sense as I know it has only been re-booted once in the cycle.
I will monitor these and post them up as the week goes on.

[#7]

I think things are still ok  
Collected for 1Day9:56:20
DSL
Link Retrains: 1 0 0 1Day3:57:56
DSL Training Errors: 0 0 0 0:00:00
Training Timeouts: 0 0 0 0:00:00
Loss of Framing Failures: 0 0 0 0:00:00
Loss of Signal Failures: 0 0 0 0:00:00
Loss of Power Failures: 0 0 0 0:00:00
Loss of Margin Failures: 0 0 0 0:00:00
Cum. Seconds w/Errors: 1202 362 3 0:01:26
Cum. Sec. w/Severe Errors: 0 0 0 0:00:00
Corrected Blocks: 0 0 0 0:00:00
Uncorrectable Blocks: 1370 422 3 0:01:26
DSL Unavailable Seconds: 19 0 0 1Day3:57:37
Now if I'm doing this right my maths is not so good   that means I have an average of 35 seconds in every hour but at least there still nothing serious turning up. It does show one re-train but that corresponds with the router diagnostic test and the disco on the PN connections log at about 5.30 on Sunday night.

*Edit rather than post again
This was one of the graphs taken

I have had router stats running most the evening and saw this, not sure exactly what it's saying but right afterwards I checked back with the router and it never showed up anything important. No descending blue lines anyway.
Last Event
Cell Header Errors 797 236 0 0:08:52
Loss of cell Delineation 10 2 0 2:48:26
DSL
Link Retrains: 1 0 0 1Day4:50:27
DSL Training Errors: 0 0 0 0:00:00
Training Timeouts: 0 0 0 0:00:00
Loss of Framing Failures: 0 0 0 0:00:00
Loss of Signal Failures: 0 0 0 0:00:00
Loss of Power Failures: 0 0 0 0:00:00
Loss of Margin Failures: 0 0 0 0:00:00
Cum. Seconds w/Errors: 1233 393 0 0:04:10
Cum. Sec. w/Severe Errors: 0 0 0 0:00:00
Corrected Blocks: 0 0 0 0:00:00
Uncorrectable Blocks: 1404 456 0 0:04:10
DSL Unavailable Seconds: 19 0 0 1Day4:50:08
Still only one re-train

[#8]

Quick question, will it matter that my router is using different DNS servers for PN? I have the router to get them auto from the isp and in the DNS boxes it's picked two other servers other than the 212.159.13.49/50. Not sure but the ones I have end in 10 I think, at work now so will check tonight.

[#9]

If the ones you have are 212.159.6.9 and .6.10 then those are our servers too. It shouldn't make any difference to the service at all.

[#10]

Thank you one less thing to think about