Добрый день всем!

Такая ситуация. Имеется компьютер Lippert на Celeron 650MHz и чипсетом VIA VT8606. К нему по шине PCI подключена плата захвата данных. Плата в режиме мастер пишет в буфер в памяти липперта данные. Размер буфера 600Кб. Буфер заполняется 30 раз в сек. и должен сливаться на диск. Диск IDE подключен 40 жильным кабелем, на 120 Гб. В общем, при записи буфера время выполнения функции write около 5 мс., но периодически, примерно раз в секунду, функция write висит в течении 300мс, соответственно пропускается куча буферов. Я так понял, что зависон происходит в момент слива кэша файловой системы на диск. Да, файловая система - fat32. Почему сливает так долго, можно ли как-то ускорить процесс?

1. Здесь не лучшее место спрашивать конкретные вопросы по QNX. Спрашивайте на qnx.org.ru, например. Здесь никто в QNX толком не понимает...

2. Кстати, и QNX какой: 4 или 6?

3. В QNX не особенно эффективный драйвер IDE. Кроме того, он сильно зависит от режима, как они называют: DMA / без DMA. Смотрите внимательно.
Вы хотите достаточно высокую скорость: 600Кб. * 30 - 18Mb/sec. - это не так мало.
За 120*10**3/18=6000 sec. < 2 час. - вы зальёте весь свой HDD полностью. И что дальше с ним будете делать?
P.S. могу предположить, что здесь имеет место плохо продуманная архитектура задачи.

4. Для QNX fat32 совершенно чужеродная система. Используйте родные qnx4/qnx6 файловую систему.

5. Попробуйте взять под свой контроль сброс буферов на диск: сопровожайте каждый write операцией sync.

6. Вынесите всё, что касается write в отдельный процесс/поток с пониженным приоритетом ... и не будет у вас "пропускается куча буферов"(с).

Вот я не у верен что это кеш. Какой QNX 4 или 6?
Может просто головка винчестера улетает в начало диска для обновления фат таблицы, хотя частовато.

Я делал два процесса с расшаренной между ними памятью. Один забирал данные из буфера PCI в мой буфер (размером несколько мегабайт, а второй отписывал или обрабатывал данные из этого буфера разделённого пополам. Всё успевало.

Данные лучше копировать из PCI не по 32, а по 64 или даже 128 бит - может быть прирост в зависимости от конкретной мамки.

Дрючить диск каждые 33мс - в корне неверно!

QNX 6.5SP1


Как раз час и есть время работы всей системы. Винт потом вынимаем - и на обработку


Попробовал qnx6 и qnx4. В qnx4 слегка побыстрее, но всё равно раз в секунду - тормоза, где то на 0,2 сек.


После этого всё стало ещё медленнее - теперь просто каждую запись тормоза где-то 70-80 мс, а мне надо 33 мс.


Запись и так в отдельном потоке - он получает сигнал от основного и по нему пишет из буфера, указатель на который объявлен глобальным, на диск.

Может дело в медленном интерфейсе? Просто нет под рукой кабеля uata100 для 2.5 дюймовых дисков. Пользую 40 жильный uata33.



А какая была средняя скорость обмена в Вашем проекте? Мне в идеале надо 22,5 Мб/сек считывания из PCI и записи на диск. Устройство на шине PCI пишет данные в режиме мастер. Бёрст сделал 128 слов - пришлось переконфигурировать регистры чипсета, т.к. биос не давал настроить и ограничивал 32 словами. Завтра попробую сделать два переключающихся буфера, сейчас у меня в один и тот же и пишет и из него же сохраняет на диск.

Это значит, что вы видите реальное время записи без буферизации - 70-80 мс.



Если вы укладываетесь с записью в отдельном потоке в условия задачи, то это вам и решение.
Если нет, то вы упёрлись в скорость записи на ваше устройство: файловая система + IDE.

Можете попробовать буферизовать N последовательных циклов под единую операцию write... с малой вероятностью это может помочь.

А иначе: меняйте оборудование + меняйте архитектуру проекта (скорее 2-е).

22,5 Мб/сек - это уже достаточно близко к пределу для некоторых устройств хранения в Linux (для сравнения), см.: Производительность диска.
В QNX, за счёт микроядерности, все временные характеристики будут ещё хуже, да и драйвер IDE там, как утверждается, проработан не лучшим образом.
Так что ваши пожелания находятся вообще достаточно близко к потенциальному пределу возможностей.

Какой номер режима dma/udma для диска используется?

Изначально использовался ATA 33 (пишет при запуске компа). Стомегабайтный файл копировался где-то 15 сек. Теперь сделал кабель 80 жильный. В биосе пишет ata 100, файл 100Мб копируется секунды 4. Но разницы в скорости записи буфера вообще никакой! Как было 0,05 сек и 0,15 сек. раз в секунду, так и осталось. Кстати, задержки зависят от размера кэша файловой системы - чем больше кэш, тем реже, но продолжительнее задержки.

Идеологически правильным решением будет организация цепочки буферов DMA (например, 256 буферов по 600 кБ), указатели на которые организованы в кольцевой буфер. Это позволит рассинхронизировать полностью потоки, управляющие захватом данных и записью на диск. Думаю, что идея очевидная и понятная - поток, управляющий захватом начинает по очереди заполнять буфер за буфером, при достижении определённого порога (скажем, заполнено 16 из 256 буферов) начинает работу поток записи на диск, опрожняющий буфера. Тут главная задача - добиться, чтобы затянувшаяся операция записи не приводила к остановке потока захвата данных.
Цепочка буферов позволит снивелировать спонтанные задержки, вызванные записью на диск, но не решит проблему, если задержка носит систематический характер, в этом случае нужно искать другие архитектурные решения.

Для начала:

Там как-то можно посмотреть, какой режим udma выбрал devb-eide
http://www.qnx.com/developers/docs/6.3.0SP.../devb-eide.html

Options:
udma=mode
Set ultra DMA mode. Values for mode can be 0-6 (or off to disable).

Какой режим авто-определил и использует devb-eide, как-то можно посмотреть в /proc/

Какой HDD используется? Какова скорость записи по datasheet?

Для измерения скорости записи можно ли выполнить:

fwrite(f);
fflush(f);

Какая скорость записи получилась?

Если сформатировать в qnx6 filesystem, скорость записи не изменяется?

может обновление фат мешает. Надо его исключить.
Попробуйте на заранее дефрагментированном чистом диске создать пустой файл на весь размер записи.
Данные будуте писать в уже существующий файл поверх старых. Обновления фат при этом не должно быть. Но может выполняться подгрузка буфера фат. Как это обойти - не представляю.

Вроде получилось. Пришлось уменьшить в два раза разрядность данных. Соответственно, буферы теперь тоже в два раза меньше. Сделал два банка буферов - пока один сливается на диск, второй заполняется. В каждом банке по 8 буферов - чтобы операции записи на диск были реже. Поставил минимальныое значение кэша файловой системы - при этом время записи примерно выравнивается, нет провалов каждую секунду. Файловая система - QNX4. QNX6 пробовал - гораздо медленнее.

Я бы все-таки разобрался, с диском.

Измерил скорость записи на диск.

Какое ядро ОС грузится (как называется)? Собственной сборки?

Выложите log загрузки системы. И настройки сборки ядра /boot/build/


#sloginfo

http://www.openqnx.com/phpbbforum/viewtopic.php?t=10261


Скорость чтения с диска ok?
#cp -V /dev/hd0 /dev/null
http://www.openqnx.com/phpbbforum/viewtopic.php?t=10261