Can anyone tell me what this means?
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Plusnet Community
- :
- Forum
- :
- Help with my Plusnet services
- :
- Broadband
- :
- Can anyone tell me what this means?
Can anyone tell me what this means?
20-12-2011 9:17 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
I have recently been moved to the 21CN network and at the moment I'm getting a lot of disconnects, in the router log (Billion 7800N) it shows the following which I've never had before:
Dec 20 20:33:34 daemon pppd[5659]: No response to 6 echo-requests
Dec 20 20:33:34 daemon pppd[5659]: Serial link appears to be disconnected.
Dec 20 20:33:34 daemon pppd[5659]: Clear IP addresses. Connection DOWN.
Has anyone any idea what this means? Current info from routerstats:
Downstream
Noise Margin: 3.9 dB
Connection Rate: 9525 Kbps
Line Attenuation: 43.0 dB
Power: 0.0 dBm
Max Rate: 9116 Kbps
SuperFrames: 7096980
SF (CRC) Errors: 402
Reed Solomon: 936801422
RS Corrected: 2590160
RS Un-Corrected: 2281
HEC: 323
Errored Seconds: 171
Severe ES: 12
Interleave Depth: 64
Bitswaps: 15489
Upstream
Noise Margin: 5.5 dB
Connection Rate: 1020 Kbps
Line Attenuation: 22.5 dB
Power: 12.9 dBm
Max Rate: 1012 Kbps
SuperFrames: 805568
SF (CRC) Errors: 555
Reed Solomon: 0
RS Corrected: 0
RS Un-Corrected: 0
HEC: 371
Errored Seconds: 358
Severe ES: 0
Interleave Depth: 1
Bitswaps: 2280
Totals
Total Uptimes (From SF counts):
WAN: 1 days, 09:31:51
LAN: 0 days, 00:00:00
CRC: 954 676
ES: 172 358
SES: 12 0
UAS: 33 33
LOS: 1 0
LOF: 9 0
Seasons Greetings
Steve
Re: Can anyone tell me what this means?
21-12-2011 2:41 AM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
The log messages themselves don't indicate what is happening to the DSL connection between you and the exchange, but they are a good bet that the DSL connection is itself suffering a problem. It *could* also indicate that your exchange can't communicate with the rest of BT, but in this instance it seems unlikely.
The stats show your DSL connection has UAS of 33 - which means it has been out of contact with the exchange for 33 seconds. That is likely to mean that you have suffered 4 or 5 DSL disconnections & resyncs (each around 7 seconds).
Your other error rates don't look particularly severe. In the course of a day, you got some 900 errors spread over 180 different second-long periods (the ES, or errored seconds), where 12 of those seconds got a severe numbere of errors (the SES). Those aren't particularly bad numbers.
Using FTTC since 2011. Currently on 80/20 Unlimited Fibre Extra.
Re: Can anyone tell me what this means?
21-12-2011 9:15 AM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
Thanks again
Steve
Re: Can anyone tell me what this means?
21-12-2011 10:21 AM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
How is your kit set up? Are you using any extension cables/sockets at all? The drops seem to mainly be happening in the evening. I'm wondering if there's something that could be interfering at home, heating, Christmas lights etc?
Jojo
Re: Can anyone tell me what this means?
21-12-2011 12:29 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
One set of low voltage Christmas tree lights in the living room that are usually only on between around 10am - 10pm, heating is on between 7 & 9am and again 3pm-9pm. Router is connected to filtered faceplate on NTE5 BT master socket by a 2m lead with main phone also connected, 1 extension phone approximately 10m hard wired into removable part of the socket.
Could you tell me when I was moved over to the 21CN network? It seems strange that nothing has altered wiring/lights/heating wise since around the 8th December but I now get the errors, I can account for one of the disconnects, it was me resetting the SNR in the Billion back to default from when I fiddled with it before as I think that may have been the cause of the 0.0 noise margins.
I'll run routerstats continuously for a few days and see how it pans out, to be honest I probably wouldn't have noticed the disconnects if I hadn't been playing on my PS3 at the time.
Thanks again
Steve
Re: Can anyone tell me what this means?
21-12-2011 1:13 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
Re: Can anyone tell me what this means?
21-12-2011 2:15 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
I'll give it a go probably tomorrow as my nephew is here playing on the main pc over the internet. I've been relegated to the laptop I'll leave routerstats running and see what happens.
Just a thought there is one thing that has altered on my network, I've added a Synology DS212J NAS via a 0.5m cable to the gigabit switch upstairs but that shouldn't affect the WAN connection though as far as I know. By the way switch to router is via around 15m of cat6 cable.
I'll update again once I've tried the test socket.
Thanks again
Steve
Re: Can anyone tell me what this means?
21-12-2011 10:29 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
I'm interested in your problem because I have had a similar problem with random and intermittent but pretty regular PPP drops (although in my case with absolutely NO change whatsoever in line synch, SNR or IP profile etc) ever since I was forcibly upgraded without warning to 21CN. It started literally within minutes of the so-called upgrade but had very rarely (if ever) been seen in the previous ~10 years ! After arguing the toss and going round and round in ever decreasing circles with Support for almost 9 months I've just about given up because it seems quite clear to me that they do not understand how things work (in particular LCP control packets and the difference between a PPP connection and the fundamental connection with the exchange equipment etc.) and are unable or unwilling to provide sensible and valid answers to questions or provide any relevant comments. All I get is pretty much an insistence that the customer's equipment is the cause of the apparent problem without any evidence or rationale whatsoever to support drawing such a wild conclusion from the stack of evidence to the contrary being provided. There are a few other BT/PN network issues as well (such as some very obvious and logged data routing errors and totally dead gateways) to consider but my conclusion at the mo is that it's primarily a bug and/or a network loading issue. Needless to say, the problem generally becomes MUCH worse when there are lots of speed or response time complaints from other customers, reports of network balance problems, announced maintenance periods or perhaps rather more telling, immediately prior to a BW increase I strongly suspect that under high network load conditions, routine LCP monitoring packets are simply being intentionally dropped/ignored for extended periods of time as and when required in addition to there being a significant increase in routing and other errors.
I would therefore be *VERY* interested to hear what happens if you do try connecting at G.DMT on 21CN although as you're apparently getting a very variable SNR then I would suspect that unlike me you do have a genuine interference problem or some other real issue somewhere. Connecting at good old G.DMT will however mean that the upper ADSL2 frequency bands will not be used so it might solve your problem PROVIDING that the problem is in fact solely down to some issue or other when using the extended ADSL2 frequencies of course. If it doesn't solve the problem then that would suggest that you may also have similar issues to me with random and intermittent PPP drops for no obvious or particularly good reason that were not in any way apparent prior to the upgrade to 21CN.
Just in case it helps, the sort of thing I'm seeing from looking at my router LCP packet logs is below:
[everything working normally for some considerable period of time]
Dec 17 04:05:59 PoE <== Protocol:LCP(c021) EchoReq Identifier:0xB8Magic Number: 0x68d8 5d e6 ##
Dec 17 04:05:59 PoE ==> Protocol:LCP(c021) EchoRep Identifier:0xB8Magic Number: 0x0 00 00 ##
Dec 17 04:07:59 PoE <== Protocol:LCP(c021) EchoReq Identifier:0xB9Magic Number: 0x68d8 5d e6 ##
Dec 17 04:07:59 PoE ==> Protocol:LCP(c021) EchoRep Identifier:0xB9Magic Number: 0x0 00 00 ##
Dec 17 04:09:59 PoE <== Protocol:LCP(c021) EchoReq Identifier:0xBAMagic Number: 0x68d8 5d e6 ##
Dec 17 04:09:59 PoE ==> Protocol:LCP(c021) EchoRep Identifier:0xBAMagic Number: 0x0 00 00 ##
Dec 17 04:11:59 PoE <== Protocol:LCP(c021) EchoReq Identifier:0xBBMagic Number: 0x68d8 5d e6 ##
Dec 17 04:11:59 PoE ==> Protocol:LCP(c021) EchoRep Identifier:0xBBMagic Number: 0x0 00 00 ##
Dec 17 04:13:59 PoE <== Protocol:LCP(c021) EchoReq Identifier:0xBCMagic Number: 0x68d8 5d e6 ##
Dec 17 04:13:59 PoE ==> Protocol:LCP(c021) EchoRep Identifier:0xBCMagic Number: 0x0 00 00 ##
[fault occurs here - expected Echo Req IN is missing and subsequent Echo Req OUTs are ignored]
Dec 17 04:16:03 PoE ==> Protocol:LCP(c021) EchoReq Identifier:0x02Magic Number: 0x0 00 00 ##
Dec 17 04:16:06 PoE ==> Protocol:LCP(c021) EchoReq Identifier:0x03Magic Number: 0x0 00 00 ##
Dec 17 04:16:09 PoE ==> Protocol:LCP(c021) EchoReq Identifier:0x04Magic Number: 0x0 00 00 ##
Dec 17 04:16:12 PoE ==> Protocol:LCP(c021) EchoReq Identifier:0x05Magic Number: 0x0 00 00 ##
Dec 17 04:16:15 PoE ==> Protocol:LCP(c021) EchoReq Identifier:0x06Magic Number: 0x0 00 00 ##
Dec 17 04:16:18 PoE ==> Protocol:LCP(c021) EchoReq Identifier:0x07Magic Number: 0x0 00 00 ##
Dec 17 04:16:21 PoE ==> Protocol:LCP(c021) EchoReq Identifier:0x08Magic Number: 0x0 00 00 ##
Dec 17 04:16:24 PoE ==> Protocol:LCP(c021) EchoReq Identifier:0x09Magic Number: 0x0 00 00 ##
Dec 17 04:16:27 PoE ==> Protocol:LCP(c021) EchoReq Identifier:0x0AMagic Number: 0x0 00 00 ##
Dec 17 04:16:30 PoE ==> Protocol:LCP(c021) EchoReq Identifier:0x0BMagic Number: 0x0 00 00 ##
Dec 17 04:16:33 PoE ==> Protocol:LCP(c021) EchoReq Identifier:0x0CMagic Number: 0x0 00 00 ##
Dec 17 04:16:36 PoE ==> Protocol:LCP(c021) EchoReq Identifier:0x0DMagic Number: 0x0 00 00 ##
Dec 17 04:16:39 PoE ==> Protocol:LCP(c021) EchoReq Identifier:0x0EMagic Number: 0x0 00 00 ##
Dec 17 04:16:42 PoE ==> Protocol:LCP(c021) EchoReq Identifier:0x0FMagic Number: 0x0 00 00 ##
Dec 17 04:16:45 PoE ==> Protocol:LCP(c021) EchoReq Identifier:0x10Magic Number: 0x0 00 00 ##
Dec 17 04:16:48 PoE ==> Protocol:LCP(c021) EchoReq Identifier:0x11Magic Number: 0x0 00 00 ##
Dec 17 04:16:51 PoE ==> Protocol:LCP(c021) EchoReq Identifier:0x12Magic Number: 0x0 00 00 ##
Dec 17 04:16:54 PoE ==> Protocol:LCP(c021) EchoReq Identifier:0x13Magic Number: 0x0 00 00 ##
Dec 17 04:16:57 PoE ==> Protocol:LCP(c021) EchoReq Identifier:0x14Magic Number: 0x0 00 00 ##
Dec 17 04:17:00 PoE ==> Protocol:LCP(c021) EchoReq Identifier:0x15Magic Number: 0x0 00 00 ##
Dec 17 04:17:03 PoE ==> Protocol:LCP(c021) TermReq Identifier:0x16 ##
Dec 17 04:17:03 PoE <== Protocol:LCP(c021) TermAck Identifier:0x16 ##
[new PPP connection established]
NOTES: The above is only a small edited sample of typical relevant data from the router logs
At no time was there any loss or change in line synch or SNR etc.
<== means INCOMING data packets from BT/PN
==> means OUTGOING data packets to BT/PN
The above quite clearly shows that the BT/PN network stopped sending or responding to routine LCP packets completely for no particularly good or obvious reason and therefore the router quite rightly concluded that there was a network fault and terminated the PPP connection. However, it is also quite clear that there was no fundamental transmission problem on the line because the PPP Termination Request was in fact received and responded to correctly even though various other routine LCP packets were being completely ignored and data flow in general had ceased If you are able to log similar data from your router then it may perhaps help to identify what exactly is going on with your connection.
B T Plusnet, a bit kinda like P T Barnum ...
... but quite often appears to feature more clowns
Re: Can anyone tell me what this means?
28-12-2011 8:11 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
Just a update, not tried the test socket yet as I was ill over Christmas but sometime on the 24th-25th it resynced at 9153 Down and 1024 up with a noise margin of between 4 & 9 and was very happy with very few error seconds untill today when its resynced at
Host: 'home', IP: '192.168.0.1', Level: 'crit', Date: '2011-12-28', Time: '13:10:37', Program: 'kernel', Message: 'Line 0: ADSL link up, Path 0, us=1012, ds=11872'
Host: 'home', IP: '192.168.0.1', Level: 'crit', Date: '2011-12-28', Time: '17:14:48', Program: 'kernel', Message: 'Line 0: ADSL link up, Path 0, us=1007, ds=10350'
Host: 'home', IP: '192.168.0.1', Level: 'crit', Date: '2011-12-28', Time: '19:21:55', Program: 'kernel', Message: 'Line 0: ADSL link up, Path 0, us=1036, ds=10080'
with a noise margin of 2.7 - 3.1 with errors seconds clocking up. Seems to me 9153 is about my max , I think it was around the 17th December I was moved to 21cn so if the training period is 14 days I should probably wait to the new year before fiddling with it.
mikeb: I have no idea if or how its possible to get LCP packet logs on my router, all the log gives is this:
Dec 28 17:00:38 daemon pppd[5659]: PPP: Start to connect ...
Dec 28 17:00:40 daemon pppd[5659]: Using interface ppp0_0_38_1
Dec 28 17:00:40 daemon pppd[5659]: Connect: ppp_0_0_38_1 <-->
Dec 28 17:00:40 daemon pppd[5659]: Couldn't increase MTU to 1500.
Dec 28 17:00:40 daemon pppd[5659]: PPP LCP UP.
Dec 28 17:00:41 daemon pppd[5659]: Couldn't increase MTU to 1500.
Dec 28 17:00:41 daemon pppd[5659]: PPP LCP UP.
Dec 28 17:00:42 daemon pppd[5659]: local IP address ------ (I've removed my static ip)
Dec 28 17:00:42 daemon pppd[5659]: remote IP address 195.166.128.231
Dec 28 17:00:42 daemon pppd[5659]: primary DNS address 212.159.6.9
Dec 28 17:00:42 daemon pppd[5659]: secondary DNS address 212.159.6.10
Dec 28 17:00:43 daemon dnsmasq[92]: using nameserver 212.159.6.10#53
Dec 28 17:00:43 daemon dnsmasq[92]: using nameserver 212.159.6.9#53
Dec 28 17:00:43 daemon pppd[5659]: Received valid IP address from server. Connection UP.
Dec 28 17:00:43 user syslog: begin: interface: ppp_0_0_38_1 go to up
Dec 28 17:00:43 daemon UPNPD[28294]: received signal 15, good-bye
Dec 28 17:00:45 daemon UPNPD[30275]: HTTP listening on port 2800
Dec 28 17:00:48 user syslog: end: interface: ppp_0_0_38_1 go to up
Dec 28 17:08:15 syslog -- MARK --
Dec 28 17:12:11 daemon pppd[5659]: No response to 6 echo-requests
Dec 28 17:12:11 daemon pppd[5659]: Serial link appears to be disconnected.
Dec 28 17:12:11 daemon pppd[5659]: Clear IP addresses. Connection DOWN.
Dec 28 17:12:11 daemon pppd[5659]: Clear IP addresses.
Dec 28 17:12:11 daemon pppd[5659]: Couldn't increase MTU to 1500.
Dec 28 17:12:12 user syslog: begin: interface: ppp_0_0_38_1 go to down
Dec 28 17:12:12 user syslog: end: interface: ppp_0_0_38_1 go to down
Dec 28 17:12:17 daemon pppd[5659]: Connection terminated.
Dec 28 17:12:17 daemon pppd[5659]: Connect time 11.6 minutes.
Dec 28 17:12:17 daemon pppd[5659]: Sent 1991809 bytes, received 1224773 bytes.
Dec 28 17:12:17 user kernel: dev_shutdown, dec ppp device refcnt, dev->refcnt=4
Dec 28 17:12:18 user kernel: unregister_netdevice: waiting for ppp_0_0_38_1 to become free. Usage count = -1
Dec 28 17:12:18 user kernel: dev->name = ppp_0_0_38_1, dev->refcnt=-1
Dec 28 17:12:18 user kernel: after reset to 0, dev->refcnt=0
Dec 28 17:12:21 daemon pppd[5659]: PPP: Start to connect ...
Dec 28 17:12:22 daemon pppd[5659]: Using interface ppp0_0_38_1
Dec 28 17:12:22 daemon pppd[5659]: Connect: ppp_0_0_38_1 <-->
Dec 28 17:12:22 daemon pppd[5659]: Couldn't increase MTU to 1500.
Dec 28 17:12:31 daemon pppd[5659]: LCP: timeout sending Config-Requests (Don't remember having seen this before....)
Dec 28 17:12:31 daemon pppd[5659]: Connection terminated.
Dec 28 17:12:34 daemon pppd[5659]: PPP: Start to connect ...
Dec 28 17:12:36 daemon pppd[5659]: Using interface ppp0_0_38_1
Dec 28 17:12:36 daemon pppd[5659]: Connect: ppp_0_0_38_1 <-->
Dec 28 17:12:36 daemon pppd[5659]: Couldn't increase MTU to 1500.
Dec 28 17:12:45 daemon pppd[5659]: LCP: timeout sending Config-Requests
Dec 28 17:12:45 daemon pppd[5659]: Connection terminated.
Dec 28 17:12:48 daemon pppd[5659]: PPP: Start to connect ...
Dec 28 17:12:50 daemon pppd[5659]: Using interface ppp0_0_38_1
Dec 28 17:12:50 daemon pppd[5659]: Connect: ppp_0_0_38_1 <-->
Dec 28 17:12:50 daemon pppd[5659]: Couldn't increase MTU to 1500.
Dec 28 17:12:59 daemon pppd[5659]: LCP: timeout sending Config-Requests
Dec 28 17:12:59 daemon pppd[5659]: Connection terminated.
Dec 28 17:13:02 daemon pppd[5659]: PPP: Start to connect ...
Dec 28 17:13:03 daemon pppd[5659]: Using interface ppp0_0_38_1
Dec 28 17:13:03 daemon pppd[5659]: Connect: ppp_0_0_38_1 <-->
Dec 28 17:13:03 daemon pppd[5659]: Couldn't increase MTU to 1500.
Dec 28 17:13:12 daemon pppd[5659]: LCP: timeout sending Config-Requests
Dec 28 17:13:12 daemon pppd[5659]: Connection terminated.
Dec 28 17:13:15 daemon pppd[5659]: PPP: Start to connect ...
Dec 28 17:13:17 daemon pppd[5659]: Using interface ppp0_0_38_1
Dec 28 17:13:17 daemon pppd[5659]: Connect: ppp_0_0_38_1 <-->
Dec 28 17:13:17 daemon pppd[5659]: Couldn't increase MTU to 1500.
Dec 28 17:13:26 daemon pppd[5659]: LCP: timeout sending Config-Requests
Dec 28 17:13:26 daemon pppd[5659]: Connection terminated.
Dec 28 17:13:29 daemon pppd[5659]: PPP: Start to connect ...
Dec 28 17:13:31 daemon pppd[5659]: Using interface ppp0_0_38_1
Dec 28 17:13:31 daemon pppd[5659]: Connect: ppp_0_0_38_1 <-->
Dec 28 17:13:31 daemon pppd[5659]: Couldn't increase MTU to 1500.
Dec 28 17:13:40 daemon pppd[5659]: LCP: timeout sending Config-Requests
Dec 28 17:13:40 daemon pppd[5659]: Connection terminated.
Dec 28 17:13:43 daemon pppd[5659]: PPP: Start to connect ...
Dec 28 17:13:44 daemon pppd[5659]: Using interface ppp0_0_38_1
Dec 28 17:13:44 daemon pppd[5659]: Connect: ppp_0_0_38_1 <-->
Dec 28 17:13:44 daemon pppd[5659]: Couldn't increase MTU to 1500.
Dec 28 17:13:53 daemon pppd[5659]: LCP: timeout sending Config-Requests
Dec 28 17:13:53 daemon pppd[5659]: Connection terminated.
Dec 28 17:13:56 daemon pppd[5659]: PPP: Start to connect ...
Dec 28 17:13:58 daemon pppd[5659]: Using interface ppp0_0_38_1
Dec 28 17:13:58 daemon pppd[5659]: Connect: ppp_0_0_38_1 <-->
Dec 28 17:13:58 daemon pppd[5659]: Couldn't increase MTU to 1500.
Dec 28 17:14:00 user kernel: Line 0: ADSL link down
Dec 28 17:14:00 user syslog: tc qdisc del dev ppp_0_0_38_1 root 2>/dev/null
Dec 28 17:14:04 user kernel: Line 0: xDSL G.994 training
Dec 28 17:14:07 daemon pppd[5659]: LCP: timeout sending Config-Requests
Dec 28 17:14:07 daemon pppd[5659]: Connection terminated.
Dec 28 17:14:13 user kernel: Line 0: ADSL G.992 started
Dec 28 17:14:17 user kernel: Line 0: ADSL G.992 channel analysis
Dec 28 17:14:24 user kernel: Line 0: ADSL link down
Dec 28 17:14:28 user kernel: Line 0: xDSL G.994 training
Dec 28 17:14:36 user kernel: Line 0: ADSL G.992 started
Dec 28 17:14:41 user kernel: Line 0: ADSL G.992 channel analysis
Dec 28 17:14:47 user kernel: Line 0: ADSL G.992 message exchange
Dec 28 17:14:48 user kernel: Line 0: ADSL link up, Path 0, us=1007, ds=10350
Dec 28 17:14:49 daemon pppd[5659]: PPP: Start to connect ...
Dec 28 17:14:51 daemon pppd[5659]: Using interface ppp0_0_38_1
Dec 28 17:14:51 daemon pppd[5659]: Connect: ppp_0_0_38_1 <-->
Dec 28 17:14:51 daemon pppd[5659]: Couldn't increase MTU to 1500.
Dec 28 17:14:51 daemon pppd[5659]: PPP LCP UP.
Dec 28 17:14:51 daemon pppd[5659]: Couldn't increase MTU to 1500.
Dec 28 17:14:51 daemon pppd[5659]: PPP LCP UP.
Dec 28 17:14:52 daemon pppd[5659]: local IP address ----------
Dec 28 17:14:52 daemon pppd[5659]: remote IP address 195.166.128.229
Dec 28 17:14:52 daemon pppd[5659]: primary DNS address 212.159.6.9
Dec 28 17:14:52 daemon pppd[5659]: secondary DNS address 212.159.6.10
Dec 28 17:14:52 daemon dnsmasq[92]: using nameserver 212.159.6.10#53
Dec 28 17:14:52 daemon dnsmasq[92]: using nameserver 212.159.6.9#53
Dec 28 17:14:52 daemon pppd[5659]: Received valid IP address from server. Connection UP.
Dec 28 17:14:53 user syslog: begin: interface: ppp_0_0_38_1 go to up
Dec 28 17:14:53 daemon dnsmasq[92]: using nameserver 212.159.6.10#53
Dec 28 17:14:53 daemon dnsmasq[92]: using nameserver 212.159.6.9#53
Dec 28 17:14:53 daemon UPNPD[30275]: received signal 15, good-bye
Dec 28 17:14:56 daemon UPNPD[32360]: HTTP listening on port 2800
Dec 28 17:14:58 user syslog: end: interface: ppp_0_0_38_1 go to up
Dec 28 17:15:54 daemon pppd[5659]: LCP terminated by peer
Dec 28 17:15:54 daemon pppd[5659]: LCP terminated by peer
Dec 28 17:15:54 daemon pppd[5659]: Clear IP addresses. Connection DOWN.
Dec 28 17:15:54 daemon pppd[5659]: Clear IP addresses.
Dec 28 17:15:54 daemon pppd[5659]: Couldn't increase MTU to 1500.
Dec 28 17:15:54 user syslog: begin: interface: ppp_0_0_38_1 go to down
Dec 28 17:15:54 user syslog: end: interface: ppp_0_0_38_1 go to down
Dec 28 17:15:57 daemon pppd[5659]: Connection terminated.
Dec 28 17:15:57 daemon pppd[5659]: Connect time 1.1 minutes.
Dec 28 17:15:57 daemon pppd[5659]: Sent 90132 bytes, received 118822 bytes.
Steve
Re: Can anyone tell me what this means?
03-01-2012 2:33 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
Now been connected for 6 days, could anyone tell me if the stats are good, bad or just plain ugly please?
Total Uptimes (From SF counts):
WAN: 6 days, 01:27:49
LAN: 0 days, 00:00:00
Downstream
Noise Margin: 5.5 dB
Connection Rate: 10080 Kbps
Line Attenuation: 43.0 dB
Power: 0.0 dBm
Max Rate: 12660 Kbps
SuperFrames: 30822590
SF (CRC) Errors: 84466
Reed Solomon: 4006936790
RS Corrected: 252476149
RS Un-Corrected: 907209
HEC: 72862
Errored Seconds: 11065
Severe ES: 1755
Interleave Depth: 64
Bitswaps: 57333
Upstream
Noise Margin: 5.5 dB
Connection Rate: 1036 Kbps
Line Attenuation: 22.6 dB
Power: 12.8 dBm
Max Rate: 1040 Kbps
SuperFrames: 812610
SF (CRC) Errors: 1117
Reed Solomon: 804107
RS Corrected: 23819
RS Un-Corrected: 0
HEC: 2062
Errored Seconds: 549
Severe ES: 0
Interleave Depth: 4
Bitswaps: 10932
Downstream noise margin varies between 2.0 & 5.9
Thanks
Steve
Re: Can anyone tell me what this means?
03-01-2012 2:36 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
Re: Can anyone tell me what this means?
03-01-2012 2:46 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
Steve
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Plusnet Community
- :
- Forum
- :
- Help with my Plusnet services
- :
- Broadband
- :
- Can anyone tell me what this means?