Re: strange ping response times...

From: Andre Oppermann <andre_at_freebsd.org>
Date: Wed, 11 Apr 2012 14:16:49 +0200
On 11.04.2012 13:00, Luigi Rizzo wrote:
> On Wed, Apr 11, 2012 at 12:35:10PM +0200, Andre Oppermann wrote:
>> On 11.04.2012 01:32, Luigi Rizzo wrote:
>>> 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...)
>>
>> Things going through loopback go through a NETISR and may
>> end up queued to avoid LOR situations.  In addition per-cpu
>> queues with hash-distribution for affinity may cause your
>> packet to be processed by a different core.  Hence the additional
>> delay.
>
> so you suggest that the (de)scheduling is costing several microseconds ?

Not directly.  I'm just trying to explain what's going on to
get a better idea where it may go wrong.

There may be a poor ISR/scheduler interaction that prevents that
causes the packet to be processed only on the next tick or something
like that.  I don't have a better explanation for this.

> Do we have something like yield() to measure how expensive is the
> scheduler ? I ran some tests in a distant past and i remember numbers
> of a few microseconds, but that was almost two gigahertz ago...

-- 
Andre
Received on Wed Apr 11 2012 - 10:16:10 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:25 UTC