[netstat -s diff] That looks mostly ok. I ask for netstat -s diffs because there are a lot of useful counters for error cases, and if some of those are incrementing it really helps to notice. In your case the only value that jumped out at me was that there were 30 more out-of-order packets received. That's not a huge number out of receiving 15000 packets, and not really cause for concern. One thing to figure out is the reason for the lack of full speed. TCP is highly sensitive to loss. So while this may end up being too complicated for you, the best path to really understanding what's going on is to first find a way to download a large file so that you don't rely on a speed test that you can't understand. Using the built-in ftp(1) and some free software mirror that's near you (use traceroute) is a good plan, to avoid problems farther out in the internet. Then, use 'tcpdump -w' to save a trace from the WAN-side interface on your router to a file. Then, install pkgsrc/math/xplot and read the documentation (in the source more than the installed package) for tcpdump2xplot. Basically, this takes the tcpdump of the TCP session and turns it into a graph, from which you can infer missed packets, out-of-order packets, and retransmissions. You can then see if a rate below what you expect is steady or bursty. Also, I concur Thor's advice to use the fxp0 interface instead of vr0. You might try all three on the WAN side, suing ftp(1) to measure each one. Keep careful notes, and refrain from assuming there is only one issue. Finally, if you're getting 30 Mbps on a TCP stream, that's likely all you'll get to someplace you actually want to talk to on the Internet anyway, because of congestion in the core.
Attachment:
pgpIUsH_Be9F2.pgp
Description: PGP signature