Comment by mlyle

> i thought you were talking about doing the rapid-response work in top-half interrupt handlers on linux.

When we talk about worst-case latency to high priority top-half handlers on linux, it comes down to

A) how much time all interrupts can be disabled for. You can drive this down to near 0 by e.g. not delivering other interrupts to a given core.

B) whether you have any weird power saving features turned on.

That is, you can make choices that let you consistently hit a couple hundred ns.

> i guess maybe you're saying that if you move the work into userland tasks instead of interrupts you get tens of microseconds of latency

I think "tens" is unfair on most computers. I think "several" is possible on most, and you can get "a couple" with careful system design.

> i'm not sure that the 'apples to apples' comparison between amd64 systems and avr microcontrollers is to use equal numbers of cores on both systems.

I wasn't saying equal numbers of cores. I was saying:

* Compare interrupt handlers with interrupt handlers; not interrupt handlers with tasks. Task latency on FreeRTOS/AVR is not that great.

* Compare latency to latency, or jitter to jitter.

> be systems of similar costs

The price of a microcontroller running an RTOS is trivial, and you can even get to something running preempt_rt for about the cost of a high-end AVR (which is not a cheap microcontroller).

You have to sell a lot of units and have a particularly trivial problem to be ahead doing things the "hard way."