From owner-freebsd-net@FreeBSD.ORG Fri Dec 7 10:21:56 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0B7716A417 for ; Fri, 7 Dec 2007 10:21:56 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id 987BB13C455 for ; Fri, 7 Dec 2007 10:21:56 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 36D316E9D5; Fri, 7 Dec 2007 05:21:56 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Fri, 07 Dec 2007 05:21:56 -0500 X-Sasl-enc: aTwL7q0shxnYNHFrxb8tT0E5MvThNB5E+aeYq4eE/rLl 1197022915 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 9A7BCB3D7; Fri, 7 Dec 2007 05:21:55 -0500 (EST) Message-ID: <47591EC2.9060902@FreeBSD.org> Date: Fri, 07 Dec 2007 10:21:54 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: Len Gross References: <27cb3ada0712061914g4aff5a7eq7d5cc64ba3d493ed@mail.gmail.com> In-Reply-To: <27cb3ada0712061914g4aff5a7eq7d5cc64ba3d493ed@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" Subject: Re: TDMA / Interrupts / Pre-emptible X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Dec 2007 10:21:56 -0000 Len Gross wrote: > I have built a "user land" prototype of a custom network protocol for an RF > network. It is based on Netgraph and using Ethernet rather than real RF. > > Eventually, all the code will go into a special piece of hardware, but the > first hardware really will look like an Ethernet card that puts messages out > N microsends after they are put into its memory. Since the protocol employs > some TimeDivisionMultipleAccess (TDMA), "precise" feeding of the board is > important. > > In "userland" I seem to have about 1 ms of "delay"/variability from when I > schedule a timer and when it wakes up a thread. I think this is pretty much > expected behavior and is fine for algorithm testing. > > When I move my userland code to "driver/kernel-land" and set a timer to send > a packet to some hardware how much delay / variability will I see in that > timer? I think the question is more/less equivalent to the pre-emptibility > of driver code and interrupts in general. > 1ms sounds about right, re the amount of userland scheduler jitter. I had a horrible experience with the MS Windows userland scheduler. Achieving low latency and jitter is particularly difficult there unless you go to the kernel. I know there are various methods to get smaller timer granularity which I've tried. It was just very variable, appeared to be nondeterministic, and it was often off by 10ms or more. In FreeBSD the userland story is far better, you should be able to just crank up HZ, it sounds like you've already done this to arrive at the 1ms figure. I can't comment on kernel scheduler jitter though, so someone who is working directly in that area will hopefully respond -- arch@ or hackers@ might be a better place to field that question. I believe microsecond resolution for your app should be possible in the kernel. If it isn't, I'd like to know why. [It would be really, really nice to have better real-time support in FreeBSD, i.e. a deadline scheduler.] cheers BMS