Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 03 Feb 2008 16:13:47 -0800
From:      Sam Leffler <sam@errno.com>
To:        Kris Kennaway <kris@freebsd.org>
Cc:        freebsd-hackers@freebsd.org, Ivan Voras <ivoras@freebsd.org>, Stefan Lambrev <stefan.lambrev@moneybookers.com>
Subject:   Re: gettimeofday() in hping
Message-ID:  <47A658BB.1080104@errno.com>
In-Reply-To: <47A62EE8.2000700@FreeBSD.org>
References:  <4795CC13.7080601@moneybookers.com>	<4795FE54.9090606@moneybookers.com>	<86lk6i0vzk.fsf@ds4.des.no>	<479605E2.6070709@moneybookers.com>	<fn5c7u$i7e$2@ger.gmane.org>	<47964356.6030602@moneybookers.com>	<479647FB.3070909@FreeBSD.org>	<47970EE2.5000400@moneybookers.com>	<fn7evj$smv$1@ger.gmane.org>	<479754E6.1060101@moneybookers.com>	<9bbcef730801230802n5c52832bk60c6afc47be578f4@mail.gmail.com>	<47976AD4.3020203@moneybookers.com> <47A62EE8.2000700@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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

The "doesn't cope with the possibility that ... the send buffer is full" 
issue is classic linux-specific mis-behaviour.  On linux the process 
will block when the default qdisc finds the device q is stopped (due to 
being full).  I remember cursing iperf for this.

	Sam



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47A658BB.1080104>