Archive for July, 2010

solving real-world problems with OpenAMD

Thursday, July 8th, 2010

This is OpenAMD: http://amd.hope.net/frequently-asked-questions-faq/ It’s a cool “hacker” project, but I think it can actually be used to solve a number of real-world problems. Small, common problems that attendees of a conference have.

Problem #1: quickly and easily looking up information about the person next to you, in parallel with talking to them. Ideally silently and covertly, but the HUD is not yet available :)
Implementation #1: use the location API, figure out which is you, figure out which other has minimum distance, display all info about that one. Perhaps do this in real-time, so you should get an updated view when a new person walks up to you. And you can probably do this on your smartphone or on your laptop.

Problem #2: find a particular person
Implementation #2: this one should be pretty easy, you just need their uid, and you query their current coordinates. However, the grid coordinates might not be so human-readable, so a directional arrow would be nice. For even more icing on the cake, display their historical path, so you can guess which direction they’re moving.

Problem #3: finding a person by real name or other attribute (zip code?) This is an extension of #2. Use case: you know your friend Dave is there, but you’re not sure where he is. How do you find his tag’s uid? Hopefully you can query just by name or handle to get the uid.
Implementation #3: sounds like you’ll have to query a separate database of metadata to see if you can identify the uid of the person based on the information that you have

iperf heuristics

Thursday, July 1st, 2010

Iperf is an excellent tool to test your network performance. But it’s also a good troubleshooting tool: run iperf and see if the results “feel” right.

There are two problems I’ve been able to diagnose using iperf. One was a performance problem with a NIC driver. Take two new machines connected by a gigE switch, and run iperf between them. You should get very close to wire speed. If you don’t, it’s worth investigating. In my case, I was getting ~650 Mbits instead of the expected ~980 (among other problems). After fixing the problem (in this case, upgrading NIC driver), iperf showed close to wire speed as expected.

Another time, there was what turned out to be a problem with a switch. It was a gigE switch, and single iperf streams were fine, ~950Mbits between two machines. However, having one machine as an iperf server and starting up several iperf clients showed much lower aggregate throughput. Another thing I noticed was that the throughput was not evenly split between nodes. After a lot of other troubleshooting (kernel settings, NIC drivers, switch config) replacing the switch with a different one and re-running iperf showed even distribution of performance, e.g. ~100Mbits for each of 10 clients, with an aggregate of ~1Gb at the server.

I use something like ‘iperf -s -w 512K -l 56k’ and ‘iperf -c head -i 3 -t 120 -P 16′.