Superzoom speed problem
That's great, Dave, thank you very much. Let's give it a go! 
With reference to your comment, Andy, the really interesting thing to me would be to see whether I would get 105Mbps throughput to "Shaun" out of a 300Mbps connection...
With reference to your comment, Andy, the really interesting thing to me would be to see whether I would get 105Mbps throughput to "Shaun" out of a 300Mbps connection...
Now you're confusing me! 
Based on what both you and Dave said, that would be the only possible option for delivering more than 100Mbps to said client, as is possible over the LAN.
I'm not expecting to get it.
But it would be the most interesting thing to test.
Based on what both you and Dave said, that would be the only possible option for delivering more than 100Mbps to said client, as is possible over the LAN.
I'm not expecting to get it.
But it would be the most interesting thing to test.
The line speed updated correctly to 100/15 (BT IP Profile now showing as 96.54Mbps down / 15Mbps up with PN Profile showing as 92Mbps).
There seems to be an extra millisecond of latency - which, although interesting, is neither here nor there.
cURL HTTP payload throughput from TBB has so far topped out at 86Mbps on all machines, including the slowest (referred to as "Shaun" above).
That's faster than was achievable over the LAN to that reference machine using 100Mbps Fast Ethernet.
Presumably, therefore, if the line speed were ever increased further, throughput to that machine could be expected to exceed 100Mbps, as is possible using Gigabit Ethernet on the LAN.
(That specific client will never reach what some may consider to be "true" gigabit speeds for obvious reasons.)
Looks like the WAN-fast-ethernet-interface-constriction theory is well and truly scotched!
A successful experiment, therefore.
Well worth doing, I think. Thank you, Dave.
As far as web browsing responsiveness goes, it continues to be variable.
I suspect that, as Andy has implied, that is perhaps more down to BTw routing, capacity and traffic load at any particular time than anything else (just as the very slight extra latency noted above is probably down to BTw rather than any PlusNet equipment which may have changed, since it seems to be the same regardless of PN gateway). Before moving to PlusNet, we were previously on LLU for ADSL, so the vagaries of the BT network were not a factor. Maybe that's the primary difference. Ultimately, it is a contended service, and TCP performance varies as such. It would be great if web browsing were always as super-responsive as it sometimes is, but there simply don't seem to be any more specific choke factors to pin down...
A further experiment I'd like to do is to see what kind of maximum throughput the router is capable of sustaining (necessarily, over a local PPPoE setup,) so I'll hopefully get to that at some point in the next week or two. Just out of interest.
If 330/30 were available, I would, of course, happily give it a try, Andy, yes!
The router should comfortably be able to cope with that and it would be interesting to reveal the limits of various clients. I think I'll have to content myself with a local test setup instead, though!
There seems to be an extra millisecond of latency - which, although interesting, is neither here nor there.
cURL HTTP payload throughput from TBB has so far topped out at 86Mbps on all machines, including the slowest (referred to as "Shaun" above).
That's faster than was achievable over the LAN to that reference machine using 100Mbps Fast Ethernet.
Presumably, therefore, if the line speed were ever increased further, throughput to that machine could be expected to exceed 100Mbps, as is possible using Gigabit Ethernet on the LAN.
(That specific client will never reach what some may consider to be "true" gigabit speeds for obvious reasons.)
Looks like the WAN-fast-ethernet-interface-constriction theory is well and truly scotched!
A successful experiment, therefore.
Well worth doing, I think. Thank you, Dave.
As far as web browsing responsiveness goes, it continues to be variable.
I suspect that, as Andy has implied, that is perhaps more down to BTw routing, capacity and traffic load at any particular time than anything else (just as the very slight extra latency noted above is probably down to BTw rather than any PlusNet equipment which may have changed, since it seems to be the same regardless of PN gateway). Before moving to PlusNet, we were previously on LLU for ADSL, so the vagaries of the BT network were not a factor. Maybe that's the primary difference. Ultimately, it is a contended service, and TCP performance varies as such. It would be great if web browsing were always as super-responsive as it sometimes is, but there simply don't seem to be any more specific choke factors to pin down...
A further experiment I'd like to do is to see what kind of maximum throughput the router is capable of sustaining (necessarily, over a local PPPoE setup,) so I'll hopefully get to that at some point in the next week or two. Just out of interest.
If 330/30 were available, I would, of course, happily give it a try, Andy, yes!
The router should comfortably be able to cope with that and it would be interesting to reveal the limits of various clients. I think I'll have to content myself with a local test setup instead, though!
You may be right, Andy - and maybe you know the implementation details and effects of the PlusNet QoS system far better than I do (which is not at all) - but on the basis that a definitive, real-world test provides a clearer insight than any amount of speculation, here is what the throughput is, via my router, using a 100Mbps PPPoE connection without any kind of further encapsulation or shaping.
I'm going to call the PPPoE concentrator I set up locally and connected to the WAN port of the router "Cedric" here to distinguish it from the more powerful machine I'm going to use later for maximum throughput testing.
The clients were connected to the router via a separate switch.
Cedric --> Router --> Shaun = 92.68Mbps
(Local PPPoE "WAN" Server)
Does a more powerful client make any difference? A little bit...
Cedric --> Router --> Walter = 94.04Mbps
(Local PPPoE "WAN" Server)
What was this amazing high-power server setup you used to skew these results in such an unfair fashion, I hear you ask?!
Well, this wasn't an absolute throughput test, but rather a test to replicate the PlusNet 100Mbps WAN link, and to do it with minimum disruption, so what I did was to simply unplug the router's WAN patch lead from the ONT and plug it into a little old laptop running Linux off a USB stick: not exactly the fastest storage medium. It has a Pentium M 753 ULV Processor running at 1.2Ghz and an integrated 100Mbps Realtek Fast Ethernet controller. Seriously powerful, I think you'll agree!
The PPPoE concentrator software was Roaring Penguin, running in user space, and the HTTP download, using cURL under Windows on the clients, was a 153MB HTML file served from nginx running on the same little laptop (no gzip or anything, just a quick, simple vanilla install).
The above results were actually exactly the same through the LAN switch, using only ethernet with no router or PPPoE involvement. So, surprisingly, at this speed anyway, PPPoE had no performance impact. (The path MTU was 1492 in both cases.) Neither did the router. It has now been proved that the router is not slowing anything down. End of doubt.
What that further illustrates quite nicely, perhaps, is that the rate that data can be sent down the line matters much more than how powerful the client is. Previously, using a more powerful machine as the HTTP server, but running Apache under Windows instead of nginx under Linux, "Shaun" topped out at 73Mbps throughput using 100Mbps ethernet, if you remember. (I'll include some 'raw' iperf figures in the max. throughput test for comparison, but I wanted to stick with HTTP for this, so, of course, the server software is a variable.)
I think it's safe to assume, however, that the ThinkBroadband download servers can supply the data fast enough, since they are designed for speed testing.
So the intriguing question now remains, why is the "overhead" on a straightforward 100Mbps PPPoE WAN link 6%,
yet it is 14% on a Plusnet 100Mbps FTTP PPPoE WAN link,
and 8.75% on an 80Mbps one?
Where do the missing megabits go?!
Can you explain the difference, Dave?
I'm going to call the PPPoE concentrator I set up locally and connected to the WAN port of the router "Cedric" here to distinguish it from the more powerful machine I'm going to use later for maximum throughput testing.
The clients were connected to the router via a separate switch.
Cedric --> Router --> Shaun = 92.68Mbps
(Local PPPoE "WAN" Server)
Does a more powerful client make any difference? A little bit...
Cedric --> Router --> Walter = 94.04Mbps
(Local PPPoE "WAN" Server)
What was this amazing high-power server setup you used to skew these results in such an unfair fashion, I hear you ask?!
Well, this wasn't an absolute throughput test, but rather a test to replicate the PlusNet 100Mbps WAN link, and to do it with minimum disruption, so what I did was to simply unplug the router's WAN patch lead from the ONT and plug it into a little old laptop running Linux off a USB stick: not exactly the fastest storage medium. It has a Pentium M 753 ULV Processor running at 1.2Ghz and an integrated 100Mbps Realtek Fast Ethernet controller. Seriously powerful, I think you'll agree!
The PPPoE concentrator software was Roaring Penguin, running in user space, and the HTTP download, using cURL under Windows on the clients, was a 153MB HTML file served from nginx running on the same little laptop (no gzip or anything, just a quick, simple vanilla install).
The above results were actually exactly the same through the LAN switch, using only ethernet with no router or PPPoE involvement. So, surprisingly, at this speed anyway, PPPoE had no performance impact. (The path MTU was 1492 in both cases.) Neither did the router. It has now been proved that the router is not slowing anything down. End of doubt.
What that further illustrates quite nicely, perhaps, is that the rate that data can be sent down the line matters much more than how powerful the client is. Previously, using a more powerful machine as the HTTP server, but running Apache under Windows instead of nginx under Linux, "Shaun" topped out at 73Mbps throughput using 100Mbps ethernet, if you remember. (I'll include some 'raw' iperf figures in the max. throughput test for comparison, but I wanted to stick with HTTP for this, so, of course, the server software is a variable.)
I think it's safe to assume, however, that the ThinkBroadband download servers can supply the data fast enough, since they are designed for speed testing.
So the intriguing question now remains, why is the "overhead" on a straightforward 100Mbps PPPoE WAN link 6%,
yet it is 14% on a Plusnet 100Mbps FTTP PPPoE WAN link,
and 8.75% on an 80Mbps one?
Where do the missing megabits go?!
Can you explain the difference, Dave?
