Специфика написание кода под RTOS RTAI

даст ли такой перенос хоть какую-то выгоду ?

Смотреть надо на архитектуры. RTOS RTOS'у рознь. Когда я писал RTOS, задача стала жёстко экономить аппаратные ресурсы. Пришлось даже регистры видеопамяти высвобождать под системные нужды. И с интерфейсной шиной мудрить.

А чего RTAI а не PREEMPT_RT патч ?

https://wiki.linuxfoundation.org/realtime/start

Переписывать почти ничего не надо будет, только приоритеты назначить

Бенчмарки на интересующее железо можно поискать тут:

https://www.osadl.org/Latency-plot-of-system-in-rack-5-slot.qa-latencyplot-r5...

Спасибо посмотрим в сторону PREEMPT_RT

Что у RTAI, что у Xenomai latency нмже, чем у PREEMPT_RT

Интересно было бы посмотреть сравнение актуальных версий на одинаковом железе

А то вот тут And the winner is: RT-PREEMPT например пишут что performance у RTAI лучше незначительно а проблем хватает:

«The performance edge provided by RTAI has become so small that it is by far outweighed by the enormous build complexity it entails for Machinekit. We have therefore decided to end support for RTAI.»

Вопрос на сколько, и при какой полезной нагрузке. Например, для tcp, по идее, отсутсвие какой нить фишечки типа TCP_NODELAY или SO_BUSY_POLL может все выигрыши от планирования потоков свести на нет при активном i/o.

А вы в своей системе уже нашли текущее узкое место, которое вам портит всё лэйтенси? Или после переписывания под RTOS* будете на асме переписывать?

Интересно было бы посмотреть сравнение актуальных версий на одинаковом железе

https://www.at91.com/linux4sam/bin/view/Linux4SAM/RealTime

по отзывчивости PREEMT_RT сосет у xenomai примерно на порядок, для слабых процессоров есть смысл использовать xenomai, из минусов - трудозатраты высокие, надо переписывать драйверы под ядро xenomai от которых требуется реалтайм

https://gitlab.denx.de/Xenomai/xenomai/wikis/Start_Here

и противопосталять их некорректно - можно использовать одновременно.

С 2.6.38 понятно, но с тех пор наука шагнула далеко вперед и хотелось бы увидеть что-нибудь более актуальное как по ядру так и по железу

а preempt_rt уже полностью hard realtime? по-моему раньше в ядре было только почти все вытесняемо

а preempt_rt уже полностью hard realtime?

Судя по википедии

Real-time systems, as well as their deadlines, are classified by the consequence of missing a deadline:

• Hard – missing a deadline is a total system failure.
• Firm – infrequent deadline misses are tolerable, but may degrade the system's quality of service. The usefulness of a result is zero after its deadline.
• Soft – the usefulness of a result degrades after its deadline, thereby degrading the system's quality of service.

все зависит от размера дедлайна. Если у какой-либо системы дедлайн 1 секунда, то и обычный Линукс будет там hard realtime

по-моему раньше в ядре было только почти все вытесняемо

Если взять вот такое приложение

#include "stdio.h"

int main (void) {
  long int l;
  for (l=0;;l++) {
    if ((l % 1000000) == 0) {
      printf("loop %lld\n", l);
    }
  }
  return 0;
}

И запустить его с наивысшим приоритетом на каждом процессоре

chrt 99 ./inf_loop 

то пинг уже работать не будет

https://wiki.linuxfoundation.org/realtime/documentation/technical_basics/pree...

Fully Preemptible Kernel (RT): All kernel code is preemptible except for a few selected critical sections.

Вот этот «except for» не мешает 100% вытесняемости?

Вот этот «except for» не мешает 100% вытесняемости?

Ядерные треды, в том числе «threaded interrupt handlers» вытеснить можно а кроме этого, я думаю, там мало что остается