NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Hard Real-Time?

Just wanted to point out that indeed, none of the "other" Unixes do hard real time, and neither do NetBSD.
Unix was not designed with real time in mind, much less hard real time.
It is usually good enough for soft real time, and that sounds like what you are looking for here as well. If you just have fast enough hardware, you usually will get responses within a very short time. But again, that is not what defines hard real time.

If you get into a discussion with someone else, and that someone else says Unix can't do hard real time, he is still correct, no matter how much you fiddled around with your RPi.


On 2020-04-20 03:58, Michael Cheponis wrote:
Thanks to all who contributed here, I'm learning a lot.

As to what is 'real time' -- as you can probably tell by watching the video at the URL, the robots were dynamically stable - they had to react within a millisecond (Read sensors; do all control; storage of data for post-run analysis, run all the low-level joint servos (12 of them on the 4-legged machine) -- and because we did not have sensors for everything, some had to be synthesized (e.g. if you have a position sensor, and you take regular samples, you can approximate velocity).  This requirement means that you need low 'jitter' from when the pin goes high (it was usually controlled by a clock) to when you can read the raw sensors - obviously, that was done first to minimize this jitter.  So to me, 'real time' means response within some specific number of microseconds.

At one point, Greg, I built a Z8002 + Weitek floating point chip to sit between the vax and the 4-legged robot.  This indeed helped because now the low-level control (servoing) was done by this Z8002+Weitek, and the 'planning' was done in the vax.   It was about 4x faster than the vax could servo; the joint motion was very smooth, because there was also less jitter (it wasn't running unix).

We ended up not using it after all that effort because (1) The ability to have 'everything' on one machine was a Big Win.  and (2) Now you had two different software stacks, which increases the overall complexity. The biggest 'win' having it all on one machine was for data collection and analysis: the kernel driver locked down a lot of memory, and wrote dozens of sensors and computed  values into a big circular buffer.  When the robot failed (which was 90% of the time), we push another button, generating an NMI, which would freeze the circular buffer.   Recall, this driver was activated by simply issuing an ioctl() to activate the driver.  When the time-sharing part had control again, the data were copied out of kernel space into user space with another ioctl().  And of course the software to drive the graphics display was also on the vax, so literally a few seconds after the robot crapped out, we were looking at data from the run.

I think the lesson is: never discount the communications issues when distributing computation.  They add system complexity and often delay.

With the RPi4 NetBSD support coming along nicely, I'd expect to use this.  It might be nice to be able to 'dedicate' a core to servicing the interrupt, leaving the other 3 to continue regular operation. Multi-core I would hope would make things that much easer for this problem.

I'll look at gpioirq(4) and gpiopps(4) - sounds promising.  I'm happy to hear the Global Interrupt Enable is used for only short times; and yes I bet a high IPL will work.


There is another motive, which is to show how it's possible to run a modern unix with a Real-Time process, specifically for robot control. The other *nix OSs out there don't do Hard Real Time, the best I've seen is a microkernel below a regular kernel (not rump).   Again, this makes things complicated.

I'll work on it and maybe it'll all 'just work'.

Thanks everybody,

On Sun, Apr 19, 2020 at 9:19 AM Sad Clouds < <>> wrote:

    On Sun, 19 Apr 2020 15:27:16 +0200
    Johnny Billquist < <>> wrote:

     > Essentially, a hard real time system guarantees that it never takes
     > longer than some specified time for something to happen. And as far
     > as I know, NetBSD cannot give such guarantees. Various combinations
     > of events and situations can lock out interrupts for some time, and
     > there is no guaranteed upper bound to that time.

    Yes you're right, "hard real time" is more about not missing deadlines,
    rather than how fast something can be executed. Also the consequences of
    missing deadlines can be quite catastrophic, i.e. air bags not
    activating in time during a collision.

    The original poster mentioned something about controlling a robot with
    a raspberry pi. If the robot is not doing anything safety critical,
    then "soft real time" is probably something that NetBSD could provide.

Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email:             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

Home | Main Index | Thread Index | Old Index