Re: RTOS

I've been thinking about calculation errors, rounding, and drift in the
FDM, and about the effect of jitter on HTTP or other I/O transmission of
updates to values derived from FDM calculations. Errors introduced by
calculations and their effects on jitter in computed results are an area of
mathematics I'd like to become more familiar with. Have any of you been
down that path before?

When using the HTTP server to drive instruments or gauges, some items
result in per-cycle updates that have no visible effect on the physical
instruments or gauges. I've observed frame-to-frame jitter in HTTP-reported
property values. There are also slowly trending values that increment every
frame, with no apparent movement on the corresponding gauge. In our current
HTTP Subscription implementation, Heading and Fuel are updated in every
frame, with differences in values well below the resolution of any physical
indicator device.

Is that a problem for anyone?

-Pat



On Wed, May 20, 2026 at 8:14 PM David Hudach <[email protected]> wrote:

> Richard,
>
> Thank you for the detailed information. There is a lot to absorb and
> digest there. The video interested me because in my initial Arduino
> experience, there was a fair amount of "condition testing" in the main
> loop, even when using interrupts. But as I mentioned in my response to
> Curt's post, the high level overview in the video planted this seed that
> possibly it seemed too simple, that it looked good on paper.
>
> I'm really not striving for a true RTOS sim. I was drawn to the concept
> and it made me wonder if I'm doing things the hard way. What I am trying to
> avoid is over use of "if" conditions to manage the data IO and the controls
> I'm trying to implement. But after doing some research, there are ways of
> implementing RTOS on RPI. And I may not actually need something like that
> to achieve the kind of realistic, functional simulator that handles the
> devices I'm striving to build. So I'm with you that for now I'll continue
> using Raspberry Pi and rather than doing a complete do-over using an
> unfamiliar technology I'll continue making things work and seek solutions
> as needs arise. In other words, though RTOS is an interesting topic for
> future reference, for what I'm trying to do, it may be overkill at this
> point.
>
> I do appreciate the insightful, educational information.
>
> Thanks,
> Dave
>
> On Wed, May 20, 2026 at 7:20 PM Richard Harrison <[email protected]> wrote:
>
>> Hi David,
>>
>>   > wondered what operating systems were used on the airliners and RTOS
>> was mentioned.
>>   There are a few different ones; all hard real-time, VxWorks and LynxOS
>> are the ones that come to mind.
>>
>> Some good information from Curt and some of that should be standing
>> advice - "measure it before deciding".
>>
>> So in terms of RTOS there are a number of ways of going; pre-emptive is
>> good - but it is quite "operating system-esque" and does carry an
>> overhead and as noted in the video doesn't prevent resource contention.
>>
>> If we're talking about proper real-time the single biggest important
>> thing is determinism; one of the things that Unix (and NT) are bad at is
>> interrupt handling; and with any sort of simulation you need to be able
>> to accurately start each simulation frame at the right point; not
>> "sometime afterwards". Linux has got better at this, IRIX used to be
>> good at this. Curt alluded to this, but basically the start of the frame
>> needs to be pretty rock solid (30Hz, or whatever). Or more precisely: a
>> slightly late start is survivable, what isn't survivable is missing the
>> budget (which gives you headroom for variance) or, worse, the hard
>> deadline before the next frame is due.
>>
>> One thing I'll push back on from the video is the use of locking
>> primitives in the simulation loop; sure, a queue with a lock on the
>> serial port to synchronise output is fine, but locks in the main loop
>> are how you end up like Mars Pathfinder. You don't sync in real-time,
>> you design it so there's no contention, usually by putting potentially
>> contentious modules on the same CPU so that there cannot be contention.
>> You have to have coding discipline.
>>
>> Cooperative multitasking is generally faster; we used to wince at the
>> cost of context switches and how many instructions they burned. The
>> example in the video that supposedly demonstrates why cooperative
>> multitasking is poor actually demonstrates poor programming. In a
>> cooperative real-time system, you simply do not perform long operations
>> in a single frame. Slow operations must be partitioned across frames.
>>
>> I've done a little work in Nasal to bring a couple of things to make
>> this sort of thing easier
>>
>> 1. Nasal/emexec.nas[1] - this is a cooperative exec that uses Emesary
>> notifications to get the work done. Like the modules in the video only a
>> lot better structured, with overrun detection, measurement, supporting
>> different exec rates.
>>
>> 2. Nasal/frame_utils.nas[2] - defines the PartitionProcessor which
>> spreads workload across frames.
>>
>>  > So I switched to Raspberry Pi. I like the idea that I can code on the
>> fly.
>>
>> If you're getting on fine with an RPI then stick with it; there is a lot
>> to be said for developing on the target.
>>
>> Back in the 1980's the Level D certified simulators we were building at
>> Rediffusion all had hard-real-time systems and they had separate
>> processing nodes (each with CPU/IPU); connected with reflective memory
>> which was used to share datapool[3] and a real-time clock that connected
>> to all of the nodes to ensure that they started the frame at pretty much
>> the same point.
>>
>> Each node had a cooperative real-time executive that started with the
>> first entry point and then ran each module in turn based on their rates
>> (full rate, half rate, quarter rate,...). This was at 30Hz, so ~33ms,
>> but with 25% spare time so we had to be done in 27ms. The spare time was
>> to allow for the natural variance as some frames would take longer than
>> others, but generally you had to be done in 27ms.
>>
>> If anything overran the 33ms then the whole real-time system would hard
>> abort and stop running. If the simulator was flying on motion this also
>> meant a hard motion abort, same with the controls. It made a frightful
>> noise.
>>
>>
>> Always happy to help with this sort of stuff.
>>
>> -- Richard
>> ---
>> [1] emexec:
>>
>> https://gitlab.com/flightgear/fgdata/-/blob/next/Nasal/emexec.nas?ref_type=heads
>> [2] frame_utils:
>>
>> https://gitlab.com/flightgear/fgdata/-/blob/next/Nasal/frame_utils.nas?ref_type=heads
>> [3] memory writes were reflected across all nodes and it was defined
>> which nodes could write to which areas of shared memory; but mostly it
>> was discipline that made it work.
>>
>>
>>
>>
>> _______________________________________________
>> Flightgear-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>>
> _______________________________________________
> Flightgear-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>

_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel