Как опрашивать датчик очень быстро и успевать писать данные в файл ?

Суровый савецкий интерпрайз

Ну и в два потока делай, естественно.

this. Этого будет достаточно. А то тут уже Redis советовали. Нейронку еще посоветуйте прикрутить чтобы байтики с места на место перекладывать.

Лучше спроси в каком тысячелетии проводили последний раз дефрагментацию фс.

Ты в каком тысячелетии живешь? В линуксовых ФС нет нужды в дефрагментации! И так сойдет.

Хотя, в чем фишка: ведь и софта для дефрагментации нет! =D

В линуксовых ФС нет нужды в дефрагментации!

ага.. конечно.. ты лучше подумай, что и lvm нуждается в дефраге и ext4 нуждается.. а в месте они могут ещё как просадить систему.

большие буфера

/thread

Не использую ни одно из этих сортов говен!

И да, если бы фрагментация действительно мешала, уже давным-давно написали бы дефрагментатор проблемных файловых систем!

Да, большие буфера - это круто. Лишь бы не больше пятого размера, а то уже вымя получается…

бгг, но иногда заходит и побольше))

дефрагментация, вот сюрприз, присутствовала ещё с ext3 в e2fsck под флагом -D. кроме того, есть утилиты такие как e4defrag! а вот для lvm дефрагментатора я ещё не видел!

Размер буфера максимально большой, чтобы реже писать на диск.

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

Тебе надо протестировать разные размеры буфера и частоту его записи и определить трёхмерную поверхность в координатах размер буфера - частота записи - величина задержек записи.

Как построишь эту поверхность, так тебе станут ясны оптимальная пара из размера буфера и частоты записи.

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

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

И сделай размер буфера равным размеру сектора ФС или блока секторов на диске, если запись у тебя хардварно идёт блоками секторов.

а зачем писать на диск реже, когда можно писать чаще

Но тем не менее стоит подождать пока не накопится кратное размеру сектора количество данных.

То есть писать буферами меньшими чем размер сектора ФС не стоит.

сменили диск и вот уже у нас новые сик и спин, ну не делают так посчитать максимальную задержку это да, прикинуть сколько будет буфер тоже да, но делать его фикс - маразм. мы больше не работаем с монопольным исполнением, сюрпризов от ОС можно ожидать каких угодно. Ну и да, посмотри сколько ныне размер сектора (: уверен что столько данных нужно ждать?

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

Тимоха, скажу тебе как фрезеровщик фрезеровщику. Не тупи, а изучай матчасть. У контроллера диска свои представления что такое «эффективная запись». И на твои оптимизации ему покласть.

Реально поможет raid контроллер с гигом памяти и включенным write cache. Стоит копейки около 10 тыс. рублей.

raid контроллер с гигом памяти и включенным write cache стоит около 10 тыс. рублей.

Знаток работы ‘‘контроллера диска’’ даст ссылку на такой райдконтроллер с обещанным тобой ценником?

П.С. Цены конечно падают, всё может быть, но как то не верится в то что такой контроллер даже с учётом этого будет стоить150$, по крайней мере новый и не б/у.

уверен что столько данных нужно ждать?

Конечно стоит, информация на ФС и потом на диск ведь пишется секторами(api конечно позволит записать меньше, но это значит что будет записан один не полностью заполненный сектор, причём это если ФС не журналиремая, если журналируемая то на каждую отдельную серию или одиночную запись будет сделано ещё и несколько записей/чтений для работы с журналом.)

Ну и да, посмотри сколько ныне размер сектора (:

А кто заставляет делать очень большие сектора?

Ой батенька, вам в школу

Да, большие буфера - это круто. Лишь бы не больше пятого размера, а то уже вымя получается…

Это да, лучше чтобы буфера были не слишком крупные, но зато в большом количестве.
Ну хотябы четыре, ожидающий заполнения, записываемый,ожидающий сброса на диск, сбрасываемый. (Понятно что если что то затормозило или отработало быстрее то работа пойдёт с ожидающим буфером.)

А что не так?

иди читай ata4

заметь, оно уже далеко не свежее

https://topcomputer.ru/tovary/569111/

Там ничего не написано про 1 ГБ кеша на контроллере.

У меня такой был, там гиг. Меньше сейчас новые и не делают.

Можешь сказать в кратце что там, /trollmode/блочную запись заменили на последовательную?//trollmode/

Ну ок, ты держал вещь в руках, тебе виднее, но по крайней мере в спецификации на странице продукта о кеше в 1 ГБ ничего не написано.

давай я тоже тролмод - 200 баксов в час

ладно, я сегодня добрый, страница 9 https://documents.westerndigital.com/content/dam/doc-library/en_us/assets/public/western-digital/product/data-center-drives/ultrastar-dc-hc300-series/product-manual-ultrastar-dc-hc310-sata-oem-spec.pdf

поверь, если у вас там ископаемые фекалии вместо железа, то все будет еще хуже

так про какие там приемлемые 1-2мс идет речь? (:

Вот тут написано: https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-writefi…

Вот этот пример пробую, но не входит в callback функцию и работает синхронно. https://gist.github.com/vkocjancic/80c637d8a9cab30383a71f17f6c1bdc8

На девятой странице твоего пдфника ничего не говорится про особенности блочной записи на диск, ну конечно на контроллере диска есть кеш записи, но из написанного никак не следует каких либо выводов о влиянии на быстродействие записи того какие сектора и в какой последовательности будут отправлены на запись.

(То что советую я заметно на глаз скажется только если кеши будут забиты потоком информации)

я советую тебе не пытаться отвечать на сообщения адресованые не тебе, особенно если ты глядишь в книгу - видишь фигу

речь шла о хотелке записи в 2мс, мой скепсис в том, что время поиска дорожки 11мс, время ожидания сектора на дороге еще 4мс

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

у современных винтов сектор 4кб и эмуляция старого железа в 512б,

А где я указывал конкретный размер сектора? И если что, то я ещё вариант и с покластерной записью предлагал.

в 4кб остается открытым, нафига он такой большой

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

речь шла о хотелке записи в 2мс, мой скепсис в том, что время поиска дорожки 11мс, время ожидания сектора на дороге еще 4мс

Но разве это не ещё один аргумент чтобы писать за раз сектор или кластер, то есть сделать большой буфер?

фс, а там сюрприз

Вендопроблемы, на линуксе stride/stipe у ext настраиваемы, а может это у драйвера FAT32?
Не помню, но настроить можно, и скорость дисковых операций это увеличивает, ну а что до винды, то пусть тот, кто её выбрал у Майкрософта нужный функционал и выторговывает.

А вообще настроить внутренние параметры диска идея правильная, хотя ты её явно и не высказал.

ну мля, ты вообще понимаешь как запись в файл происходит нет? оверхед на файл максимум 4кб - байт, при условии, что кластер фс 4кб.

покластерная запись реализуется средствами фс в ОС (: ты блин шутник однако

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

Реализовал асинхронную запись через WriteFileEx, делаю замеры времени исполнения этой функции, иногда 5-10 мс выполняется, хотя работает асинхронно. Почему так происходит с этой функцией ?

А вас не смущает что винда может тупо остановить ваш процесс на время большее чем 3 мс и дать работать другим процессам?

Как вы собираетесь делать гарантированный опрос каждые 3 мс, даже безотносительно проблем с записью на диск?

Условие на винду ставит заказчик, если бы сам решал, то выбрал чего-нибудь по-лучше для таких задач. Нужно успевать делать опрос не реже 1,5 мс просит заказчик. Сейчас это реализовано тупо в цикле опрашиваем, тред работает с флагом THREAD_PRIORITY_TIME_CRITICAL. Я не знаю можно ли организовать по таймеру такой опрос, который бы не реже 1,5 мс.

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

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

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

А воевать с ОС, которая не относится к системам реального времени и выжимать из нее маленькое время отклика, лично по моему мнению, это плохая идея. Тем более если там антивирус по ТЗ.

сброс на диск и опрос идут в одном потоке Размер буфера максимально большой

Удивительно, что могло пойти не так.

А может лучше написать драйвер, работающий в пространстве ядра? Хотя тут используется компилятор от borland, а я понятия не имею, можно ли им как-то собирать полноценные драйвера.

Вообще, лучше обратитесь на форум по программированию под Windows.

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

А какой форум по винде советуете

Понятия не имею, попробуйте RSDN или в интернете поищите, вот например есть уже какая-то тема https://www.cyberforum.ru/drivers-programming/thread2031905.html

https://www.cyberforum.ru/drivers-programming/

Попробуйте понаблюдать дисковую активность, может будут заметные пики, можно будет списать на антивирус. И размер/активность файла подкачки (своп). А может винчестер уже подыхает (SMART).

Дабл-буффером. Приоритет ничего не меняет. Размер буффера такой, чтобы за время наполнения успеаало сбрасывать. С запасом.

Мне нужно

Не нужно. Тебе нужно чтобы один поток опрашивал датчик и если у тебя не ядро реального времени, то за переключения между потоками отвечает ОС и ты даже не особо натюнишь что-то. Т.е. у тебя 2 буфера, 2 потока. Один поток долбит датчик с нужной частотой (примерно нужной на самом деле) и заливает буфера, второй поток сбрасывает при наличии заполненного буфера буфер на диск. Размер буфера сделай кратным размеру блока на диске. Лучше ты ничего не выжмешь, ИМХО.

Нет смысла больше чем в тройной буферизации.

что ему там выжимать, сказано же компьютер 2005 года, значит и винчестер такой же, 2мс там а принципе быть не может, ванную что и фрагментация под 90%, винда небось стоит типа windows2000.

Нет смысла больше чем в тройной буферизации.

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

А подскажи как реализовать опрос, если заказчик хочет, чтобы это было не чаще 1,5 мс. Датчик пасивного типа, опрос идет по запросу из компа. Сам опрос по юсб через библиотеку от производителя платы тратит 0,5 мс, парсинг полученного 2-3 мс. Сейчас в цикле просто идет опрос, я так понимаю с 1,5 мс не получится ничего лучше типа таймеров. Мне просто интересно сможет ли 2 поток вообще брать процессорное время для сброса на диск, если первый поток с высоким приоритетом все время в цикле опрашивает и парсит данные. Или с такими условиями не решить на винде задачу ?

А в корне не хотите поменять решение? Датчик опрашивает микроконтроллер, а уже из микроконтроллера данные читает компьютер.