Example: Measuring the Rate of 802.11 Packet Capture and
Calculating the % Transmission Efficiency
When it comes to troubleshooting an 802.11 wireless network
measuring the rate of packet capture may be a more valuable
metric of the quality of 802.11 transmission / reception
than RF spectrum analysis because you are measuring the real
thing - i.e. performance throughput. Though this metric can
not distinguish between interference versus obstacles or
"dead spots" being the cause of poor performance, since
packet rates are measured then whatever improvements you
make to the system should directly translate to better
performance. This is very useful - network discovery tools
and spectrum analysis can not make the same claim.
Whereas WifiCopper is used to
inject wireless traffic, to complete this type of
measurement it is also necessary to employ packet capture
software. We've had success using AirPcap/Wireshark,
though other packet capture solutions are available -- e.g.
CommView for WiFi, and
OptiView® Network Analyzer. In the example
below we'll be using AirPcap/Wireshark
- that is, on one machine we'll run
WifiCopper (to inject 802.11 packets) and on a
second machine we'll run AirPcap/Wireshark
(to capture packets).
Figure 1 shows
WifiCopper running on the first machine where
we've set transmission on channel 13, injection rate to 80
packets / sec, and packet size to approximately 1500 bytes /
packet. We then press the 'Start' button and
WifiCopper begins transmitting packets using
these parameters.
On a second machine we run AirPcap/Wireshark,
configure packet capture on channel 13, and capture packets
for 60 seconds. This is shown in Figure 2.
Referring to the arrows, we see that 4703 packets were
captured over a 60 second interval (approximately 80 packets
per second). Furthermore, when we begin examining the
packet's fields we see the overall frame size of 1552 bytes
is close to the 1500 bytes we specified in
WifiCopper.
Next, in Figure 3, we learn more
about the packets that were transmitted by
WifiCopper. For example, we see the
transmission rate used by WifiCopper's
802.11 adapter was set to 1 Mb / sec, which is roughly
125,000 bytes /sec. Furthermore, 80 packets per second, each
1552 bytes in size, works out to 124,160 bytes / sec. So,
under these particular conditions where
WifiCopper's transmitting device and
AirPcap's receiving device were within a
few feet of one another with no obstruction between them, we
saw essentially no packet loss. However, when greater
distances are tested or obstructions introduced, then the
packet capture rate is significantly affected and declines
accordingly.
Finally, refer to Figures 4 and
5. WifiCopper
embeds a packet number near the beginning of the data field.
The data bytes are all hexadecimal 0xA5 -- however, data
byte numbers 9,10 are the packet number as encoded by
WifiCopper. Packets are numbered
from [0,65535] and when 65536 is reached then it starts over
at '0'. That is, the 9th and 10th data bytes are not 0xA5
but, rather, a two-byte counter. Figure 4 highlights packet
number 4703, the last packet in the 60 second interval
during which packets were captured. We see that
WifiCopper embedded packet number hexadecimal
0x682F -- or decimal 26671. Figure 5 highlights packet
number 0, the first packet in our 60 second interval. And we
see that WifiCopper embedded
packet number hexadecimal 0x55CE -- or decimal 21966. The
difference between 26671 and 21966 is 4705 - that is,
WifiCopper sent 4705 packets
during the 60 second interval. Since AirPcap/Wireshark
captured 4703 packets, then we have nearly 100% transmission
efficiency. Turns out that due to the way
AirPcap/Wireshark numbers the packets, the
transmission efficiency is slightly over-stated. The 4703
packets reported by AirPcap/Wireshark
not only include the ones injected by WifiCopper
but also other packets transmitted on channel 13 by other
access points in the area. This number is dwarfed by the
number of packets transmitted by WifiCopper,
but it could affect the overall, computed transmission
efficiency by 1 or 2 percent.
|