[Caxec 0]

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

 

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

[Olej 0]

В общем, при записи буфера время выполнения функции write около 5 мс., но периодически, примерно раз в секунду, функция write висит в течении 300мс, соответственно пропускается куча буферов. Я так понял, что зависон происходит в момент слива кэша файловой системы на диск. Да, файловая система - fat32. Почему сливает так долго, можно ли как-то ускорить процесс?

 

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

 

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

 

3. В QNX не особенно эффективный драйвер IDE. Кроме того, он сильно зависит от режима, как они называют: DMA / без DMA. Смотрите внимательно.

Вы хотите достаточно высокую скорость: 600Кб. * 30 - 18Mb/sec. - это не так мало.

За 120*10**3/18=6000 sec. < 2 час. - вы зальёте весь свой HDD полностью. И что дальше с ним будете делать? :rolleyes:

P.S. могу предположить, что здесь имеет место плохо продуманная архитектура задачи.

 

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

 

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

 

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

[_4afc_ 24]

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

 

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

 

Вот я не у верен что это кеш. Какой QNX 4 или 6?

Может просто головка винчестера улетает в начало диска для обновления фат таблицы, хотя частовато.

 

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

 

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

 

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

 

[Caxec 0]

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

QNX 6.5SP1

 

3. В QNX не особенно эффективный драйвер IDE. Кроме того, он сильно зависит от режима, как они называют: DMA / без DMA. Смотрите внимательно.

Вы хотите достаточно высокую скорость: 600Кб. * 30 - 18Mb/sec. - это не так мало.

За 120*10**3/18=6000 sec. < 2 час. - вы зальёте весь свой HDD полностью. И что дальше с ним будете делать? :rolleyes:

P.S. могу предположить, что здесь имеет место плохо продуманная архитектура задачи.

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

 

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

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

 

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

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

 

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

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

 

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

 

Вот я не у верен что это кеш. Какой QNX 4 или 6?

Может просто головка винчестера улетает в начало диска для обновления фат таблицы, хотя частовато.

 

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

 

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

 

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

 

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

[Olej 0]

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

 

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

 

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

 

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

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

 

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

 

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

 

[Olej 0]

Мне в идеале надо 22,5 Мб/сек считывания из PCI и записи на диск.

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

В QNX, за счёт микроядерности, все временные характеристики будут ещё хуже, да и драйвер IDE там, как утверждается, проработан не лучшим образом.

Так что ваши пожелания находятся вообще достаточно близко к потенциальному пределу возможностей.

 

[gosha 0]

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

 

 

[Caxec 0]

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

 

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

Изменено 2 октября, 2012 пользователем Caxec

[gerber 7]

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

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

[gosha 0]

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

Для начала:

 

Там как-то можно посмотреть, какой режим 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, скорость записи не изменяется?

 

[_3m 4]

... при записи буфера время выполнения функции write около 5 мс., но периодически, примерно раз в секунду, функция write висит в течении 300мс, соответственно пропускается куча буферов. Я так понял, что зависон происходит в момент слива кэша файловой системы на диск. Да, файловая система - fat32. Почему сливает так долго, можно ли как-то ускорить процесс?

может обновление фат мешает. Надо его исключить.

Попробуйте на заранее дефрагментированном чистом диске создать пустой файл на весь размер записи.

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

[Caxec 0]

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

[gosha 0]

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

 

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

 

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

 

Выложите 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