FTTC Home extension

Hi Forum,

Just looking for some advice to squeeze the most out of my FTTC broadband. I live about 200-300m from the Huawei cabinet and my phone line enters my property at roof level from a pole. Currently there is an extension from the BT drop cable in the loft to a point under my stairs (about 15m or so in floor space) via 6core twisted pair cable which i believe is CW1308. At this point I have a BT MK 4 master socket.

Currently these are my stats.
up/down
current sync Kbps 19,999/79,999
max sync Kbps 32,217/91,644
Attenuation DB 0.0/12.6
delay 0.0/3.0
INP 0.0/4.0
Power dbm 0.6/13.3
SNR db 15.0/9.2

And when I ping bbc.co.uk I generally get around 5-6 ms and when I do a speed test I get 74 Mbps down and 16 Mbps up. I do not experience any drops in connection. My only issue is that when I am working away from home and need to connected back to my linux box via ssh I loose connection at least for or five times during the day and have to reconnect, the IP has not changed and the modem and router have not rebooted or anything. In addition I do see a spikes (from modem stats) in CRC and ES on the upstream once or twice an hour and the the same on FEC on the downstream.

I am looking for some advice as follows. Are these drops in ssh connection something to do with the CRC/EC/FEC spikes ? and could my current setup be a source of them? My options as I see them from reading on this forum are as follows:

1) do nothing, most people would give their right arm for those stats and bandwidth!
2) Move the master socket and connect straight to the BT drop then use existing CW1308 as an extension to another socket (under the stairs) where it then split to data and phone.
3)move the master socket to the BT drop and use the existing CW1308 to run separate data and phone (i.e. split at master socket) to two sockets (BT and RJ11 or RJ45) under the stairs.
4) move master socket to BT drop and run a new (better ?) cable cat5e or cat6 for my data and use the existing CW1308 for the phone line,
5) move master socket to BT drop and run a new (better ?) cable cat5e or cat6 for both my data and phone

would appreciate any advice. Using the existing cable would be fairly straight forward but would like to know if it would likely make any difference. Running a new cable (cat5e or 6) would be done but would a big job, under floors and wall ducting etc! So I would want to be very sure it will have a positive impact.


Would appreciate any comments or suggestions.

many thanks,

Pete.

When you lose connection has the modem actually resynced?

SSH should cope with the odd blip in latency, i.e. tcp/ip is generally only affected when CRC/ES climb to high levels and at those levels the DLM would react and slow you down.

Given the margin between max and actual sync I don't think your issues are noise on VDSL induced.

In reply to a post by ear9mrn:

My only issue is that when I am working away from home and need to connected back to my linux box via ssh I loose connection at least for or five times during the day and have to reconnect, the IP has not changed and the modem and router have not rebooted or anything. In addition I do see a spikes (from modem stats) in CRC and ES on the upstream once or twice an hour and the the same on FEC on the downstream.

I am looking for some advice as follows. Are these drops in ssh connection something to do with the CRC/EC/FEC spikes ?

Do the times you lose connection coincide with the times of the spikes?

There's nothing you can do about that. The CRC's/ES need to be very high to cause a dropped connection like that. With you being on a Huawei cabinet with retransmission it becomes even less likely.

Think of the number of hops between the 2 connections. I'm my opinion this is very unlikely to be anything you could influence or improve.

In reply to a post by ear9mrn:

My only issue is that when I am working away from home and need to connected back to my linux box via ssh I loose connection at least for or five times during the day and have to reconnect, the IP has not changed and the modem and router have not rebooted or anything.

It may not be relevant but have you looked into setting SSH's keepalive facility in case router NAT is disrupting your SSH session?

Explained why/how quite well here

I recommend setting up a
Broadband Quality Monitor
and try to route its pings though to the linux box.

my guess is that this will show it is staying connected all the time

Post deleted by ear9mrn

In reply to a post by ggremlin:

I recommend setting up a
Broadband Quality Monitor
and try to route its pings though to the linux box.

my guess is that this will show it is staying connected all the time

Thanks for the reply and yes. I have set the keep alive with the client (putty) as well as the server side (ssh_config).

In reply to a post by ggremlin:

I recommend setting up a
Broadband Quality Monitor
and try to route its pings though to the linux box.

my guess is that this will show it is staying connected all the time

Yep, doing this. Check it out here My vdsl stats, scroll to the bottom of the page. Here you can also see stats collected from my Huawei modem.

In reply to a post by BatBoy:

In reply to a post by ear9mrn:

My only issue is that when I am working away from home and need to connected back to my linux box via ssh I loose connection at least for or five times during the day and have to reconnect, the IP has not changed and the modem and router have not rebooted or anything. In addition I do see a spikes (from modem stats) in CRC and ES on the upstream once or twice an hour and the the same on FEC on the downstream.

I am looking for some advice as follows. Are these drops in ssh connection something to do with the CRC/EC/FEC spikes ?

Do the times you lose connection coincide with the times of the spikes?

Good question. It is hard to say as I am not at my terminal the whole time, I go back to it on and off and sometimes I have lost connection and have to sign in again so I do not know the precise time it went down.

It got me thinking though, if I can some how log the dropped ssh sessions on the server side as well as the spikes in CRC/ES then cross-correlate them this may well shed some light on the issue as at this time I am not sure the two issues are related.

In reply to a post by MrSaffron:

When you lose connection has the modem actually resynced?

SSH should cope with the odd blip in latency, i.e. tcp/ip is generally only affected when CRC/ES climb to high levels and at those levels the DLM would react and slow you down.

Given the margin between max and actual sync I don't think your issues are noise on VDSL induced.

No, as far as I can tell I am not loosing sync at all. The connection itself seems very stable other than the spikes in upstream CRC/ES.

UPDATE.....

Over the weekend I was able to move my master socket (yes I know you are not supposed to). To the roof space and connect up the data and phone line separately via the cw1308 cable using one pair for the data (AB) and one pair for the phone (2/5) down to an Rj11 and BT socket under the stairs. This was a disaster, sync dropped to 44 Mb down and 10Mb up.

So we can cross no. 2 of the list as a solution.

Can anyone tell me what (if any) difference there is between connecting direct to the A and B of the BT drop cable and the A and B terminals of the master socket (I have a MK4 with the vdsl face plate). I know the 5/2 terminals are for phone extension and as such are filtered so extensions do not need micro filters.

Over the weekend I was able to move my master socket (yes I know you are not supposed to). To the roof space and connect up the data and phone line separately via the cw1308 cable using one pair for the data (AB) and one pair for the phone (2/5) down to an Rj11 and BT socket under the stairs. This was a disaster, sync dropped to 44 Mb down and 10Mb up.

So both signals are separated , but still travelling through separate pairs in the same cable ..... What was the point of that ??

Plus the twists on the pair aren't especially high. If the length of the pair carrying the DSL signal after the filter is long enough this in itself can cause issues, especially if the phone line itself is being used for speech at the same time.

Can anyone tell me what (if any) difference there is between connecting direct to the A and B of the BT drop cable and the A and B terminals of the master socket

Eh ??

In reply to a post by ear9mrn:

Can anyone tell me what (if any) difference there is between connecting direct to the A and B of the BT drop cable and the A and B terminals of the master socket (I have a MK4 with the vdsl face plate). I know the 5/2 terminals are for phone extension and as such are filtered so extensions do not need micro filters.

A data extension should be taken from the A&B "red" terminals on the Mk4 filtered faceplate rather than from the A&B terminals on the back of the master NTE5C socket. A filtered voice extension is taken from the front "blue" or "clear" terminals on the NTE5C (if using a Mk4 filtered faceplate.)

In your case its probably better to use CAT5e cable for the data extension and separately CW1308 for the filtered voice extension since you already have a suitable length of CW1308.

In reply to a post by ear9mrn:

My only issue is that when I am working away from home and need to connected back to my linux box via ssh I loose connection at least for or five times during the day and have to reconnect, the IP has not changed and the modem and router have not rebooted or anything.

This isn't really fixing the underlying issue, if there is one, but can I suggest you look into trying the Mosh Shell: https://mosh.org

It's designed for situations where they is high latency and intermittent connections. Might be worth a look to see if it solves your problem.

further update...

looked up my details on here http://www.dslchecker.bt.com/

and discovered the following for my line/cabinet

VDSL Range A (clean)
down rate(Mbps) high = 80, low = 62.6
up rate (Mbps) high = 20, low = 19

VDSL Range B (Impacted)
down rate(Mbps) high = 74.1, low = 44
up rate (Mbps) high = 20, low = 14.2

Looking at my modem (xdslcmd info --stats) tells me I am on Annex B (impacted) so clearly there is "some issue" with my line and the sync rates confirm this and tally with the table above, its odd how I have close to the max on the down by way off max in the up!

I am starting to think it may be worth hooking my modem up to the master socket right next to the BT drop cable and rule out this extension once and for all. If I get the same sync rates with that scenario and same CRC and ES spikes I know its outside my control and I just have either moan a lot at my ISP/open reach or live with it.

In reply to a post by ear9mrn:

Looking at my modem (xdslcmd info --stats) tells me I am on Annex B (impacted)

It doesn't tell you that. Annex B means your modem is set to Europe.

In reply to a post by ear9mrn:

further update...

looked up my details on here http://www.dslchecker.bt.com/

and discovered the following for my line/cabinet

VDSL Range A (clean)
down rate(Mbps) high = 80, low = 62.6
up rate (Mbps) high = 20, low = 19

VDSL Range B (Impacted)
down rate(Mbps) high = 74.1, low = 44
up rate (Mbps) high = 20, low = 14.2

Looking at my modem (xdslcmd info --stats) tells me I am on Annex B (impacted) so clearly there is "some issue" with my line and the sync rates confirm this and tally with the table above, its odd how I have close to the max on the down by way off max in the up!

I am starting to think it may be worth hooking my modem up to the master socket right next to the BT drop cable and rule out this extension once and for all. If I get the same sync rates with that scenario and same CRC and ES spikes I know its outside my control and I just have either moan a lot at my ISP/open reach or live with it.

Annex B has nothing to do with whats on the DSL checker. You are better off learning before jumping to wrong conclusions.

So you�ve an internal bridge tap affecting your service then.

Well, if a "bridge tap" is as I have described in my original post as an extension from the BT drop cable then yes, I have a bridge tap.

In reply to a post by Zarjaz:

So you�ve an internal bridge tap affecting your service then.

Not shown in the stats though

In reply to a post by ear9mrn:

Currently these are my stats.
up/down
current sync Kbps 19,999/79,999
SNR db 15.0/9.2

In reply to a post by BatBoy:

In reply to a post by Zarjaz:

So you�ve an internal bridge tap affecting your service then.

Not shown in the stats though

In reply to a post by ear9mrn:

Currently these are my stats.
up/down
current sync Kbps 19,999/79,999
SNR db 15.0/9.2

Were those stats posted prior to the OP doing a rewiring job?

What holds true for NAT also holds true for any other router that is between you and the SSH server you are logging onto.

As such in my experience you need to make use of SSH's keepalive options regardless if you leave sessions open and idle if you don't want disconnects.

If you are getting disconnected while you are active in the session then the problem lies elsewhere. However nowhere in the thread do you state that.

In the interim and it's best practice especially if a disconnect could be a problem to run inside a screen on the server. That way if you do suffer disconnect you can just log back on and reconnect to the screen and pick up exactly where you left off. In fact you can also see any output that has been generated in the meantime. Anything like a firmware update, fsck or simple yum/apt update should be done in a screen if it is on a remote machine, where remote is any machine your keyboard is not directly connected via USB/PS2.