View Full Version : Single Stream vs Parallel Stream Bench Speed
lncommunications
08-30-2009, 03:58 PM
Just a bit of clarification...
After testing my new Bullet2M's, as Mike suggested, using the jperf utility I did definately get better results using 10 parallel connection as opposed to just 1.
Now the question is...if we used a Bullet2M for a PtMP application and the client(s) happened to use an application that only supported single TCP streams would we see a slower rate of transfer than if it used multiple.
The reason I ask is that from the testing ive done so far has certainly pleased me, ive seen 80mbps+ using 10 parallel connections but when using only the one stream ive only managed to get ~22mbps.
Hope ive described the scenario for you to respond if not please just ask for more clarification on my part, thanks in advance.
george
08-30-2009, 04:17 PM
Yes, you aren't going to be able to saturate that link with a single TCP stream, but in a PtMP scenario that is largely irrelevant as you will always have multiple streams using the access point end of the link.
In practice, same thing goes for the vast majority of PtP applications.
lncommunications
08-30-2009, 04:42 PM
Thanks George, gonna do some more testing tomorrow im hoping to find, unless someone tells me beforehand, that if I have 4 x streams each stream will be 20mbit and 8 streams will be 10mbit, 16 will be 5mbit per stream and so on...
...or at least at what point does x amount of stream fully saturate the potential bandwidth, if its of use ill post all my results tomorrow.
lncommunications
08-31-2009, 07:19 AM
Ok some test results!
Please bear in mind this is a bench test and not 'out in the field' but hope its of some use to someone.
Devices: Bullet2M x 2
Wireless Mode: WDS (both)
AirMax: Disabled
Encryption: WPA2
Channel: 13 (clear)
Channel Width: 40mhz
Tests performed using jperf
1 x Stream = 32mbps ave / 35mbit peak
2 x Streams = 38mbit ave / 44mbit peak
4 x Streams = 54mbit ave / 58mbit peak
8 x Streams = 58mbit ave / 69mbit peak
16 x Streams = 70mbit ave / 76mbit peak
32 x Streams = 74mbit ave / 84mbit peak (at this point the cpu on the client end was topping out @ 100% load)
....will try with AirMax enabled now!
lncommunications
08-31-2009, 07:38 AM
Same setup but with AirMax enabled...
1 x Stream = 3mbps ave / 3mbit peak
2 x Streams = 12mbit ave / 13mbit peak
4 x Streams = 23mbit ave / 24mbit peak
8 x Streams = 45mbit ave / 48mbit peak
16 x Streams = 58mbit ave / 64mbit peak
32 x Streams = 65mbit ave / 78mbit peak (at this point the cpu on the client end was topping out @ 100% load)
its somewhat an interesting set of results...
danielh
08-31-2009, 11:57 AM
at 100mbps you're not going to be able to saturate the link with a single tcp connection, assuming you're using default configuratinos (you and your peers that is)
it certainly is possible to saturate if if you increase the transmit windows and the mtu. however that needs to be done on both client and server and the intermediate links need to support the larger MTU.
over internet that is unlikely to ever be true, so no matter what kind of pipe you have, fiber or wireless, you wouldn't saturate the link with a single stream
there's some good information that expains it in more details, search for "tcp tuning":
http://www.psc.edu/networking/projects/tcptune/
lncommunications
08-31-2009, 12:05 PM
Thanks for the info ill give it a good read.
My concern is...if you look at the results of my tests, and we have AirMax then a client starts streaming video, which is uses one TCP stream/connection the max seems to be 3mbit.
UBNT-Mike.Ford
08-31-2009, 12:46 PM
Thanks for the info ill give it a good read.
My concern is...if you look at the results of my tests, and we have AirMax then a client starts streaming video, which is uses one TCP stream/connection the max seems to be 3mbit.
Hey,
Is this just in a poing to point scenario? Can you run a single High Def video over the link to test?
Thanks,
lncommunications
08-31-2009, 02:14 PM
Hi Mike, over here we have something called BBC iPlayer which is a Video-on-Demand service, there are other services but the BBC's is by far the most popular. We have seen a huge growth in this service and what worries me, please dont get me wrong I guess every service provider will suffer from this, not just those using Ubiquiti devices, is that the BBC have just released a HD version which needs at least 3.5mbit.
Now from my results above if we have AirMax enabled it looks that each client will get 3mbit max throughput per TCP connection and the tests I performed using the BBC iPlayer is that it is a single TCP connection also.
I was hoping for a simple explanation but no worries ill be performing more tests over the next week so ill let you know. I will also play a HD vid across the LAN as you suggested.
Oh and im thinking in a PtMP scenario.
rconaway
08-31-2009, 02:43 PM
We tested many video scenarios from 2Mbps up to 26Mbps with the Bullet as the AP. Unfortunately, the company we were testing with ran out of funds just as they sent the mailers for the clients.
However, with 2 locations and 4 streams running (2 cable boxes each location), we used 4Mbps streams and had no problems or hiccups. We also used UDP instead of TCP/IP so we could have more viewers. We were going to have 8 users per Bullet and 16 users per Rocket upon final deployment based on testing bandwidth, CPU percentage, etc... Keep in mind we are also delivering Internet over the same radio so we couldn't push them to the end. The clients were using 28dBi parabolics are were out 2 and 3 miles. Our connection speed was 65Mbps.
lncommunications
08-31-2009, 02:46 PM
Sounds nice! let me know how it goes with the Rockets ill post our results with HD VoD very soon.
Does BBC fallback to UDP if TCP don't work ? Filtering TCP from that server would save you airtime (as 802.11 traffic is already ACK'ed for)...
drewlsvern
01-24-2010, 10:38 PM
Sounds nice! let me know how it goes with the Rockets ill post our results with HD VoD very soon.
I'm curious, did You ever test this? Do You have any results?
lncommunications
03-14-2010, 06:18 PM
Sorry for the late post I didn't see your reply.
No not yet but hopefully this week will be able to get some results.