Выбрать стратегию...

← →
MBo (2003-06-28 10:40) [0]

Исходные данные:
некий девайс поставляет данные со скоростью 22 мегабайта в секунду. Прием осуществляется так:
1) разрешаю связной плате генерировать прерывание
2) при получении его вызывается callback-функция, записывающая фрейм данных в буфер
3) выставляю флаг, что прерывание обработано, можно принимать следующий фрейм

Принятые данные нужно сохранять на диск в течение по меньшей мере 10-и секунд. Опробовано:

а) Если это делать до 3), то происходят пропуски фреймов, т.е. не обеспечивается максимальная скорость приема. Кэширование под XP эффективнее, пропуски одного-двух фреймов изредка (но и это недопустимо), под 98 периодически задержка до 2 секунд.

б) данные неоднородны, и RLE сжатие выигрыша по объему не дает, арифм. сжатие (LZ) сжимает в полтора раза, но напрягает процессор - опять же пропуски. Хаффмана не пробовал, но думаю, что примерно то же, что и c LZ.

в) MMF в памяти, запись данных туда, сброс на диск по окончании накопления - при заполнении свопа опять же начинаются тормоза. С 512 мег. оперативки это наступает позже, но все равно неотвратимо

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

д) Дополнительный поток с несколько меньшим приоритетом, данные в главном потоке заносятся в потокозащищенный список, тут же демаскируется прерывание (3), а доп. поток потихоньку сбрасывает данные на диск, освобождая память. Требования по памяти несколько уменьшаются. Пропусков фреймов нет при указанном времени (10 сек, ок. 220 мегабайт), но постепенно список все же разбухает, вызывая свопирование.

Хотелось бы добиться увеличения времени непрерывной записи.

Возможно, кому-то приходилось сталкиваться с подобными задачами (при записи видеопотока, например, хотя его обычно сжимают).

← →
Malder (2003-06-28 11:52) [1]

MBo, я вообще с такими объемами не работал, но может не стоит особо упирать на логику программы ? Может просто увеличить мощность железа ? Типа 2-ух процессорная система (сжатие) + RAID массив на SCSI 0 обязательно должно помочь, особенно если ты это сейчас все проворачиваешь на IDE, да еще винчестеры старенькие...

← →
Юрий Зотов (2003-06-28 12:23) [2]

Я бы попробовал вариант Г, но с высоким приоритетом процесса. И именно маппинг с записью по указателю, а не просто в файл.

← →
vuk (2003-06-28 13:07) [3]

Можно попробовать модифицировать метод Д таким образом, чтобы в памяти сидел некий буфер (один блок памяти), в который заведомо поместится несколько фреймов и в процессе работы его больше не увеличивать. Буфер размещается один раз и это исключит как фрагментацию памяти так и дополнительное свопирование. Можно вместо одного блока для нескольких фреймов сделать несколько (каждый для одного фрейма), но все их выделить сразу и не возвращать системе память.

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

← →
Vad (2003-06-30 01:34) [4]

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

Должен быть вариант е) в котором облегчены условия приема
информаци путем(навскидку):
- физического распаралеливания приема
- аппаратной компрессии данных на входе
- ПДП
и т.д.

← →
Evgeny V (2003-06-30 06:09) [5]

Работал по методу д, но у тебя проблема со скоростью записи на диск, насколько я понял. Посчитаем скорость прохождения данных по IDE(или может у тебя SCSI) и скорость получения инфо от твоего устройства. Извини не помню точно цифр, взял с инет http://www.techmarket.ru/news/news_120701.shtml и http://www.siemens.kharkov.ua/600-800.htm, там стоит 16 и 33 мегабита в сек(без учета скорости самого винта, он тож еще тормозит, ну вот флэш винт он конечно просится, но все равно мало по скорости), ну если ты не будешь жать данные, то так и будет у тебя идти с накоплением(явно не обрадывал и не сказал ничего нового, а сжатие тож время требует, правда если с потерями можно, то есть варианты). А нельзя приостанавливать работу девайса, чтобы он потом продолжал передачу с того же места где остановили, или это сплошной поток? Или как вариант, два винта на разных шинах, и распарралель работу, буфер туда, буфер сюда,и асинхронная запись, потом тебе сшивать файл правда прийдется(ну конечно тож не очень красиво, но так делают:-))).

← →
AZ (2003-06-30 06:15) [6]

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

← →
Evgeny V (2003-06-30 06:19) [7]

http://xdd.h1.ru/stati/kontr/mylex_prod.html, добавка к скоростным усройствам, 40 мегабайт в сек:-)))

← →
MBo (2003-06-30 06:42) [8]

Спасибо откликнувшимся
>Malder
>может не стоит особо упирать на логику программы ?
>Может просто увеличить мощность железа ?
Не могу согласиться. Именно совершенствование логики позволило добиться увеличения количества сохраняемых данных в несколько раз.

Вариант с рейдом уже обсуждали, но возможностей приобретения пока нет, тем более что задача является временной - отладочной.
Кстати, интересно, каких честных (Не сказки про загрузку 200 мегабайт в StringList за секунду :)) скоростей записи удается добиться, скажем, в варианте с двумя ATA100 винчестерами 7200 на RAID

>Юрий Зотов
запись осуществлялась именно по указателю. Результаты повышения приооритета всего процесса неустойчивы - иногда, но не всегда наблюдается некоторое улучшение

>vuk
Экспериментирую с подобными подходами

Vad AZ Evgeny V>
Система быстрого съема данных нужна временно, для отладки устройства, поэтому материальных вложений ждать не приходится :(
Максимум, на что можно рассчитывать - временно добавлять памяти до 512 и ставить самый быстрый из имеющихся винт.

>нельзя приостанавливать работу девайса
Увы, интересует как раз динамика процесса без пропусков и потерь. В принципе, достигнутое время уже разумное, осталось добиться устойчивой работы.

← →
MBo (2003-06-30 07:03) [9]

>два винта на разных шинах, и распарралель работу, буфер туда, буфер сюда,
ОК, попробуем при возможности.

← →
vuk (2003-06-30 11:01) [10]

to MBo:
>Кстати, интересно, каких честных (Не сказки про загрузку 200
>мегабайт в StringList за секунду :)) скоростей записи удается
>добиться, скажем, в варианте с двумя ATA100 винчестерами 7200
>на RAID
Ну если ATA100, то вот...

Обзор Promise FastTrak100 TX2 Pro
http://www.fcenter.ru/articles.shtml?hdd/315

Обзор, понятное дело, старый - сейчас более актуальными вещами являются ATA133 и SerialATA.

← →
MBo (2003-06-30 11:22) [11]

>vuk
спасибо за ссылку, любопытно.

← →
panov (2003-06-30 12:10) [12]

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

← →
vuk (2003-06-30 13:01) [13]

to panov:
>Можно попробовать использовать кольцевой буфер с методом д)
На мой взгляд эффективнее будет использовать несколько буферов, каждый для одного фрейма, т.к. в этом случае сильно облегчается чтение и запись фрейма - он однозначно начинается с начала буфера. Опять же проблем с межпотоковыми блокировками меньше.

← →
Zebra (2003-06-30 14:46) [14]

Такая глупая идея:
Если мегабайт на 300 в памяти сделать виртуальный диск
на него и писать.
Если все только для отладки.

← →
MBo (2003-06-30 15:00) [15]

Zebra
Это опробованный вариант в)
Штатно на машине 256М, иногда можно будет ставить 512

← →
vuk (2003-06-30 15:13) [16]

Кстати о птичках... Сейчас пишу сборщик данных, поступающих от маршрутизатора cisco по протоколу NetFlow. Видимо придется организовывать похожую схему с множеством буферов. Правда, там объемы данных маленькие.

← →
Polevi (2003-06-30 16:25) [17]

а если попробовать писать блок данных асинхронно несколькими потоками, как CopyFile у Рихтера с портами завершения, если я не ошибаюсь

Выбрать стратегию... Найти похожие ветки