Superzoom speed problem
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Plusnet Community
- :
- Forum
- :
- Help with my Plusnet services
- :
- Broadband
- :
- Re: Superzoom speed problem
Re: Superzoom speed problem
19-07-2013 1:49 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
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...
Re: Superzoom speed problem
19-07-2013 4:11 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
Re: Superzoom speed problem
19-07-2013 4:44 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
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.
Re: Superzoom speed problem
19-07-2013 5:16 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
Something doesn't seem right if you're testing GigE and only getting 105 Mbps between internal machines. You should be getting around 600-700 Mbps.
Do you mean you want to test the 330/30 Mbps FTTP to see what throughput you can get?
Re: Superzoom speed problem
20-07-2013 10:02 AM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
Re: Superzoom speed problem
20-07-2013 12:48 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
Quote from: SuperZoom "What is it that makes gigabit ethernet faster than fast ethernet?"
4x pairs vs 2x pairs
2 bits per signal
But you're talking in riddles...I don't understand what you mean by
Quote from: SuperZoom to see whether I would get 105Mbps throughput to "Shaun" out of a 300Mbps connection...
Re: Superzoom speed problem
24-07-2013 11:39 AM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
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!
Re: Superzoom speed problem
24-07-2013 3:23 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
I mean, if one gets about 73Mbps out of an 80Mbps connection normally, that's only 8.75% ...
Re: Superzoom speed problem
24-07-2013 3:45 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
Quote from: AndyH The 100/15 Mbps variant will give you a max real life throughput of 88Mbps +/- 1Mbps. We've tested this with different ISPs etc.
Maybe dave can shed some light on this - but I do know someone on a 80/20 FTTC connection (max line speed) will get better speed tests than someone on 80/20 FTTP. I don't quite understand why people can't get reach the speeds their IP Profile is set to.
Re: Superzoom speed problem
24-07-2013 4:24 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
It might not really be about protocol overheads so much as VLANs.
Does the attached shed any light?
Re: Superzoom speed problem
25-07-2013 7:23 AM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
It brought me right back to the notion that the way in which QoS is set up (broadly, even, not necessarily per-customer,) can in fact have the effect of introducing small web browsing latencies, even if that isn't the aim -- which is undoubtedly worth bearing in mind.
There is an implication that QoS setup can have a bearing on the available bandwidth for a connection too. Something has to account for all those 'lost' megabits!
EDIT: More FTTP traffic prioritization information in the attached.
Re: Superzoom speed problem
25-07-2013 7:07 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
I just think the IP Profiles are lower than published. Why does a TAP3 test at 5am give you only 1-2Mb better than you get with PN?
Re: Superzoom speed problem
29-07-2013 9:49 AM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
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?
Re: Superzoom speed problem
29-07-2013 2:52 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
Quote from: SuperZoom
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?
Yeah, the FTTP 100Mbps profile on our side of the network is set at 92000kbps whereas on the BT side it's set at 96543kbps. I'll get our profile increased to match and that should bring the gap down. I'll see if I can see when it changed as I'm pretty certain it used to be 92000kbps BT side too.
Enterprise Architect - Network & OSS
Plusnet Technology
Re: Superzoom speed problem
30-07-2013 8:19 AM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
If the PN profile is just a QoS choke to make sure the BTw side doesn't get overwhelmed, what prevents that being the upper limit?
ie. Why would the throughput be 86Mbps rather than 92Mbps?
Is that 6.5% difference simply the "unseen" data - the headers necessary to transmit the measured payload? So that, in fact, 92 million bits really are being delivered every second.
That would make sense from my test above - about 6% overhead.
Surely, as you say, then, the PN profile only needs to be set fractionally below the BT one to serve its purpose?
What's the reasoning behind the 3.457% reduction from 'line speed' effected by the BT IP profile (which, obviously, you can't do anything about)? And do you know why they might have decided to reduce it from the 8% they had it at previously?
There's no similar profile reduction from line speed on the upstream, of course...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page