Date: Sat, 8 Dec 2007 17:12:04 -0800 From: "Len Gross" <sandiegobiker@gmail.com> To: "Harti Brandt" <harti@freebsd.org> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, "Bruce M. Simpson" <bms@freebsd.org> Subject: Re: TDMA / Interrupts / Pre-emptible Message-ID: <27cb3ada0712081712o26e33d75y48f71f881b51b6d3@mail.gmail.com> In-Reply-To: <20071207113727.J30903@knop-beagle.kn.op.dlr.de> References: <27cb3ada0712061914g4aff5a7eq7d5cc64ba3d493ed@mail.gmail.com> <47591EC2.9060902@FreeBSD.org> <20071207113727.J30903@knop-beagle.kn.op.dlr.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 7, 2007 2:46 AM, Harti Brandt <hartmut.brandt@dlr.de> wrote: > On Fri, 7 Dec 2007, Bruce M. Simpson wrote: > > BMS>I can't comment on kernel scheduler jitter though, so someone who is > working > BMS>directly in that area will hopefully respond -- arch@ or hackers@ > might be a > BMS>better place to field that question. > BMS> > BMS>I believe microsecond resolution for your app should be possible in > the > BMS>kernel. If it isn't, I'd like to know why. [It would be really, really > nice > BMS>to have better real-time support in FreeBSD, i.e. a deadline > scheduler.] > > A couple of years I did exactly the same as the OP - implementing a > satellite MAC layer (FM-TDMA) on a cluster of 5 FreeBSD machines. I think > it was the time when we moved from 4.X to 5.0 or 5.1. I could not get it > reliable because the jitter in the kernel (I implemented everything in > netgraph over ethernet) was in the order of several 100 usec. I had HZ at > 10000 (all my simulation machines run on that). I tried really hard to > find out where these jitters came from, but failed. Trying to trace the > timing of execution changed the figures completely each time. Finally I > gave up, because the project luckily ended :-/ At one point I tried to > bump HZ to 20000 or so, but at this point TCP broke. I think this might > have come from the RTT computation which is/was done in ticks and the > square of something would overflow the variable. > > One must also carefully choose the ethernet adapter for this kind of > things, because it may add any kind of jitter/delay. At that time the best > where the DEC/intel if_dc types. > > Of course with the actual kernel the situation may be quite different. > Don't know what influence have interrupt threads and this stuff. I would > be interested to hear how things work out and, yeah, better real-time > support would be great :-) > > Regards, > harti > > I think the general answer is probably that drivers and Kernel code have the same lack of determinism as user-land code. I found a LINUX article "A measurement- based Analysis of the real-time performance of LINUX" that seems to support this view. If I can get latency/jitter of 100 microseconds that would be good enough for my next step. Will keep you posted. -- Len
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?27cb3ada0712081712o26e33d75y48f71f881b51b6d3>