TDMA / Interrupts / Pre-emptible

Bruce M. Simpson bms at
Fri Dec 7 02:21:56 PST 2007

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 


More information about the freebsd-net mailing list