[amaora 39]

Все знают такую структура данных как FIFO. В данном случае она используется для кольцевой записи во время работы и в дальнейшем анализа хвостового обрезка, который остался записан в логе. Интересует запись в некую структуру, которая обеспечивает прореживание устаревающих данных. Так чтобы общая длина хранимой истории стала значительно больше за счёт того, что старые данные хранятся прореженными. Вижу несколько вариантов.

1) Каскадирование FIFO. Несколько FIFO и прореживание между ними, каждый n-й элемент вышедший из первой очереди кладётся во вторую и так далее. Нужно заранее разбить доступную память на несколько блоков под каждую FIFO и выбрать коэффициенты прореживания.

2) Один блок памяти, но запись производится по псевдослучайному индексу. Интерес представляет алгоритм выбора псевдослучайного индекса для записи так чтобы обеспечивались требуемые характеристики, распределение плотности записи по времени. А так же возможность прокрутить генератор псевдослучайных чисел в обратную сторону, чтобы собрать лог в правильном порядке. Но можно добавить в каждый элемент обратную ссылку (на предыдущий элемент) и время регистрации данных, а не пытаться их восстановить исходя из алгоритма записи.

Кто такое делал? Как это называется? Пока считаем, что данные хранятся в RAM.

 

 

[RobFPGA 97]

1 hour ago, amaora said:

Интересует запись в некую структуру, которая обеспечивает прореживание устаревающих данных.

Пока не понятен смысл для всего этого.  Какова будет ценность случайной выборки событий в таком логе? 

[Arlleex 333]

Мне, скорее, не понятна изначальная мысль, чего хочет сделать автор.

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

Речь об этом же?

[amaora 39]

31 minutes ago, RobFPGA said:

Пока не понятен смысл для всего этого.  Какова будет ценность случайной выборки событий в таком логе? 

Данные идут со скоростью ~2 Мб/сек, памяти для сохранения лога около 90 Кб. Когда образуется аварийная ситуация логирование останавливается и записанные данные сохраняются/выводятся для дальнейшего анализа. Данные в основном вещественные, токи, напряжения, температуры. Для анализа может быть полезно видеть не только последние 45 мс но и предысторию за несколько минут до аварии.

[RobFPGA 97]

23 minutes ago, amaora said:

Для анализа может быть полезно видеть не только последние 45 мс но и предысторию за несколько минут до аварии.

Это понятно, но повторю вопрос "Какова будет ценность случайной выборки?"  
Периодичность логирования определяется  необходимой вероятностью поймать соответствующе событие. Для параметров типа, токи напряжения, etc это определяется динамикой системы (полосой частот) 
Если изначально реже нельзя то какой смысл прореживать ? Ведь вы теряете информацию.  
Если можно реже, то почему изначально  выбрана высокая частота для логов? 

[jcxz 361]

11 часов назад, amaora сказал:

Данные идут со скоростью ~2 Мб/сек, памяти для сохранения лога около 90 Кб. Когда образуется аварийная ситуация логирование останавливается и записанные данные сохраняются/выводятся для дальнейшего анализа. Данные в основном вещественные, токи, напряжения, температуры. Для анализа может быть полезно видеть не только последние 45 мс но и предысторию за несколько минут до аварии.

Так и не понял - зачем тут "псевдослучайные индексы"  , но если речь про систему хранения, то что-то подобное я реализовывал лет ~9 назад: В устройство идёт непрерывный поток данных и нужно было сохранение пред- и пост- истории при неожиданном аварийном отключении питания устройства. А также возможность сохранения по какому-либо иному событию (конфигурируемому) при штатной работе в любой момент времени (почти любой - запрет на такое событие выставлялся только на время записи осц. во FLASH по предыдущему событию). Пред-история - длительностью до 1 сек, пост-история - до 10 сек. Поток был ~1Мб/сек. Причём - никакого "останавливания логгирования" не должно было быть: как только устройство включается, оно сразу, максимально быстро должно было стартовать систему записи потока, и одновременно - сделать запись события с пред- и пост-историей осциллограмм об аварийном откл. во флешь. Также - при штатных записях осциллограмм, это должно было выполняться естественно без остановки непрерывного потока.

Для этой системы заложили в устройство 1 FRAM (256КБ) + 2 FLASH. Всё это сидело на одном общем SPI. 2 флешки потому как, из на тот момент доступных SPI-FLASH, ни одна не обеспечивала необходимую скорость потоковой записи (со стиранием). Сейчас уже хватило бы одной. Во FRAM я завёл кольцо из кадров, в которое писал кадры каждую миллисекунду. А во время записи осциллограмм во флешь (формирование записи о событии с осц.), происходило одновременно: запись нового кадра во FRAM каждую мс; чтение кадра из хвоста кольца FRAM (с позиции, вычисленной на основании требуемой длины записи предыстории); запись во FLASH. Никакие "остановки логгирования" не допускались ни на мсек. Т.е. - получалось, что логгируемый поток прокачивался через FRAM, и после - записывался во флешь. Таким образом, в случае аварийного отключения питания, во FRAM всегда есть как минимум 1 секунда данных до аварии (пред-история). В реале объём FRAM получился с большим запасом - можно было писать более чем в 2 раза бОльший поток; ограничение скорости накладывали тогдашние FLASH - малой скоростью стирания. Остаток FRAM (больше половины) использовался для других нужд: файловой системы с конфигом и пр., журналов событий и т.п.

"Прореживания" по ТЗ никакого не требовалось, но если бы было нужно, можно было также непрерывно читать поток с выхода кольца во FRAM и писать в другое кольцо (более медленное) с необходимым прореживанием. Какие-то "рандомные числа" имхо - тут что-то совершенно левое.

Эти девайсы уже много лет находятся в серийном производстве.

[amaora 39]

17 hours ago, RobFPGA said:

Это понятно, но повторю вопрос "Какова будет ценность случайной выборки?"  

Не случайной а псевдослучайной, но можно и по регулярному правилу выбирать, я ограничений не ставлю. Главное обеспечить заданную фукнцию плотности записи (частота от времени) и алгоритм был бы простой, однородный и эффективный. Выбор параметров функции плотности может остаться и за пользователем, где-то надо 20мс-30кГц + 10с-50Гц, а в другом месте 5с-50Гц + 90с-10Гц. Такое настраиваемое сжатие с потерями.

[RobFPGA 97]

1 hour ago, amaora said:

но можно и по регулярному правилу выбирать, я ограничений не ставлю

Ну так  как вы и писали в самом начале - цепочка FIFO. Выход  первого фильтруете и децимируете как надо и результат на вход следующего FIFO буфера, и так далее.