i suspect there is some ipsec internal bottleneck there. with an other long-running test we were not able to push more then 40Mbyte/s over the net, and cpu did not max out. there were no massiv kernel threats and disks were far from their limit.
can someone with more insight into ipsec explain what happens? this is an importan point. we need to get more performance (about twice as much) out of these boxes then this. On Tue, Dec 29, 2009 at 2:55 AM, Andreas Schuldei <[email protected]> wrote: > so i configured ssh to bypass ipsec, set up ssh to use blowfish > encryption and set up rshd on the test machine (which gave me > goosebumps). > > r...@krista:~# time rcp bigfile teagan: > > real 0m8.738s > user 0m0.008s > sys 0m7.188s > r...@krista:~# time scp bigfile teagan: > bigfile > 100% 325MB 65.1MB/s 00:05 > > real 0m4.945s > user 0m3.716s > sys 0m0.980s > > there is a real chance that rcp sucks on the security AND the > performance level. so i retried with http (apache and wget): > > 100%[=====================================================================================================>] > 341,218,664 36.8M/s in 8.8s > > 2009-12-29 01:53:20 (37.1 MB/s) - `bigfile.1' saved [341218664/341218664] > > that is the same result. i use a heavier cipher for ipsec then for ssh: > > AES_CBC-128/HMAC_SHA1_96, rekeying in 92 seconds, last use: 136s_i 145s_o > > what ciphers are faster that i could use? is it plausible that AES is > that much slower then blowfish on an idle server with an up to date > xeon cpu? these servers are connected to each other via a switch. > > /andreas > _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
