gettimeofday() in hping
Kris Kennaway
kris at FreeBSD.org
Sun Feb 3 13:16:15 PST 2008
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... at ...........:....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
More information about the freebsd-hackers
mailing list