> - scp directly: avg 3.3 MB/s -- tests ssh and ramdisk i/o > - scp via OpenVPN: avg 1.8 MB/s -- tests ssh, openvpn, and ramdisk i/o > - netio directly: 100 Mbit saturated -- tests network stack only > - netio via OpenVPN: 2.6 MB/s TX, 3 MB/s RX -- tests network stack and OpenVPN > - iperf directly: 100 Mbit saturated -- tests network stack only > - iperf via OpenVPN: 1.75 MB/s -- tests network stack and OpenVPN
> Is it supposed to be that slow?! :-/ Depends on what you're trying to test. In each of these tests (direct netio & iperf excluded), you seem to have placed multiple loads on the machine since it served both as a test endpoint and the router - if that's wrong, then disregard the rest of this email. If you intend to use your 5501 as both a router and an endpoint for applications, then yes - your testing is probably valid and your numbers are probably right. A more clear test would be to watch the CPU utilization during these tests and see whether you are CPU bound or if there is some other limiting factor that could be tuned out. If, your intent is to use your 5501 as just a router, 2/3 of your tests are invalid (if not inaccurate), as they are 'dirty' - i.e. too many potentially contributing factors. To accurately test OpenVPN performance (or others with the same methodology), you need to have two test endpoints in addition to the 5501. One (and only one) would terminate an OpenVPN tunnel on the 5501, and you would run iperf and/or netio between it and the other endpoint that is connected via clear ethernet. The reason behind testing only one tunnel is that once you go beyond a single load per processor core, you start testing more of your kernel's performance (context switching, etc.) and less of the CPU's. That will give you a theoretical maximum to base evaluation of any further tests (multiple tunnels, etc.) from. Just remember - if you want to do accurate testing, focus on repeatability and eliminating (or limiting) extraneous factors that will affect your outcome, even if they are perceived (like ramdisk i/o) to be minimal in impact. Only test and change one thing at a time. _______________________________________________ Soekris-tech mailing list Soekris-tech@lists.soekris.com http://lists.soekris.com/mailman/listinfo/soekris-tech
