John Navas <spamfilter0@navasgroup.com> hath wroth:
>On Sat, 24 Mar 2007 17:47:47 -0700, Jeff Liebermann
><jeffl@comix.santa-cruz.ca.us> wrote in
><92hb03df9lt2ar4k2ism0gt41kr0gi4ubj@4ax.com>:
>
>>dold@05.usenet.us.com hath wroth:
>>
>>>John Navas <spamfilter0@navasgroup.com> wrote:
>
>>>> measurements. My preference is to use a radio with good real-time
>>>> signal monitoring capability.
>>>
>>>I don't bother installing manufacturer client software, if that's what you
>>>mean. I think perfmon is adequate, and it's already there on WinXP, not
>>>something that has to be added, learned, or preferred.
>>
>>No opinion, but I have an alternative. At a given signal strength,
>>thruput and speed are inversely proportional. If I lock down one,
>>signal strength becomes proportional to the other. Instead of
>>measuring signal strength, which tends to be rather erratic, I like to
>>measure thruput. I lock the speed to 54Mbits/sec, ignore the signal
>>strength, and measure megabits/sec thruput using Iperf.
>><http://dast.nlanr.net/Projects/Iperf/>
>>
>>I don't really know if this is the superior method, but it does have 2
>>advantages:
>>1. It does the measurement with traffic. ...
>>2. It takes into consideration any interference and reflection
>>effects. ...
>>
>>On the down side, it's kinda hard to make pretty looking antenna
>>patterns using data rate instead of signal strength. Oh well.
>Another downside is that it doesn't tell you much that's useful,
I beg to differ. The conventional method of measuring signal strength
and SNR are usually done with NO traffic moving on the networks. All
that will tell you is if the link is capable of delivering the
expected data rate, not whether it actually does. For example, the
presence of interference might affect the SNR, does not affect the
signal strength, and will seriously affect the thruput. The measure
of thruput (at a fixed connection speed) as compared to what might be
expected, is a great indication of how well and how reliable the
system will be. For example, if I lock the wireless data rate to
54Mbits/sec, and my IPerf benchmark yields 25Mbits/sec, I can safely
say that everything is working. However, if I get considerably less
than 25Mbits/sec, I would go looking for retransmissions,
interference, or a sick computah. You don't get such clues from just
the signal strength and SNR.
In addition, today's modern all digital chipsets do not really measure
the IF (intermediate frequency) analog signal strength as they did in
the daze of Prism 1 chipsets. There's simply no analog signal
available to measure. So, they fake it using the error rate for SNR
and the thruput for signal strength. It's actually a fairly good way
to do it if the manufacturer adheres to the reference design. If not,
the conversion factors need to be calculated for the specific
implementation.
Nice article on "Understanding WLAN Signal Strength":
<http://www.gwec.org/students/resources/Files/Understanding%20WLAN%20signal%20strength.pdf>
She doesn't cover the conversion problem, but does cover the basics
and supplies a good list of WLAN tools.
>much
>like diagnosing a car problem just by seeing how fast it will/won't go.
Oh, like a dynamometer? That's exactly how it works. Floor the pedal
almost to the metal, and supply some frictional resistance on the rear
wheel rollers. The amount of resistance is a measure of delivered
horsepower at a given RPM. The lack of wind resistance makes
extrapolations such as gas mileage a problem (which is why the sticker
MPG is always higher than reality). However, it's really good for
troubleshooting engine and drive train problems.
>If you find the car won't go over 35 MPH, you still have no clue as to
>why.
Sure I do. If I limit myself to only using speed as a criteria for
performance, I certainly will have no clue. However, the
instrumentation offers considerable other useful input. For example,
acceleration, gas mileage, weird noises, smoke out the exhaust,
operating temperature, etc.
>That's part of why I'd rather look at the actual data, just as
>I would with a car, instead of just measuring data throughput.
Using performance parameters to troubleshoot automobiles and wireless
systems are very similar. The only real difference is that with an
automobile, you can usually see, hear, smell, and otherwise sense
performance parameters. With WLAN, you can't see RF, so you gotta use
test equipment. WLAN is kinda like auto repair for the blind, but it
works.
>Another
>part is that throughput can be adversely affected by things other than
>the wireless connection; i.e., there is no real test control.
True. If I were preparing results for a data sheet that proclaims the
merits of my technology, I would use an RF anechoic chamber, perfect
antennas, and properly calibrated test equipment. Nothing but perfect
is good enough. The idea is to make it reproducible as well as
yielding the best possible numbers.
However, I don't know anyone that lives in an RF anechoic chamber or
that cannot detect at least one neighbor with a 2.4Ghz wireless
emitter (cordless phone, microwave oven, wireless video, etc). The
ability of the system to function (and survive) in such an environment
is probably as important as the maximum theoretical thruput. I'll
concede that it's probably not reproducible, but neither is reality.
Which would you prefer:
1. I set the speed to automatic and take a walk measuring the signal
strength and SNR. I inform the customer that 6dB signal strength is
good for a 2x increase in range.
2. I lock the speed to 54Mbits/sec and take a walk while downloading
some giant file and measuring either thruput or PER (packet error
rate). I draw a curve of the thruput versus distance at 54Mbits/sec.
The drop off should be quite abrupt. I repeat the test for other
wireless speeds.
The first is what you recommend and the way it's done today by most of
the wireless industry. The 2nd is the way I think it should be done.
Which do you think is more useful?
Maybe I should go back to working on my taxes...
--
Jeff Liebermann
jeffl@comix.santa-cruz.ca.us
150 Felker St #D
http://www.LearnByDestroying.com
Santa Cruz CA 95060
http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558