Path: csiph.com!feeder.erje.net!2.us.feeder.erje.net!nntp.club.cc.cmu.edu!micro-heart-of-gold.mit.edu!bloom-beacon.mit.edu!bloom-beacon.mit.edu!panix!not-for-mail From: Grant Edwards Newsgroups: comp.arch.embedded Subject: Re: soft real-time on linux Date: Sat, 12 Nov 2016 17:16:16 +0000 (UTC) Organization: PANIX Public Access Internet and UNIX, NYC Lines: 30 Message-ID: References: <87eg2gerei.fsf@digitalsignallabs.com> NNTP-Posting-Host: 67-130-15-94.dia.static.qwest.net X-Trace: reader2.panix.com 1478970976 953 67.130.15.94 (12 Nov 2016 17:16:16 GMT) X-Complaints-To: abuse@panix.com NNTP-Posting-Date: Sat, 12 Nov 2016 17:16:16 +0000 (UTC) User-Agent: slrn/1.0.2 (Linux) Xref: csiph.com comp.arch.embedded:25484 On 2016-11-12, Randy Yates wrote: > I was told by someone on the ##kernel channel that if the kernel is > compiled with "preemptive" enabled, there is a way to set a thread's > priority to "real-time" and it will not only have priority over other > user-land threads but also will preempt much of the kernel's internal > threads. This sounds promising. In my experience (on a 400MHz ARM9), if you build the kernel with all the pre-emptable options, and run your task at the highest real-time priority then latency between an external event that causes an interrupt and your user task waking up and running is going to be somwhere in the 100-300 microsecond range. [Assuming the interrupt routine and device driver require minimal processing.] That, of course, depends on the exact set of drivers you have enabled. All it takes is one long critical section in a poorly written driver to run that into many hundreds of microseconds. I would be shocked if it ever got up to 1ms. Unless you disable the rx FIFO, I would guess that the vast majority of the latency is going to be in the UART itself. With the rxFIFO enabled, there's often a delay of several tens of bit-times between the last data byte and the receive interrupt. -- Grant Edwards grant.b.edwards Yow! Zippy's brain cells at are straining to bridge gmail.com synapses ...