General Discussion
  >> Fibre Broadband


Register (or login) on our website and you will not see this ad.


Pages in this thread: 1 | 2 | 3 | (show all)   Print Thread
Standard User wobblyheed
(learned) Sun 03-Feb-13 15:59:54
Print Post

Plusnet FTTC unlimited


[link to this post]
 
Im considering migrating to FTTC (from adsl) which has now been on stream from my cabinet for a few months. Since the FTTC cabinet has been enabled, my adsl connection has teneded to be more stable (recent connection didnt drop for over 500 hours! although in the last 2 days, has dropped twice in 48 hours! GRRRRRR!).

Now it might just be a coincidence and even the phone line has less crackling on it.

Anyway, Plusnet are doing a very good deal right now (unlimited FTTC for under a tenner for the first 6 months) so, what are people's impression on Plusnet FTTC unlimited? Good, bad, indifferent?

All views gratefully received.
Standard User kasg
(experienced) Sun 03-Feb-13 17:49:34
Print Post

Re: Plusnet FTTC unlimited


[re: wobblyheed] [link to this post]
 
In reply to a post by wobblyheed:
Anyway, Plusnet are doing a very good deal right now (unlimited FTTC for under a tenner for the first 6 months) so, what are people's impression on Plusnet FTTC unlimited? Good, bad, indifferent?

Good. Next question?

Kevin

plusnet Unlimited Fibre
Using OpenDNS
Domains and web hosting with TSOHOST
Standard User wobblyheed
(learned) Sun 03-Feb-13 17:57:06
Print Post

Re: Plusnet FTTC unlimited


[re: kasg] [link to this post]
 
Hardly a rounding endorsement!


Register (or login) on our website and you will not see this ad.

Standard User kasg
(experienced) Sun 03-Feb-13 18:01:53
Print Post

Re: Plusnet FTTC unlimited


[re: wobblyheed] [link to this post]
 
Well what am I supposed to say? It works, it's fast, it's cheap, support is great and I've had no problems at all.

Kevin

plusnet Unlimited Fibre
Using OpenDNS
Domains and web hosting with TSOHOST
Standard User wobblyheed
(learned) Sun 03-Feb-13 18:20:53
Print Post

Re: Plusnet FTTC unlimited


[re: kasg] [link to this post]
 
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?
Standard User kasg
(experienced) Sun 03-Feb-13 18:26:02
Print Post

Re: Plusnet FTTC unlimited


[re: wobblyheed] [link to this post]
 
In my case, yes and yes.

Kevin

plusnet Unlimited Fibre
Using OpenDNS
Domains and web hosting with TSOHOST
Standard User RobertoS
(sensei) Sun 03-Feb-13 18:32:39
Print Post

Re: Plusnet FTTC unlimited


[re: wobblyheed] [link to this post]
 
In reply to a post by wobblyheed:
Now it might just be a coincidence and even the phone line has less crackling on it.
Depending on what is causing the phone to crackle, that could destroy FTTC/VDSL2 rather than just causing your ADSL dropouts. Or it may disappear like mine did, because it was the exchange side of the cabinet not my side.

You ought to get it fixed.

Does your phone master socket have a removable bottom half, as in this pic? If so, find a corded phone, (cheap from many places if you haven't got one), and plug it into the test socket - the one on the wall at the back in the pic.

Dial 17070 and take Option 2. If there is noise, you have a voice fault. If that is fixed your broadband stability will improve.

There could be a problem in timing though. I forget when the Plusnet offer expires, I think it is soon. You would need to check if you could order from Plusnet even if there is a line fault report in Openreach's system from your line rental company.

My broadband basic info/help site - www.robertos.me.uk | Domains,website and mail hosting - Tsohost.
Connection - Plusnet UnLim Fibre (FTTC). Sync ~ 54.3/15.4Mbps @ 600m. - BQM

"Where talent is a dwarf, self-esteem is a giant." - Jean-Antoine Petit-Senn.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allergy information: This post was manufactured in an environment where nuts are present. It may include traces of understatement, litotes and humour.
Standard User RobertoS
(sensei) Sun 03-Feb-13 18:40:06
Print Post

Re: Plusnet FTTC unlimited


[re: wobblyheed] [link to this post]
 
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?
There is a dodgy bit in the estimated figure, in that there is no way it can be within 1Mbps as it says! However, it is generally a reasonable estimate. If you use this checker you may get a range.

Re everything else, I don't download much, but I joined in Feb 2012 on the 40/2 product, went onto the 80/20 250GB one in October, and upgraded to the Unlimited one just for the sake of it as soon as I could after it was announced. That last move, eleven months into my contract, restarted my 18 months.

I think that shows I'm confident about it.

My broadband basic info/help site - www.robertos.me.uk | Domains,website and mail hosting - Tsohost.
Connection - Plusnet UnLim Fibre (FTTC). Sync ~ 54.3/15.4Mbps @ 600m. - BQM

"Where talent is a dwarf, self-esteem is a giant." - Jean-Antoine Petit-Senn.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allergy information: This post was manufactured in an environment where nuts are present. It may include traces of understatement, litotes and humour.
Standard User David_W
(experienced) Sun 03-Feb-13 18:40:08
Print Post

Re: Plusnet FTTC unlimited


[re: wobblyheed] [link to this post]
 
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?
As with ADSL, the FTTC speed quoted at sign-up is a best estimate, not a guarantee. Most people find these estimates are pessimistic and their speeds are higher, though the speeds can drop back towards the estimate over time because of increasing crosstalk when more people subscribe to FTTC on that cabinet. In some cases, the speed is lower than estimated.

No FTTC ISP can guarantee you will receive the estimated speed.

Standard User wobblyheed
(learned) Sun 03-Feb-13 18:45:58
Print Post

Re: Plusnet FTTC unlimited


[re: RobertoS] [link to this post]
 
In reply to a post by RobertoS:
In reply to a post by wobblyheed:
Now it might just be a coincidence and even the phone line has less crackling on it.
Depending on what is causing the phone to crackle, that could destroy FTTC/VDSL2 rather than just causing your ADSL dropouts. Or it may disappear like mine did, because it was the exchange side of the cabinet not my side.

You ought to get it fixed.

Does your phone master socket have a removable bottom half, as in this pic? If so, find a corded phone, (cheap from many places if you haven't got one), and plug it into the test socket - the one on the wall at the back in the pic.

Dial 17070 and take Option 2. If there is noise, you have a voice fault. If that is fixed your broadband stability will improve.

There could be a problem in timing though. I forget when the Plusnet offer expires, I think it is soon. You would need to check if you could order from Plusnet even if there is a line fault report in Openreach's system from your line rental company.


Hi mate.

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.

Due to the improved reliability and lot less crackle on the line, Im convinced there some connection with the FTTC cabinet. Nothing scientific or concrete but the slight improvement is there.

However, Im looking at FTTC now since BT \ Plusnet both say my speed would go upto 52meg while sky only deliver 38meg.
Standard User RobertoS
(sensei) Sun 03-Feb-13 18:51:42
Print Post

Re: Plusnet FTTC unlimited


[re: wobblyheed] [link to this post]
 
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.

My broadband basic info/help site - www.robertos.me.uk | Domains,website and mail hosting - Tsohost.
Connection - Plusnet UnLim Fibre (FTTC). Sync ~ 54.3/15.4Mbps @ 600m. - BQM

"Where talent is a dwarf, self-esteem is a giant." - Jean-Antoine Petit-Senn.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allergy information: This post was manufactured in an environment where nuts are present. It may include traces of understatement, litotes and humour.
Standard User RobertoS
(sensei) Sun 03-Feb-13 18:55:05
Print Post

Re: Plusnet FTTC unlimited


[re: wobblyheed] [link to this post]
 
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.

My broadband basic info/help site - www.robertos.me.uk | Domains,website and mail hosting - Tsohost.
Connection - Plusnet UnLim Fibre (FTTC). Sync ~ 54.3/15.4Mbps @ 600m. - BQM

"Where talent is a dwarf, self-esteem is a giant." - Jean-Antoine Petit-Senn.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allergy information: This post was manufactured in an environment where nuts are present. It may include traces of understatement, litotes and humour.
Standard User wobblyheed
(learned) Sun 03-Feb-13 19:18:14
Print Post

Re: Plusnet FTTC unlimited


[re: RobertoS] [link to this post]
 
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)

Standard User DRW
(committed) Sun 03-Feb-13 23:03:51
Print Post

Re: Plusnet FTTC unlimited


[re: wobblyheed] [link to this post]
 
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.
Standard User WWWombat
(fountain of knowledge) Mon 04-Feb-13 13:09:22
Print Post

Re: Plusnet FTTC unlimited


[re: wobblyheed] [link to this post]
 
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.
Standard User R0NSKI
(experienced) Mon 04-Feb-13 13:24:27
Print Post

Re: Plusnet FTTC unlimited


[re: wobblyheed] [link to this post]
 
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.

Standard User StephenTodd
(committed) Mon 04-Feb-13 13:35:03
Print Post

Re: Plusnet FTTC unlimited


[re: R0NSKI] [link to this post]
 
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.

--
Moved (with trepidation) to BT Infinity 2 for upload speed. Happy BE user for several years.
Standard User WWWombat
(fountain of knowledge) Mon 04-Feb-13 16:24:19
Print Post

Re: Plusnet FTTC unlimited


[re: StephenTodd] [link to this post]
 
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 frown

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.
Standard User StephenTodd
(committed) Mon 04-Feb-13 17:01:39
Print Post

Re: Plusnet FTTC unlimited


[re: WWWombat] [link to this post]
 
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)

--
Moved (with trepidation) to BT Infinity 2 for upload speed. Happy BE user for several years.
Standard User WWWombat
(fountain of knowledge) Mon 04-Feb-13 18:25:10
Print Post

Re: Plusnet FTTC unlimited


[re: StephenTodd] [link to this post]
 
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 wink

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%.
Standard User StephenTodd
(committed) Mon 04-Feb-13 19:07:21
Print Post

Re: Plusnet FTTC unlimited


[re: WWWombat] [link to this post]
 
Thanks very much for that detail. I knew a little of it, but not most.
I do indeed have FEC on, as I have interleaving 1193 and delay 8.0; I monitor these fairly regularly.
I'll have a closer look at the others with interest when I've got a bit more time just to see how it all ties up.

I knew about the tcp window; but some downloads use a protocol like
request send 1MB
receive 1MB
request send 1MB
receive 1MB
etc
Each 1MB receive block gets the benefit of the tcp window to mask out latency,
but the latency comes in between complete receive of one block and the request of the next.

--
Moved (with trepidation) to BT Infinity 2 for upload speed. Happy BE user for several years.
Standard User StephenTodd
(committed) Tue 05-Feb-13 14:35:13
Print Post

Re: Plusnet FTTC unlimited


[re: WWWombat] [link to this post]
 
@WWWombat: Thanks again for that very informative post.

I've just had a look at my figures, shown complete below.
Clearly quite a few errors are causing quite high interleaving and FEC.
Still perfectly acceptable overall performance, though of course faster and less latency would be good.

One clarification on your post where my new understanding doesn't match my figures..
From what you said, I would have expected
Path = Max * (N-R)/N
as (N-R) is the number of useful bytes and N the total number.

However, for downstream, Rate = 75260 but Max * (N-R)/N = 70544,


Text
1
23
45
67
89
1011
1213
1415
1617
1819
2021
2223
2425
2627
2829
3031
3233
3435
3637
3839
4041
4243
4445
4647
4849
5051
5253
5455
5657
58
# xdslcmd info --show
xdslcmd: ADSL driver and PHY statusStatus: Showtime
Retrain Reason: 0Max:    Upstream rate = 23910 Kbps, Downstream rate = 88180 Kbps
Path:   0, Upstream rate = 20000 Kbps, Downstream rate = 75260 Kbps 
Link Power State:       L0Mode:                   VDSL2 Annex B
VDSL2 Profile:          Profile 17aTPS-TC:                 PTM Mode
Trellis:                U:ON /D:ONLine Status:            No Defect
Training Status:        Showtime                Down            Up
SNR (dB):        6.0             15.4Attn(dB):        0.0             0.0
Pwr(dBm):        14.2            6.9                        VDSL2 framing
                        Path 0B:              63              237
M:              1               1T:              64              45
R:              16              16S:              0.0271          0.3782
L:              23651           5373D:              1193            1
I:              80              127N:              80              254
                        Counters                        Path 0
OHF:            3121191941              2325124OHFErr:         36655           633
RS:             2268398122              4210906RSCorr:         486883048               101183
RSUnCorr:       5403560         0 
                        Path 0HEC:            1977557         0
OCD:            0               0LCD:            0               0
Total Cells:    379436542               0Data Cells:     1303444197              0
Drop Cells:     0Bit Errors:     0               0
 ES:             1387            521
SES:            44              0UAS:            22              22
AS:             4069977 
                        Path 0INP:            3.00            0.00
PER:            1.29            4.25delay:          8.00            0.00
OR:             129.34          60.17 
Bitswap:        1622875         48270


--
Moved (with trepidation) to BT Infinity 2 for upload speed. Happy BE user for several years.
Standard User WWWombat
(fountain of knowledge) Tue 05-Feb-13 17:19:29
Print Post

Re: Plusnet FTTC unlimited


[re: StephenTodd] [link to this post]
 
In reply to a post by StephenTodd:
Clearly quite a few errors are causing quite high interleaving and FEC.

Wow!

If I read that correctly, about 25% of RS blocks are received with errors, but 99% of them get successfully corrected.

Your line is *definitely* in need of FEC and interleaving - it just wouldn't work otherwise!

One clarification on your post where my new understanding doesn't match my figures..
From what you said, I would have expected
Path = Max * (N-R)/N
as (N-R) is the number of useful bytes and N the total number.

However, for downstream, Rate = 75260 but Max * (N-R)/N = 70544,

In theory, that sounds about right.

Remember, though, that the "Max Attainable" alters based on current line conditions - particularly the current noise conditions - while the line speed and FEC/interleaving settings were all set in stone at the last sync (looks like 47 days ago). If it is noisier now than then, the "max attainable" figure will be lower.

What does your "--pbParams" output look like? If SNR is not 6dB, then line conditions have changed.

In practice, the Huawei also doesn't quite follow the theory. Whether it is a fault, or a consequence of the way it prepares the estimate, I don't know. When people swap between fastpath and FEC/interleaving, both line speed *and* max attainable change - usually in opposite directions.

The only thing we know for sure is that FEC is indeed eating capacity of your line - 16 bytes extra for each 64 bytes you receive
Standard User StephenTodd
(committed) Tue 05-Feb-13 18:08:50
Print Post

Re: Plusnet FTTC unlimited


[re: WWWombat] [link to this post]
 
The line was running without interleaving for quite a time,
then suddenly got quite high interleaving (as you see) at a marginally increased sync rate.
Unfortunately, Windows Task Manager was being stroppy at the time so my statistics logging wasn't working.
It's still easily fast enough for my needs, and no gaming, so I hadn't really looked into the reason behind the interleaving.

The snr has been varying between 5 and 6 since the last connection.

Looking at the graphs I can see that there are a few bursts of very high RSCorr:.
I must look a bit deeper.
Thanks again.


Text
1
23
45
67
89
1011
1213
1415
1617
1819
2021
22
# xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY statusStatus: Showtime
Retrain Reason: 0Max:    Upstream rate = 24097 Kbps, Downstream rate = 86504 Kbps
Path:   0, Upstream rate = 20000 Kbps, Downstream rate = 75260 Kbps 
Discovery Phase (Initial) Band PlanUS: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3959)Medley Phase (Final) Band Plan
US: (0,95) (868,1207) (1972,2783)DS: (32,859) (1216,1963) (2792,3959)
       VDSL Port Details       Upstream        DownstreamAttainable Net Data Rate:      24097 kbps         86504 kbps
Actual Aggregate Tx Power:        6.9 dBm          14.1 dBm============================================================================
  VDSL Band Status        U0      U1      U2      U3      D1      D2      D3  Line Attenuation(dB):  4.6     24.5    37.3     N/A    12.2    30.1    47.2
Signal Attenuation(dB):  4.6     23.3    35.6     N/A    12.2    30.1    47.2        SNR Margin(dB):  15.5    15.5    15.5     N/A    6.6     5.0     4.9
         TX Power(dBm): -4.2    -19.3    6.4      N/A    10.6    8.0     7.3


--
Moved (with trepidation) to BT Infinity 2 for upload speed. Happy BE user for several years.
Pages in this thread: 1 | 2 | 3 | (show all)   Print Thread

Jump to