21cn exchange - 1.01km away, 2mb down rate?

[#1]

Apart from answering Jim's questions, can you post the latest stats assuming you have remained connected in the test socket?
Also for future reference you can add jpgs as an attachment to a post, if you didn't use the Reply button, when you've typed the message, click on Preview, then below the box you'll see the + Additional Options and Attachments..., click on the plus then Browse to where you saved the .jpg  - this is preferable to using external sites
Edit: Forgot to ask, whilst you are connected to the Test socket are all the extension sockets dead? Check with a phone+filter.

[#2]

Living Room:  Master Socket,  1 secondary socket
Master Room: 1 secondary socket
Secondary Bedroom: 1 secondary socket.

Router: This is connected to the master room secondary socket  (Which I'd want tbh) as it makes the lead for it very short. 
@Anotherone - Apologies for the images.
I will post those stats later on as my main pc doesn't have wireless, so I changed it back, However, I've plugged it in to the test socket to run until I get home so will post then.
Yes all extension sockets are dead when connected to master.

[#3]

Hi Lightning1, From your earlier photos that looks like the classic 'ring wire' problem ( see here for explanation http://www.kitz.co.uk/adsl/socket.htm ).
I would suggest,  as Ao says,  that we get a definitive set of stats from the test socket, remove the ring wire and then connect your router where you want it to be and get another set of stats for comparison. Hopefully that should sort the problem.
Now as to removing the ring wire, it MUST be removed at the master socket faceplate and, ideally, at all extension sockets where it is connected. The link above shows how the ring wire is often connected and explains how it should be removed. From your pictures, however it would appear that you have an older style faceplate with only 4 terminals rather than the normal 6. They should be numbered 2 though 5, if that's not the case then post back with the numbering details. The extension sockets should have similar terminal blocks.
If you're unsure of anything then post back ( with photos if you think they may be useful ).

[#4]

Also, as you've done a number of disconnects with sync loss with swapping about and testing, probably best to use the following Disconnect method in future when you need to disconnect from the line (or anything involving loss of sync, even a reboot) -
Log in to the Modem/Router, in the Internet box, click Disconnect to drop the PPP Internet session (this is not the sync), wait about a minute and then power down the Modem/Router. After about another minute you can unplug it from the line.
Do whatever is needed, but stay offline for at least 10 minutes. When you re-connect and power up, Login to the Modem/Router and click Connect to establish a new PPP session.
Don't do this more than 5 times in an hour, then leave it for the rest of the day. This method is to help stop the Exchange DLM from thinking your sync loss was a dropped connection.
PS. You can do a Disconnect & Connect (without a power down) to Gateway hop.
As MisterW has mentioned, it's the Bell or Ring wire (the Orange/white) that needs to be removed from Terminal 3 on the rear of the faceplate of the master socket.  Just pull it vertically out of the IDC terminal, be careful not to pull the wires out from 2 & 5. You can remove the one from 4 as well (the other one of the pair), twist them together and wrap them back around the cable sheath out of the way.
Most modern phones don't need a bell wire, but in a broadband situation the bell wire unbalances the line at Broadband frequencies and picks up interference. Also a filtered bell wire is recreated in each filter for any phones that might need one.
Before you reconnect your modem/router to your extension socket, just check that all the extension socket wiring is to the correct cable standard (CW1308) ie a Blue/white on terminal 2 and a White/blue on Terminal 5. You can remove the Orange wires there as well. Check that none of the extension sockets have a ring capacitor ie. they are proper secondary sockets.
Tip: Should you accidentally pull a wire out of terminal 2 or 5, do not be tempted to push it back in with a screwdriver in the jaws. Use an IDC tool if you have one, otherwise push the wire down either side of the jaws with a small screwdriver or other suitable implement

[#5]

^^, Did as you both mentioned and removed 3 & 4 from the sockets.
It's now working as intended, phone works as well.
Averaging 9.2mb - perfect
Much appreciated, thank you^^

[#6]

Excellent news.

[#7]

Hmm, should of been up for longer,

Quote

Uptime: 0 days, 9:15:15 DSL Type: ITU-T G.992.5 Bandwidth (Up/Down) [kbps/kbps]: 444 / 11.065 Data Transferred (Sent/Received) [MB/GB]: 39,78 / 1,53 Output Power (Up/Down) [dBm]: 12,9 / 0,0 Line Attenuation (Up/Down) [dB]: 20,6 / 38,5 SN Margin (Up/Down) [dB]: 29,3 / 4,4 System Vendor ID (Local/Remote): TMMB / ---- Chipset Vendor ID (Local/Remote): BDCM / IFTN Loss of Framing (Local/Remote): 9 / 0 Loss of Signal (Local/Remote): 1 / 0 Loss of Power (Local/Remote): 0 / 0 Loss of Link (Remote): - Error Seconds (Local/Remote): 205 / 0 FEC Errors (Up/Down): 0 / 3.582.816 CRC Errors (Up/Down): 0 / 290 HEC Errors (Up/Down): 0 / 4.434

[#8]

As you have a fault ticket open, that loss of sync might have been a line test. Check your ticket for any information that might have indicated something around 1100 on the 4th.
But otherwise can you hear/have you heard any crackling or other noises on the line when using the phone? Have you had any problems with incoming or outgoing calls?
If not, what might be a good idea is using the Disconnect method previously mentioned, do a daytime reboot which will reset all the stats and then post up some stats after several hours uptime which may give us an idea of how things are performing.

[#9]

Looks like the fault ticket was closed a couple of days back via the portal, so I don't think it'll have been a line test. Having said that things from our side are looking a lot more stable:
<img src="http://community.plus.net/visualradius/generated/image13730271338780.png"/>

Hope that's the case from your side of things too Lightning1?

[#10]

Definitely a loss of Session there just before 1100 on the 4th which presumably was co-incident with the loss of sync suggested by the stats. Also a session drop earlier circa 0930!

[#11]

Quote

Link Information Uptime: 1 day, 6:34:48 DSL Type: ITU-T G.992.5 Bandwidth (Up/Down) [kbps/kbps]: 444 / 11.065 Data Transferred (Sent/Received) [MB/GB]: 79,88 / 1,99 Output Power (Up/Down) [dBm]: 12,9 / 0,0 Line Attenuation (Up/Down) [dB]: 20,6 / 38,5 SN Margin (Up/Down) [dB]: 29,3 / 4,8 System Vendor ID (Local/Remote): TMMB / ---- Chipset Vendor ID (Local/Remote): BDCM / IFTN Loss of Framing (Local/Remote): 9 / 0 Loss of Signal (Local/Remote): 1 / 0 Loss of Power (Local/Remote): 0 / 0 Loss of Link (Remote): - Error Seconds (Local/Remote): 402 / 0 FEC Errors (Up/Down): 0 / 9.181.668 CRC Errors (Up/Down): 0 / 842 HEC Errors (Up/Down): 0 / 18.696

Seems to be not losing connection at the moment, as far as the time connected goes.
@Anotherone -  Phone line is clear  /  No problem using a mobile to ring the house phone and answering it - no drop in connection and voice clarity is fine.
Wondering why it disconnected randomly then?
Also are the FEC errors (down) ok or high?

[#12]

The FEC errors don't get reset when there's a loss of sync, so it's a bit difficult to draw specific conclusions especially as Thomson modem/routers seem to count them up for something to do  (note the sarcasm!). The CRC errors are a more significant indicator and whilst they aren't especially large, lower would be better.
Those disconnections are probably being caused by a fairly large spike of interference that occurs from time to time.
Looking at the Vis Radius, there doesn't seem to be any overnight 0000-0600, nor any mid-day to 1800hrs. This possibly hints at some equipment that's only in use at the other times, possibly when someone is in. Have you had a new equipment of any sort recently perhaps? It could also be something that's recently developed a bit of a fault.
If your SNRM is still currently stable around the 4.8dB (not if it's dropped) I'd be inclined to do a reboot using the method mentioned in reply #18. Make sure it's well before dusk. That way it should restore your 6dB Margin, a bit more SNRM will help reduce the vulnerability to a spike, but you'll lose about 1Mbps in speed if the previous stats can be relied on, ie you'll sync at around 10Mbps. (It'll also reset all the stats to zero).

[#13]

No new equipment, only House phone, router, and mobile phone wireless, Smart TV Wireless. All setup roughly same time (day)
Did a reset over an hour ago, when I got home and now the stats are:

Quote

Link Information Uptime: 0 days, 1:16:26 DSL Type: ITU-T G.992.5 Bandwidth (Up/Down) [kbps/kbps]: 444 / 10.990 Data Transferred (Sent/Received) [MB/MB]: 29,57 / 641,44 Output Power (Up/Down) [dBm]: 12,8 / 0,0 Line Attenuation (Up/Down) [dB]: 20,7 / 38,5 SN Margin (Up/Down) [dB]: 29,7 / 5,1 System Vendor ID (Local/Remote): TMMB / ---- Chipset Vendor ID (Local/Remote): BDCM / IFTN Loss of Framing (Local/Remote): 0 / 0 Loss of Signal (Local/Remote): 0 / 0 Loss of Power (Local/Remote): 0 / 0 Loss of Link (Remote): - Error Seconds (Local/Remote): 54 / 0 FEC Errors (Up/Down): 0 / 1.535.550 CRC Errors (Up/Down): 0 / 28 HEC Errors (Up/Down): 0 / 510

[#14]

Those FECs do seem rather large for an hour, but more so, the HECs do as well. I've also noted the SNRM is 5.1dB. All suggestive of a bit of steady noise/interference. Is that a cordless phone? If so, try double filtering it - not the Modem/router mind! Make sure the mobile isn't close to the modem/router.

[#15]

Getting some loss of packets in online games    ( where characters / enemies will stand in the same spot, then speed up and move to their next position ) - This is happening frequently.
Any ideas?  The phone line etc is clear.

Quote

Link Information Uptime: 2 days, 22:33:21 DSL Type: ITU-T G.992.5 Bandwidth (Up/Down) [kbps/kbps]: 444 / 10.930 Data Transferred (Sent/Received) [MB/MB]: 771,99 / 580,26 Output Power (Up/Down) [dBm]: 12,8 / 0,0 Line Attenuation (Up/Down) [dB]: 20,7 / 39,0 SN Margin (Up/Down) [dB]: 26,9 / 4,0 System Vendor ID (Local/Remote): TMMB / ---- Chipset Vendor ID (Local/Remote): BDCM / IFTN Loss of Framing (Local/Remote): 9 / 0 Loss of Signal (Local/Remote): 1 / 0 Loss of Power (Local/Remote): 0 / 0 Loss of Link (Remote): - Error Seconds (Local/Remote): 12.937 / 0 FEC Errors (Up/Down): 0 / 37.392.642 CRC Errors (Up/Down): 15 / 20.800 HEC Errors (Up/Down): 6 / 224.319

Uptime should be longer than that