View Full Version : FTP test results
We couldn't try it with a 40 MHz channel width. The connection had too much trouble stay up.
At 20 Mhz, the FTP client was showing 2,420 KBps upload speeds, or 19,360 Kbps. Since that is a network card to network card result (via a wireless connection), I don't think any delay in writing the data to the hard drive is the problem.
Interestingly, when we downloaded the same files, we were seeing 300 KBps, or 2,400 Mbps speeds. Now that might be a hard drive delay at the FTP server end. Unfortunately, AirOs 5 dos not have a built in speed test - they took it out after my testing showed it was too unreliable (that was like 3 months ago)
Nevertheless, 2.4 Mbps connected to a 5 Mbps DSL line 22 miles away is fine with me. Considering that a standard Bullet was getting me at best a reliable 36 Mbps data connection and I'm my Bullet M5 is consistently holding at least a 58.5/58.5 MbpsTX/TX connection (usually its 65/65) - I'm not complaining.
I was reading this to Mike and he thinks a new firmware release night help me.
Considering that a standard Bullet was getting me at best a reliable 36 Mbps data connection and I'm my Bullet M5 is consistently holding at least a 58.5/58.5 MbpsTX/TX connection (usually its 65/65) - I'm not complaining.
First, thanks for finally posting the test results.
I hope you know that the "air speed rate" means very little. There isn't anything unusual with a 36 Mbps connection outperforming a 48 Mbps connection in TCP tests.
19 Mbps is a good start, hopefully new firmware and different environments will result in better speeds.
I was making a simple apples to apples comparison of two products based on RX sensitivities for various data rates.
UBNT-Mike.Ford
08-07-2009, 10:05 AM
I was making a simple apples to apples comparison of two products based on RX sensitivities for various data rates.
Speaking of wich. Email me, ill get you the firmware we are shipping with now.
Thanks,
Mike
DrNutbush
08-07-2009, 12:16 PM
Nevertheless, 2.4 Mbps connected to a 5 Mbps DSL line 22 miles away is fine with me. Considering that a standard Bullet was getting me at best a reliable 36 Mbps data connection and I'm my Bullet M5 is consistently holding at least a 58.5/58.5 MbpsTX/TX connection (usually its 65/65) - I'm not complaining.
Did you mean 2.4 MBps?
yes, 2.4 Mbps, or 2,400 Kbps
avantwireless
08-07-2009, 02:38 PM
Hopefully this might get a firmware offer too...?
The speed test s/w is MT btest in both cases, testing through the wireless devices. PC on one side, MT433AH on the other
This is a 6.3Mile link. On the same antennas but 2x2 as required by MT, we are seeing with a 20mhz channel, ~50mb/s tcp.
AirOSV to AirOS V 20mhz channel we see ~40mb/s tcp and with a 40mhz channel we have seen 80mb/s UDP is erratic going from (20mhz) 55mb/s to 0. Reminds me of the problems we had originally with the bullet twos on 10mhz channels..
UBNT-Mike.Ford
08-07-2009, 04:12 PM
Hello,
2x2 Mimo will always be faster then 1x1 mimo. You only lost 10Mbps when dropping down to 1x1 so thats not bad at all. Can you post the rest of your settings?
Thanks,
Mike
A friend reading this forum asked in email for a clarification.
2.4 Mbps and 2.4 MBps are 2 totally different critters,
with about 10 times the speed difference. You wrote that you
got 36 Mbps with a standard Bullet, yet you feel 2.4 Mbps is
faster.
That's why whenever I mention a file size in MB, I add the size in Mb.
The 36 Mbps was referring to a data speed when I was comparing it to the
58 Mbps data speed of the Bullet 5M. The 24 Mbps was referring to the FTP speeds, not the data speeds.
masked
08-07-2009, 08:41 PM
2,400 Mbps speeds.
:lol:
also, can we have a clear way of referring to data rates or "speeds" or what i like to call "air rates" and defining the difference from what i would call "data rates" (tcp/ip or udp) mostly for new-comers?
i think it's a common misconception... but understandable.
edit: oh and maybe some rf tech would like to explain what all that wireless overhead actually consists of?
kijoma
08-08-2009, 04:08 AM
hi,
overhead is a mix of things, ack turnaround, how long before you get an ack.. the actual time to send an ack.. the preamble (the leader that enables the receiver detector to synch to the data) , the inter symbol guard band.. the differences in L2 and Ethernet MTU...
The CSMA period so other stations get a chance to talk..
hell a load of stuff :)
Some people include the half duplex nature of wireless as part of the overhead, others assume you already know that and would be referring to other processes that effectively slow things down.
Lets say you have a wired 100 Mbps connection. Data is sent from device A to device B on one data pair and device B can simultaneously send data back to device A on the other pair. That is called a full duplex setup.
But with wireless, the devices can't transmit and receive at the same time. So that's called half duplex. So the "data speed" or over the air data rate", the radios "data speed setting", or whatever you want to call it is set for 100 Mbps (as a comparative example as 802.11g is actually 54 Mbps), then device A transmits 100 Mb of data on one second to device B; then device B sends 100 Mb of data back to device B during the second one second interval. So 100 mB of data has been exchanged between the two deices over a two second period of time.Sso effectively its a 50 Mbps data exchange.
For that reason, you'll see me refer to data speed and "end user internet experience speed". If you have a 10 Mbps DSL connection and send it to a user over wireless, they will have a 5 Mbps internet browsing experience.
Now...you have some more overhead or processes that slow things down:
Using auto negotiation for the best speed.
Using auto ACK at the far end instead of a manual setting.
Poor signal path that forces a repeat of the data.
Hidden node contention.
Co-channel interference that forces a repeat.
Force setting too fast a data speed for the distance of the path.
avantwireless
08-08-2009, 08:41 AM
Hello,
2x2 Mimo will always be faster then 1x1 mimo. You only lost 10Mbps when dropping down to 1x1 so thats not bad at all. Can you post the rest of your settings?
Thanks,
Mike
Yes I was more upset with the lack of performance of MT than what UBNT did against the specs that were talked about. I'm not sure what settings you are looking for UBNT or MT, but MT is running the configs that are on the MT site. Most importantly, it's running Nstream, as without, throughput was ziltch. We have a fair amount of N transmitters in this residential area. The only thing to note on the UBNT side is that we have gotten more consistant speeds with a fixed ACK timeout. We are also testing with station WDS, as this let's us keep the routing in MT, where we are comfortable with the OSPF implementation to date. We are very disappointed on the MT performace as others have been posting speeds right at 100mb/s
Keep in minds, my 22 mile link has been the first opportunity for UBNT to test long haul type N out.
One thing I suspect the developers might work on taking out the default 17 mile limit for 40 MHz channel width. And no, its not changeable in the cfg file, already tried that. If I had been able to set it to at least 22 miles, the radios might have had the opportunity to connect and settle things out.
Another thing is the way UDP and TCP is processed. We, as in Rory and me, are seeing some odd things. It might be a firmware problem. Mike is working at new firmware at his end.
A friend of mine in Germany emailed me asking for clarifications, let me repost that:
Thanks for somewhat clarifying to me and to the forum members. The reason I assumed you meant MB, or the reason I just stated "somewhat", is because I believe the info is still written falsely. I'll try to explain...
Your Qoute:
"Nevertheless, 2.4 Mbps connected to a 5 Mbps DSL line 22 miles away is fine with me"
This is what threw me the curve ball. Now I am assuming you meant 24 Mbps and not 2.4Mbps...
I also assume this because of your new post:
"The 24 Mbps was referring to the FTP speeds, not the data speeds."
I should have been more clear on that. When I communicate with Mike and Rory, they already know what I'm working with and I leave out a lot of "givens" that other readers may not understand yet. There are still a lot of bugs to be worked out to make an apples to apples comparison. I have a Mikrotik server at the other end that I can pull off linw and put it in the backhaul link, and put another Mikrotik at the head end. That might give us more and better tools to work with.
Again, this is a very long haul link that was unheard of a year ago. The developers may not have realized the potential of the Bullet 5M for this application and not optimized some things.
Aside from the "...DOUBLE SECRET..." feature (to paraphrase Dean Vernon Wormer - "Well, as of this moment, they're on DOUBLE SECRET PROBATION!" - Animal House, 1978) that I haven't been able to discuss, there is one more special feature that is really gonna knock yer socks off (assuming you're not from California where people don't wear socks).
If you have a 10 Mbps DSL connection and send it to a user over wireless, they will have a 5 Mbps internet browsing experience.
That's incorrect. If you have a 10 Mbps DSL connection and send it over a 30 Mbps (TCP) wireless link then the user will have a 10 Mbps internet browsing experience.
The experience decreases only where the wireless link is the bottleneck.
Yet once again, you have attempted to prove me wrong with an incorrect or unwarranted assumption.
No, Ron...I am not incorrect. If I have a 10 Mbps DSL with a 10 Mbps data speed, the end user will experience a 5 Mbps internet experience.
Now of course you will argue that I never said I was using a 10 Mbps data speed, likewise I never said I was using 30. So why did you erroneously assume that?
If you had kept up with my post where I have used the phrase "end user internet experience" you would see I qualified my data speeds.
drwho17
08-09-2009, 04:24 AM
Hrm, I'm not sure where this 5Mbps end user experience on a 10Mbps backhaul theory is coming from. I'm using G.SHDSL.BIS loop bonding at a few towers, and I can get pretty much the wirespeed to a wireless client if I don't shape it.
The one I'm on right now has 4 loops at 2.5Mbps, for a 10Mbps EFM bond group. I can hit 10Mbps on ethernet, and 10Mbps with a 10mhz channel width client through the access point using Bullet2HP AP to PS2. The wireless user (IE ME) is getting a 10Mbps experience on a 10Mbps loop.
NielK
08-09-2009, 10:35 AM
Doesn't this really depend on what you normally do when you connect to the Internet?
We know that the wifi link is half-duplex. For example, I have a 4 mile wireless link that runs at 17 Mbit/s one-way TCP throughput (i.e. if I run IPERF in one direction only). Running bi-directionally (IPERF running in both directions simultaneously) gives 8.5 Mbit/s TCP throughput in both directions.
My normal Internet experience is dominated by data travelling down to me from the Internet, with relatively little going back up. So for my normal use, my wireless link feels like a 17 Mbit/s Internet connection.
If I did a lot of two-way transfers (HD Video conferencing anybody?), it would feel like an 8.5 Mbit/s Internet connection.
Hrm, I'm not sure where this 5Mbps end user experience on a 10Mbps backhaul theory is coming from.The wireless half-duplex thing as it applies to an AP to CPE connection.
drwho17
08-09-2009, 11:13 AM
Hrm, I'm not sure where this 5Mbps end user experience on a 10Mbps backhaul theory is coming from.The wireless half-duplex thing as it applies to an AP to CPE connection.
It's not a typical end user experience to simultaneously upload and download synchronously at the same time. A typical internet end user experience is to download with small upload acks for TCP throughput, leaving the real throughput at nearly the full 10Mbps, hence the end user experience is 10Mbps.
Strictly speaking the max is 10Mbps of TCP throughput 1 way obviously, however in reality that limit is also what the end user experiences in their internet experience. Especially given the fact that I traffic shape all connections at the termination device to basically a 5 to 1 download/upload ratio.
Dave-D
08-09-2009, 11:14 AM
Sorry if this is off-topic; I can't quite remember the topic.
Another WiFi product I use has an asymmetrical setting
for the transmit-receive time. The effect is to 'tune' the
circuit for the common scenario where the client has
much more download traffic than upload.
I think that product offers only 1:1 and 2:1, but I assume
there could also be 3:1, 4:1, 5:1 and so on.
Does this make sense for Bullets used in a CPE setting?
It seems to me it could greatly improve thruput. Dave
kijoma
08-09-2009, 01:22 PM
hi,
the throughput improves if the data is asymmetric anyway.. if there are only ack packets going back then the ack return time is faster so one way throughput is at its max..
if traffic is loaded equally both ways then the speed each way will drop accordingly..
you can change the "rate" parameter, this affects the TX speed, absolutely no benefit in reducing it unless you want to lock a set speed/prevent rate changes or have a low signal scenario.
Dave-D
08-09-2009, 01:47 PM
I'm not sure I have this right, Bill.
I've been assuming that the half-duplex schedule
consists of equal, alternate windows. If so, the
number of bits available per unit time is the
same in each direction.
The typical (very asymmetric) traffic scenario is:
...client sends a URL (from a browser)
...client receives Website contents (Kb to Mb)
...client responds with keyboard or mouse data
...client receives more Website contents/pages
This is not just ACK, which is insignificant traffic.
In that case, the client-to-host (browser to Internet)
traffic window will be almost empty, while the host-
to-client window will be very busy.
If we can 'tune' the timing so the inbound window is
larger than the outbound one, that would greatly
improve inbound traffic speed, because more bits
are available. Even better, if there's some kind of
buffer priority, as soon as the outbound buffer is
empty, the inbound traffic gets the path back.
If this isn't the case, then why would the other vendor
provide asymmetric traffic control in the first place?
I believed the 'TX' parameter must be the same on
both ends, and is used to improve path quality by
limiting data speed for a particular bandwith. Dave
kijoma
08-09-2009, 02:05 PM
hi,
your assumption is incorrect i believe.. if all there is to send back is an ack then the packet length will be just that plus any 802.11 overhead..
The TX rate can be asymmetric to the RX rate on most radios, sometimes this can be advantageous..
It's not a typical end user experience to simultaneously upload and download synchronously at the same time.I am using it in the sense what an internet user would experience on the speed a web page loads on their computer.
Dave-D
08-09-2009, 02:54 PM
In my ignorance, I've gotta make a stab:
This is my guess about AirMAX: it's a strategy for
handling bandwidth by managing traffic flows. Of
course, that includes QoS; so it will be an
implementation of IEEE 802.11e.
Call it 'intelligent spectrum control'. And it might
even include a spectrum analyzer.
If that's the case, I was more or less right about
the fixed framewidth/turnanround issue. And I
would no longer be right.
How's that for ignorance? Dave
Internet traffic is bandwidth asymmetric, but usually have the same amount of pps (packets per second) going upstream and downstream. As Wi-Fi is mostly pps limited, there is no point in defining a TDD ratio like WiMAX have.
I wonder though if 802.11n packing can change that assumption; I still think it doesn't, but some real testing is required.
davey
08-10-2009, 07:23 AM
This is my guess about AirMAX: it's a strategy for
handling bandwidth by managing traffic flows. Of
course, that includes QoS; so it will be an
implementation of IEEE 802.11e.
That would be nice. I always liked the idea of Trango's SmartPolling, which included bandwidth management at the MAC level - sequential adaptive polling allowing setting of CIR and MIR and giving more frequent polls to active clients. If they had combined it with an 802.11a radio, rather than 802.11b up-converted, it would have been a killer system.
Dave-D
08-10-2009, 12:39 PM
Internet traffic is bandwidth asymmetric, but usually have the same amount of pps (packets per second) going upstream and downstream. As Wi-Fi is mostly pps limited, there is no point in defining a TDD ratio like WiMAX have.
RKJ, I don't know how you made these conclusions.
My client point-to-point link via 802.11 is Internet traffic, and
it definitely does not have the same packets number of packets
or bits going both ways. Nearly all of the traffic is inbound.
And because WiFi is 'pps limited' (or rather bandwidth limited),
there is a large value in defining a 'TDD' ratio. It's simply a
balancing act between the inbound and outbound streams. Dave
Internet traffic is bandwidth asymmetric, but usually have the same amount of pps (packets per second) going upstream and downstream. As Wi-Fi is mostly pps limited, there is no point in defining a TDD ratio like WiMAX have.
RKJ, I don't know how you made these conclusions.
My client point-to-point link via 802.11 is Internet traffic, and
it definitely does not have the same packets number of packets
or bits going both ways. Nearly all of the traffic is inbound.
And because WiFi is 'pps limited' (or rather bandwidth limited),
there is a large value in defining a 'TDD' ratio. It's simply a
balancing act between the inbound and outbound streams. Dave
If you read the RFCs describing the TCP protocol you will see where that is coming from. You are probably not measuring packets per second in your interfaces, only bits/bytes per second. Monitor the right variables and you will see what I'm talking about. Remember that IEEE 802 networks like Ethernet, Wi-Fi and WiMAX have variable packet sizes, so the same amount of packets per second may not give the same amount of bytes per second. That is dependent on packet size distribution, and that is totally different by direction.
Also, if you do RFC-2544 testing on your Wi-Fi radios, you will see that the perform poorly bandwidht-wise for small packets, due to the packets per second limitation. Iperf and similar tests will only tell you large packets performance, which is far from the whole story of Internet access.
Dave-D
08-10-2009, 03:28 PM
RKJ, I think I see your theoretical point.
And I agree there 802.11 strategies for dealing with channel
use aren't always optimal.
But i could care less about packets--it's the number of data
bits transported that determine the channel payload.
If outbound traffic is small, I'd like to be sure that the channel
is allocated more to inbound traffic. It's that simple. How this
can be done and whether it's partly automatic, I don't know.
I assume that the asymmetrical ratio one of the equipment
providers offers is one tool to control inbound/outbound
allocation, to improve channel payload. Dave
Guys,
Did a bench test and managed stable 70 mbps in one direction, with peaks of 87 mbps
and stable 45mbps fdx, this was using solarwinds wan killer.
I trust this tool to be very exact and with the variability to try the units
at different packet sizes.
today will test the units on a 18 mile link.
Regards
Guys,
Did a bench test and managed stable 70 mbps in one direction, with peaks of 87 mbps
and stable 45mbps fdx, this was using solarwinds wan killer.
I trust this tool to be very exact and with the variability to try the units
at different packet sizes.
today will test the units on a 18 mile link.
Regards
What is the performance with smaller packet sizes ?
namery
10-15-2009, 06:20 AM
can someone help. i ahve in my office two rockets 5M separate about 3 meters, the connection as you can suposed, perfect the rate are 300Mb/s sometimes 270Mb/s when i make a ftp it is only 30Mb/s maximum. what i make wrong?
i change the distance now is around 10m but still i have the same result.
