> Unix can't do hard real time, he is still correct I'm not sure I have been clear: I modified 4.3BSD to do Hard Real Time. https://youtu.be/Bd5iEke6UlE shows you all the machines that operated with my mods to 4.3BSD.
And, I'd like to modify NetBSD to also be Hard Real Time. Ultimately, it's just "Can you guarantee that you task switch to my robot task within <requirement> time?" For Running, Hopping, and Jumping robots in the video, <requirement> was < 100 usec. Given that the method I chose worked on a 1 MIPS uniprocessor, I'm hopeful that a 1.2 GHz quad-processor machine running at over 2000 MIPS will be able to do the same. Maybe even a little better. Thanks again, Mike p.s. For a little more detail, a KW11-P programmable clock interrupted at 1 KHz. https://usermanual.wiki/Document/DEC11HPWBDKW11POct72.1688176585.pdf This clock conveniently had a register counting up at 100 kHz that could be read any time. It was synchronized to the 1 kHz interrupts (every 100 counts gives the interrupt). When the interrupt was taken, the interrupt routine immediately read this register to get the *actual* time it had received control; And the difference between that register and a 'perfect' multiple of 100 counts meant the code was some number of 'counts' later than desired. So if you read 14307, that meant that you got to that 1st instruction 7 x 10 usec = 70 usec later. This is how I know what the maximum delay was. The other thing, for fun, had the simplest interrupt handler, which just did a return from interrupt. Interrupt was triggered by a change on an external pin. I ran a signal generator into this pin and cranked up the knob until the vax crashed. I believe this was around 12 kHz. What was fun was turning up the sig gen frequency, and watching the machine get slower, and slower, and slooower - because of course it was spending more and more time fielding the ever-more-frequent interrupts. On Sun, Apr 19, 2020 at 8:42 PM Johnny Billquist <[email protected]> wrote: > 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. > > Johnny > > 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, > > Mike > > > > > > On Sun, Apr 19, 2020 at 9:19 AM Sad Clouds <[email protected] > > <mailto:[email protected]>> wrote: > > > > On Sun, 19 Apr 2020 15:27:16 +0200 > > Johnny Billquist <[email protected] <mailto:[email protected]>> 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: [email protected] || Reading murder books > pdp is alive! || tryin' to stay hip" - B. Idol >
