From owner-freebsd-net@freebsd.org Sat Nov 7 01:51:39 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0D359A2570C for ; Sat, 7 Nov 2015 01:51:39 +0000 (UTC) (envelope-from ralsaadi@swin.edu.au) Received: from iport1.cc.swin.edu.au (iport1.cc.swin.edu.au [136.186.0.49]) by mx1.freebsd.org (Postfix) with ESMTP id 7E0D7106C for ; Sat, 7 Nov 2015 01:51:37 +0000 (UTC) (envelope-from ralsaadi@swin.edu.au) X-IronPort-AV: E=Sophos;i="5.20,255,1444654800"; d="scan'208";a="14644137" Received: from gsp-ex03.ds.swin.edu.au (HELO outlook.swin.edu.au) ([136.186.126.19]) by iport1.cc.swin.edu.au with ESMTP; 07 Nov 2015 12:51:29 +1100 Received: from GSP-EX02.ds.swin.edu.au ([169.254.2.2]) by gsp-ex03.ds.swin.edu.au ([169.254.3.127]) with mapi id 14.03.0248.002; Sat, 7 Nov 2015 12:51:29 +1100 From: Rasool Al-Saadi To: Hans Petter Selasky , Luigi Rizzo CC: "freebsd-net@freebsd.org" Subject: RE: Timing issue with Dummynet on high kernel timer interrupt Thread-Topic: Timing issue with Dummynet on high kernel timer interrupt Thread-Index: AdEWOVE5DoAlkzqPQWaBZ8ln4esVd///TXiA//0UVtCABdKzgP/+Z6XggAMXeACAAAG5AIAAEWQAgAAEeACAAFKsAP/+mCjA Date: Sat, 7 Nov 2015 01:51:29 +0000 Message-ID: <6545444AE21C2749939E637E56594CEA3C0E1B79@gsp-ex02.ds.swin.edu.au> 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> <563C786C.1050305@selasky.org> <563CC186.9000807@selasky.org> In-Reply-To: <563CC186.9000807@selasky.org> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [136.186.126.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2015 01:51:39 -0000 On Saturday, 7 November 2015 2:05 AM, Hans Petter Selasky wrote: > On 11/06/15 11:08, Luigi Rizzo wrote: > > On Fri, Nov 6, 2015 at 10:52 AM, Hans Petter Selasky > wrote: > >> On 11/06/15 09:50, Luigi Rizzo wrote: > >>> > >>> On Fri, Nov 6, 2015 at 9:44 AM, Hans Petter Selasky > >>> > >>> 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=3D4000. Or if the dummyne= t'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 id= ea. > > >=20 > Rasool: >=20 > It might be worth trying to set: >=20 > kern.eventtimer.periodic=3D1 >=20 > In /boot/loader.conf . Can you test that too? >=20 > You need to reboot before the setting takes into effect. Hans, Yes, this solves the problem! I will do more checking when I am near my testbed. Thanks for your effort and time! Cheers, Rasool >=20 > Luigi: >=20 > I'm wondering if there is a problem with: >=20 > cpu_new_callout(a,b,c); >=20 > --HPS >=20 > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"