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..Received on Tue Apr 10 2012 - 21:12:53 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:25 UTC