From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 3 21:16:15 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 D27C116A420; Sun, 3 Feb 2008 21:16:15 +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 BE7A413C457; Sun, 3 Feb 2008 21:16:14 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47A62F1D.8070507@FreeBSD.org> Date: Sun, 03 Feb 2008 22:16:13 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Kris Kennaway 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> <47A62EE8.2000700@FreeBSD.org> In-Reply-To: <47A62EE8.2000700@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Ivan Voras , Stefan Lambrev 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:16:15 -0000 Kris Kennaway wrote: > 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 that is the next place to look. [hit send too soon] Kris