From owner-freebsd-net@freebsd.org Fri Nov 6 10:08:48 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 86AF9A270BE for ; Fri, 6 Nov 2015 10:08:48 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0BE2D14BC for ; Fri, 6 Nov 2015 10:08:48 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by lfbn126 with SMTP id n126so70116780lfb.2 for ; Fri, 06 Nov 2015 02:08:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ZlyNXFdGCjJrMVff1Xd6ifZBdByq1DQotOUQUOAoseo=; b=aaeFLzQ8an/qds2UrbaXGYQ8z14wzDUBrNkcOnO5AekPo/frCzxag5p6AKtYEKq9WC lymz9b7Si9BPmKpJlex4/a377lrxlLGU+WgWBm8xgyf7GHS2X48IceeCBmsdAg1w2YkQ QiBBPXjZgZ+KMOI2e2eCpReMRkYpviYjjgqrZIzOmMP9HF0uv/dxshnDnlv3Q8fcs2EO xXqeaSIwhZqEGxN+OSmDHVaGeNxaXmM9ivpt+LtgM6D6MF8I7wF1Zap/sDht8JO5hL0Q gN/q9+4L+pq5L8Wd+1u4ar7rW3/22JeE8SC1vV4ELAUjQoGX2hifOEOXKyVeoMahkqRh FQ9w== MIME-Version: 1.0 X-Received: by 10.25.165.206 with SMTP id o197mr3848469lfe.83.1446804525049; Fri, 06 Nov 2015 02:08:45 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.78.3 with HTTP; Fri, 6 Nov 2015 02:08:44 -0800 (PST) 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> <563C786C.1050305@selasky.org> Date: Fri, 6 Nov 2015 11:08:44 +0100 X-Google-Sender-Auth: n3TpOh307Q1LmuCChCSyJdVdF_k Message-ID: Subject: Re: Timing issue with Dummynet on high kernel timer interrupt From: Luigi Rizzo To: Hans Petter Selasky Cc: Rasool Al-Saadi , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 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: Fri, 06 Nov 2015 10:08:48 -0000 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=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) -----------------------------------------+-------------------------------