How are these numbers?

Any particular reason you didn't bother supplying the hardware vendors and model numbers? Just curious why it should be a secret.

If you can get a 54Mbit/sec association at that range, though one wall, I'm impressed, especially if you happen to be using the stock antennas. Perhaps your unspecified hardware shows 54Mbits/sec when no data is moving, and much less when they're moving data.

You won't see anything. You're looking at IP layer 3 statistics. The retries are all on the MAC layer 2 statistics, which are not easy to extract from a Windoze machine. However, you get a clue as to the number of retries by simply using ping. Assuming your unspecified operating system is Windoze XP, try: ping -t 192.168.1.1 You should see *CONSISTENT* 1 to 2 msec latency returns, with no dramatic changes in latency, and no lost packets. If you do see these changes and losses, your system is experiencing come packet loss.

Argh. Windoze ping doth suck. Try fping instead:

which will show more accurate latency delays.

Also, after running ping for a while, and possibly seeing some losses, check your layer 3 stats with: netstat -e netstat -e -s My guess(tm) is despite the layer 2 packet losses and retransmissions, you won't see any errors on layer 3 (which is the way it should be).

If you're going to do some useful testing, you MUST move some data. No points for just providing the connection speed with no traffic. Download and use iPerf or preferably JPerf:

Tutorial:

Downloads:

If you want to see what information is useful, read some of the wireless tests and reviews on:

They use IXI Chariot (vedddy expensive), but in the past have done the same tests using iPerf.

Have a look at Wavemon [eden-feed.erg.abdn.ac.uk/wavemon/]. It builds a nice little histogram of wireless interface stats [as reported by the wireless driver], which I find useful when trying to site APs/clients.

Thx Jeff, Alex.

I posted quick, in a hurry, I know.

I am actually going to follow up with some better detail; thx to your links as well. (The OS is sometimes Windoze but often not), here is another copy/paste with some tran/rec info in it...

... UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1531972 errors:0 dropped:0 overruns:0 frame:0 TX packets:564738 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:651177416 (651.1 MB) TX bytes:176059236 (176.0 MB)

The fact that I don't seem to see any collisions, errors, etc, etc creates that warm fuzzy feeling, _but_ I'm going to do some metric capturing during a big download (like the Win7 RC; 2Gig).

berk

It's not a fact without data. Try the simple ping the router test I mentioned and see what happens. If the numbers are a consistent 1-2 msec, there's no packet loss. If the numbers are all over the place, you have packet loss. To get real numbers, you can either interrogate your unspecified model wireless router (some have MAC layer stats), or find a utility that shows the MAC errors on the client.

You've posted the layer two stats from the interface, not the layer one stats. Try 'iwconfig ...' instead.

Look fellas, despite the fact hat I'm an idiot, I was posting before scrambling out the door. (It seems to be a reoccurring symptom of this particular NG. Hmmmm.)

Lets see if third time can be the charm..... gathering data.

berk

Don't bust a gut doing it, I was just saying that looking at ifconfig for wireless data won't tell you anything, but iwconfig will.

As Jeff mentioned upthread, wireless stats are all well and good, but the proof of the pudding is in the pinging [or something else that tries to send data across the link, like iperf]. When doing a walk test, I reduce the ping interval [ -i whatever, or just -A if you're feeling clever] to get more instantaneous feedback on what's changing. Larger packet sizes [ -s 250, for example] are more likely to highlight loss on the link.