From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 24 09:24:13 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55C4C16A417; Thu, 24 Jan 2008 09:24:13 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id C957713C447; Thu, 24 Jan 2008 09:24:12 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: by blah.sun-fish.com (Postfix, from userid 1002) id 699FD1B10EE0; Thu, 24 Jan 2008 10:24:11 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on blah.cmotd.com X-Spam-Level: X-Spam-Status: No, score=-10.6 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 Received: from hater.haters.org (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id F403B1B10EA4; Thu, 24 Jan 2008 10:24:07 +0100 (CET) Message-ID: <47985936.2030705@moneybookers.com> Date: Thu, 24 Jan 2008 11:24:06 +0200 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.9 (X11/20071120) MIME-Version: 1.0 To: Kris Kennaway References: <4795CC13.7080601@moneybookers.com> <4795FE54.9090606@moneybookers.com> <86lk6i0vzk.fsf@ds4.des.no> <479605E2.6070709@moneybookers.com> <47964356.6030602@moneybookers.com> <479647FB.3070909@FreeBSD.org> <47970EE2.5000400@moneybookers.com> <479754E6.1060101@moneybookers.com> <9bbcef730801230802n5c52832bk60c6afc47be578f4@mail.gmail.com> <479794DB.4020504@FreeBSD.org> In-Reply-To: <479794DB.4020504@FreeBSD.org> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5542/Thu Jan 24 07:17:51 2008 on blah.cmotd.com X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org, Ivan Voras Subject: Re: gettimeofday() in hping X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2008 09:24:13 -0000 Greets, Kris Kennaway wrote: > Ivan Voras wrote: >> On 23/01/2008, Stefan Lambrev 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@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,0) 3385 hping NAMI "/dev/bpf0" 3385 hping RET open -1 errno 16 Device busy 3385 hping CALL open(0xbfbfe8a4,O_RDWR,0) 3385 hping NAMI "/dev/bpf1" 3385 hping RET open 4 -- Best Wishes, Stefan Lambrev ICQ# 24134177