http://marc.info/?l=linux-kernel&m=126155699817914&w=2
but i dont understand what the bottleneck is. can someone help me out? On Tue, Dec 29, 2009 at 9:31 PM, Andreas Schuldei <[email protected]> wrote: > now i switch the cipher to blowfish. as a result the percentage the > server spends in the kernel went down to 3.5%-4.9%. my guess is that > this is due to the quicker cipher. > the apache process which is serving the file, however, bounces > between 20-95% cpu usage. how come? how does ipsec change user-space > so that the application needs more cpu? > the used bandwidth is even worse then before: the server manages to > push only 27.9M/s, which is slightly more then a quarter of its rated > network throughput. > > i cant see any bottelnecks in the server (like 100%cpu somewhere, > swapping because of full RAM, etc). > > i start to suspect package fragmentation, windowsize/flow control or > similar issues. are there /proc or /sys files to look at to get more > information about such issues when doing ipsec? tcpdump is less > helpful. > > btw: this is what i get when tcpdumping: > > 20:25:03.313692 IP 78.31.14.86 > 78.31.14.93: > ESP(spi=0xc929dbe8,seq=0x100a8c), length 1476 > 20:25:03.313699 IP 78.31.14.93 > 78.31.14.86: > ESP(spi=0xc4967810,seq=0x7bcd3), length 68 > 20:25:03.313734 IP 78.31.14.86 > 78.31.14.93: > ESP(spi=0xc929dbe8,seq=0x100a8d), length 1332 > 20:25:03.313788 IP 78.31.14.86 > 78.31.14.93: > ESP(spi=0xc929dbe8,seq=0x100a8e), length 1476 > 20:25:03.313812 IP 78.31.14.93 > 78.31.14.86: > ESP(spi=0xc4967810,seq=0x7bcd4), length 68 > 20:25:03.313847 IP 78.31.14.86 > 78.31.14.93: > ESP(spi=0xc929dbe8,seq=0x100a8f), length 1476 > 20:25:03.313887 IP 78.31.14.86 > 78.31.14.93: > ESP(spi=0xc929dbe8,seq=0x100a90), length 1332 > > why the odd package size? MTU is 1500. there seems to be plenty of > space. this is ONE huge file transmitted via http. > > On Tue, Dec 29, 2009 at 5:34 PM, Andreas Schuldei > <[email protected]> wrote: >> 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
