|
|
|
Hi Guys, I hope you can help me with a question.
My download speeds have until recently, been pretty good 5-6Mbps.
Now they keep dropping to 1.4Mbps. It forst dropped about 2 weeks ago.
I went through some checks with my ISP (Eclipse), Changed filters, modem, and tested from my test socket at the master socket. All showed no improvement.
After a few days my speed started to climb again and got back uip to a steady 5.5Mbps.
On Friday they dropped again and are now steady at 1.4Mbps again.
My ISP is asking me to go through the same check again even though theyt didn't make any difference last time.
My question is quite simple realy... The DSLAM at the exchange reduced my profile speed when it sees drops in the line. When the line is steady it gradualy increases my profile speed over 10 days as long as it remainsd stable.
So.. If I change say a faulty filter will I see an immediate improvement in speed or will it take time for the DSLAM to see the improvement and increase my profile speed?
In other words do I need to change one thing and leave it for a day or so to see if there is any improvement or can I test and prove/disprove a faulty item straight away.
One other point I am pondering... I notice I very slight level of background noise on the telephone side whn off hook. It's certainly not enough to interfere with phone operation. In fact I can't be sure it's not me being paranoid to be honest.
If I book it out as a phone fault and BT find nothing wrong will they charge me the earth for doing b*gg*r all?
Just to be clear I have spare filters and a spare Modem (albeit and old SMC barricade) all of which make no difference.
I have an NTU5 Master socket and am currently plugged into the test socket so no extensions to worry about.
My main concern is the threat that BT will charge extortionate amounts if they find no fault so I am having to jump through hoops to p;rove it isn't my kit.
Any advice greatly appreciated.
Regards
Clive
|
|
|
|
Your line speed (on a resold BT product) is limited by BT's profiling system. The system drops your maximum line speed quickly if your sync rate drops, and raises it slowly if your sync rate climbs. Drops within minutes, climbs after up to 5 days.
Have you done a quiet line test with your router disconnected? (BT dial 17070 option 2).
Are your stats the same in and out of the test socket (within modern BT master sockets)?
|
|
|
Many thanks for fast reply John.
Your line speed (on a resold BT product) is limited by BT's profiling system. The system drops your maximum line speed quickly if your sync rate drops, and raises it slowly if your sync rate climbs. Drops within minutes, climbs after up to 5 days.
So that means I won't see any improvement if I swap say a faulty filter for a good one straight away?
Have you done a quiet line test with your router disconnected? (BT dial 17070 option 2).
Never heard of it. I will go offline and try it now. Thanks for the heads up on it.
Are your stats the same in and out of the test socket (within modern BT master sockets)?
Yes same in test socket as it is with faceplate in place.
UPDATE:
Just done quiet line test and with a wired handset in place the noise level is hardly discernable. I think I was just being paranoid.
Edited by deleted (Sun 03-Apr-11 17:00:38)
|
|
Register (or login) on our website and you will not see this ad.
|
|
|
|
If you restart your router it will sync as high as possible given the current line conditions, so if you replace a faulty component the sync rate will improve immediately. However BT's profiling system imposes a cap at the old, slower, sync rate for up to five days.
|
|
|
Sorry If I'm being dim but does that mean that as long as I restart my router I will see an improvement immediately and if I don't then I won't see any improvement for several days?
My route connection speed, which I think is the sync rate yopu refer to is a constant at 6.7Mbps.
If I understand you correctly is it true to say that restarting modem will reset the profile in the DSLAM?
Just trying to get my head around the processes here. Thanks for your patience 
|
|
|
If you always sync at the same rate the BT profiling system isn't a factor.
e.g. if you sync at 8128kbps the BT profile will be 7150kbps. If you sync lower the BT profile will be quickly reduced so that they don't pump data to you at a rate greater than you can receive. If you sync higher they slowly start to pump data at a greater rate again, but the ramp up in profile can take days.
Can you do a BT speed test and cut & paste the result excluding your phone number.
See http://www.speedtester.bt.com/
|
|
|
|
Here results......
Download speed achieved during the test was - 1362 Kbps
For your connection, the acceptable range of speeds is 400-2000 Kbps.
Additional Information:
Your DSL Connection Rate :6784 Kbps(DOWN-STREAM), 448 Kbps(UP-STREAM)
IP Profile for your line is - 1500 Kbps
|
|
|
The IP/BT profile of 1500 kbps is the sticking point, that is what is limiting your speeds. That should rise if your sync rate stays the same.
A profile of 1500 kbps suggests that your router/modem has recently synced at less than 2272 kbps.
Have a look at http://www.dslzoneuk.net/adslmax_explained.php
|
|
|
|
Thanks for the link John, good reading.
So as I see it my sync rate (Router Status/Show SAtats/Connection Speed on my Netgear 834GT) of 6752 kbps should give me a max data rate of 5.5Mbps. Which is exactly what I had before.
This looks to be stable and is the same every time I look it up. It is however a real time monitor, polling every 10 seconds. So how can I be sure that in the meantime it hasn't done a resync at a lower speed and then another at the higher? From what the tutorial says it would take the lower one unless the higher was maintained for some time.
I do get a log file emailed out of my router daily and sometimes it shows one or a number of LCP Down/Init LPC/LCP is allowed to come up and CHAP Authentication Failed or success. Sometimes it goes through this sycle many timers before a chap authentication is successful a bad one pasted at bottom....
I have sent these to my ISP but they seem to ignore them. Are they relevant?
Is this my modem resyncing?
If so how do I know what rate it synced at given this is historical information?
Am I right in assuming that my modem must be resyncing at a lower rate at some point for my speed to be reduced like this?? Or could it be the BRAS stuck??
I have now simplified my side of things completely. Discxonnected from my LAN and connected my PC directly to router, router connected directly to test socket using different filter so not sure what else I can do to prove it's not my end??
Wed, 2011-03-30 02:52:30 - LCP is allowed to come up.
Wed, 2011-03-30 02:53:30 - Initialize LCP.
Wed, 2011-03-30 02:53:30 - LCP is allowed to come up.
Wed, 2011-03-30 02:54:31 - Initialize LCP.
Wed, 2011-03-30 02:54:31 - LCP is allowed to come up.
Wed, 2011-03-30 02:55:25 - CHAP authentication failed
Wed, 2011-03-30 02:55:25 - LCP down.
Wed, 2011-03-30 02:55:31 - Initialize LCP.
Wed, 2011-03-30 02:55:31 - LCP is allowed to come up.
Wed, 2011-03-30 02:56:31 - Initialize LCP.
Wed, 2011-03-30 02:56:31 - LCP is allowed to come up.
Wed, 2011-03-30 02:57:31 - Initialize LCP.
Wed, 2011-03-30 02:57:31 - LCP is allowed to come up.
Wed, 2011-03-30 02:58:31 - Initialize LCP.
Wed, 2011-03-30 02:58:32 - LCP is allowed to come up.
Wed, 2011-03-30 02:59:32 - Initialize LCP.
Wed, 2011-03-30 02:59:32 - LCP is allowed to come up.
Wed, 2011-03-30 03:00:32 - Initialize LCP.
Wed, 2011-03-30 03:00:32 - LCP is allowed to come up.
Wed, 2011-03-30 03:01:17 - CHAP authentication failed
Wed, 2011-03-30 03:01:17 - LCP down.
Wed, 2011-03-30 03:01:32 - Initialize LCP.
Wed, 2011-03-30 03:01:32 - LCP is allowed to come up.
Wed, 2011-03-30 03:02:32 - Initialize LCP.
Wed, 2011-03-30 03:02:32 - LCP is allowed to come up.
Wed, 2011-03-30 03:03:32 - Initialize LCP.
Wed, 2011-03-30 03:03:32 - LCP is allowed to come up.
Wed, 2011-03-30 03:04:32 - Initialize LCP.
Wed, 2011-03-30 03:04:32 - LCP is allowed to come up.
Wed, 2011-03-30 03:05:32 - Initialize LCP.
Wed, 2011-03-30 03:05:32 - LCP is allowed to come up.
Wed, 2011-03-30 03:06:32 - Initialize LCP.
Wed, 2011-03-30 03:06:32 - LCP is allowed to come up.
Wed, 2011-03-30 03:06:54 - CHAP authentication failed
Wed, 2011-03-30 03:06:54 - LCP down.
Wed, 2011-03-30 03:07:33 - Initialize LCP.
Wed, 2011-03-30 03:07:33 - LCP is allowed to come up.
Wed, 2011-03-30 03:08:33 - Initialize LCP.
Wed, 2011-03-30 03:08:33 - LCP is allowed to come up.
Wed, 2011-03-30 03:09:33 - Initialize LCP.
Wed, 2011-03-30 03:09:33 - LCP is allowed to come up.
Wed, 2011-03-30 03:10:33 - Initialize LCP.
Wed, 2011-03-30 03:10:33 - LCP is allowed to come up.
Wed, 2011-03-30 03:11:33 - Initialize LCP.
Wed, 2011-03-30 03:11:33 - LCP is allowed to come up.
Wed, 2011-03-30 03:12:34 - Initialize LCP.
Wed, 2011-03-30 03:12:34 - LCP is allowed to come up.
Wed, 2011-03-30 03:13:34 - Initialize LCP.
Wed, 2011-03-30 03:13:34 - LCP is allowed to come up.
Wed, 2011-03-30 03:14:34 - Initialize LCP.
Wed, 2011-03-30 03:14:34 - LCP is allowed to come up.
Wed, 2011-03-30 03:15:34 - Initialize LCP.
Wed, 2011-03-30 03:15:34 - LCP is allowed to come up.
Wed, 2011-03-30 03:16:34 - Initialize LCP.
Wed, 2011-03-30 03:16:34 - LCP is allowed to come up.
Wed, 2011-03-30 03:17:34 - Initialize LCP.
Wed, 2011-03-30 03:17:34 - LCP is allowed to come up.
Wed, 2011-03-30 03:17:40 - CHAP authentication failed
Wed, 2011-03-30 03:17:40 - LCP down.
Wed, 2011-03-30 03:18:34 - Initialize LCP.
Wed, 2011-03-30 03:18:34 - LCP is allowed to come up.
Wed, 2011-03-30 03:19:34 - Initialize LCP.
Wed, 2011-03-30 03:19:34 - LCP is allowed to come up.
Wed, 2011-03-30 03:20:34 - Initialize LCP.
Wed, 2011-03-30 03:20:35 - LCP is allowed to come up.
Wed, 2011-03-30 03:21:35 - Initialize LCP.
Wed, 2011-03-30 03:21:35 - LCP is allowed to come up.
Wed, 2011-03-30 03:22:35 - Initialize LCP.
Wed, 2011-03-30 03:22:35 - LCP is allowed to come up.
Wed, 2011-03-30 03:23:28 - CHAP authentication failed
Wed, 2011-03-30 03:23:28 - LCP down.
Wed, 2011-03-30 03:23:35 - Initialize LCP.
Wed, 2011-03-30 03:23:35 - LCP is allowed to come up.
Wed, 2011-03-30 03:24:35 - Initialize LCP.
Wed, 2011-03-30 03:24:35 - LCP is allowed to come up.
Wed, 2011-03-30 03:25:35 - Initialize LCP.
Wed, 2011-03-30 03:25:35 - LCP is allowed to come up.
Wed, 2011-03-30 03:26:35 - Initialize LCP.
Wed, 2011-03-30 03:26:35 - LCP is allowed to come up.
Wed, 2011-03-30 03:27:35 - Initialize LCP.
Wed, 2011-03-30 03:27:35 - LCP is allowed to come up.
Wed, 2011-03-30 03:28:36 - Initialize LCP.
Wed, 2011-03-30 03:28:36 - LCP is allowed to come up.
Wed, 2011-03-30 03:29:06 - CHAP authentication failed
Wed, 2011-03-30 03:29:06 - LCP down.
Wed, 2011-03-30 03:29:36 - Initialize LCP.
Wed, 2011-03-30 03:29:36 - LCP is allowed to come up.
Wed, 2011-03-30 03:30:36 - Initialize LCP.
Wed, 2011-03-30 03:30:36 - LCP is allowed to come up.
Wed, 2011-03-30 03:31:36 - Initialize LCP.
Wed, 2011-03-30 03:31:36 - LCP is allowed to come up.
Wed, 2011-03-30 03:32:36 - Initialize LCP.
Wed, 2011-03-30 03:32:36 - LCP is allowed to come up.
Wed, 2011-03-30 03:33:36 - Initialize LCP.
Wed, 2011-03-30 03:33:36 - LCP is allowed to come up.
Wed, 2011-03-30 03:34:36 - Initialize LCP.
Wed, 2011-03-30 03:34:36 - LCP is allowed to come up.
Wed, 2011-03-30 03:34:54 - CHAP authentication failed
Wed, 2011-03-30 03:34:54 - LCP down.
Wed, 2011-03-30 03:35:36 - Initialize LCP.
Wed, 2011-03-30 03:35:36 - LCP is allowed to come up.
Wed, 2011-03-30 03:36:37 - Initialize LCP.
Wed, 2011-03-30 03:36:37 - LCP is allowed to come up.
Wed, 2011-03-30 03:37:37 - Initialize LCP.
Wed, 2011-03-30 03:37:37 - LCP is allowed to come up.
Wed, 2011-03-30 03:38:37 - Initialize LCP.
Wed, 2011-03-30 03:38:37 - LCP is allowed to come up.
Wed, 2011-03-30 03:39:37 - Initialize LCP.
Wed, 2011-03-30 03:39:37 - LCP is allowed to come up.
Wed, 2011-03-30 03:40:37 - Initialize LCP.
Wed, 2011-03-30 03:40:37 - LCP is allowed to come up.
Wed, 2011-03-30 03:41:37 - Initialize LCP.
Wed, 2011-03-30 03:41:37 - LCP is allowed to come up.
Wed, 2011-03-30 03:42:37 - Initialize LCP.
Wed, 2011-03-30 03:42:37 - LCP is allowed to come up.
Wed, 2011-03-30 03:43:38 - Initialize LCP.
Wed, 2011-03-30 03:43:38 - LCP is allowed to come up.
Wed, 2011-03-30 03:44:38 - Initialize LCP.
Wed, 2011-03-30 03:44:38 - LCP is allowed to come up.
Wed, 2011-03-30 03:45:38 - Initialize LCP.
Wed, 2011-03-30 03:45:38 - LCP is allowed to come up.
Wed, 2011-03-30 03:46:10 - CHAP authentication failed
Wed, 2011-03-30 03:46:10 - LCP down.
Wed, 2011-03-30 03:46:38 - Initialize LCP.
Wed, 2011-03-30 03:46:38 - LCP is allowed to come up.
Wed, 2011-03-30 03:47:38 - Initialize LCP.
Wed, 2011-03-30 03:47:38 - LCP is allowed to come up.
Wed, 2011-03-30 03:48:38 - Initialize LCP.
Wed, 2011-03-30 03:48:38 - LCP is allowed to come up.
Wed, 2011-03-30 03:49:38 - Initialize LCP.
Wed, 2011-03-30 03:49:38 - LCP is allowed to come up.
Wed, 2011-03-30 03:50:38 - Initialize LCP.
Wed, 2011-03-30 03:50:38 - LCP is allowed to come up.
Wed, 2011-03-30 03:51:39 - Initialize LCP.
Wed, 2011-03-30 03:51:39 - LCP is allowed to come up.
Wed, 2011-03-30 03:51:59 - CHAP authentication failed
Wed, 2011-03-30 03:51:59 - LCP down.
Wed, 2011-03-30 03:52:39 - Initialize LCP.
Wed, 2011-03-30 03:52:39 - LCP is allowed to come up.
Wed, 2011-03-30 03:53:39 - Initialize LCP.
Wed, 2011-03-30 03:53:39 - LCP is allowed to come up.
Wed, 2011-03-30 03:54:39 - Initialize LCP.
Wed, 2011-03-30 03:54:39 - LCP is allowed to come up.
Wed, 2011-03-30 03:55:39 - Initialize LCP.
Wed, 2011-03-30 03:55:39 - LCP is allowed to come up.
Wed, 2011-03-30 03:56:39 - Initialize LCP.
Wed, 2011-03-30 03:56:39 - LCP is allowed to come up.
Wed, 2011-03-30 03:57:27 - CHAP authentication failed
Wed, 2011-03-30 03:57:27 - LCP down.
Wed, 2011-03-30 03:57:39 - Initialize LCP.
Wed, 2011-03-30 03:57:39 - LCP is allowed to come up.
Wed, 2011-03-30 03:58:39 - Initialize LCP.
Wed, 2011-03-30 03:58:40 - LCP is allowed to come up.
Wed, 2011-03-30 03:59:40 - Initialize LCP.
Wed, 2011-03-30 03:59:40 - LCP is allowed to come up.
Wed, 2011-03-30 04:00:40 - Initialize LCP.
Wed, 2011-03-30 04:00:40 - LCP is allowed to come up.
Wed, 2011-03-30 04:01:40 - Initialize LCP.
Wed, 2011-03-30 04:01:40 - LCP is allowed to come up.
Wed, 2011-03-30 04:02:40 - Initialize LCP.
Wed, 2011-03-30 04:02:40 - LCP is allowed to come up.
Wed, 2011-03-30 04:03:18 - CHAP authentication failed
Wed, 2011-03-30 04:03:18 - LCP down.
Wed, 2011-03-30 04:03:40 - Initialize LCP.
Wed, 2011-03-30 04:03:40 - LCP is allowed to come up.
Wed, 2011-03-30 04:04:40 - Initialize LCP.
Wed, 2011-03-30 04:04:40 - LCP is allowed to come up.
Wed, 2011-03-30 04:05:40 - Initialize LCP.
Wed, 2011-03-30 04:05:40 - LCP is allowed to come up.
Wed, 2011-03-30 04:06:41 - Initialize LCP.
Wed, 2011-03-30 04:06:41 - LCP is allowed to come up.
Wed, 2011-03-30 04:07:41 - Initialize LCP.
Wed, 2011-03-30 04:07:41 - LCP is allowed to come up.
Wed, 2011-03-30 04:08:41 - Initialize LCP.
Wed, 2011-03-30 04:08:41 - LCP is allowed to come up.
Wed, 2011-03-30 04:09:22 - CHAP authentication failed
Wed, 2011-03-30 04:09:22 - LCP down.
Wed, 2011-03-30 04:09:41 - Initialize LCP.
Wed, 2011-03-30 04:09:41 - LCP is allowed to come up.
Wed, 2011-03-30 04:10:41 - Initialize LCP.
Wed, 2011-03-30 04:10:41 - LCP is allowed to come up.
Wed, 2011-03-30 04:11:41 - Initialize LCP.
Wed, 2011-03-30 04:11:41 - LCP is allowed to come up.
Wed, 2011-03-30 04:12:41 - Initialize LCP.
Wed, 2011-03-30 04:12:41 - LCP is allowed to come up.
Wed, 2011-03-30 04:13:41 - Initialize LCP.
Wed, 2011-03-30 04:13:42 - LCP is allowed to come up.
Wed, 2011-03-30 04:14:42 - Initialize LCP.
Wed, 2011-03-30 04:14:42 - LCP is allowed to come up.
Wed, 2011-03-30 04:14:52 - CHAP authentication failed
Wed, 2011-03-30 04:14:52 - LCP down.
Wed, 2011-03-30 04:15:42 - Initialize LCP.
Wed, 2011-03-30 04:15:42 - LCP is allowed to come up.
Wed, 2011-03-30 04:16:42 - Initialize LCP.
Wed, 2011-03-30 04:16:42 - LCP is allowed to come up.
Wed, 2011-03-30 04:17:42 - Initialize LCP.
Wed, 2011-03-30 04:17:42 - LCP is allowed to come up.
Wed, 2011-03-30 04:18:42 - Initialize LCP.
Wed, 2011-03-30 04:18:42 - LCP is allowed to come up.
Wed, 2011-03-30 04:19:42 - Initialize LCP.
Wed, 2011-03-30 04:19:42 - LCP is allowed to come up.
Wed, 2011-03-30 04:20:22 - CHAP authentication failed
Wed, 2011-03-30 04:20:22 - LCP down.
Wed, 2011-03-30 04:20:42 - Initialize LCP.
Wed, 2011-03-30 04:20:42 - LCP is allowed to come up.
Wed, 2011-03-30 04:21:42 - Initialize LCP.
Wed, 2011-03-30 04:21:42 - LCP is allowed to come up.
Wed, 2011-03-30 04:22:43 - Initialize LCP.
Wed, 2011-03-30 04:22:43 - LCP is allowed to come up.
Wed, 2011-03-30 04:23:43 - Initialize LCP.
Wed, 2011-03-30 04:23:43 - LCP is allowed to come up.
Wed, 2011-03-30 04:24:43 - Initialize LCP.
Wed, 2011-03-30 04:24:43 - LCP is allowed to come up.
Wed, 2011-03-30 04:25:43 - Initialize LCP.
Wed, 2011-03-30 04:25:43 - LCP is allowed to come up.
Wed, 2011-03-30 04:26:08 - CHAP authentication failed
Wed, 2011-03-30 04:26:08 - LCP down.
Wed, 2011-03-30 04:26:43 - Initialize LCP.
Wed, 2011-03-30 04:26:43 - LCP is allowed to come up.
Wed, 2011-03-30 04:27:43 - Initialize LCP.
Wed, 2011-03-30 04:27:43 - LCP is allowed to come up.
Wed, 2011-03-30 04:28:43 - Initialize LCP.
Wed, 2011-03-30 04:28:43 - LCP is allowed to come up.
Wed, 2011-03-30 04:29:43 - Initialize LCP.
Wed, 2011-03-30 04:29:43 - LCP is allowed to come up.
Wed, 2011-03-30 04:30:44 - Initialize LCP.
Wed, 2011-03-30 04:30:44 - LCP is allowed to come up.
Wed, 2011-03-30 04:31:44 - Initialize LCP.
Wed, 2011-03-30 04:31:44 - LCP is allowed to come up.
Wed, 2011-03-30 04:32:44 - Initialize LCP.
Wed, 2011-03-30 04:32:44 - LCP is allowed to come up.
Wed, 2011-03-30 04:33:44 - Initialize LCP.
Wed, 2011-03-30 04:33:44 - LCP is allowed to come up.
Wed, 2011-03-30 04:34:44 - Initialize LCP.
Wed, 2011-03-30 04:34:44 - LCP is allowed to come up.
Wed, 2011-03-30 04:35:44 - Initialize LCP.
Wed, 2011-03-30 04:35:44 - LCP is allowed to come up.
Wed, 2011-03-30 04:36:44 - Initialize LCP.
Wed, 2011-03-30 04:36:44 - LCP is allowed to come up.
Wed, 2011-03-30 04:36:55 - CHAP authentication failed
Wed, 2011-03-30 04:36:55 - LCP down.
Wed, 2011-03-30 04:37:45 - Initialize LCP.
Wed, 2011-03-30 04:37:45 - LCP is allowed to come up.
Wed, 2011-03-30 04:38:45 - Initialize LCP.
Wed, 2011-03-30 04:38:45 - LCP is allowed to come up.
Wed, 2011-03-30 04:39:45 - Initialize LCP.
Wed, 2011-03-30 04:39:45 - LCP is allowed to come up.
Wed, 2011-03-30 04:40:45 - Initialize LCP.
Wed, 2011-03-30 04:40:45 - LCP is allowed to come up.
Wed, 2011-03-30 04:41:45 - Initialize LCP.
Wed, 2011-03-30 04:41:45 - LCP is allowed to come up.
Wed, 2011-03-30 04:42:42 - CHAP authentication failed
Wed, 2011-03-30 04:42:42 - LCP down.
Wed, 2011-03-30 04:42:45 - Initialize LCP.
Wed, 2011-03-30 04:42:45 - LCP is allowed to come up.
Wed, 2011-03-30 04:43:45 - Initialize LCP.
Wed, 2011-03-30 04:43:45 - LCP is allowed to come up.
Wed, 2011-03-30 04:44:45 - Initialize LCP.
Wed, 2011-03-30 04:44:46 - LCP is allowed to come up.
Wed, 2011-03-30 04:45:46 - Initialize LCP.
Wed, 2011-03-30 04:45:46 - LCP is allowed to come up.
Wed, 2011-03-30 04:46:46 - Initialize LCP.
Wed, 2011-03-30 04:46:46 - LCP is allowed to come up.
Wed, 2011-03-30 04:47:46 - Initialize LCP.
Wed, 2011-03-30 04:47:46 - LCP is allowed to come up.
Wed, 2011-03-30 04:48:29 - CHAP authentication failed
Wed, 2011-03-30 04:48:29 - LCP down.
Wed, 2011-03-30 04:48:46 - Initialize LCP.
Wed, 2011-03-30 04:48:46 - LCP is allowed to come up.
Wed, 2011-03-30 04:49:46 - Initialize LCP.
Wed, 2011-03-30 04:49:46 - LCP is allowed to come up.
Wed, 2011-03-30 04:50:46 - Initialize LCP.
Wed, 2011-03-30 04:50:46 - LCP is allowed to come up.
Wed, 2011-03-30 04:51:46 - Initialize LCP.
Wed, 2011-03-30 04:51:46 - LCP is allowed to come up.
Wed, 2011-03-30 04:52:46 - Initialize LCP.
Wed, 2011-03-30 04:52:46 - LCP is allowed to come up.
Wed, 2011-03-30 04:53:47 - Initialize LCP.
Wed, 2011-03-30 04:53:47 - LCP is allowed to come up.
Wed, 2011-03-30 04:54:38 - CHAP authentication failed
Wed, 2011-03-30 04:54:38 - LCP down.
Wed, 2011-03-30 04:54:47 - Initialize LCP.
Wed, 2011-03-30 04:54:47 - LCP is allowed to come up.
Wed, 2011-03-30 04:55:47 - Initialize LCP.
Wed, 2011-03-30 04:55:47 - LCP is allowed to come up.
Wed, 2011-03-30 04:56:47 - Initialize LCP.
Wed, 2011-03-30 04:56:47 - LCP is allowed to come up.
Wed, 2011-03-30 04:57:47 - Initialize LCP.
Wed, 2011-03-30 04:57:47 - LCP is allowed to come up.
Wed, 2011-03-30 04:58:47 - Initialize LCP.
Wed, 2011-03-30 04:58:47 - LCP is allowed to come up.
Wed, 2011-03-30 04:59:47 - Initialize LCP.
Wed, 2011-03-30 04:59:47 - LCP is allowed to come up.
Wed, 2011-03-30 04:59:57 - CHAP authentication failed
Wed, 2011-03-30 04:59:57 - LCP down.
Wed, 2011-03-30 05:00:48 - Initialize LCP.
Wed, 2011-03-30 05:00:48 - LCP is allowed to come up.
Wed, 2011-03-30 05:01:48 - Initialize LCP.
Wed, 2011-03-30 05:01:48 - LCP is allowed to come up.
Wed, 2011-03-30 05:02:48 - Initialize LCP.
Wed, 2011-03-30 05:02:48 - LCP is allowed to come up.
Wed, 2011-03-30 05:03:48 - Initialize LCP.
Wed, 2011-03-30 05:03:48 - LCP is allowed to come up.
Wed, 2011-03-30 05:04:48 - Initialize LCP.
Wed, 2011-03-30 05:04:48 - LCP is allowed to come up.
Wed, 2011-03-30 05:05:02 - CHAP authentication failed
Wed, 2011-03-30 05:05:02 - LCP down.
Wed, 2011-03-30 05:05:48 - Initialize LCP.
Wed, 2011-03-30 05:05:48 - LCP is allowed to come up.
Wed, 2011-03-30 05:06:48 - Initialize LCP.
Wed, 2011-03-30 05:06:48 - LCP is allowed to come up.
Wed, 2011-03-30 05:07:48 - Initialize LCP.
Wed, 2011-03-30 05:07:48 - LCP is allowed to come up.
Wed, 2011-03-30 05:08:49 - Initialize LCP.
Wed, 2011-03-30 05:08:49 - LCP is allowed to come up.
Wed, 2011-03-30 05:09:49 - Initialize LCP.
Wed, 2011-03-30 05:09:49 - LCP is allowed to come up.
Wed, 2011-03-30 05:10:46 - CHAP authentication failed
Wed, 2011-03-30 05:10:46 - LCP down.
Wed, 2011-03-30 05:10:49 - Initialize LCP.
Wed, 2011-03-30 05:10:49 - LCP is allowed to come up.
Wed, 2011-03-30 05:11:49 - Initialize LCP.
Wed, 2011-03-30 05:11:49 - LCP is allowed to come up.
Wed, 2011-03-30 05:12:49 - Initialize LCP.
Wed, 2011-03-30 05:12:49 - LCP is allowed to come up.
Wed, 2011-03-30 05:13:49 - Initialize LCP.
Wed, 2011-03-30 05:13:49 - LCP is allowed to come up.
Wed, 2011-03-30 05:14:49 - Initialize LCP.
Wed, 2011-03-30 05:14:49 - LCP is allowed to come up.
Wed, 2011-03-30 05:15:50 - Initialize LCP.
Wed, 2011-03-30 05:15:50 - LCP is allowed to come up.
Wed, 2011-03-30 05:15:53 - CHAP authentication success
|
|
|
All it tells us is that the modem was slow at authenticating, the WAN uptime in the router statistics should allow you to work out when it last resynced.
It takes up to five days of a better speed for the IP Profile to recover, one bad sync resets this. Now for big changes it should be faster, but depends on what the line is doing.
If BRAS stuck it will NEVER change, but the ISP should be able to look at the data for your line and figure things out, if they are any good
|
|
The author of the above post is a thinkbroadband staff member. It may not constitute an official statement on behalf of thinkbroadband.
|
|
|
|
Thanks for that. From what I can see the only time the system up timer resets is when I do some thing. I'll keep a record of it for a while though just to be sure.
Thanks again.
|
|
|
|
Just a thought. If the WAN is up and stays up, why would it re authenticate?
|
|
|
Might be worth having a look at RouterStats which will collate and graph relevant stats. See http://www.vwlowen.co.uk/internet/files.htm
|
|
|
Because of an issue at the ISP end that handles the authentication, i.e. logs you off perhaps
|
|
The author of the above post is a thinkbroadband staff member. It may not constitute an official statement on behalf of thinkbroadband.
|
|
|
|
OK Thanks. So that's not nesesarily associated with a resync.
So am I right in sayimng that if I sync at 6752 kbps and my router shows an uptime of >5days my profile speed should increase?
|
|
|
|
Thanks John I'll have a look.
|
|
|
Should do. Can't be 100% as it is possible for a router to drop the link and resync and the user interface to not update.
Resyncs themself are not the problem, you can resync a number of times a day, but if always around the 6752Kbps mark, then the IP Profile should still improve.
|
|
The author of the above post is a thinkbroadband staff member. It may not constitute an official statement on behalf of thinkbroadband.
|
|
|
OK thanks. I should have said if it doesn't do any resyncs at a lower speed.
I'm running routerstats for a day or so at the moment to see what that shows up.
I wish BT would take some responsibility without the threat of massive charges if they find no fault. Who's the bl**dy customer here 
|
|
|
If you restart your router it will sync as high as possible given the current line conditions, so if you replace a faulty component the sync rate will improve immediately. However BT's profiling system imposes a cap at the old, slower, sync rate for up to five days.
Just reading this again John.. So if I already have a good sync rate as I have now (6725kbps) but my profile is capped to 1.4Mbps. If I change a faulty piece of kit I won't see any difference because the sync rate won't change and neither will my actual data rate. Am I reading that right??
|
|
|
Wrong
Sync rate changes are instant always
IP Profile which governs data rate will not change, may take 1 hour to 5 days to change
|
|
The author of the above post is a thinkbroadband staff member. It may not constitute an official statement on behalf of thinkbroadband.
|
|
|
Wrong
Sync rate changes are instant always
IP Profile which governs data rate will not change, may take 1 hour to 5 days to change
Sorry, I think that's what I was trying to say in a roundabout way. Long time since inglishh o level 
As I see it...
My sync rate won't change in my circumstances because it's already pretty good at 6725kbps (better than my profile would suggest). So if I resync it will sync at the same speed (assuming my line is at max potential).
If my sync rate did improve my data rate wouldn't immediately change because my profile would limit it for 1hour to 5 days.
So from a testing perspective if I change something and restart my router I am unlikely to see any change immediately because my sync rate won't go any higher and my profile won't change straight away??
Sorry to be so verbose but I want to make sure of my facts before I shout at ISP
Is it also true to say that if these stats stay constant then my modem, cabling and line to the exchange are all ok, my profile should improve and any issues must be deeper in the network?
|
|
|
|
Router stats show a steady sync rate of 6752kbps
and Rx noise marging of 14-15dB since yeasterday early PM.
Is it true to say that if they stay that way for 5 days my profile rate should increase back up to 5.5Mbps for the above sync rate?
Are there any other factors I need to look for which may effect my profile?
|
|
|
"Is it also true to say that if these stats stay constant then my modem, cabling and line to the exchange are all ok, my profile should improve and any issues must be deeper in the network? "
Probably - there can still be issues affecting throughput that are not showing up via poor connection speed and IP Profiles, but on balance if all is well as you suggest, then does point towards core network/ISP issues
|
|
The author of the above post is a thinkbroadband staff member. It may not constitute an official statement on behalf of thinkbroadband.
|
|
|
...So from a testing perspective if I change something and restart my router I am unlikely to see any change immediately because my sync rate won't go any higher and my profile won't change straight away??
Changing your kit etc. will allow your to see changes to your sync/attention/noisemargin immediately so you can see if you are improving (or not!) things (the link is to my web page where I've tried to explain the basics).
Not sure if this has been mentioned but resyncs/reconnects should always be done during the day to get the best results (darkness=noise) also don't resync too often or BT will think you have a line problem and increase your Target SNRM!
|
|
|
...So from a testing perspective if I change something and restart my router I am unlikely to see any change immediately because my sync rate won't go any higher and my profile won't change straight away??
Changing your kit etc. will allow your to see changes to your sync/attention/noisemargin immediately so you can see if you are improving (or not!) things (the link is to my web page where I've tried to explain the basics).
Not sure if this has been mentioned but resyncs/reconnects should always be done during the day to get the best results (darkness=noise) also don't resync too often or BT will think you have a line problem and increase your Target SNRM!
Thanks b4deger, I'll read up on your site.
So, as I already have a decent sync rate of6725kbps and Rx Noise Margin of >14dB
My Line Attenuation is 24dB but surely I can't do anything about that as it's mainly a function of distance from exchange.
These figures, assuming thay can be maintained (I am running RouterStats on it) should give me a profile speed of 5.5Mbps (which I had before the problem). So I don't need to change any kit my end because I have no figures to improve. Therefor problem is with ISP/BT.
Or am I looking at this wrong??
Regards
Clive
|
|
|
Profile up to 5.5mbps now with speed test showing 5.1Mbps down. Slightly lower than I had before but getting there
I'm leaving it alone for the rest of today/night with router stats running. Will normalise wiring (I am in test socket ATT) tommorow and see if it affects my sync rate.
With a sync rate of 6752kbps and noise margin of >14dB is there anything I can do to increase my profile further?
I already have NTE5 socket with ADSL faceplate etc.
|
|
|
|
If you have a downstream attenuation of 24dB you should normally be syncing at 8128 on standard ADSL.
Could you post your router stats?
i.e. SNR margin, attenuation, sync rate for both up and down stream, plus any error counts you can find and uptime?
|
|
|
|
Don't know if this will post properly but here the router stats table...
I can't get it to line up properly and can't get it into a tabler. I can save it as a jpg but can't post attachments, is that cos I is new?
System Up Time 56:05:46
Port Status TxPkts RxPkts Collisions Tx B/s Rx B/s Up Time
WAN PPPoA 305484 452738 0 293 2453 56:05:14
LAN 10M/100M 468833 336595 0 2234 286 56:05:41
WLAN 11M/54M/108M195869 177793 0 905 339 56:05:35
ADSL Link Downstream Upstream
Connection Speed 6752 kbps 448 kbps
Line Attenuation 24.0 db 14.5 db
Noise Margin 14.3 db 24.0 db
|
|
|
Attachments/images arent allow to protect you spammers/scammers
The high target noise margin is probably why you aren't getting the 8Meg sync, if the target noise margin was reduced to 9dB then 8Meg sync seems possible
|
|
The author of the above post is a thinkbroadband staff member. It may not constitute an official statement on behalf of thinkbroadband.
|
|
|
Attachments/images arent allow to protect you spammers/scammers
The high target noise margin is probably why you aren't getting the 8Meg sync, if the target noise margin was reduced to 9dB then 8Meg sync seems possible
Is that figure the "target" noise margin and not the "actual" margin?
In any case I'm guessing that it is for my ISP/BT to reduce or is there anything I can do to reduce it?
Thanks for heads up on piccies
|
|
|
|
The default target SNR margin is 6dB. Yours seems to have been raised. It is meant to lower in 3dB steps if your line is stable, but each 3dB step drop is rumoured to take 2 weeks.
You could ask your ISP to have the target SNR margin reset. The problem is most ISPs don't seem to understand the request, and even if they do not all are successful at passing the request on to BT.
You have the additional problem of not knowing what caused the bad sync which triggered the lowering of your profile. You might get your line reset only to suffer a bad sync again.
|
|
|
Sorry but I'm confused 
Is the figure I am quoting from my router a "target" Noise Margin or "actual" Noise Margin? It's labled "Noise Margin"
When I look at a plot of it on a graph in routerstats it varies throughout the day +/- the odd dB here and there. So does that not suggest I am looking at a live noise figure and not some target set by DLM which would be a constant surely?
I thought I understood SNR Noise Margin and Target Noise Margin but I'm not so sure now. Google here I come
|
|
|
|
The figure given by your router is the current SNR margin. Typically when a router syncs it will be at the fastest speed possible to achieve a target SNR margin of 6dB. As line conditions fluctuate the SNR margin will rise and fall accordingly (more radio interference at night tends to cause the SNR margin to fall).
In your case it seems that at one stage your router couldn't sync at all with target margins of 6dB, or 9dB, but could sync at 12dB.
The next time you restart your modem/router look at the SNR margin as soon as possible after restart. That should indicate your target SNR margin.
|
|
|
|
Thanks John, I plan to normalise my wiring tommorow morning so will do it then.
Regards
Clive
|
|
|
Just normalised wiring so now connected through NTE5 and adsl faceplate.
Router Stats below look musch the same. In fact sync rate a bit higher, attenuation figure the same, noise figure slightly higher ...
Speed test results the same @ 5.1Mbps.
System Up Time 00:02:07
Port Status TxPkts RxPkts Collisions Tx B/s Rx B/s Up Time
WAN PPPoA 340 289 0 2853 4609 00:00:32
LAN 10M/100M 415 603 0 1473 1066 00:02:02
WLAN 11M/54M/108M172 6 0 196 5 00:01:56
ADSL Link Downstream Upstream
Connection Speed 6880 kbps 448 kbps
Line Attenuation 24.0 db 14.5 db
Noise Margin 14.8 db 24.0 db
Edited by deleted (Thu 07-Apr-11 08:54:57)
|
|
|
What did you do to normalise the wiring?
|
|
The author of the above post is a thinkbroadband staff member. It may not constitute an official statement on behalf of thinkbroadband.
|
|
|
|
One question.
I am only about 0.8Km from the exchange as the crow flies. Is 24dB Line attenuation a bit high for that kind of distance?
|
|
|
|
I put my ADSL faceplate back into the NTE5 and wired my router back to my LAN wiring (just a small patch panel set up). I had disconnected everything apart from my main PC and the WAN connection from the router to eliminate all unnessesary patching etc.
|
|
|
Guys,
In an attempt to sort out my confusion I have read up on several sites. I found a somewhat bewildering array of information but I think I am starting to get to grips with it.
I have tried to collate all the information I have found into one document. It's a work in progress but I'd like to put it up here to see if I am talking sence or pure gibberish (like I normaly do )
Please feel free to comment, good and bad (I can take it )
Any constructive critisism on anything I have wrong or could be explained better greatly appreciated....
ADSL Stats As I see them
Transmit Power The amount of signal sent from the exchange dBmw Tx Power
Line Attenuation The amount of power lost through line impedance, Joints etc dB Atten Generally the longer the line the higher the line attenuation will be. It can also be effected by joints in the line (especially if they are badly made) amongst other things. The data rate or frequency of transmission also effects line attenuation. The higher the frequency/data rate the higher the line attenuation.
Received Power What is left of the transmitted power received by the modem after the line attenuation dBmw Rx Power = Tx Power - Atten The receiver will need a minimum amount of power to be able to decode the signal. This is called receiver sensitivity.
Noise level The amount of noise power on a line. dBmw Noise Again the longer the line the more noise will be induced in it. Noise comes from many sources; Atmospheric noise (thunder storms etc.), electrical interference from white goods or vehicles in the area and crosstalk from other lines running parallel to your line. This figure will change throughout the day. Cable quality also effects noise levels.
Signal to Noise Ratio The difference between the wanted signal and the noise levels dB SNR =Rx Power - Noise Probably the most important factor in any transmission service. The receiving equipment must have enough received power in the signal and it must not be swamped by noise. i.e. the SNR must be at least a minimum value
Connection speed The data rate established between the modem and DSLAM at the exchange when synchronisation takes place. This is the maximum data rate that can be maintained point to point between the modem and DSAM Kbps or Mbps Note data throughput (speed test results will be lower due to overheads)
Signal to Noise Margin This is where I get a bit grey...but as I see it...
SNR Margin = Required SNR + a Margin for variations in noise levels. dB SNRM To maintain a given data rate the modem required sufficient Rx Power with a high enough SNR to enable it to decode the signal. Given that noise levels fluctuate the SNRM figure is used to ensure a stable connection.
Target Signal to Noise Margin Again a bit grey...
Given the historical noise fluctuations on your line this figure is set by the DLM (Dynamic Line Management (a misnomer if ever there was one)) to ensure a stable connection. dB Target SNRM
To summarise all this.
As your data rate increases the line attenuation for that signal also increases.
Therefore you will lose more of your signal and so your Signal to noise ratio will reduce.
If the SNR falls below a certain level you will start to get errors/packet loss etc. If this happens the DLM will reduce your profile and therefore your throughput speed until it sees a period of sustained improvement.
The only way to avoid/minimise the chances of this is to
a) Reduce your data rate. This is what DLM does through profiling.
b) Reduce noise levels by using quality cable, minimising joints, ensuring good separation from power lines and other electrical devices.
c) Make sure you run modem from master socket, remove bell wire etc.
d) Increase Transmit power level. This will raise your signal out of the noise. Unfortunately we can't control this.
e) Presumably some modems will be more sensitive than others and so better at digging low signal levels out of noise?
|
|
|
No because, the phone line does not fly like a crow, but wriggles up and down the road
|
|
The author of the above post is a thinkbroadband staff member. It may not constitute an official statement on behalf of thinkbroadband.
|
|
|
No because, the phone line does not fly like a crow, but wriggles up and down the road
I appreciate that but proportionaly the line will be shorter than someone who is 5km away for the exchange. I guess the question I asked should be - is 24dB a reasonable loss for that distance from the exchange?
|
|
|
5km of cable is around 60dB attenuation
2km is around 24dB of cable
|
|
The author of the above post is a thinkbroadband staff member. It may not constitute an official statement on behalf of thinkbroadband.
|
|
|
Have a look at http://en.wikipedia.org/wiki/ITU_G.992.1 and http://www.itu.int/rec/T-REC-G.992.1-199907-I/en
9.5.1 Near-end test parameters
The following near-end test parameters shall be provided at the ATU-C and the ATU-R:
o Attenuation (ATN): The attenuation is the difference in dB between the power received at
the near-end and that transmitted from the far-end. Received signal power in dBm is the sum
of all data-carrying (i.e. bi > 0) DMT subcarrier powers averaged over a 1 second period.
Transmitted signal power is �3.65 �2n + 10 log (sigma gi**2 ) dBm, summed over the data-carrying
subcarriers. The attenuation ranges from 0 to 63.5 dB with 0.5 dB steps.
o Signal-to-Noise Ratio (SNR) margin: The signal-to-noise ratio margin represents the
amount of increased received noise (in dB) relative to the noise power that the system is
designed to tolerate and still meet the target BER of 10**-7 , accounting for all coding
(e.g. trellis coding, RS FEC) gains included in the design. The SNR margin ranges from
�64.0 dB to +63.5 dB with 0.5 dB steps.
If you understand those documents you'll have more understanding than anyone here (speaking for myself of course).
|
|
|
Have a look at http://en.wikipedia.org/wiki/ITU_G.992.1 and http://www.itu.int/rec/T-REC-G.992.1-199907-I/en
9.5.1 Near-end test parameters
The following near-end test parameters shall be provided at the ATU-C and the ATU-R:
o Attenuation (ATN): The attenuation is the difference in dB between the power received at
the near-end and that transmitted from the far-end. Received signal power in dBm is the sum
of all data-carrying (i.e. bi > 0) DMT subcarrier powers averaged over a 1 second period.
Transmitted signal power is �3.65 �2n + 10 log (sigma gi**2 ) dBm, summed over the data-carrying
subcarriers. The attenuation ranges from 0 to 63.5 dB with 0.5 dB steps.
o Signal-to-Noise Ratio (SNR) margin: The signal-to-noise ratio margin represents the
amount of increased received noise (in dB) relative to the noise power that the system is
designed to tolerate and still meet the target BER of 10**-7 , accounting for all coding
(e.g. trellis coding, RS FEC) gains included in the design. The SNR margin ranges from
�64.0 dB to +63.5 dB with 0.5 dB steps.
If you understand those documents you'll have more understanding than anyone here (speaking for myself of course).
That's what I said, I think
Thanks John, some heavy reading to do now then
|
|
|
Such detail is unnecessary, unless you are a Signals Specialist.
1999: Freeserve 48K Dial-Up => 2005: Wanadoo 1 Meg BB => 2007: Orange 2 Meg BB => 2008: Orange 8 Meg LLU BB => 2010: Orange 19 Meg Tweaked / 16 Meg Untweaked LLU BB
|
|
|
Such detail is unnecessary, unless you are a Signals Specialist.
I don't see it as detailed. I'm just trying to clear up in my own mind what is happening and unless you have a modicum of understanding then it is very hard to see what is happening. I'm just asking for help in doing so.
For instance I'm still not perfectly clear whether it is better to have a high or low Rx Noise Margin. I'm thinking that a high NM will give you a stable line but at the cost of reduced speed.
The Noise Margin must be a function of the Signal to Noise Ratio which is the only concrete measurable quantity. So I assume that to achive a required margin the speed is reduced to reduce attenuation and therefore increase SNR?
In other word there is a required minimum SNR to support a given data rate. However, because the noise levels will vary a margin is added to the requires SNR to allow for this without compromising stability. This gives you the Recieve Noise Margin which is in fact an adjusted SNR figure to allow for variations in noise.
They are all interelated so an understanding of each perameter and how it interelates with the others is, IMHO, quite important.
|
|
|
A number of misconceptions!
Principally, that attenuation is a function of anything other than the line (length & quality) itself and, possibly, the ADSL mode being employed. Generally, it remains constant from day to day.
Yes, a high NM will give you a stable line but at the cost of reduced speed. But it could be indicative of past instability triggering the DLM imposing a higher Target NM. Or it could indicate you last Synced at night when it was noisy. Or it could be that the ISP is capping you. ... The Target NM is decided by the ISP's DLM at some standard value (like 3, 6, 9 , 12) and applied at Sync time, from which the NM then drifts.
Have a read here: http://www.kitz.co.uk/adsl/linestats.htm It's simpler than those others.
1999: Freeserve 48K Dial-Up => 2005: Wanadoo 1 Meg BB => 2007: Orange 2 Meg BB => 2008: Orange 8 Meg LLU BB => 2010: Orange 19 Meg Tweaked / 16 Meg Untweaked LLU BB
|
|
|
|
I have been running router stats since Monday and things have been pretty consistent. Mt profile has raised to 5.5Mbps since Wednesday
Router stats shows a fairly consistent..
Synce Speed of 6,848 kbps
RX Noise Margin 14.4dB
With afew exceptions the NM has vaied within +/- 1dB the exceptions are..
Thu 07 Apr 2011 14:23:04 Both Sync Speed and Noise Margin went to 0. The router up time restarted at this point.
Thu 08 Apr 2011 04:19:04 Noise Margin showed a blip down to 7dB.
Thu 07 Apr 2011 05:13:04 Noise Margin showed a blip down to 11dB.
I can't be sure as I wasn't running stats then but the timing of these blips seems to coincide with a similar time last week when my profile was reduced. I may be just imagining this though as I have no stats to prove it.
Is a short complete loss as shown in the first instance above and the couple of minor blips that followed enough to trigger a reduction in profile/increase in target NM?
|
|
|
|
The profile should only be lowered in response to a poor sync event and it would happen within a few hours. The algorithms for lowering/raising profiles and target SNR margin are not published, so only guess work I'm afraid. Do you have many HEC, CRC, or FEC errors? A lot of those may trigger a rise in target SNR margin.
|
|
|
What is clasified as a poor sync event? Is it a resync that results in a lower sync speed or could a couple of synce over a few hours that resulted in the same sync speed being avhieved be considered as poor?
I am seeing the odd event being graphed where my sync and noise figures go to zero for < 1 minute. My uptime resets to zero at the same time and my router seems to restart. Not sure which is cause and which is effect here . Is the router restating as a result of the poor line conditions or are the line conditions shown as a result of the router restarting??
These have only occured in the last 24 hours (since I normalised my wiring and went back to NTE5 socket with ADSL front plate as my filter. I have been using test socket with a seperate filter up to yesterday. Could it be my faceplate filter? It's brand new.
As for errors. The only stats I can find on my router are collisions, of which there are non.
Thanks and Regards
Clive
|
|
|
|
The BT profiles are defined by sync ranges, i.e. if you sync at x that'll be in the range for profile y. If you sync within the range for a lower profile, as far as I am aware, the sync will result in a move to the lower profile (moves in the other direction can take 5 days).
If you re-sync at the same or higher rate this is not seen as a poor sync event unless the resyncs happen at a rate of 10 times or more per hour.
Might be worth bunging a screen dump of your router stats to a site such as imageshack and posting a link.
I'm not sure about getting stats from your router.
See if http://192.168.0.1/setup.cgi?todo=debug enable debugs (replace the 192.168.0.1 with your router's address).
If that works go to a command prompt (Windows start->cmd, I think) and launch telnet.
e.g.
telnet 192.168.0.1
On my Netgear (different model) I can then
cat /proc/avalanche/modem_stats
to get the error stats.
|
|
|
|
Think I've got telnet working now...
I tried your telnet command but got no such file. Bit of searching came up with the command "adslctl info --stats"
It gives the following....
BusyBox v1.00 (2008.10.21-10:23+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
# adslctl info --stats
adslctl: ADSL driver and PHY status
Status: ShowtimeRetrain Reason: 0
Channel: INTR, Upstream rate = 448 Kbps, Downstream rate = 6880 Kbps
Link Power State: L0
Mode: G.DMT
Channel: Interleave
Trellis: ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 14.2 25.0
Attn(dB): 24.0 14.5
Pwr(dBm): 19.8 12.3
Max(Kbps): 7648 1216
Rate (Kbps): 6880 448
G.dmt framing
K: 216(0) 15
R: 16 8
S: 1 8
D: 32 4
ADSL2 framing
MSGc: 1 1
B: 216 15
M: 1 8
T: 1 1
R: 16 8
S: 1.0737 8.5000
L: 1736 128
D: 32 4
Counters
SF: 864408 864418
SFErr: 10 1
RS: 58779774 7346550
RSCorr: 3655 15
RSUnCorr: 208 0
HEC: 9 1
OCD: 1 1
LCD: 0 0
Total Cells: 238446185 0
Data Cells: 903690 0
Drop Cells: 0
Bit Errors: 0 0
ES: 3 0
SES: 0 0
UAS: 14 0
AS: 14695
INP: 1.17 1.00
PER: 1.87 1.85
delay: 8.58 8.50
OR: 29.80 30.11
Bitswap: 0 0
Total time = 4 hours 5 min 15 sec
SF = 864408
CRC = 10
LOS = 0
LOF = 0
ES = 3
Latest 1 day time = 4 hours 5 min 15 sec
SF = 864408
CRC = 10
LOS = 0
LOF = 0
ES = 3
Latest 15 minutes time = 5 min 15 sec
SF = 18526
CRC = 0
LOS = 0
LOF = 0
ES = 0
Previous 15 minutes time = 15 min 0 sec
SF = 52923
CRC = 0
LOS = 0
LOF = 0
ES = 0
Previous 1 day time = 0 sec
SF = 0
CRC = 0
LOS = 0
LOF = 0
ES = 0
15 minutes interval [-30 min to -15 min] time = 15 min 0 sec
SF = 52923
CRC = 0
LOS = 0
LOF = 0
ES = 0
15 minutes interval [-45 min to -30 min] time = 15 min 0 sec
SF = 52982
CRC = 0
LOS = 0
LOF = 0
ES = 0
15 minutes interval [-60 min to -45 min] time = 15 min 0 sec
SF = 52923
CRC = 0
LOS = 0
LOF = 0
ES = 0
Showtime Drop Reason: 0
Last Retrain Reason: 0
#
#
|
|
|
There seem to be two variants of Netgear firmware, you have the other one. I think your firmware is supported by the DMT tool, so you could play around with that.
Check http://dmt.mhilfe.de/ to see if your model is supported. If it is I think you may be able to adjust the target SNR margin down to see if you can get increased sync rates. At your own risk though.
Your line is interleaved (as opposed to fast path) and thus uses Reed Solomon techniques to correct single bit errors in transmitted data (same technique as is used to auto correct CD read errors).
RSCorr: 3655 15
RSUnCorr: 208 0
Means that 3655/15 packets (down/up) had errors auto corrected (out of a total 58779774/7346550 down/up packets),
208 downstream packets couldn't be corrected, which probably caused an error at a higher protocol layer (TCP) requiring data retransmission.
That number of errors is insignificant considering your 4 hour uptime.
|
|
|
Such detail is unnecessary, unless you are a Signals Specialist.
...or a masochist.
|
|
|
...or a masochist. Yes, I refrained from saying that 
1999: Freeserve 48K Dial-Up => 2005: Wanadoo 1 Meg BB => 2007: Orange 2 Meg BB => 2008: Orange 8 Meg LLU BB => 2010: Orange 19 Meg Tweaked / 16 Meg Untweaked LLU BB
|
|
|
I think your firmware is supported by the DMT tool, so you could play around with that. If it is I think you may be able to adjust the target SNR margin down to see if you can get increased sync rates. At your own risk though. Or, you don't need to use DMT; you can do it all thro' TELNET - see Netgear DG834GT & DG834 v4- Override Target SNR
1999: Freeserve 48K Dial-Up => 2005: Wanadoo 1 Meg BB => 2007: Orange 2 Meg BB => 2008: Orange 8 Meg LLU BB => 2010: Orange 19 Meg Tweaked / 16 Meg Untweaked LLU BB
|
|
|
|
I sort of guessed you wouldn't need DMT but I've never had a router with compatible firmware to practice on.
|
|
|
Thanks John, glad to hear my errors are insignificant
I'll keep monitoring for a few days.
Am I right in assuminmg that the error counts will reset if the router resets?
Daft question of course they will
How can I log these errors so I know how many there were leading up to an event like a reboot?
Had a look at http://dmt.mhilfe.de/ , noit sure I fancy messing if the support is all in German. I speak a bit but not enough to get techie with it
|
|
|
Such detail is unnecessary, unless you are a Signals Specialist.
...or a masochist.
Whip me, whip me
|
|
|
That sound more interesting. Thanks XRaySpeX
|
|
|
I think your firmware is supported by the DMT tool, so you could play around with that. If it is I think you may be able to adjust the target SNR margin down to see if you can get increased sync rates. At your own risk though. Or, you don't need to use DMT; you can do it all thro' TELNET - see Netgear DG834GT & DG834 v4- Override Target SNR
How can I get the current Target SNRM?
|
|
|
|
I think DMT is well known to users of this forum. They could give you any support needed.
|
|
|
How can I get the current Target SNRM? Do a re-sync in daytime and immediately reread this stat: SNR (dB): 14.2 25.0 Your Target is most likely 15. N.B. "SNR" is a misnomer; should say "SN(R)M".
You can analyze your stats & errors here: http://adsl.tin2tin.net/
1999: Freeserve 48K Dial-Up => 2005: Wanadoo 1 Meg BB => 2007: Orange 2 Meg BB => 2008: Orange 8 Meg LLU BB => 2010: Orange 19 Meg Tweaked / 16 Meg Untweaked LLU BB
Edited by XRaySpeX (Fri 08-Apr-11 17:20:20)
|
|
|
Thanks John. It's also pretty well documented on kitz http://www.kitz.co.uk/routers/DMTv8.htm. So I may try it
Eclipse seem to want to do nothing to see if it improves. They say it should climb over time. But will it? If I have synced at 6880kbps I will be limited by that until and unless I resync again won't I?
Edited by deleted (Fri 08-Apr-11 17:36:40)
|
|
|
|
The SNR margin is said to drop in a 3dB step after two weeks of stability, it does for some posters, not for others. Each 3dB step drop should result in something like a 500 kbps increase in sync rate.
|
|
|
http://www.kitz.co.uk/routers/DMTv8.htm. You need to edit that and not press [SHIFT] on last "[".
1999: Freeserve 48K Dial-Up => 2005: Wanadoo 1 Meg BB => 2007: Orange 2 Meg BB => 2008: Orange 8 Meg LLU BB => 2010: Orange 19 Meg Tweaked / 16 Meg Untweaked LLU BB
|
|
|
http://www.kitz.co.uk/routers/DMTv8.htm. You need to edit that and not press [SHIFT] on last "[".
[/quote]
Ooops sorry
|
|
|
How can I get the current Target SNRM? Do a re-sync in daytime and immediately reread this stat:SNR (dB): 14.2 25.0 Your Target is most likely 15. N.B. "SNR" is a misnomer; should say "SN(R)M".
You can analyze your stats & errors here: http://adsl.tin2tin.net/
Just ran my stats through tin2tin. this is the result
BlueEther's stats checker at http://adsl.tin2tin.net thinks my line is made of [color=orange]pretty standard wiring that could have seen better days.[/color]
Can you help me fix my line?
http://adsl.tin2tin.net/yourstats.php?statsID=151282
[color=red]Down sync is low (35% of the theoretical maximum).[/color]
[color=red]Very high SNR at 14.5 down / 25 up.[/color]
[color=red]SN margins vary by too much.[/color]
[color=green]Attenuation looks normal.[/color]
[color=green]Output power looks normal.[/color]
There are a few FEC errors. | Text | 1
23
45
67
89
1011
1213
1415
1617
1819
2021
22 | Uptime: 20h 58m 49s
Modulation: G.DMT - Interleaved on Annex A (Up Stream) / (Down Stream)
Sync: 448 / 6880Data Transferred: /
Attenuation: 14.5 / 24SN Margin: 25 / 14.5
Power: 12.3 / 19.8Vendor: /
Modem: an unknown modem with adslctlLoF: 0 / 0
LoS: 0 / 0Error Sec.: 0 / 11
FEC (Uncorrected): 327FEC (Corrected): 44677
FEC (RS Counter): 317822578
HEC (Errors): 2 / 17Data Cells: 0 / 2438911
CRC (SFerr): 3 / 19
Supper Frames: 4673861 / 4673861 |
Not sure if I still have a problem or if it's just my profile stuck. I think I'll monitor for a few days and see what happens.
Thanks to all for the help. Moist appreciated and informative.
Regards
Clive
|
|
|
Look at the error counts, you are getting errors that interleaving cannot cope with.
I reckon that is why your 15dB target margin is staying firmly set, i.e. its not stuck, you simply aren't meeting the criteria for the BT Wholesale systems to lower it.
Solve the issues with errors, which are wiring, or phone line based, or the result of electrical interference from devices in your or neighbours home and the target margins might come down in time.
Has the ISP been asked to lower your target margin, and see what happens?
|
|
The author of the above post is a thinkbroadband staff member. It may not constitute an official statement on behalf of thinkbroadband.
|
|
|
|
327 uncorrected FEC in 20 hours doesn't seem so bad.
|
|
|
Its not horrendous, but suspect the size of the FEC count is the main reason for profile not lowering.
BT will be working on the assumption, if the interleaving has uncorrected errors at this speed, then lowering margin and running line faster will create more uncorrected errors and at some point the retransmits these produce negate any faster connection speed.
Solve the uncorrected errors and lower the FEC count and a lower margin may be possible.
|
|
The author of the above post is a thinkbroadband staff member. It may not constitute an official statement on behalf of thinkbroadband.
|
|
|
|
I seem to be getting some issues whereby my SN Margin drops to 0 as does my sync speed. My modem resyncs at this time, so not sure if it's modem causing the problem or reacting to the problem. This seems to have happened at about 11am on the past couple of days (since I have been running routerstats.
Anyway My figures seemed to be worse when I installed the NTE5 ADSL faceplate as opposed to using the NTE5 with a normal faceplate and separate filter. So I have gone back to the original faceplate and separate filter to see if that changes things at all.
My initial sync rate and Noise Margin figures are the same though.
Apart from that I have a spare router I can try, albeit an old SMC barricade. There are no extensions currently wired in and I have no ringwire connected. The BT Line enters my house by the front door on an old style POTS socket where it is jumpered onto another cable that goes through to my computer room where the NTE5 is located. Not sure if it's cat5 but it is UTP of some sort within the house and the run isn't near anything that I can think of that might cause interference. A quiet test on the phone proved ok a week or so ago.
Thinking about it the phone is cordless, may be worth trying a wired phone for a while.
I'll let it soak for a while with the old faceplate and filter in place and see what happens. Unless anyone has any other ideas?
|
|
|
Look at the error counts, you are getting errors that interleaving cannot cope with. His error counts are insignificant. OP forgot to post the BlueEther's Errors page, which I find the most informative: Check Error Seconds
You have had 11 seconds in which errors happened in the last 20h 58m 49s on the down link.
That is an average of 6,866 seconds between each errored second.
* Error Seconds on the upstream are kept on the DSLAM so are imposable to diagnose problems from our end.
Check FEC Errors
Known as Forward Error Corrections, these are error corrections implemented by the interleaving process between the modem and DSLAM in the exchange.
The firmware on your Thompson Speedtouch has a bug in it that miss-represents the FEC up errors, please ignore these errors
There have been 0.0141% FEC errors on the downstream since your last resync
As these errors are corrected errors thy are not necessarily something to worry about but might slow your throughput down as the router has to correct the errors before passing them on to your PC.
1999: Freeserve 48K Dial-Up => 2005: Wanadoo 1 Meg BB => 2007: Orange 2 Meg BB => 2008: Orange 8 Meg LLU BB => 2010: Orange 19 Meg Tweaked / 16 Meg Untweaked LLU BB
|
|
|
Again at mid morning today I had a sudden drop to zero in my noise figure. Roputer doesn't seem to have restarted this time but it resynced at as slightly slower speed.
Looks like my filter is off the hook.
Have posted below the same stats as before but also a copy and paste of the Errors tab from BlueEther. Is that what you refer to XRaySpecs? Seem to be more errors than last time. Are they significant or not? Obviously the noise spikes are what is causing the problem. I use cordless phone usualy and do notice occasional noise when using it.. When I replace it with wired handset and do quiet line test it seems to be practicaly silent. Should I ditch the wireless phone as a test?
His error counts are insignificant. OP forgot to post the BlueEther's Errors page, which I find the most informative
This is the data from the summary page that BlueEther gives you to copy and paste....
BlueEther's stats checker at http://adsl.tin2tin.net thinks my line is made of [color=orange]some Welsh hill farmers old fence.[/color]
Can you help me fix my line?
http://adsl.tin2tin.net/yourstats.php?statsID=151332
[color=red]Down sync is low (35% of the theoretical maximum).[/color]
[color=red]Very high SNR at 15.1 down / 24 up.[/color]
[color=red]SN margins vary by too much.[/color]
[color=green]Attenuation looks normal.[/color]
[color=green]Output power looks normal.[/color]
[color=orange]There are some of FEC errors.[/color] | Text | 1
23
45
67
89
1011
1213
1415
1617
1819
2021
22 | Uptime: 17h 43m 51s
Modulation: G.DMT - Interleaved on Annex A (Up Stream) / (Down Stream)
Sync: 448 / 6880Data Transferred: /
Attenuation: 14.5 / 24SN Margin: 24 / 15.1
Power: 11.9 / 19.8Vendor: /
Modem: an unknown modem with adslctlLoF: 0 / 0
LoS: 0 / 0Error Sec.: 0 / 162
FEC (Uncorrected): 327FEC (Corrected): 439784
FEC (RS Counter): 268595338
HEC (Errors): 0 / 14Data Cells: 0 / 1792604
CRC (SFerr): 0 / 17
Supper Frames: 3949981 / 3949931 |
This from the Errors tab.... Is this what you refer toXRaySpecs??
Check Error SecondsYou have had 162 seconds in which errors happened in the last 17h 43m 51s on the down link.
That is an average of 394 seconds between each errored second.
* Error Seconds on the upstream are kept on the DSLAM so are imposable to diagnose problems from our end.
Check FEC ErrorsKnown as Forward Error Corrections, these are error corrections implemented by the interleaving process between the modem and DSLAM in the exchange.
There have been 0.16% FEC errors on the downstream since your last resync
As these errors are corrected errors thy are not necessarily something to worry about but might slow your throughput down as the router has to correct the errors before passing them on to your PC.
Check CRC ErrorsKnown as a cyclic redundancy check this is used to verify the proper frame transmission between the transmitting and receiving end.
These errors often mean that data has to be retransmitted and will slow the throughput transmission down. In extreme cases can lead to disconnections.
There have been 17 CRC errors on the downstream.
* CRC errors on the upstream are kept on the DSLAM so are imposable to diagnose problems from our end.
Check HEC ErrorsUsed to check and rectify the cell headers, if these errors are too high it will slow the throughput transmission down.
There have been 14 HEC errors on the downstream.
That is 0.0008% of the data cells.
* HEC errors on the upstream are kept on the DSLAM so are imposable to diagnose problems from our end.
|
|
|
|
You need to track down the cause of the mid-morning noise (which is causing your SNR margin drop).
Does anything in your house switch on at that time? Microwave, central heating, recording etc.
Does anything nearby create radio interference at that time?
|
|
|
|
Hi John, yes I've been trying to establish the cause but I can't think of anything that's on at the times that it happens. It's not at a set time every day but in the area of mid day +/- 2 hours roughly.
Washing machine seemed a likely culprit but it was off this morning at the time of the spike.
Freezer and fridge cut in and out throughout the day so would expect it to happen at more varied times if it was one of them.
Heating not on at the time.
All these are at least 10ft away from the phone line.
Could it be my wireless phone? I do notice occasional noise on it when I go off hook which isn't there when I use a wired handset and do a quiet line check.
Externaly I know we had a mains water burst in the area yesterday which was repaired with all the associated power tools in action but they aren't there today. There is some building work going on down the road but, again, they aren't working today. Next door is doing up his house but can't hear him doing anything at the time.
It seems strange because a few weeks ago I took all my extension wiring out because it was a real mess and my speed weren't great and got speed test result of >6Mbps consistently. Nothing has changed in house since then except the addition of an ADSL faceplate on my NTE5, which I have tried swapping back so it isn't that.
I tried a different router and saw no change in Noise or sync figures so swapped back.
Would it be worth changing it over for a long term test?
The only problem is I have my Netgear router configured as I want it and the SMC isn't cabable of exactly replicating my set up. For instance I can't find a way on the SMC to give items a fixed IP address like my music server and printer so that everyone can find it on the same address all the time.
|
|
|
Just tried putting SMC barriacade on the line. Sync speed and noise much the same as Netgear. Problem is I can't get RouterStats to see it.
It logs oin ok but I can't get it to graph the stats at all. I think it's because everything is in tables in the smc UI and I can't find a simple html page to pint it to so won't get the same stats off it
|
|
|
|
What you describe doesn't sound like a router problem. It does sound like you are getting noise on the line. I'm not familiar with wireless phones, perhaps that is a candidate.
|
|
|
What you describe doesn't sound like a router problem. It does sound like you are getting noise on the line. I'm not familiar with wireless phones, perhaps that is a candidate.
Totaly agree John. I'm not at all convinced it's my Router, a. it's been solid up to now and b. When I put the other one on it makes no difference.
It just that, apart from the cable leading accross my house to the NTE5 box all I have is one filter plate, a cable and a router to swap. The BT riser cable comes in by my front door and is jumpered via a connectioon block to a lead running accross the front of my house (in the roof space above front ground floor) to my "office" where the NTE5 is terminated. Only one extension connected to NTE5 as well so pretty confident that's OK.
I would like to say I have eliminated all noise sources in the house but whenever I do a quiet line check it's fine.
I have taken the cordless phone out for a while to see if that has any effect. It is a DECT phone but is quite old.
I'm running a washing machine cycle and watchinmg the graph whilst it's running just to bve certain it isn't that.
Think I'll have to get Eclipse to get BT involved. Not sure thay can expect me to do much more.
|
|
|
|
Don't think it's washing machine. Just finished it's cycle. I did see a blip of approx 2dB towards the end but nothing as severe as the drops to zero I've been seeing.
I'm assuming a swing of a couple of dB isn't anything to worry about??
|
|
|
You need to track down the cause of the mid-morning noise (which is causing your SNR margin drop).
Does anything in your house switch on at that time? Microwave, central heating, recording etc.
Does anything nearby create radio interference at that time?
Have proved it isn't my cordless phone as it's not in use and the problem is still evident.
I did have a small breakthrough in that at the last occurence, an hour or so ago, I noticed a couple of "pips" on my wired phone even though it was on hook. On going off hook I noticed a crackling on the line. Did a quiet line test and it was indeed noisy. Checked router stats and it had seen a drop in noise figure down to about 4dB at the same time. So it's quite definitley noise related.
I moved the corded phone to the NTE5 socket and quiet line test was still noisy. Removed faceplate and tried from test socket and it was quiet. Put it back together and it was also quiet, so no hard proof there. I have tried several time going from test socket back to faceplate socket, disconnecting the extension wiring from the back of the faceplate and everything.
I can't conclusivly prove it's internal but I have been unable to get any noise on a quiet line test from the test socket. I do get some instances of noise on the line when I use the faceplate. I just can't get it to do it consistently so I don't know if it's the faceplate itself (doubt it as I have 2, one adsl and one ordinary faceplate and both are same), the extension wiring or ??? nothing else it can be is there??
I did completely disconnect the extension wiring for a few days testing and the problem was still evident.
I don't think it's anything electrical in the house causing it. I have cycled the freezer off and on and it makes no difference, same with everything I can think of.
Everything wired up and line is quiet now.
Pulling my teeth out would be more fun and probably more productive at the monet as I'm going in circles.
I was ready to shout BT but now I'm not so sure
|
|
|
|
How is your BT IP profile? As long as it is stable there's not really anything to worry about. I'd only get concerned if it keeps dropping because of low sync rates.
|
|
|
How is your BT IP profile? As long as it is stable there's not really anything to worry about. I'd only get concerned if it keeps dropping because of low sync rates.
My current profile is 5.5, speed tests around 5Mbps.
I have been over 6Mbps on speed tests in the past.
My concern is that if I keep getting noise hits on the line my profile will get worse.
|
|
|
Just to clear something in my mind...
Is it true to say that every time my modem resyncs (either resart or reconnection) it will sync at the Maximum rate achievable at that time given the current line conditions; Noise, attenuation etc. and taking into account any faulty equipment on the line such as filters etc.?
And that the sync speed is not limited by IP profile or any other limiting perameter set by the operator?
And once synced at a certain speed that the max throughput is limited to this speed minus overheads untill a faster sync is achieved?
Does the sync speed rise dynamicaly/automaticaly if conditions improve or does a resync have to be initiated to get the benefit of the improved conditions?
If I have this right then my sync speed of 6784kbps is pretty consistent, give or take a small margin, every time I resync.
So is it true to say that.. Unless and untill I achive a sync speed in a higher profile bracket I will be limited to a profile speed of 5.5mbps?
I am still getting regular spikes in my stats indeed at 2am today it was spiking to zero for about 10 mins. After the event my sync and noise figures settle back down so don't apear to be affecting my profile, at least in the short term. My only question is could they be stoppping it going up?
I am now back to connecting through NTE5 test socket and, to be honest haven't so far had any noise spikes since I connected at 8:50Am. So regular morning spike hasn't happened so far. Sync and noise figures the same as connecting normaly.
Sorry if I'm going over old ground again but I just want to get it clear in my thick head
|
|
|
it will sync at the Maximum rate achievable at that time given the current line conditions
correct. It won't go up from there unless restarted in order to try again, but it will fall back to a lower speed if conditions deteriorate. It won't recover from that without a retrain either. The target noise margin is of course a factor, and that can vary from the default 6 dB to as high as 15.
Unless and untill I achive a sync speed in a higher profile bracket I will be limited to a profile speed of 5.5mbps?
correct again. The profile speed reflects the lowest sync speed you've seen recently. The system is designed for stability, if every night you drop to the equivalent of a 5500 profile then it wants to stay at 5500 24/7.
Phil
MaxDSL - goes as fast as it can and doesn't read the line checker first.
MaxDSL diagnostics
Are your kids pirates ? Limewire, Bearshare, Kazaa, BitTorrent, eMule are all tools of the trade.
|
|
|
The target noise margin is of course a factor, and that can vary from the default 6 dB to as high as 15.
Thanks Phil, I'm getting there
My target noise margin is quite high (Reading it after sync shows between 14 & 15dB).
It stays there pretty consistently (around 14.2dB) apart from a couple of times a day when it drops dramaticaly, sometimes causing a retrain.
So when I retrain it will sync at the max speed it can to achive the target noise margin?
This will only change if better noise figures are seen for a period of time?
I'm just trying to figure if my target noise margin is high because my line is generaly noisy or if it's these spikes that are causing the problem. They can last for up to 10 minutes but generaly just a minute or so acording to my RouterStats.
|
|
|
Hmmm.
Not a blip in my stats since 0900 this morning when I connected to the test socket.
Current stats:
BlueEther's stats checker at http://adsl.tin2tin.net thinks my line is made of [color=orange]pretty standard wiring that could have seen better days.[/color]
Can you help me fix my line?
http://adsl.tin2tin.net/yourstats.php?statsID=151401
Please submit your stats with at least 6 hours uptime for the best results.
If your line is too unstable to gain 6 hours then here is an interpretation of the submitted stats:
[color=red]Down sync is low (35% of the theoretical maximum).[/color]
[color=red]Very high SNR at 14.4 down / 24 up.[/color]
[color=red]SN margins vary by too much.[/color]
[color=green]Attenuation looks normal.[/color]
[color=green]Output power looks normal.[/color]
There are a few FEC errors. | Text | 1
23
45
67
89
1011
1213
1415
1617
1819
2021
22 | Uptime: 5h 38m 10s
Modulation: G.DMT - Interleaved on Annex A (Up Stream) / (Down Stream)
Sync: 448 / 6784Data Transferred: /
Attenuation: 15 / 24SN Margin: 24 / 14.4
Power: 12.1 / 19.8Vendor: /
Modem: an unknown modem with adslctlLoF: 0 / 0
LoS: 0 / 0Error Sec.: 0 / 1
FEC (Uncorrected): 30FEC (Corrected): 51805
FEC (RS Counter): 85379334
HEC (Errors): 2 / 2Data Cells: 0 / 619698
CRC (SFerr): 6 / 2
Supper Frames: 1255595 / 1255578 |
Check Error SecondsYou have had 1 seconds in which errors happened in the last 5h 38m 10s on the down link.
That is an average of 20,290 seconds between each errored second.
* Error Seconds on the upstream are kept on the DSLAM so are imposable to diagnose problems from our end.
Check FEC ErrorsKnown as Forward Error Corrections, these are error corrections implemented by the interleaving process between the modem and DSLAM in the exchange.
The firmware on your Thompson Speedtouch has a bug in it that miss-represents the FEC up errors, please ignore these errors
There have been 0.0607% FEC errors on the downstream since your last resync
As these errors are corrected errors thy are not necessarily something to worry about but might slow your throughput down as the router has to correct the errors before passing them on to your PC.
Check CRC ErrorsKnown as a cyclic redundancy check this is used to verify the proper frame transmission between the transmitting and receiving end.
These errors often mean that data has to be retransmitted and will slow the throughput transmission down. In extreme cases can lead to disconnections.
There have been 6 CRC errors on the upstream.
There have been 2 CRC errors on the downstream.
* CRC errors on the upstream are kept on the DSLAM so are imposable to diagnose problems from our end.
Check HEC ErrorsUsed to check and rectify the cell headers, if these errors are too high it will slow the throughput transmission down.
There have been 2 HEC errors on the upstream*.
There have been 2 HEC errors on the downstream.
That is 0.0003% of the data cells.
* HEC errors on the upstream are kept on the DSLAM so are imposable to diagnose problems from our end.
Equipment CheckIt is recommended that you check all of your equipment for faults:
Check (and swap if possable) all ADSL filters, extension cables/sockets, the DSL cable that connects the modem and the modem its self.
This helps to eliminate any internal issues that are not directly related to the phone wiring.
Quiet Line TestIt is recommended that you do a quiet line test:
This is done by connecting a corded analogue phone and dialling 17070 opt 2.
This needs to be done in the test socket, this can be found behind the faceplate of the master socket.
Don't use an ADSL filter
If you don't have a test socket disconnect all other equipment from the line.
There should be no noise on the line, any pops, crackles, hiss or hum etc will need to be reported to BT or who you pay line rental to as a "vioce fault".
Make sure that it is not an issue with the phone or any other equipment connected to the line or BT OpenReach will charge around £130 for the call out.
Monitor your LineIt is recommended that you monitor your line if support have increased SN margin targets, if you have had BT out to fix a voice fault you may wish to change back to the standard profile and continue to monitor your line for excessive errors or dropped connections.
Some good tools for monitoring many routers:
RouterStatsLite
DMT
Or you could try Tone a tool that I have written.
Test SocketIt is recommended that you test your connection from the test socket. This can be found behind the faceplate of the master socket.
If the stats vary a great deal from those in the master socket or an extension then you need to look into improving your internal wiring.
Above image © yesyesuk, used by kind permission.
Internal WiringIt is recommended that you check and remove the ring wire. The ring wire is a legacy of old phones that could not produce their own ring and needed a separate voltage to ring the bells. This is no longer needed for modern phones, and the ADSL filter also provides this function as a fall-over.
For the best operation of ADSL2+ there should only be two wires connected at each end of any extension socket. They are usually the blue and white/blue pair and should be connected to terminals 2 & 5. The BT line will also be connected to 2 & 5 on the old style master socket and on the new NTE5 master will be connected to A & B on the back section. It is safe and within your rights to remove any wiring that is after where the BT line terminates at the master.
The ring wire is normally orange in colour and will be connected to terminal 3 of the faceplate, this needs to be removed at each end, along with any other wires.
All extension wiring should be of a good quality solid core wire and be twisted pair. The flat DIY extensions from B&Q etc will very quickly kill the ADSL2+ signals so will need to be replaced for the best functioning ADSL.
After you have compleated the above and if you have problems with your connection to your ISP it is recommended that you start a thread at your ISP's forum in the speed and connection section (for Be* that can be found here: Be Speed & Line Issues ) with the stats that you used here, and a description of your problems. The summary in the first tab has a BBcode cut and past section if you forun supports BBcode.
Less errors as well
Looks like I have an internal problem.
Could it be my filters? I have several old ones and a just aquired ADSL v1.0 adsl faceplate (not sure how old it is thoughg as I was given it by a friend "in the trade".
I know it could be my fgilters but what are the chances of all of them being duff? and are they likely to cause intermittent spikes in my noise/signal levels?
I'm leaving to work in France for a few weeks tomorow so won't be around for a while.
I'm leaving it in test socket for the duration to see what happens to my profile while I'm away.
Thanks to all for the help so far. I'll be in danger of knowing what I'm talking about soon
|
|
|
Enjoy your holiday.
|
|
|
|
Can someone explain the relationship between Target Noise Margin and Sync Speed please?
Does a high Target Noise Margin limit your possible Sync Speed or will it sync at the highest possible rate acording to the noise levels at the time regardless of the Target Noise Margin?
In other words, if I re sync at a time when I have low noise on the line will it sync at a higher rate or will the sync be limited because I had noise on the line before and the target was set high because of it?
|
|
|
Enjoy your holiday.
Holiday? I'm going out to work
|
Pages in this thread: 
Print Thread
