Date: Wed, 11 Apr 2012 01:32:11 +0200 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Barney Wolff <barney@databus.com> Cc: current@freebsd.org, net@freebsd.org Subject: Re: strange ping response times... Message-ID: <20120410233211.GA53829@onelab2.iet.unipi.it> In-Reply-To: <20120410230500.GA22829@pit.databus.com> References: <20120410225257.GB53350@onelab2.iet.unipi.it> <4F84B6DB.5040904@freebsd.org> <20120410230500.GA22829@pit.databus.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 10, 2012 at 07:05:00PM -0400, Barney Wolff wrote: > CPU cache? > Cx states? > powerd? powerd is disabled, and i am going down to C1 at most > sysctl -a | grep cx hw.acpi.cpu.cx_lowest: C1 dev.cpu.0.cx_supported: C1/1 C2/80 C3/104 which shouldn't take so much. Sure, cache matters, but the fact is, icmp processing on loopback should occur inline. unless there is a forced descheduling on a select with timeout > 0 which would explain the extra few microseconds (and makes me worry on how expensive is a scheduling decision...) cheers luigi > On Tue, Apr 10, 2012 at 03:40:27PM -0700, Julian Elischer wrote: > > On 4/10/12 3:52 PM, Luigi Rizzo wrote: > > > I noticed this first on a 10G interface, but now there seems > > > to be a similar issue on the loopback. > > > > > > Apparently a ping -f has a much lower RTT than one with non-zero > > > delay between transmissions. Part of the story could be that > > > the flood version invokes a non-blocking select. > > > On the other hand, pinging on the loopback should make > > > the response available right away, so what could be the reason > > > for the additional 3..10us in the ping response time ? > > > > > > The following are numbers on an i7-2600k at 3400 MHz + turboboost, > > > running stable/9 amd64. Note how the min ping time significantly > > > increases moving from flood to 10ms to 1s. > > > On an Intel 10G interface i am seeing a min of 14-16us with > > > a ping flood, and up to 33-35us with the standard 1s interval > > > (using -q probably trims another 2..5us) > > > > I'd suggest some ktr points around the loopback path..
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120410233211.GA53829>