LINUX.ORG.RU

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


0

0

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

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

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

Вижу три выхода:

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

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

3. Из драйвера при получении / отправке данных генерировать программное прерывание, которое обрабатывать в пользовательской программе (опять вызывать из него драйвер), сократив таким образом время между обращениями к драйверу. Если кто знает как это сделать, или еще какой-нить способ решить проблему, напишите.


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

anonymous
()

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

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

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

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

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

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

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

cvv ★★★★★
()

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

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

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

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

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

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

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

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

>

cvv ★★★★★
()
Ответ на: комментарий от cvv

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

snilga
() автор топика
Ответ на: комментарий от snilga

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

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

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

cvv ★★★★★
()

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

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

sts
()
Ответ на: комментарий от sts

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

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

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

cvv ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.