If you get the right Sky rep you can get the 52Mbps one (the 80/20 product) from them as well. I believe it costs more. It just doesn't appear on their website.

I wouldn't want Sky LLU'ing my phone line though! Which is what they do. It can be a real pain to move it back if you want to.

Been through all the tests with BT etc time and time again before the FTTC cabinet was enabled and the line was poor, constantly dropped connection etc, etc.

BT always said no fault even after an engineer's visit and they tried to charge me.

If you were reporting broadband faults that isn't surprising.

If the test I suggest gives you crackles, you report a voice fault. You do not mention broadband.

You get a different part of Openreach and line engineer not a broadband one. They fix that and the broadband is fixed as a by-product.

In reply to a post by RobertoS:

Been through all the tests with BT etc time and time again before the FTTC cabinet was enabled and the line was poor, constantly dropped connection etc, etc.

BT always said no fault even after an engineer's visit and they tried to charge me.

If you were reporting broadband faults that isn't surprising.

If the test I suggest gives you crackles, you report a voice fault. You do not mention broadband.

You get a different part of Openreach and line engineer not a broadband one. They fix that and the broadband is fixed as a by-product.

Hi mate.

Thanks for this but no I havent just reported BB faults. And as soon as you mention crackles on the line they ask do you have BB enabled etc, etc, etc. BT and the phone provider have been rubbish all the way through and I dont want to get bogged down in that here.

Plusnet's offer ends in a couple of days. Unfortunately they dont have access to the cloud or BT wi fi hotspots. So, while the offer looks good, mobile wi fi isnt included.

Oh, and I appreciate no ISP can guarantee download speeds which is why I asked how good they were.

Edited by wobblyheed (Sun 03-Feb-13 19:19:50)

I am on Plusnet FTTC Unlimited and I also have a SamKnows White box installed that is measuring the line performance on an hourly or so basis.

For January I had the following results from SamKnows

Downstream Throughput of 64.07 Mbps Average - there was a dip to 20.20 Mbps at 8pm on Saturday 19th Jan and a peak of 72.66 Mbps on at 3pm Mon 7th of January

Upstream throughput of 17.26 Mbps average with a dip to 16.49Mbps at 6pm on the 7th of January and a maximum of 18.07Mbps at 3pm on the 3rd of January.

I am about .2 of a mile from the cabinet.

So make your own judgement. I am very pleased with it - it is nice to have an upload rate that is faster than most peoples download rate.

In reply to a post by wobblyheed:

Well how about reliability? Is it stable, do they deliver the speed via FTTC that they claim when they are testing your line before you sign up etc, etc?

Is it reliable? Yes. They do suffer from any outage in BT Wholesale or Openreach, as any other ISP would, but they don't seem to suffer much of their own. They do respond to outages, and do work at getting things back on line.

Can they fill an 80/20-synced line? Yes. I'm synced at 80/20, with profile values of 77/20. My Samknows box reports average speeds of 72/17, which I think are good throughput speeds for those sync/profile values.

Is it stable? Yes. The line stays synced for months on end - usually dropping only when we interrupt power to the modem - but this part is more generic FTTC rather than Plusnet-specific. The attainable speed has dropped over the course of the last year, as more people use the FTTC service (my sync would drop to 77/20 if I resynced now).

Plusnet's part stays stable over the course of the day too. The throughput speeds are mostly maintained throughout the peak period. Samknows reports that the 72 throughput speed drops to 70 at 19:00, 68 at 20:00, 69 at 21:00 and 70 at 22:00. Those are the average performance over the last 2 months.

The conclusion is that Plusnet *can* deliver the speeds needed for a full-speed 80/20 FTTC line.

But can they deliver the speed predicted for *your* line before you sign up? That one is harder to judge.

Plusnet's predictions only reflect the prediction made by BT Wholesale (or BT Openreach). The accuracy figure they present (1 Mbps) reflects how accurate their figure is compared with the value reported by BT (it means they round up or down to the nearest whole Mbps values). However, it doesn't indicate an accuracy of what you'll actually get!

The BT prediction figures appear to be a "worst case" value, assuming that your line encounters a lot of crosstalk - which is only likely to happen when take-up figures increase - ie in a few years time. As a consequence, most people get initial sync speeds that are higher than the prediction. But we are also seeing that the speeds *do* come down after time, as take-up increases. We also see that interleaving and FEC are being turned on as such interference increases, which itself eats some of the bandwidth and some of the latency.

Unfortunately, the speed reduction is a natural consequence of take-up rates - and there is nothing that Plusnet or BT Wholesale can do to affect this. There is technology in the pipeline that undoes the effect of crosstalk (known as vectoring), which may also allow BT to increase the headline speed to 100Mbps.

Unfortunately, vectoring is still being developed, and may not be here for another 2 or 3 years. In the meantime, sync speed reductions are to be expected.

But, whatever sync speed you end up at, Plusnet do indeed seem to be capable of delivering data across it.

I'm with Plusnet and have been since 2003, I upgraded to FTTC when it became available last August, and upgraded to unlimited when that became available.

My estimate was 57/20, but I get around 45/11 with an attainable around 52/11. Interleaving eats about 7 Mbps.

I had a lot of problems to start with and Plusnet did try to get things sorted, but the real stumbling block is Open Reach, and this applies whoever you go with. There was a loose connection in the FTTC cab which improved reliability, but my speed still fluctuates occasionally, but in use it really isn't noticeable, so I've not pursued it any further.

I monitor my connection 24/7 so if/when the problem gets worse I'll have the info to pass on to Plusnet.

Sometimes you will get less than the estimate, but the majority get a bit more than the estimate, and that applies whoever your with.

Minor quibble ~ does not affect whether or not to use PlusNet.

In reply to a post by R0NSKI:

Interleaving eats about 7 Mbps.

Interleaving increases latency. It will reduce throughput where inappropriate protocols are used that rely on too much synchronous acknowledgement.
With appropriate protocols (eg multithreaded downloads) interleaving should not affect speed.

The speed reduction from max attainable is as the system likes to keep a small snr threshold (typically 6db) to improve stability.

Higher interleaving can even increase effective speed, as it allows for better error correction, and potentially the use of a lower snr and higher sync speed for same level of reliability.

In reply to a post by StephenTodd:

In reply to a post by R0NSKI:

Interleaving eats about 7 Mbps.

Interleaving increases latency.

Interleaving alone adds the latency, while FEC (forward error correction) uses bandwidth - a portion of the bits sent across the VDSL2 link are used as parity bits, and are used to correct any bit errors in the useful bits.

I've seen parity settings of 16 bytes in a block of 255, and I've seen settings of 16 bytes in a block of 60. That means the overhead can vary from 6% to 25% of the raw capacity (ie the capacity if FEC were turned off). I have a vague recollection that I've seen it use even more (33%), but it isn't a strong recollection.

FEC and interleaving can be used independently, and I've certainly seen cases where FEC is turned on without interleaving (especially upstream). However, the only point in turning interleaving on is to allow the effects of a burst of noise to be distributed over many FEC blocks, so the FEC process stands a chance of working. That means you'll never see interleaving without FEC.

The result is... when interleaving is turned on, you'll notice both an increase in latency *and* a reduction in bandwidth.

It will reduce throughput where inappropriate protocols are used that rely on too much synchronous acknowledgement.
With appropriate protocols (eg multithreaded downloads) interleaving should not affect speed.

The first part is strictly true, but downloading isn't one of the protocols that gets affected much by the latency (TCP window sizes should adjust to cope). Therefore downloading in multiple threads won't be a fix for this (though it is a fix for slow servers).

The speed reduction from max attainable is as the system likes to keep a small snr threshold (typically 6db) to improve stability.

No, the Max Attainable figure already takes this 6dB into account.

At the moment, my line is running at 80Mbps - a speed that is faster than the max attainable (of 77Mbps). It has been synchronised for 2 months, and in that time the SNR values have gradually dropped from around 7dB (when max attainable was 81Mbps) to around 4.7dB (now the max attainable is 77Mbps).

The "max attainable" is, in effect, the modem's estimate of what speed it could run at if it were synchronising at exactly 6dB SNR.

In addition, it is the estimate of what speed it could give the end user if FEC were not turned on.

Higher interleaving can even increase effective speed, as it allows for better error correction

You're right here...

Higher FEC settings, with a greater %age of parity overhead (perhaps requiring deeper interleaving, depending on the noise characteristics) can do a better job of correcting bit faults, which in turn can result in lower CRC errors.

If, on lower settings, a high level of CRC errors is causing a high level of packet loss to the app layers above, then some of the line capacity is being used up by application-layer retries. However, the packet loss rate needs to be quite high (say above 5%) for this to have a significant effect.

On the whole, though, swapping capacity from "retries" into "parity overhead" isn't clear-cut. In fact, there are studies looking at whether DSL should not use FEC, but instead perform retries as a more efficient setting. But I can't remember the name of it

Where higher FEC does have an advantage is for the protocols where retries just don't happen - for example, when streaming video. Having higher FEC and interleaving protection makes sure you don't end up with more visible artifacts in the video.

It seems to be the ability for FTTC to carry HD Video decently that is driving the requirement for FEC/Interleaving settings to result in almost no CRC errors. The target seems to be to get video working at a quality for an evening of BBC1 on the living room TV, rather than 5 minutes of YouTube in a small window, hampered by buffering pauses.

, and potentially the use of a lower snr and higher sync speed for same level of reliability.

I guess that turning FEC and interleaving on does allow you to contemplate doing this. However, you're already in a situation where noise is interfering with signal (otherwise FEC would have nothing to correct), so I'm not sure there would be that much to really gain by reducing the SNR margin ... which would cause even more errors to occur.

Thanks for the reply. I'm sure you are pretty much right, but a couple of comments/questions that may help me clarify my understanding.

FEC and interleaving can be used independently, and I've certainly seen cases where FEC is turned on without interleaving (especially upstream). However, the only point in turning interleaving on is to allow the effects of a burst of noise to be distributed over many FEC blocks, so the FEC process stands a chance of working. That means you'll never see interleaving without FEC.

I thought that the amount of error correction used was always the same; with interleaving spreading it as you say to reduce problems from burst noise. Does VDSL ever work with no error correction? I can't see any way to see how much error correction is being used in my stats. That clearly would improve speed as long as it didn't force a significant number of retries.

TCP window sizes should adjust to cope

I agree, as long as the protocol asks for all the data and leaves it to tcp. I think downloads protocols often have other higher level request/response handshaking getting data in blocks, which mean that the latency effect is more marked.

No, the Max Attainable figure already takes this 6dB into account.

My figures don't reflect this: they currently show
Attainable rate (kbit/s) 87124
SNR margin (dB) 5.7
Line rate (kbit/s) 75260
Maybe it depends on which modem and how it reports (mine is HG612)

In reply to a post by StephenTodd:

No, the Max Attainable figure already takes this 6dB into account.

My figures don't reflect this: they currently show
Attainable rate (kbit/s) 87124
SNR margin (dB) 5.7
Line rate (kbit/s) 75260
Maybe it depends on which modem and how it reports (mine is HG612)

Mine is an HG612 too, so they should be comparable.

The attainable rate seems to be quoted as a speed without FEC, while the actual line speed will have FEC taken into account, if the line is currently using it. The difference in yours, around 15%, suggests that FEC has been put on your line.

There goes my reputation if it hasn't got FEC

I thought that the amount of error correction used was always the same; with interleaving spreading it as you say to reduce problems from burst noise. Does VDSL ever work with no error correction?

The modem sync negotiation can vary both the amount of interleaving and the amount of FEC, and yes - there can be no interleaving and no FEC on the line.

How can you find out about FEC and interleaving? There are 3 places it can be seen in the output of the "--show" and "--stats" variants of the xdslcmd command.

First, you can see the demand that DLM has placed on the modems from this part:

INP:            3.00            0.00
PER:            2.21            8.87
delay:          8.00            0.00
OR:             86.72           55.88

Those are from an old line of mine, which had FEC and interleaving activated downstream.

"INP" (impulse noise protection) indicates how many symbols need to be protected against - which tells the negotiation how many consecutive faulty bits it must protect against. This shows 3 symbols.

"delay" dictates the maximum delay that is acceptable for the additional latency. In this case 8 milliseconds.

The negotiation for that line resulted in these figures:

B:              57              111
M:              1               2
T:              64              50
R:              16              16
S:              0.0461          0.7101
L:              12835           2704
D:              701             1
I:              74              120
N:              74              240

Interleaving is shown by properties "I" and "D" - bytes to be sent out get written into an array 74x701, while the interleaved data is read out of the same array in the other direction (written in rows of length 701, read from columns of length 74). "D" is otherwise known as the depth, so shows how spread out the data is.

A depth of 1 means no interleaving (like the upstream figure).

FEC is shown by properties N and R, where R is the number of bytes of parity, while N is the total number of bytes in a "Reed Solomon" (RS) block. In this case, the block is 74 bytes, but 16 are used for parity overhead while the remaining 58 are for the user's data - so 21.6% of the line capacity is used for FEC overhead.

Note that there is FEC being applied upstream (16/240, or 6.6%), even though there is no interleaving (D=1) and there was no requirement to do so either (INP=0 and delay=0).

Finally, a clue that FEC is taking place comes from the line statistics:

OHF:            492092661               362863
OHFErr:         2162            254
RS:             4287526116              2051247
RSCorr:         7773977         19758
RSUnCorr:       260868          0

The RS count is non-zero, so FEC is taking place. RSCorr shows how many RS frame errors were corrected using the parity data, while RSUnCorr shows how many RS blocks could not be fixed with the parity data (ie were too corrupted).

The RSUnCorr blocks then become corruptions in the larger blocks protected by CRC checks - which will result in an OHFErr. RS blocks are smaller than the CRC blocks, so the count of CRC failures will usually be smaller than the RSUnCorr count - because RS failures can occur in batches within a single CRC frame.

My current line is shorter (so can get 80/20-ish) and better quality. It hasn't much need for interleaving.

Last January, when it was still on a 40/10 package, the figures looked like this:

Max:    Upstream rate = 27209 Kbps, Downstream rate = 90520 Kbps
Path:   0, Upstream rate = 10000 Kbps, Downstream rate = 39999 Kbps

INP:            0.00            0.00
delay:          1.00            0.00

R:              14              0
D:              19              1
I:              255             120
N:              255             240

OHF:            422503933               663284
OHFErr:         114             616
RS:             1270464109              23430
RSCorr:         9376            0
RSUnCorr:       1759            0

Note that interleaving was turned on fractionally, and FEC lightly (about 5.5%). But that's a very low RSCorr count, and isn't really needed much!

Later in February, it was converted to 80/20. The "max attainable" estimate dropped quite a lot, but FEC and interleaving were turned off.

Max:	Upstream rate = 26428 Kbps, Downstream rate = 84792 Kbps
Path:	0, Upstream rate = 20000 Kbps, Downstream rate = 79999 Kbps

INP:		0.00		0.00
delay:		0.00		0.00

R:		0		16
D:		1		1
I:		240		120
N:		240		240

OHF:		179858276		2859890
OHFErr:		69202		773
RS:		0		658425
RSCorr:		0		4870
RSUnCorr:	0		0

Strangely, the line has gained FEC upstream (but not interleaving), while it lost it downstream.

TCP window sizes should adjust to cope

I agree, as long as the protocol asks for all the data and leaves it to tcp. I think downloads protocols often have other higher level request/response handshaking getting data in blocks, which mean that the latency effect is more marked.

The TCP protocol is responsible for making sure that data is received in the right order, and nothing goes missing - and most "download" protocols (such as FTP and HTTP) are built on top of this. TCP uses handshaking to acknowledge safe receipt of individual blocks of data, so is certainly susceptible to latency delays when packets are lost, and the delays in getting back on track.

However the "window" is used by TCP to allow many blocks to be in transit, so a re-transmission of one block will not unduly delay others. But if lots of blocks start to need retransmission, then the overall throughput drops because it does cause delays in getting back on track.

The TCP window should adjust itself to take account of the end-end latency, and the speed of the link. This was a limitation in older Windows versions, and settings needed to be tweaked to allow for full throughput on links that were either high speed or long latency (eg satellite links).

As an example of the impact on throughput...

My first line suffered errors from the moment it was turned on (and you can see the FEC/interleaving setting that DLM chose in my first example above). However, DLM only intervened after 2 days, so I got to see the effect of the errors directly for those first 2 days.

The line synced at the full 40Mbps, with a profile of 38.7Mbps. I was getting about 4% packet loss (as measured on the TBB "ping graph", or BQM).

Without packet loss, you would expect such a line to show speeds of around 37Mbps (using speedtest.net). My line would show speeds of around 33.5Mbps (IIRC).

So the random 4% packet loss (seen using unprotected UDP packets) caused throughput limitations on the protected TCP packets of around 10%.

Other cases I have seen suggest that a link starts to become unusable when the packet loss is around 10%.