Date: Sat, 7 Nov 2015 01:51:29 +0000 From: Rasool Al-Saadi <ralsaadi@swin.edu.au> To: Hans Petter Selasky <hps@selasky.org>, Luigi Rizzo <rizzo@iet.unipi.it> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: RE: Timing issue with Dummynet on high kernel timer interrupt Message-ID: <6545444AE21C2749939E637E56594CEA3C0E1B79@gsp-ex02.ds.swin.edu.au> In-Reply-To: <563CC186.9000807@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> <CA%2BhQ2%2Bj0WiGgzV119M1ZQiXP5Z7fq7deVxDPkOhvTc7hpTETKw@mail.gmail.com> <563CC186.9000807@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <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=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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6545444AE21C2749939E637E56594CEA3C0E1B79>