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