Superzoom speed problem
@Kelly
It was the early morning of the 12th, actually. I posted that afternoon that:
It seemed the more notable observation.
As I said, the two things aren't necessarily linked. But they might be. Either way, I hope the information is useful to you in finding out. It sounds like you might not have a great deal of control over significant parts of the network, so you might be just as much in the dark as I am.
@AndyH
Yeah, I'm not on 330Mbps... The plan was for 160/20 but something seemed to go wrong with that. It hasn't been explained why so far.
Eventually I'll get around to doing the throughput tests by setting up the router on a local PPPoE session, just for the sake of definitively putting to bed the notion that it could possibly be the bottleneck in any way, and then I'll sit back and wait for PlusNet to suggest that I might have a problem with a duff ethernet cable, or some bird poo on the window, or the way the gerbils are running around their cage (I don't have any gerbils)!!!
BT could well be upgrading and improving our exchange, as implied above, and the short term effect might well be patchily negative and positive. Dunno really. Nobody has told me either way. We generally notice the responsiveness of web surfing more than average throughput. As I said to Kelly, the throughput information was what I had to offer. Guessing what on Earth might be going on at any particular time seems to be something of a recherché PlusNet sport - the Eton Fives of the ISP world, only more time-consuming.
So your testing setup is:
GigE Clients --> GigE Switch --> GigE LAN Port of SamKnows Box --> GigE WAN Port of SamKnows Box --> GigE LAN Port of Router --> GigE WAN Port of Router --> ONT
Is that right? Along with some wireless clients off the router, I assume.
It was the early morning of the 12th, actually. I posted that afternoon that:
Quote from: SuperZoom Don't know what's changed, but browsing seems to be very snappy today.
Latency is certainly very low: 3ms to BBC and cached DNS queries returned in 6 or 7ms; but beyond that no chance for non-subjective testing.
Very welcome improvement, though
It seemed the more notable observation.
As I said, the two things aren't necessarily linked. But they might be. Either way, I hope the information is useful to you in finding out. It sounds like you might not have a great deal of control over significant parts of the network, so you might be just as much in the dark as I am.
@AndyH
Yeah, I'm not on 330Mbps... The plan was for 160/20 but something seemed to go wrong with that. It hasn't been explained why so far.
Eventually I'll get around to doing the throughput tests by setting up the router on a local PPPoE session, just for the sake of definitively putting to bed the notion that it could possibly be the bottleneck in any way, and then I'll sit back and wait for PlusNet to suggest that I might have a problem with a duff ethernet cable, or some bird poo on the window, or the way the gerbils are running around their cage (I don't have any gerbils)!!!
BT could well be upgrading and improving our exchange, as implied above, and the short term effect might well be patchily negative and positive. Dunno really. Nobody has told me either way. We generally notice the responsiveness of web surfing more than average throughput. As I said to Kelly, the throughput information was what I had to offer. Guessing what on Earth might be going on at any particular time seems to be something of a recherché PlusNet sport - the Eton Fives of the ISP world, only more time-consuming.
So your testing setup is:
GigE Clients --> GigE Switch --> GigE LAN Port of SamKnows Box --> GigE WAN Port of SamKnows Box --> GigE LAN Port of Router --> GigE WAN Port of Router --> ONT
Is that right? Along with some wireless clients off the router, I assume.
Quote from: SuperZoom @Kelly
It was the early morning of the 12th, actually. I posted that afternoon that:
Quote from: SuperZoom Don't know what's changed, but browsing seems to be very snappy today.
Latency is certainly very low: 3ms to BBC and cached DNS queries returned in 6 or 7ms; but beyond that no chance for non-subjective testing.
Very welcome improvement, though
It seemed the more notable observation.
As I said, the two things aren't necessarily linked. But they might be. Either way, I hope the information is useful to you in finding out. It sounds like you might not have a great deal of control over significant parts of the network, so you might be just as much in the dark as I am.
I'm confused. Your previous post talked about performance problems which you'd shown in early morning, but that doesn't suggest that? Sorry if I'm being dense.
Quote from: Kelly I'm confused. Your previous post talked about performance problems which you'd shown in early morning, but that doesn't suggest that? Sorry if I'm being dense.
I was trying to say - obviously not very clearly - that I thought the problem might be a constricted link.
Such a link may also be expected to end up being a congested link at peak times.
The fact that I am unable now to reach the same level of throughput previously possible, even at 4am when there would be no congestion, does tend to suggest a constriction.
I posited a 100Mbps ethernet link which should be running at 1Gbps, but it could equally well be a smaller capacity than usual backhaul link. That would tie in with dave's idea that BTw could be in the process of
Quote from: dave moving users to new backhaul capacity.
Who knows? I'm bowing out of the guessing game for today, I'm afraid...
Quote from: AndyH BTO don't even offer such a product. BT Infinity offer a 160/20Mbps service which based on a capped 330/20Mbps product variant.
That's an extremely helpful insight, Andy. Thank you. Maybe that has been the source of the confusion all along. If only they'd said in so many words.
Quote from: AndyH The SamKnows box is connected directly into my switch, without using the WAN port.
Ah, I see. Doesn't it have problems knowing when the network is quiet then, though?
Yes, you're right, I was getting about 72.9Mbps (with bursts of faster) - which is what I expected.
To be honest, I am not exactly fascinated by all this testing. I wouldn't feel any need to know what was going on at all if the web browsing was zippy snap snap and stayed that way! It's just a matter of looking for clues as to why it might not be.
It would actually be quite interesting to know if there are any other PlusNet FTTP trialists on the same exchange. Nearby properties are all on Infinity - and, of course, the Openreach guy was astonished that anything else might be a possibility
Quote from: SuperZoom I posited a 100Mbps ethernet link which should be running at 1Gbps, but it could equally well be a smaller capacity than usual backhaul link. That would tie in with dave's idea that BTw could be in the process of
I'd be surprised if any of BT's exchanges with FTTP are using 100Mbps ethernet links for joining into their 21CN network. It would kind of defeat the purpose of high speed connections.
Are you using speedtest.net? If you are, can you go to http://www.speedtest.net/results.php?a=share and Export Results (you'll need to edit the *.csv to remove the IP_Address column.
Quote from: SuperZoom Ah, I see. Doesn't it have problems knowing when the network is quiet then, though?
The firmware picks up when there is no activity on the network to run the tests. It's also got some external antennas to detect when there is no wifi activity.
Quote from: SuperZoom To be honest, I am not exactly fascinated by all this testing. I wouldn't feel any need to know what was going on at all if the web browsing was zippy snap snap and stayed that way! It's just a matter of looking for clues as to why it might not be.
It would actually be quite interesting to know if there are any other PlusNet FTTP trialists on the same exchange. Nearby properties are all on Infinity - and, of course, the Openreach guy was astonished that anything else might be a possibility
What's your setup like? Wired/wireless? PCs/Macs?
FTTP is still a pretty niche product. You would be amazed how many houses around me that are FTTP capable homes still on their 1Mb ADSL connections. People just don't know anything about it because none of the ISPs really market it as a product. A PlusNet advert in one of the local papers about FTTP (up to 330/30Mbps etc. speeds) in Milton Keynes would surely attract a large number of interested people
Yeah, I didn't mean deliberately using 100Mbps kit, of course 
Well, hopefully I won't be doing too much speedtesting if Kelly's desire to get things pinned down comes to fruition
Things seem OK today from the odd web site visited, and a quick TBB speedtest looked good; although I still don't understand why the HTTPx6 results are often anomalous - strange things seem to happen with HTTP on PlusNet, which I can only ascribe to the traffic management in the absence of other explanations. Still in the process of making absolutely sure it's nothing at this end before posting further on that, though.
Generally, however, the fact that ThinkBroadband makes fixed size test files available for download is more useful for troubleshooting than Flash-based testers, pretty though they are. Results can be compared more reliably across hardware and operating systems and benchmarked more easily against local servers. The text results in post 41, for example, were from cURL.
As far as your SamKnows box goes (unless your switch has a replication port for analysis and you've plugged it into that) it won't be able to see other internet traffic on your wired network if you plug it into the switch separately. That's how switches work. You can check for yourself by running Wireshark in promiscuous mode on one client whilst browsing the internet or some other unicast activity on another.
Well, hopefully I won't be doing too much speedtesting if Kelly's desire to get things pinned down comes to fruition
Things seem OK today from the odd web site visited, and a quick TBB speedtest looked good; although I still don't understand why the HTTPx6 results are often anomalous - strange things seem to happen with HTTP on PlusNet, which I can only ascribe to the traffic management in the absence of other explanations. Still in the process of making absolutely sure it's nothing at this end before posting further on that, though.
Generally, however, the fact that ThinkBroadband makes fixed size test files available for download is more useful for troubleshooting than Flash-based testers, pretty though they are. Results can be compared more reliably across hardware and operating systems and benchmarked more easily against local servers. The text results in post 41, for example, were from cURL.
As far as your SamKnows box goes (unless your switch has a replication port for analysis and you've plugged it into that) it won't be able to see other internet traffic on your wired network if you plug it into the switch separately. That's how switches work. You can check for yourself by running Wireshark in promiscuous mode on one client whilst browsing the internet or some other unicast activity on another.
I think it might be worth upping the line speed to 100Mbps just to see what comes of it, Dave, if you're willing to do that. It could provide you with some useful info as much as me.
Before putting you to any trouble, however, I've done some more testing to try to establish a better picture of where the limits are and to try to shed some further light on LAN vs WAN performance.
What I haven't done yet (but will do when I can) is set up a local PPPoE server so that I can control the WAN side of the data feed (although that will also take GPON out of the equation, of course.) Changing the line speed in the meantime will usefully vary that variable, however. And I have also, meanwhile, tested without the router in the mix, by making a direct PPPoE connection via the ONT, as you previously requested.
All of this throughput information may have no bearing whatsoever on general browsing responsiveness, so it could be a total diversion. I suspect it is; and is only tangentially related. But it's probably still worth getting a sense of the dimensions of it anyway, for reference.
So this is the test setup, which was intended to make sure any auto-negotiation problems between switch and router were apparent (there were none). I will refer to the machines involved by friendly, cuddly, memorable names I have just invented to make things clearer! All HTTP throughput measurements are taken from cURL. Both the LAN and WAN MTUs were set to 1492 bytes with a 1045440 byte maximum receive window.
This time, rather than using a separate 100Mbps local web server, I've kept the same (gigabit) server machine and just changed the network card settings. It is a faster machine than the one I previously used for the 100Mbps test. Whether it is the greater processor power or the better network card which accounts for the resulting higher LAN transfer speed to the same low-power client, it isn't possible to say, but it is possible to conclude that the rate at which data can be sent matters a lot. If something is slowing it down, it will be slower(!)
Shaun = Slow, Old, Gigabit Wired Client
- connected to gigabit switch
Walter = Local Machine Running Apache Web Server,
Also Acting As Client For Some TBB Download Tests (Both Via Router And Making Own PPP Connection)
- connected to a gigabit switch port on the router
TBB = ThinkBroadband Download Server
[tt]
Shaun --> Gigabit Switch --> Router <-- Walter ( --> ONT)
(Client) (also Switch) (Server/Client)
|
ONT[/tt]
And these are the (rounded) results:
The hardware optimizations are network card settings like checksum offloading.
I thought perhaps they were making a difference, but it seems not so much.
GigE with hardware optimizations on
Walter --> Shaun = 105Mbps
TTB --> Shaun = 69Mbps
TTB --> Walter bypassing router (PPPoE direct through ONT) = 62Mbps
GigE with hardware optimizations off
Walter --> Shaun = 101Mbps
TTB --> Walter = 69Mbps
100Mbps Ethernet with hardware optimizations on
Walter --> Shaun = 73Mbps
100Mbps Ethernet with hardware optimizations off
Walter --> Shaun = 73Mbps
TTB --> Walter = 69Mbps
It looks like the 80Mbps WAN connection is topping out at 69Mbps actual payload today, on this measure; whilst the 100Mbps LAN can deliver 73Mbps (at least to this client). But 105Mbps is also possible...
The difference is two different ethernet technologies as opposed to an arbitrary QoS limit.
So it would be a worthwhile experiment to see what a 100Mbps WAN link comes in at, I think.
The router doesn't seem to have any negative effect from the above. I wonder whether it only establishes a gigabit link on the WAN side if that link is running at over 100Mbps, though, or something like that?... If I sound like I don't know what I'm talking about there, it's because I don't!
Nevertheless, it is well worth noting that the WAN throughput figures have improved considerably since 12th July: on the morning of 11th July, the TTB --> Shaun GigE figure was 57Mbps, for example. So that does support the theory of Openreach / BTw reconfigurations constricting speeds for a period, and perhaps thereby also causing congestion, consistent with the preparatory works which seem to be going on more often in local roads.
Would that have a bigger impact on responsiveness than any (as yet not established) effect from traffic management latency? Maybe...
Before putting you to any trouble, however, I've done some more testing to try to establish a better picture of where the limits are and to try to shed some further light on LAN vs WAN performance.
What I haven't done yet (but will do when I can) is set up a local PPPoE server so that I can control the WAN side of the data feed (although that will also take GPON out of the equation, of course.) Changing the line speed in the meantime will usefully vary that variable, however. And I have also, meanwhile, tested without the router in the mix, by making a direct PPPoE connection via the ONT, as you previously requested.
All of this throughput information may have no bearing whatsoever on general browsing responsiveness, so it could be a total diversion. I suspect it is; and is only tangentially related. But it's probably still worth getting a sense of the dimensions of it anyway, for reference.
So this is the test setup, which was intended to make sure any auto-negotiation problems between switch and router were apparent (there were none). I will refer to the machines involved by friendly, cuddly, memorable names I have just invented to make things clearer! All HTTP throughput measurements are taken from cURL. Both the LAN and WAN MTUs were set to 1492 bytes with a 1045440 byte maximum receive window.
This time, rather than using a separate 100Mbps local web server, I've kept the same (gigabit) server machine and just changed the network card settings. It is a faster machine than the one I previously used for the 100Mbps test. Whether it is the greater processor power or the better network card which accounts for the resulting higher LAN transfer speed to the same low-power client, it isn't possible to say, but it is possible to conclude that the rate at which data can be sent matters a lot. If something is slowing it down, it will be slower(!)
Shaun = Slow, Old, Gigabit Wired Client
- connected to gigabit switch
Walter = Local Machine Running Apache Web Server,
Also Acting As Client For Some TBB Download Tests (Both Via Router And Making Own PPP Connection)
- connected to a gigabit switch port on the router
TBB = ThinkBroadband Download Server
[tt]
Shaun --> Gigabit Switch --> Router <-- Walter ( --> ONT)
(Client) (also Switch) (Server/Client)
|
ONT[/tt]
And these are the (rounded) results:
The hardware optimizations are network card settings like checksum offloading.
I thought perhaps they were making a difference, but it seems not so much.
GigE with hardware optimizations on
Walter --> Shaun = 105Mbps
TTB --> Shaun = 69Mbps
TTB --> Walter bypassing router (PPPoE direct through ONT) = 62Mbps
GigE with hardware optimizations off
Walter --> Shaun = 101Mbps
TTB --> Walter = 69Mbps
100Mbps Ethernet with hardware optimizations on
Walter --> Shaun = 73Mbps
100Mbps Ethernet with hardware optimizations off
Walter --> Shaun = 73Mbps
TTB --> Walter = 69Mbps
It looks like the 80Mbps WAN connection is topping out at 69Mbps actual payload today, on this measure; whilst the 100Mbps LAN can deliver 73Mbps (at least to this client). But 105Mbps is also possible...
The difference is two different ethernet technologies as opposed to an arbitrary QoS limit.
So it would be a worthwhile experiment to see what a 100Mbps WAN link comes in at, I think.
The router doesn't seem to have any negative effect from the above. I wonder whether it only establishes a gigabit link on the WAN side if that link is running at over 100Mbps, though, or something like that?... If I sound like I don't know what I'm talking about there, it's because I don't!
Nevertheless, it is well worth noting that the WAN throughput figures have improved considerably since 12th July: on the morning of 11th July, the TTB --> Shaun GigE figure was 57Mbps, for example. So that does support the theory of Openreach / BTw reconfigurations constricting speeds for a period, and perhaps thereby also causing congestion, consistent with the preparatory works which seem to be going on more often in local roads.
Would that have a bigger impact on responsiveness than any (as yet not established) effect from traffic management latency? Maybe...