Billion UK Forum

You're only getting about 60% throughput on that, but BT's attitude (as I'm led to believe) is as long as you're getting above, in your case 400Kbps then you have a working connection and it looks as though tinytim agrees with me that it could be your ISP's line management that is taking your SNRM back up.

I've noticed in the telnet stats that your Downstream Power is 17dBm whereas mine (with TalkTalk's LLU) is zero, perhaps that's a BT thing. Your FECs are quite high for the 6hr sync time, perhaps it's not too happy with the 3dB Target SNRM and perhaps a 4.5dB may suit your line better. Lower Downstream FECs should lower the browsing lag because it won't have to resend as much

If a 4.5dB target produces less errors and those errors are within the line management's parameters, then it may leave you alone once it retrains (hopefully)

Not sure if adjusting the MTU would improve the errors or not. Have you used this prog before http://www.speedguide.net/downloads.php there are tutorial links within the page.

It downloads as a .exe and it can only be run as an Administrator so Save it then right click to run as Admin. There is provision within the prog to reset the adaptors in your pc to the optimized value, but you will need to set them in the router and pc to 1500 first and afterwards, the router to the optimized value as well as the other PCs.

You probably know how to do this, but to save a bit of time in case you haven't manually changed the MTU settings in a pc before, run the cmd prompt as an Administrator and enter the cmds as per my cmd prompt. Mine are already set to 1392 but the cmds are for illustrative purposes and the MTU value you will set, will be the optimized one and see if that improves things.

The first cmd "....show interfaces" ID's the adaptor Index Nos. In this case they are 13 and 12. The next cmds change the mtu values and repeating the ....show interfaces cmd is to confirm they have been changed.

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Windows\system32>netsh interface ipv4 show interfaces

Idx Met MTU State Name
--- ---------- ---------- ------------ ---------------------------
1 50 4294967295 connected Loopback Pseudo-Interface 1
13 25 1392 connected Wireless Network Connection
12 5 1392 disconnected Local Area Connection


C:\Windows\system32>netsh interface ipv4 set subinterface 13 mtu=1392 store=pers
istent
Ok.


C:\Windows\system32>netsh interface ipv4 set subinterface 12 mtu=1392 store=pers
istent
Ok.


C:\Windows\system32>netsh interface ipv4 show interfaces

Idx Met MTU State Name
--- ---------- ---------- ------------ ---------------------------
1 50 4294967295 connected Loopback Pseudo-Interface 1
13 25 1392 connected Wireless Network Connection
12 5 1392 disconnected Local Area Connection


C:\Windows\system32>

for your info just checked at 11pm my sync has gone down to 2144 and snr margin is up to 5.2db .

certainly looks like it's adapting itself -
just going to see if it keeps going down.
if it goes back down to the results I was getting on my 2wire router then it will definitely go back as the only reason i got it was to tweak my snr.

also am worried about what happened this morning with computers dropping off the network - will see what happens tomorrow.

Thanks all

Mike

Tomken wrote:I've noticed in the telnet stats that your Downstream Power is 17dBm whereas mine (with TalkTalk's LLU) is zero, perhaps that's a BT thing.

Around 18 is normal on BT, Orange LLU,Sky LLU, O2 LLU etc. I think TalkTalk's is the odd one out actually.

Tomken wrote:Lower Downstream FECs should lower the browsing lag because it won't have to resend as much

That's incorrect. FEC is Forward Error Correction, and its whole purpose is to negate the need for retransmission of the data when errors occur. Extra information is added to the transmitted data to enable the receiving router to reconstruct the data in the event of errors. So-called "FEC errors" are actually events which would have been errors if forward error correction were not there to correct them.

FEC does add a small amount of latency to the connection, but it's only of the order of 20-30 ms, and it won't have any visible effect on browsing.

roseway wrote:

Tomken wrote:Lower Downstream FECs should lower the browsing lag because it won't have to resend as much

That's incorrect. FEC is Forward Error Correction, and its whole purpose is to negate the need for retransmission of the data when errors occur. Extra information is added to the transmitted data to enable the receiving router to reconstruct the data in the event of errors. So-called "FEC errors" are actually events which would have been errors if forward error correction were not there to correct them.

FEC does add a small amount of latency to the connection, but it's only of the order of 20-30 ms, and it won't have any visible effect on browsing.

Apologies, I got my CRCs mixed up with my FECs but it's also been my experience when there has been a very large number of FECs in a very short time without noticeable high CRCs, that there would be a certain amount of lag.

I think a gamer would notice an increase of 20 - 30ms (?)