Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 6 Nov 2015 11:08:44 +0100
From:      Luigi Rizzo <rizzo@iet.unipi.it>
To:        Hans Petter Selasky <hps@selasky.org>
Cc:        Rasool Al-Saadi <ralsaadi@swin.edu.au>,  "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>
Subject:   Re: Timing issue with Dummynet on high kernel timer interrupt
Message-ID:  <CA%2BhQ2%2Bj0WiGgzV119M1ZQiXP5Z7fq7deVxDPkOhvTc7hpTETKw@mail.gmail.com>
In-Reply-To: <563C786C.1050305@selasky.org>
References:  <6545444AE21C2749939E637E56594CEA3C0DCCC4@gsp-ex02.ds.swin.edu.au> <5638B7B5.3030802@selasky.org> <6545444AE21C2749939E637E56594CEA3C0DE7FF@gsp-ex02.ds.swin.edu.au> <563B2703.5080402@selasky.org> <6545444AE21C2749939E637E56594CEA3C0E0BD9@gsp-ex02.ds.swin.edu.au> <563C6864.2090907@selasky.org> <CA%2BhQ2%2Bhm2z0MkB-8w5xJM7%2Biz13r_ZjwmpZBnb30_D_48gaf-w@mail.gmail.com> <563C786C.1050305@selasky.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Nov 6, 2015 at 10:52 AM, Hans Petter Selasky <hps@selasky.org> wrote:
> On 11/06/15 09:50, Luigi Rizzo wrote:
>>
>> On Fri, Nov 6, 2015 at 9:44 AM, Hans Petter Selasky <hps@selasky.org>
>> wrote:
...
>>> Hi,
>>>
>>> The C_DIRECT_EXEC flag reduces task switching overhead, that you don't
>>> have
>>> to wakeup a thread to wakeup the dummynet worker thread. It affects
>>> timing.
>>
>>
>> Hans,
>> thanks for the explanation.
>>
>> Can you clarify the behaviour of C_DIRECT_EXEC ?
>> Does this mean that the task is run within some common
>> thread instead of a dedicated one ?
>
>
> Hi Luigi,
>
> C_DIRECT_EXEC means that the timer callback is executed directly from the
> fast interrupt filter of the timer or IPI.
>
>>
>> If so, for this type of task (dummynet may run at high rate
>> and use a significant amount of cpu time) it may be a good
>> idea to remove C_DIRECT_EXEC altogether.
>
>
> The ipfw dummynet code is not run from the timer callback. It is run from a
> taskqueue. I suspect there is likely a bug somewhere. At the moment it is
> not clear to me if there is a bug in the callout subsystem, that the when
> the timer is started with 1 tick delay it doesn't kick in until after 50ms
> or so at HZ=4000. Or if the dummynet's task is doing a lot of work for 50ms.
> I think we need some more information to nail this one.

It certainly does not run for 50ms, but it might occasionally keep the
thread busy for some 10-50us (I doubt it is longer than that)
and possibly cause the reschedule request to
fall into the interval where it should actually run.

So if your theory is correct, it may well be that the callout system
sees the request "in the past" (possibly as a result as some incorrect
wraparound, or undefined behaviour on integer wraps) and then the
event is only recovered when the callout wheel (or whatever is the
underlying implementation) happens to go again through the entry.

What is so magic in the values we see (400 or 600 or 40ms) i have no idea.

cheers
luigi

> --HPS
>
>>
>> cheers
>> luigi
>>
>



-- 
-----------------------------------------+-------------------------------
 Prof. Luigi RIZZO, rizzo@iet.unipi.it  . Dip. di Ing. dell'Informazione
 http://www.iet.unipi.it/~luigi/        . Universita` di Pisa
 TEL      +39-050-2217533               . via Diotisalvi 2
 Mobile   +39-338-6809875               . 56122 PISA (Italy)
-----------------------------------------+-------------------------------



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BhQ2%2Bj0WiGgzV119M1ZQiXP5Z7fq7deVxDPkOhvTc7hpTETKw>