gettimeofday() in hping

Stefan Lambrev stefan.lambrev at moneybookers.com
Thu Jan 24 01:24:13 PST 2008


Greets,

Kris Kennaway wrote:
> Ivan Voras wrote:
>> On 23/01/2008, Stefan Lambrev <stefan.lambrev at moneybookers.com> wrote:
>>> Greets,
>>>
>>> Now I have final results with Linux and FreeBSD on the same hardware
>>> CPU: Intel(R) Xeon(R) CPU 3070  @ 2.66GHz - dual core
>>> Lan: em0 at pci0:3:0:0: class=0x020000 card=0x10bc8086 chip=0x10bc8086
>>> rev=0x06 hdr=0x00
>>>     vendor     = 'Intel Corporation'
>>>     device     = '82571EB Gigabit Ethernet Controller (Copper)'
>>>     class      = network
>>>     subclass   = ethernet
>>>
>>> FreeBSD releng_7_0 from today - amd64, sched_ule.
>>>
>>> ACPI-Fast - 6.187 MB/s
>>> TSC - 9.455 MB/s
>>> dummy - 9.577 MB/s
>>>
>>> Linux rambo2 2.6.22-14-generic #1 SMP Tue Dec 18 05:28:27 UTC 2007
>>> x86_64 GNU/Linux - kubuntu
>>>
>>> TSC - 19.456 MB/s
>>> acpi_pm - 15.394 MB/s
>>> jiffies - 19.480 MB/s
>>>
>>> This is really not what I expected.
>>
>> For once, it's something I expected :) I just hope it isn't one of
>> those cases where Kris absolutely cannot reproduce it and arrives at
>> numbers in favour of FreeBSD :)
>> (just joking here, absolutely no ill feelings involved).
>
> Harumph :)  The first step is that we need to understand where the 
> application is spending its time.  Hopefully Stefan or someone else 
> will  be able to test it under hwpmc.
>
>> It would be helpful if you post exact command line arguments from all 
>> cases.
>>
>>> The other thing that bothers me is, that under freebsd is quite easy 
>>> to get:
>>> [send_ip] sendto: No buffer space available
>>> It happens almost always on my laptop just few seconds after I start
>>> hping with timecounter=TSC
>>
>> I'm not sure, but from what I understood of Robert Watson's
>> explanation in the big ZFS thread on -current, maybe increasing
>> kmem_size (exactly as for ZFS...) could help you with these buffers.
>
> It is the socket buffer that is filling up.  Either the application is 
> not increasing it to large enough size or the default maximum is too 
> low (Linux may set a larger default).  Try increasing 
> kern.ipc.maxsockbuf and confirming with the source and/or ktrace that 
> it is doing the right setsockopt() call.
Increasing kern.ipc.maxsockbuf doesn't help.

Actually this is the code that failed and print this error:

        result = sendto(sockraw, packet, packetsize, 0,
                (struct sockaddr*)&remote, sizeof(remote));

        if (result == -1 && errno != EINTR && !opt_rand_dest && 
!opt_rand_source) {
                perror("[send_ip] sendto");

Those are the only references for setsockopt when ktracing:
 3385 hping    CALL  __sysctl(0xbfbfe870,0x6,0,0xbfbfe888,0,0)
  3385 hping    RET   __sysctl 0
  3385 hping    CALL  __sysctl(0xbfbfe870,0x6,0x28305180,0xbfbfe888,0,0)
  3385 hping    RET   __sysctl 0
  3385 hping    CALL  socket(PF_INET,SOCK_DGRAM,IPPROTO_IP)
  3385 hping    RET   socket 3
  3385 hping    CALL  setsockopt(0x3,SOL_SOCKET,SO_BROADCAST,0xbfbfe884,0x4)
  3385 hping    RET   setsockopt 0
  3385 hping    CALL  connect(0x3,0x8067da0,0x10)
  3385 hping    RET   connect 0
  3385 hping    CALL  getsockname(0x3,0xbfbfe874,0xbfbfe888)
  3385 hping    RET   getsockname 0
  3385 hping    CALL  close(0x3)
  3385 hping    RET   close 0
  3385 hping    CALL  socket(PF_INET,SOCK_RAW,IPPROTO_RAW)
  3385 hping    RET   socket 3
  3385 hping    CALL  setsockopt(0x3,SOL_SOCKET,SO_BROADCAST,0xbfbfe914,0x4)
  3385 hping    RET   setsockopt 0
  3385 hping    CALL  setsockopt(0x3,0,0x2,0xbfbfe914,0x4)
  3385 hping    RET   setsockopt 0
  3385 hping    CALL  open(0xbfbfe8a4,O_RDWR,<unused>0)
  3385 hping    NAMI  "/dev/bpf0"
  3385 hping    RET   open -1 errno 16 Device busy
  3385 hping    CALL  open(0xbfbfe8a4,O_RDWR,<unused>0)
  3385 hping    NAMI  "/dev/bpf1"
  3385 hping    RET   open 4

-- 

Best Wishes,
Stefan Lambrev
ICQ# 24134177



More information about the freebsd-hackers mailing list