I sit here and posit a response to your flame bait. "Prune juice"? Too funny, and the expletives are landing like mortar fire now. Your message seems... emotional.
In specific response, I did posit some about the requisite antenna gain(s), transmit powers, etc required to close the link(s).
The 'protocol' isn't going to matter much. I know whats possible with a TDM implmentation on top of the Atheros chipset (I've seen 5km links doing 70Mbps of actual data throughput. Getting to that requires a lot of work, and no, before you ask or imply, this isn't my implementation.)
So I went digging in your product line some. One 802.11 a/b/g card you carry has rx sens specs listed as:
54 Mbps OFDM - 73 dBm; 48 Mbps OFDM - 76 dBm; 36 Mbps OFDM - 82 dBm; 24 Mbps OFDM - 85 dBm; 18 Mbps OFDM - 88 dBm; 12 Mbps OFDM - 89 dBm; 9 Mbps OFDM - 90 dBm; 6 Mbps OFDM - 91 dBm;
The customer said they'd locked the radios at 24Mbps, so we'll use that as a modulation rate, and note that even though your card is listed as "100mW" (20dBm) tx power, by 24Mbps, you've had to "back off" the PA some due to PAPR issues. Not much, mind you, but some. Perhaps -1dBm. This isn't going to matter much in our link budget calculations, but your product documentation is slightly flawed for not mentioning this backoff.
LOS (assuming that you have LOS) path loss at 2.4GHz over 50km is 135 dB. At 5.7GHz this increases 7dB for 142 dB.
So we're sending 19dBm, have at least 135 dB of path loss, and can decode with acceptable frame loss at a signal level of -85dBm at the other end. We need 31 dB of gain, plus some additional gain to 'make' up for any cable losses, allow for a fade margin, etc. Lets guess at 2dBm of IL in each end due to cable losses, connectors, etc. And give ourselves a 10dB "fade margin".
So we need 14 dB more gain in the system, for a total of 45 dBi of antenna gain. This is 'only' 22.5 dBi per end, so it works.
Note that going to 5.7GHz will require 7 dBi more (so 3.5 dBi per end), plus some to allow for the higher IL at 5.7GHz. Call it 5 dBi more gain per end just to be safe. Now we need a 27.5 dBi antenna at each end.
Either of these systems complies with the FCC EIRP rules for PTP operation. (I don't know that the customer who locked their cards at 24Mbps is operating under these rules (unlikely, given that they express distance in km), but this is the SoCal list. That doesn't mean they're *legal*, because putting this much antenna gain on an Atheros (or, frankly nearly any other WiFi card) without a lot of additional engineering will result in out of band emissions that are above the legal limits. (The gain of the antenna will raise the sidelobes on the signal, too.)
BTW, your datasheet also has this little tidbit:
802.11b/g: DSSS (DBPSK, DQPSK, CCK),
OFDM for data rate >20 Mbps
forgetting of course that the OFDM rates listed in the table on the same page (correctly) specify OFDM for all of the non-11b rates.
BTW, maximum theoretic TCP performance over a 24Mbps link (assuming no SIFS-related issues, 0 packet loss, only one other station, etc) is 10.84Mbps (max UDP for the same 'theoretic' link is 13.55Mbps). Your customer reports "15-19Mbps UDP and 10-16Mbps (TCP)", so the gains you've achieved, while respectible, aren't that far off what a pure DIFS-based CSMA/CA 802.11 system could do (in theory). Readers who want to see whats possible (though still 802.11 based) might wish to read over http://www.super-g.com/atheros_superg_whitepaper.pdf (although this paper does contain some misleading statements about simultaneous operation.)
Yes yes, there is is a lot of difference between 'in theory' and " in the real world". I grant you that before you respond.
Everyone interested in the subject should know that the Atheros chipsets support a compression mode these days, so random data' (or better, pre-compressed data) is the best path toward a meaningful benchmark.
And, btw, I'll stack my "clue" against yours anyway. I'm ready for a round of "Wireless Jeopardy" in front of a live SOCALWUG audience, are you?
jim
John Tully wrote:
Jim,
The fact that you will write so much about a paragraph that has very little information about the frequencies, antennas, details on protocol, and so on, shows that you are sloppy and ready to spew shit without having a clue.
Get some prune juice and start again!
John
At 03:54 PM 10/5/2004, you wrote:
Oh, this is rich. I read a little bit of one of the links provided:
http://www.mikrotik.com/forum/viewtopic.php?t=9&highlight=nstreme
> Note: We only let our radios go to 24Mbps in order to improve link
> stability (might be better now that we are running 2.8.10 (will try
> 36Mbps and higher tonight)).
>
> We are seeing about 15-19Mbps UDP and 10-16Mbps (TCP) across each of
> 4 50km+ links running nstreme. This is a BIG improvement per link.
> However, when we run test traffic across all 4 router links we only
> see 5-6Mpbs TCP. However the UDP numbers are still around 15Mbps. Our
> routers are 1GHz processors, 128Mb RAM with 2 or 3 wlan cards in each
> so power should not be a problem. I will run some more tests tonight
> and pay attention to processor utilization while I do it.
>
> Any ideas why the routers slow down with TCP when passing traffic
> from link to link?
>
> Thanks, Ken tully Veteran Veteran
>
>
> Joined: 28 May 2004 Posts: 257
>
> PostPosted: Wed Jun 02, 2004 9:17 am Post subject: Reply with
> quote There is no need to restrict the higher rates of 802.11. There
> is an algorithm that calculates which rate will produce the highest
> throughput even with lost frames and such. Packets will never be lost
> unless the quality at the lowest rate is so bad that the client will
> be unregistered.
>
> One session of TCP will never use the full throughput of a link. Many
> multiple sessions of TCP will get close, but a UDP bandwidth test
> will give the accurate number.
>
> John
Wait, they've got 4 radios on each end. They get 15-19Mbps over UDP (which is it?) and 10-16Mbps (TCP) (again, which is it?)
But when they turn *all* the radios on.. presto, speed drop.
Tully blames it on some kind of undocumented lack of efficiency in TCP, but the real problem is... packet loss. TCP reacts rather badly in the face of a lossy link. Turning up the other links means that more packets are smashed, so TCP closes its window.
This is such a well-understood phenomena that it wouldn't even qualify for a senior year research project anymore.
Note that UDP isn't unaffected, the "15-19Mbps" is now "around 15Mbps".
Hello, this is a 25% reduction in throughput. Likely 25% or greater packet loss from "2 to 3 wlan cards". Wait, I thought there were "4 links".
And, btw, packet loss is *assumed* in wireless networks. Ever wonder why rx sensitivity (and lots of other parameters in 802.11) are calculated at some errored frame (or bit error) rate?
The algorithm is "rate fallback", and these are notoriously difficult to get right. The tuning for benchmarks (max throughput) is not quite what you want for the real world (more emphasis on reliability, which tends to translate to an algorithm that is less agressive about seeking the higher modulation rates.)
The other interesting side effect, of course is that as the modulation rate goes down, the capacity of the link goes down. If you've got more than one 'client" on the link (say, a MPTP system), then your slower clients take up more of the "capacity" of the cell.
I won't go into the "capture" issues here.
And then there is this:
We have removed NStreme from all of our routers until the winbox interface is available. We found that even though single links were very fast the routers (routerboards) could not keep up with the traffic. 4 links that were about 10-16Mbs (TCP, 50km) each would only yield 3-5Mbits of TCP through put. I tried many connections and could not get anything higher. I would LOVE to have a 10Mbs total throughput connections along these 4 routers but so far we get better total performance without NStreme.
likely that before the "close by" radios were prevented from transmitting because the RSSI of any one outbound packet was high enough to set CCA in the other radios.
I find it likely that some "programmer" at Microtik set the CCA threshold down, and this combined with the (should I say 'obvious'?) TDMA protocol ("NStreme") yeilds some really hairy co-interference issues.
But we've been over that, and I said I wouldn't talk about it any more.
I am nearly entertained.
Jim
