From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 3 21:15:22 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1727216A46E; Sun, 3 Feb 2008 21:15:22 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 360B713C459; Sun, 3 Feb 2008 21:15:21 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47A62EE8.2000700@FreeBSD.org> Date: Sun, 03 Feb 2008 22:15:20 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Stefan Lambrev References: <4795CC13.7080601@moneybookers.com> <4795FE54.9090606@moneybookers.com> <86lk6i0vzk.fsf@ds4.des.no> <479605E2.6070709@moneybookers.com> <47964356.6030602@moneybookers.com> <479647FB.3070909@FreeBSD.org> <47970EE2.5000400@moneybookers.com> <479754E6.1060101@moneybookers.com> <9bbcef730801230802n5c52832bk60c6afc47be578f4@mail.gmail.com> <47976AD4.3020203@moneybookers.com> In-Reply-To: <47976AD4.3020203@moneybookers.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Ivan Voras Subject: Re: gettimeofday() in hping X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2008 21:15:22 -0000 Stefan Lambrev wrote: > I run from host A : hping --flood -p 22 -S 10.3.3.2 > and systat -ifstat on host B to see the traffic that is generated > (I do not want to run this monitoring on the flooder host as it will > effect his performance) OK, I finally got time to look at this. Firstly, this is quite an inefficient program. It performs 5 syscalls for each packet that it sends: 2391 initial thread CALL sendto(0x3,0x61b050,0x28,0,0x5232c0,0x10) 2391 initial thread GIO fd 3 wrote 40 bytes 0x0000 4500 2800 7491 0000 4006 0000 0a00 0004 0a00 0001 3a96 0016 1865 a781 39d8 12aa 5002 0200 52c9 |E.(.t...@...........:....e..9...P...R.| 0x0026 0000 |..| 2391 initial thread RET sendto 40/0x28 2391 initial thread CALL sigaction(SIGALRM,0x7fffffffe6b0,0x7fffffffe690) 2391 initial thread RET sigaction 0 2391 initial thread CALL setitimer(0,0x7fffffffe6c0,0x7fffffffe6a0) 2391 initial thread RET setitimer 0 2391 initial thread CALL gettimeofday(0x7fffffffe680,0) 2391 initial thread RET gettimeofday 0 2391 initial thread CALL gettimeofday(0x7fffffffe680,0) 2391 initial thread RET gettimeofday 0 Here is a further litany of some of the ways in which this software is terrible: * It does not attempt to increase the socket buffer size (as we have already discussed), but * It also doesn't cope with the possibility that the packet may not be sent because the send buffer is full. * With every packet sent in flood mode it sets a timer for 1 second in the future even though we have told it not to send packets once a second but as fast as possible * We also set the signal handler with each packet sent, instead of setting it once and leaving it. * We call gettimeofday twice for each packet, once to retrieve the second timestamp and once to retrieve the microseconds. This is only for the purpose of computing the RTT. However, we can only keep track of 400 in-flight packets, which means this is also useless in flood mode. * The suspend handler does not work * This does not strike me as quality software :) Fixing all of the above I can send at about 13MB/sec (timecounter is not relevant any more). The CPU is spending about 75% of the time in the kernel, so Kris