This serverfault answer has good high-level guidance on what to do - so start with that. That last step is a real doozy though: presumably you (I mean, me) don't want to invest in dedicated hardware for this...
Below are some good tools, first for understanding connectivity health within the local wifi network, and then to an internet endpoint.
Wifi Tools
It tracks the local WiFI APs and provides basic data like SNR, Channel, Signal Strength. It can also do a basic site survey for a physical space indicating strengths and interference. In the AP discovery mode, you can also chart signal strength over time, allowing you to test placements and adjust interference possibilities.
Very helpful. You'll run a simple python server on your machine and the app can test a few scenarios giving you realtime speed feedback.
Wifi Analyzer, another great android app, has a few valuable views of what AP wifi channels are active. Might be the best free tool for choosing AP channel without doing a lot of work.
Well respected tool for understanding local network performance. You need two boxes, one as server, one as client. You can set up a number of parameters, run a test, and see the results for bandwidth and jitter. I perfer using it with the jPerf GUI for charting results and tweaking parameters.
brew install iperf
iperf -s # on server, next one on client
iperf -c 192.168.1.XXX -P 1 -i 1 -p 5001 -f m -t 60
Internet Connectivity Health
mtr (ping & traceroute combined)
Pings all your traceroute hops. Provides trend data. Crazy awesome.
brew install mtr
mtr 8.8.4.4
The CLI version of the common ookla speedtest.net thing. The project maintainer declares it's not consistent, but still, it's handy to try to gauge large differences.
wget -O speedtest-cli https://raw.github.com/sivel/speedtest-cli/master/speedtest_cli.py
chmod +x speedtest-cli
speedtest-cli --list | head # and chose a top server (sorted by distance)
speedtest-cli --server 2761 # re-use the same server
NPAD : Network Path and Application Diagnosis
Automatic diagnostic server for troubleshooting end-systems and last-mile network problems. After running a battery of tests, gives a Result Summary page like this. I recommend using this NPAD server redirect link to find the closest NPAD server (they're all over) and using that hostname for your tests.
wget http://netspeed.usc.edu:8000/diag-client.c
cc diag-client.c -o diag-client
# ./diag-client <server_name> <port> <target_RTT> <target_data_rate_in_MB/S>
./diag-client ps.psc.xsede.org 8001 30 5
My personal results:
I spent a good few hours doing all this, trying different things (switching from DD-WRT to Tomato firmware) and reading. Turns out it wasn't network layer and was good old RF interference, mostly from Bluetooth! I had my computer, a bluetooth mouse and keyboard within 5 feet of the router. (And old router still on 2.4Ghz where they clash.)
For this, I got the most out of Wifi Speed Test for Android, running that regularly while I moved things around in the apartment. Since it reports updates every 200ms or so, it clearly communicated when interference was dropping my packets.
I definitely recommend reading the Common Sources of Interference guide from Metageek. (They also make InSSIDer and other Wifi analysis tools that seem good.)
One tool I didn't have was a physical spectrum analysis meter. Phones and laptops can only detect Wifi APs, but can't pick up on interference from Bluetooth or other RF-based technologies. Metageek has some nice solutions in this space (Wi-Spy and inSSIDer Office) and hopefully we see more tools emerge like AirShark.
What router and/or on-board router software are you using if it is not the stock install? – Jeff Clayton – 2015-01-03T19:25:36.627
@JeffClayton Linksys WRT54GSv2 (old-school) running Tomato (Shibby). Used to run DD-WRT but it's been buggy and confusing to maintain. – Paul Irish – 2015-01-03T19:46:33.717
Interesting yet familiar, I used to have a WRT54G as well, also running DD-WRT. – Jeff Clayton – 2015-01-03T19:51:11.530
1Do you have an actual problem or is this purely a cosmetic issue? WiFi routers are not generally designed to be super-fast ping responders, they have real work to do. – David Schwartz – 2015-01-05T09:42:49.653
Tools commonly used to diagnose Wi-Fi issues can actually cause this problem. When scanning for Wi-Fi networks the radio has to go off channel, typically it tells the AP to buffer frames for it so it can 'sleep' then switches channels to scan. – alfwatt – 2015-01-05T16:15:39.127
1@DavidSchwartz we should be able to complete a full roundtrip to a wifi AP in under 10ms, no? If your intra-wifi latency is above 500ms then EVERY PACKET you pull from the web/internet also suffers this latency. It's killer. – Paul Irish – 2015-01-05T19:58:34.610
1@PaulIrish All true, but that has nothing to do with ping times. Ping measures the sum of network latency plus the ping response latency itself. SoHo WiFi routers are not meant to be efficient ping responders, so using ping to measure network latency is not recommended. – David Schwartz – 2015-01-05T20:37:38.270