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.([EMAIL PROTECTED]:....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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
