LWN: Comments on "A Q&A about the realtime patches"

A Q&A about the realtime patches - CAN / CAN FD subsystem testing

ppisa — Mon, 31 Jul 2023 07:27:13 +0000

Zephyr has CAN support. But I have no own experience with Zephyr. In the past, I did not like approach of integration of the MCU support based on the layers specific to individual chip producers. NuttX has had much more unified approach. RTEMS lacks broad MCU support but the core and scheduler has been much more durable and scalable and it is prequalified for serious serious space grade missions now. But the precise support targets small number of expensive platforms. Support for Raspbery Pi and others is mainly a toy to allow playing with system on cheap hardware which can lead to core enhancements and or gaining experience to continue in real flight applications with appropriate HW...

But I agree that Zephyr gains momentum and API refines to real POSIX alternative now.

A Q&A about the realtime patches

mpr22 — Tue, 25 Jul 2023 07:58:27 +0000

Live audio performance is a hard realtime workload.

A safety-certified RTOS is overkill for running Ardour or Blue or Cecilia.

A Q&A about the realtime patches

DemiMarie — Mon, 24 Jul 2023 23:04:04 +0000

I seriously question whether Linux is the correct platform for hard realtime work, as opposed to a safety-certified RTOS.

A Q&A about the realtime patches - CAN / CAN FD subsystem testing

andy_shev — Fri, 21 Jul 2023 22:07:26 +0000

Does Zephyr support CAN? It may be the best choice as the RTOS is well discributed.

A Q&A about the realtime patches - CAN / CAN FD subsystem testing

paulj — Thu, 20 Jul 2023 09:50:40 +0000

Oh, and token ring didn't need nodes to be statically configured with a priority-ID before hand, did it? :)

A Q&A about the realtime patches - CAN / CAN FD subsystem testing

paulj — Thu, 20 Jul 2023 09:49:53 +0000

Yeah, a bit! Also, as the creator pointed out, it's also definitely /not/ TMDA, cause it's not synchronous - no master clock. There's just synchronisation via the BEACON frame, CSMA/CD, and the local clocks that run to determine the min slot times (hopefully those clocks can't drift too much from each other in the short time they need to be roughly consistent).

A Q&A about the realtime patches - CAN / CAN FD subsystem testing

Cyberax — Wed, 19 Jul 2023 18:31:25 +0000

> The highest priority node (ID 0) sends a BEACON frame that marks the start of an ordered series of "transmission opportunities"
Token Ring v2.0!

A Q&A about the realtime patches - CAN / CAN FD subsystem testing

ppisa — Wed, 19 Jul 2023 10:09:55 +0000

I am not sure if Ethernet prevails in the count of connection in automotive. I agree that for IP based traffic and interconnection of main nodes it can be more straightforward than CAN XL - up to 2 kB frames, full push pull symmetric data phase etc... But is seems that simplicity of CAN and it iterfacing leads to actual increase of CAN FD cores on SoCs, i.e. 14 of these on a single SoC, so I expect that local electronics nests will even more intensively use CAN in future. And there is CAN FD lite which can replace LIN and can be integrated into chips directly as I2C but allows to communicate even out of single PCB.

By the way, it funny that our uLAN protocol mentioned above provided deterministic arbitration with 11 times lower pulses at arbitration phase (max 64 nodes on the net) with dominant recessive logic and then switched to push-pull data phase and provided priority rotation without tokens or other single point of failure nodes for cases where 16 full time data flood pushing units have been used at given time. All that with commodity HW in 1991 and fully documented and open source without patents costs etc...

A Q&A about the realtime patches - CAN / CAN FD subsystem testing

paulj — Wed, 19 Jul 2023 09:30:10 +0000

There seems to be a push to replace CAN with "Automotive Ethernet". Basically, 10Base-T1S for a shared ethernet bus, using a single twisted-pair, with CSMA/CD. "But, doesn't CSMA/CD suck for bounded latency and performance collapse under load?", yes, so they're augmenting CSMA/CD with a "Phy-Level Collision Avoidance Reconciliation Scheme" (PLCA RS). In PLCA-RS the nodes on the ethernet bus are each assigned an ID, the IDs encode a priority (like CAN). The highest priority node (ID 0) sends a BEACON frame that marks the start of an ordered series of "transmission opportunities" - each node uses CSMA/CD access + a local timer to determine when it has a slot to transmit.

Kind of an adaptive TDMA, without a shared synchronised clock - but nodes still have to run local clocks.

A Q&A about the realtime patches - CAN / CAN FD subsystem testing

ppisa — Wed, 19 Jul 2023 09:27:55 +0000

But CAN protocol goes through full networking packets SHB machinery in the case of the SocketCAN implementation. Simple character drivers provided less comfort but has not been dependent on soft-irq mess. There the light on the tunnel end now, the individual NAPI real threads per interface. So may it be, we will se improvement in our tests over years.

Another problem is that most SocketCAN drivers provide only single FIFO Tx queue and when message from its head is the only one participating in arbitration then classical priority inversion is inevitable. So there is really large space to improve situation. CTU CAN FD IP core is prepared for that because it allows to change order of messages participating in Tx arbitration without need to request stop attempts to succeed on the bus for the current one. This setup allows to maintain virtual multiple FIFO queues. Then the head messages witch highest priority specify from which queues are messages pushed into HW Tx buffers and if FIFO with higher priority appears then the messages in HW Tx buffers can be rescheduled.

But that would be long way for SockeCAN and even our driver to get there. We probably test that approach during our planned bring-up of CAN FD support in RTEMS.org which is much smaller RTOS and we have possibility to introduce more principal changes in shorter time.

A Q&A about the realtime patches - CAN / CAN FD subsystem testing

paulj — Wed, 19 Jul 2023 09:10:19 +0000

Presumably why they mentioned CAN. CAN has prioritisation. High priority node can always transmit, and collision resolution is bounded, via synchronisation. Assuming you have some bound on higher-priority nodes, that should let you have bounded latency on all nodes. Not switched though.

A Q&A about the realtime patches - CAN / CAN FD subsystem testing

taladar — Wed, 19 Jul 2023 07:06:08 +0000

> Even that discussion confirmed that networking in its current form is not more suitable for areas requiring bounded latency than when many years ago, there are were and are applications which need at least some level of time predictability.

Wouldn't networking with bounded latency require circuit switching instead of packet switching?

A Q&A about the realtime patches

ppisa — Tue, 18 Jul 2023 21:00:36 +0000

The mentioned out of tree project which required special chip level of support at UART chips level is uLAN RS-486 protocol https://ulan.sourceforge.net/ which use in our instruments predates Linux. The actual driver uses single source for DOS, Linux, Windows, NuttX and system-less bare metal application. API is and C level compatible even with assembly driver for 8051 chips. C driver is usable for ISA, PCI, PCIe and USB HW but with limited range of chips.

It would be great to integrate code into mainline Linux, but it would require complete rewrite to get rid of all compatibility with old kernels and other systems and I have minimal resources to investment into rewrite. I have no personal income from this project for its whole existence even that others use it to obtain funding from European Union. And our main area of investment into laboratory instruments has been used by others often without paying the penny as well.

So I focus to CAN/CAN FD where we strive to go into Linux, NuttX, QEMU, RTEMS mainline with or even more without funding, because this is area where broader community would profit.

As for the TTY layer based project, we have implemented on Volkswagen contract LIN bus solution - slLIN https://github.com/lin-bus/linux-lin which I try to maintain usable for others, again mostly in my spare time when I do not teach https://comparch.edu.cvut.cz/ nor do work on or company motion control systems and other solution for partner companies and even ESA now...

A Q&A about the realtime patches

flussence — Tue, 18 Jul 2023 20:44:32 +0000

I've seen a few last around 10-15 years. Reiser4 and BFQ come to mind.

Those are bolt-on features in a framework designed for pluggable drivers though. RT is a fundamental rework of the kernel to make it do things beyond what it's designed/allowed to do, in hostile environments (cpu scheduler code, a burnout graveyard for enthusiastic hackers), *and* it's survived several major eras in kernel development (not just the major version numbers, but the BKL, and the state of the early-2000s LKML besides).

It's a statistical miracle that this project has gotten this far. It deserves respect for that.

A Q&A about the realtime patches - CAN / CAN FD subsystem testing

ppisa — Tue, 18 Jul 2023 20:44:27 +0000

Even that discussion confirmed that networking in its current form is not more suitable for areas requiring bounded latency than when many years ago, there are were and are applications which need at least some level of time predictability.

We have restarted our initiative to analyze CAN subsystem latency profiles. This time automated with daily results for mainline and RT-Preempt kernels. The results overview https://canbus.pages.fel.cvut.cz/can-latester/ with option to switch to detailed insect for individual loads and kernel variants. Actual tests are running on AMD/Xilinx Zynq based MZ_APO educational kits with our own CTU CAN FD IP cores. But device under the test can be replaced easily, there are no specific needs, only two CAN or better CAN FD interfaces are required. The monitoring and traffic generation system needs precise time-stamping in addition, CTU CAN FD offers 10 ns resolution with common time-base used for four controllers in the given configuration.

The project is part of our CAN/CAN FD support investments into GNU/Linux, NuttX, RTEMS, QEMU... Page with links to some of the efforts including CAN FD IP core project there https://canbus.pages.fel.cvut.cz/ . Some more links to project related to RT and control systems can be found there https://gitlab.fel.cvut.cz/otrees/org/-/wikis/knowbase

Short recapitulation of about 30 years with CAN on CTU and in my projects has been presented at DevConf CZ 2023 https://devconfcz2023.sched.com/event/1MYjG . YouTube https://youtu.be/RwmQYjfzQAg

A Q&A about the realtime patches

vstinner — Tue, 18 Jul 2023 18:42:55 +0000

GRsecurity maintained large patches outside upstream and it took a few years to get most of them merged upstream, no? I don't know how many years, but it seems like it's still a work-in-progress 😁

A Q&A about the realtime patches

Cyberax — Tue, 18 Jul 2023 17:32:19 +0000

> Just curious: are there any well-known (mostly) out-of-tree patchsets that have survived 25+ years?

DAHDI drivers for telephony: https://github.com/asterisk/dahdi-linux

A Q&A about the realtime patches

tsoni.lwn — Tue, 18 Jul 2023 16:54:29 +0000

..and let's not forget the FSM Labs RTLinux story around 2003-2004.

A Q&A about the realtime patches

andreashappe — Tue, 18 Jul 2023 15:23:02 +0000

Just curious: are there any well-known (mostly) out-of-tree patchsets that have survived 25+ years?

I remember when I first saw rt patches on the lkml, mad respect for the people developing/maintaining them (also a reminder of how quickly time passes).