Как сократить время между системными вызовами в программе?

лучше всего конечно в драйвере все реализовать

>Есть железо для обмена данными между персоналкой и старой СМ-2М

Что за железо?? Чё нибуть стандартное типа RS-XXX не катит????

>Написал драйвер, поддерживающий операции read(), write(). Логический протокол обмена, состоящий из запросов к СМ-2М, получения и отправки данных и подтверждений реализовал в обычном приложении.

Ну типа правильно сделал

>Но оказалось, что все это не работает под Linux и вот почему. Посылаю запрос к СМ-2М вызовом write() из программы, потом по протоколу должен получить подтверждение от СМ-2М, то есть вызвать read(). Но если планировщик задач снимает мою задачу с выполнения, то задержка между моим write() и read() где-то 100 мс (проверял на осцилографе :-)). А в СМ-2М таймаут 30 мс. Так что, если моя задача снимается с выполнения, то весь обмен накрывается.

А твоя железка случайно не дёргает какихто IRQ??? Если та то на него тебе нужно повесить свой обработчик который подхватит принимаемые данные и отдаст твоей проге когда она затребует.

Если ж всё-таки не дёргает то может на железку надо поставить FIFO-буфера??? Кстати откуда они её вообще взяли???

>Но если планировщик задач снимает мою задачу с выполнения, то задержка между моим write() и read() где-то 100 мс

ты уверен??? такие задержки могут быть только на очень перегруженой машине. Например под оракловой базой обслуживающей 100 клиентов одновременно(что вообщето довольно много).

>1. Перенести реализацию протокола в драйвер, т.е. в один системный вызов. Плохо, потому что теряется универсальность драйвера и чесно говоря за реализацию протокола мне никто не платит.

Возможно неплохое решение но с такой тормознутой железкой у тебя скорее всего вылезут проблемы в другом месте

>2. Попытаться скомпилировать ядро с меньшим тактом работы планировщика (10 мс.) Но заказчик упирается рогами и говорит что это не выход. Думаю, он прав

Где ты/твой заказчик нашёл ядро с тактом работы планировщика больше 10mc ????

Выбрось его на помойку и действительно пересобири ядро с тактом 10 мс.

Если заказчик будет упиратся без серьёзных причин выбрось его тудаже

>

Буфер на чтение это конечно ясно и хорошо, но мне надо прочитать, понять что я прочитал и записать в ответ. Все равно между моим чтением и записью таймаут.

Тоесть после чтения ты опять выполняешь запись???

А ещё можеш попытытся использовать ф-ю sched_setscheduler()

А может тебе всего навсего надо поднять приоритет твоей проге???

> 1. Перенести реализацию протокола в драйвер, т.е. в один системный > вызов. Плохо, потому что теряется универсальность драйвера и чесно > говоря за реализацию протокола мне никто не платит.

Протоколы реализуются в kernel-space. А в приложении можно сделать только непредсказуемое глюкалово. Или отказывайся или пусть платят.

>> 1. Перенести реализацию протокола в драйвер, т.е. в один системный > вызов. Плохо, потому что теряется универсальность драйвера и чесно > говоря за реализацию протокола мне никто не платит.

>Протоколы реализуются в kernel-space. А в приложении можно сделать только непредсказуемое глюкалово. Или отказывайся или пусть платят.

А они тебе хотяб 100$ заплатят? если нет то бросай их пусть идут рыщут в другом месте. Дешевле им разве что студент-дипломник сделает

Да кстати если диплом не завалит