Comments 142
заказчики хотели только windows в принципе, или только windows как интерфейс? первая приходящая в голову идея - исполнить realtime часть в чёрном ящике с OS действительно реального времени, с буферизацией данных, а на стороне windows оставить управление и приём данных уже из буфера. скорее всего, там такие стоимости оборудования, что +1 ящик не играет роли. почему решили так не делать?
Да, казалось бы проще объединить АЦП и память в одном устройстве, а результат уже передавать в систему.
Так и было раньше. От этого решения отказались.
а почему отказались? очень интересная история, хочется подробностей.
Использовался DSP фирмы Texas Instruments, C6678 "Keystone I". В нём 8 ядер. Одно ядро занималось тем, что получало данные от FPGA по PCIe, шесть занимались применением фильтров к полученным данным, восьмое отправляло всё это богатство в UI через обычный Ethernet. Решение отлично работало на 128 каналах, но уже при 512 каналах начало скрипеть сразу по нескольким параметрам: ширины канала Ethernet перестало хватать, скорости выполнения фильтров перестало хватать, памяти перестало хватать, скорость получения данных из FPGA была на грани допустимого. (Там был PCIe Gen. 1). Можно было заменить DSP на Keystone II или что-то более существенное, поднять скорость Ethernet до 10 гигабит в секунду, перейти на другое подключение, но это увеличивало стоимость продукта, а она и так не низкая. Потом возникла гениальная мысль: почему бы всё, что можно, не перевести на GPU, оставив CPU только менеджмент, и не воткнуть FPGA в слот PCIe компьютера напрямую? Это исключает дорогущий модуль с DSP и, теоретически, должно сильно уменьшить latency. Я взял под козырёк и начал копать в указанном направлении.
Для визуального просмотра в реальном времени такие скорости наверно не нужны и 32 разряда на мониторе не отразить.
Визуальный просмотр в реальном времени нужен. Нейрохирурги умеют реагировать на нужный паттерн на экране, лично убедился. И 32 бита — тоже не просто так придуманное требование; конечно, оно нужно больше для исследователей, чем для клинического применения, но всё равно нужно.
Я не к тому, что вообще не надо, а о том, что человек может увидеть в реальном времени. Нужно ли все это? Понятно, что потом в спокойной обстановке можно что угодно разглядывать.
Вообще-то нужно. Всё дело в том, как показывать.
Если накладывать сигналы друг на друга, то будут хорошо видны повторяющиеся шаблоны, паттерны в сигналах. И внешний вид такого "слоёного пирога" позволяет врачу уверенно знать, в каком конкретно месте мозга сейчас находится электрод, надо ли его вставить глубже или, наоборот, вынуть.
Вот пример. Белый шум от всего шестнадцати сигналов — но видите, как несколько сигналов описывают плавные дуги между 0 и +2 mV? Вот по таким штукам ориентируется в мозгах нейрохирург.
Честь им и хвала, если они в этом способны разобраться!
Это годы и годы тренировки и непрерывное самообучение. Вот могу поспорить (если у Вас стаж программистом больше 5-6 лет), что глядя на код, сам код Вы уже не видите. Ну, то есть, видите, конечно, но Ваш мозг уже реагирует на определенные шаблоны и вместе с кодом Вы видите ..., как бы это сказать... процесс и можете легко и с достаточной достоверностью предсказать результат. Может быть Вы процесс увидите раньше, а код, как код, распознаете немного позже, Или посмотрите не него с мыслью - что-то тут фигня какая-то, а саму фигню увидите чуть позже. (Привет, Матрица).
Когда мне студенты приносят на проверку свои работы с иллюстративным материалом (диаграммы фазового равновесия, петли магнитного гистерезиса, какие-то другие специфичные графики) и если в них есть неправильность на уровне логики и/или физики, я могу на полминуты залипнуть с мыслью - а что, собственно, мне здесь не нравится? И нахожу же.
вообще говоря, если вы говорите про АЦП, то 32 битных АЦП, да еще работающих на таких скоростях, не бывает...
Поддерживаю, 2^32 уровней квантования хватит, чтобы залезть в область тепловых шумов компонент РЭА, что сводит на нет всякий смысл АЦП таких разрядностей.
тепловые шумы небось на уровне 16 бит, а 32 будет уже на уровне дробных долей заряда электрона.. Тут с 12-ю то не знаешь что откуда навелось..
У нас в прошлом продукте 16 разрядов, и этого объективно мало. В новом будут 24 и 32. И ADC такие есть…
делаем оценку на пальцах. Измеряемые напряжения порядка 10 милливольт. Измеряют обычно измерением напряжения на делителе. Допустим, сопротивление делителя 100 Ом. 1 попугай 32 разрядного АЦП - 2.3*10^-10
Тогда ток, соответствующий 1 попугаю 32 разрядного ацп в вашем случае (10*10^-3 * 2.3*10^-10)/10^2 = 2.3 * 10^-14 А
Один ампер - это один кулон (6.2*10^18 электронов) в секунду.
Найденный выше ток это 2.3 * 10^-14 * 6.2*10^18 = 1.4 * 10^5 электронов. Тээкс, что там у нас со скоростью ? " сорок тысяч замеров с каждого контакта в секунду. " 1.4 * 10^5 электронов поделить на 4*10^4 будет 3.5 электрона. Таким образом элементарный расчет на пальцах показывает, что заявленные характеристики измерительной системы несколько завышены и явно упираются в пределы квантовой механики, и это не считая наводок от работающей аппаратуры, мобильной связи и прочих везде вылазящих 50 Гц.
Хотя и согласен, но замечу, что операционные (тем более нейрохирургические) кабинеты обычно очень хорошо экранируются от любых электромагнитных сигналов, в том числе паразитных наводок от электросети и сотовых станций. По крайней мере должны. Кстати, @Alex_Hitech, и действительно, как организуется питание таких оборудований? Там же любой всплеск на десятки милливольт уже даст нехилую погрешность измерений…
Я с аппаратной частью не знаком, у нас для этого отдельный железячник есть, я завтра его спрошу. Мы получаем сигналы вот с этих устройств, а сейчас делаем ещё своё собственное устройство.
Но с точки зрения неспециалиста — а разве запрещается пропустить сигнал через усилитель перед тем, как его квантовать и оцифровывать?..
Усилитель в общем случае может только добавить шумов, и чем более усилитель «low-noise», тем дороже. Причём при приближении к нулю цена растёт чуть ли не экспоненциально, а ноль так и не достигается.
в описании этих устройств черным по белому написано " All signals are amplified and digitized directly on the headstage, so data on the interface cables is purely digital and immune to noise pickup". Т.е. все сигналы усиливаются и оцифровываются на месте. Вот тут есть описание используемого чипа https://intantech.com/products_RHD2000.html и даташит https://intantech.com/files/Intan_RHD2164_datasheet.pdf В описании читаем, что там используется 16 битный АЦП. 64 канала, скорость АЦП 30кГц на канал и стандартный протокол SPI для передачи данных. Чип производит максимум 2байта*30000*64=3.84 Мегабайта данных в секунду. С другой стороны, у вас в ТЗ вероятно стоит "320 мегабайт данных в секунду", 320/3.84*64 =5333. Т.е. для получения заданной скорости передачи данных вам потребуется 5333 электрода и столько же каналов АЦП.
Спросил у нашего железячника. Он говорит, что 24-битные ADC, которые приносят что-то разумное из интервала (-5mV, +5mV) существуют, и мы будем использовать именно их. А до 32 бит добьём нулями.
В смысле не отразить? 12 бит на субпиксель=36бит на пиксель.
Только Windows в принципе. На Linux можно было бы добиться результата с меньшим геморроем и с меньшим latency, но клиенты при слове Linux впадают в кому.
Хотя жалко, потому что нынешняя программа, в отличие от предыдущей, легко портируется на что угодно, а низкая задержка (latency) перед обратной стимуляцией в качестве реакции на определённый входящий сигнал невероятно важна. С Linux`ом мне удалось снизить задержу до 4 миллисекунд, что, в принципе, достаточно для предотвращения эпилептических припадков. Из-под Windows пока не получается снизить меньше чем 6 миллисекунд, это на грани для эпилепсии и слишком долго для болезни Паркинсона.
С другой стороны, я пока в самом начале разработки продукта, так что, может, удастся натянуть сову на глобус и добиться идеальной 1 миллисекунды между генерацией импульса в мозге и отправкой ответной стимуляции обратно в мозг.
Раньше, в предыдущей версии продукта, был отдельный DSP, без операционки вообще, который я программировал, и который выполнял три четверти работы. В новой версии от этого DSP отказались, потому что исчерпали его возможности, а более дорогой DSP ставить не хотят: цену надо снижать, а не увеличивать.
но клиенты при слове Linux впадают в кому.
есть в этом мире несколько человек которые с моей подачи работают на линуксе стилизованном под винду и не знают об этом.. я ни на что не намекаю но...
Я понимаю основную идею, но нет, Windows — объективная необходимость, данная нам в ощущении :-)
Есть специфическое ПО, разработчики которого принципиально отказываются разрабатывать его для ОС, отличных от Windows. Например. Это, де факто, стандарт обработки и визуализации экспериментальных данных в научных исследованиях - можете посмотреть любой рецензируемый журнал и 3/4 графиков там будет из Origin, причем, зачастую, на дефотных темах. Да, Вы сможете его запустить на виртуальной машине, но когда требуется realtime - это не спасет. ИМХО.
но клиенты при слове Linux впадают в кому.
А при словах DSP, DMA, FPGA, PCIe, GPU они не впадают в кому? :)
Я к тому что может клиентам и не обязательно знать технических решений: вот вам компьютер, вот вам специальное приложение на весь экран, запускаемое при включении - включайте и работайте...
Нет, так это не работает, увы. Медицинская техника всё-таки. Надо очень подробно рассказать, что там внутри.
Ну а в чем проблема с альтернативными ОС? Вы подробно рассказываете им про устройство Windows? Может люди лет 30 назад видели какой-то линукс у которого кроме консоли ничего нет, или слышали от кого-то, отсюда и негативное отношение. Может, показ им современного ноутбука, на котором установлен максимально виндоподобный дистрибутив с максимально виндоподобными темами и привычным софтом (тем же матлабом), решил бы проблему?
Я не к тому что линукс был бы лучше в вашей задаче (на самом деле я не знаю), а просто удивило то, что казалось бы такая высокотехнологичная сфера, умные люди, и такие странные, немотивированные ничем кроме инерционности мышления ограничения.
У меня нет никаких проблем с альтернативными ОС, я вон Гайкой занимаюсь в свободное время.
Что б человек что то сделал... непривычное нужен стимул. Пока его нет, и зачем напрягаться?
Так я не вас имею в виду, а врачей нейрохирургов:)
Если этот компьютер подключен к столь серьезному оборудованию, то это уже не просто компьютер, а специализированный аппаратно-программный комплекс, с заранее установленным ПО. Какая там ОС никого не должно волновать, он может вообще должен быть полностью закрытый без права втыкать флэшки в USB (а вдруг вирус).
Нет. Один из планируемых видов продаж новой версии устройства — просто плата с источником питания. Студент сможет собрать свой собственный компьютер, отвечающий нашим минимальным требованиям, воткнуть в него нашу плату, загрузить и установить ПО, докупить электроды и, теоретически, сможет проводить исследования на открытом мозге не хуже, чем какой-нибудь НИИ. Но откуда у студента-медика компьютер без Windows? :)
Больше интересно откуда у него открытый мозг?
Мозг необязательно должен быть человеческим. Большинство исследований мозга выполняются на крысах и мышах, — их мозг очень похож на наш, а стоят они не в пример дешевле.
А сколько стоит человеческий мозг?
Смотря в какой стране и в каком состоянии. Для исследований ведь не каждый мозг подходит. Нужен живой мозг человека, который страдал от какой-то болезни, перенёс инсульт с повреждением мозга и излечился. У мышек это состояние хотя бы искусственно создавать можно, с людьми так поступать считается негуманным.
А как Вы думаете, что с отчисленными студентми происходит?
мне кажется или либо требования к железу будут очень жёсткими, или это ещё дальше уйдёт от реалтайма?
Как я понимаю даже на своём железе вы не можете гарантировать реалтайма... просто по опыту эксплуатации говорите, что работает достаточно хорошо.... а если другой патч винды, другой чипсет? Не внесёт ли это непредвиденные изменения? Ладно ещё в мозг мышку тыкать, а если человека?
я долго мечтал войти в медицину и больше 5 лет пытался работать с врачами. в итоге пришёл к печальному выводу, что это очень трудные во взаимодействии люди. не умеют мыслить структурно, стараются постоянно держать лицо, привыкли к строгой иерархии и за её пределами работать не обучены. так что непреодолимое и авторитарное требование виндовса тут неудивительно.
Вот и у меня такое же впечатление складывается.
да, это верно, и любое отклонение от разработанных специально обученными людьми методик является смертным грехом, независимо от цены ошибки. и это сложно критиковать, потому мало кто из пациентов хочет, чтобы именно на нём ставили бы опыты с неизвестными исходом.
и этот же подход работает в жизни в целом, за пределами работы.
но я немного о другом.
вот когда пытаешься в рабочей обстановке общаться с врачом, он первым делом решает для себя, кто ты: начальство или младший медперсонал.
если ты начальство, то далее следуют тонны любезности и заверений в глубочайшем почтении и преданности.
а если ты холоп, то поди принеси подотри, подожди два часа под дверью, писать не барское дело, вот тебе обрывочные фразы, конспектируй на лету. задаёшь неудобные вопросы - не тебе, холопу, спрашивать с авторитетов, ты же неграмотен.
все ит-специалисты по умолчанию отнесены к классу холопов.
я немного карикатурно описал, но вот прям как наяву вижу эту историю с линуксом, который объективно лучше, но никто из пользователей не знает, как к нему подойти, а потому нужен виндовс и точка.
Просто эти люди являются величайшими умами, которые совершенствуются в нейро...логии (не знаю, как назвать). И им IT неинтересно. И это правильно. Они не должны заниматься изучением ОС, консоли и т.п. Все должно быть просто и привычно, как топор, они профессиональные пользователи программно-аппаратных комплексов. Потому, как если они будут отвлекаться на изучение ОС, они будут медленнее развиваться как нейрохирурги и их квалификация будет неизбежно падать. Я бы не хотел, чтобы хирург, который будет меня оперировать (тьфу-тьфу-тьфу, здоровья вам всем и добра) изучал бы какие-то другие методики взаимодействия с компьютером вместо хирургии. А Вы?
просто удивило то, что казалось бы такая высокотехнологичная сфера, умные люди, и такие странные, немотивированные ничем кроме инерционности мышления ограничения.Во-первых, не странные, а консервативные (не навреди).
Во-вторых, вы себе представляете, сколько всяческих сертификаций проходит медицинская техника? Серификат на то, на это. И MS, например, запросто может потратить время и деньги на сертификацию своей ОС (и открыть себе дорогу на рынок медицинских устройств), то кто будет заниматься сертификацией линукса? Коммьюнити?
Я уже много лет работаю с PLC. Сейчас массово пошли контроллеры, которые windows-based. Уже несколько лет работаю, но не могу принять контроллер на винде. Контроллер, который может вылететь в синий экран, или стартует чёрт знает сколько времени.
то кто будет заниматься сертификацией линукса? Коммьюнити?
Например, производитель конкретного дистрибутива, который захочет продавать его.
Когда я работал в некоем банке (тоже ведь сфера консервативная и сертификации подверженная, не так ли), там вовсю работали серверы под RedHat. А когда впоследствии начальство обсуждало, что неплохо было бы RedHat заменить на что-нибудь, потому что дорого поддержка обходится, то в качестве альтернативы рассматривался аналогичный коммерческий дистрибутив с платной поддержкой(SUSE, ЕМНИП, был в числе кандидатов), а отнюдь не Gentoo, Debian или, там, LFS
Нет, так это не работает, увы. Медицинская техника всё-таки
Это на самом деле очень интересный момент. По идее сабжевый агрегат косвенно несет ответственность за здоровье. А следовательно должен пройти серьезную сертификацию, и до кучи, если является средством измерения внесен в единый гос реестр СИ. И вот в этом процессе подобные архитектурные "решения" следовало бы присекать на корню ИМХО.
Раньше, в предыдущей версии продукта, был отдельный DSP, без операционки вообще, который я программировал, и который выполнял три четверти работы. В новой версии от этого DSP отказались, потому что исчерпали его возможности, а более дорогой DSP ставить не хотят: цену надо снижать, а не увеличивать.
Омерзительно!
Если уж такая проблема с реальным временем - почему не взять SoC - FPGA + ARM - там же поднять ОСРВ какой нить который занимается первичной обработкой/фильтрацией и там же сделать DMA для прямой трансляции в память GPU.....
Хотя если честно я не понимаю почему нельзя всю обработку делать на FPGA? Xilinx VU9P - сейчас можно тысячи за полторы две баксов Взять - плата, с памятью и нормальным Охлаждением...
А что если писать на кучку SSD сразу на FPGA? А потом лениво тащить в любую систему?
Задержка будет большой. Там одно из условий — задержка между генерацией в мозге сигнала определённого вида и отправкой стимуляции в мозг в одну миллисекунду. Определённый вид можно узнать только после фильтра высоких частот, то есть нужно получить данные, пропустить их через фильтр, наложить шаблон, получить соответствие и принять решение о стимуляции за миллисекунду.
Сейчас, в предыдущей версии, где фильтр выполняется на отдельном DSP, задержка 1.2 миллисекунды, и это абсолютный максимум, если сделаю хуже — продукт не выпустят.
Пока что максимальный тест, который я гонял, длился только 7 часов. Я ж только взялся за работу, это первые судороги моего монстра Франкенштейна :-)
Windows в виртуальной машине рассматривался, но был отметён сразу, как только я сказал, что придётся запускать на одном компе две операционки и использовать программу, которая транслирует вызовы из одной в другую. Если запускать внутренний Windows на полный экран сразу при загрузке компьютера, то кто и как будет заботиться об обновлениях внешнего Linux? Он, вообще-то, почти напрямую к мозгам подключён, если оставить его без обновлений, FDA взвоет. Какие-то автоматические решения использовать? - Я не спец в безопасности Linux`ов, боюсь в такие вещи лезть... А если не грузить виртуальную машину сразу, клиенты увидят непривычный интерфейс, впадут в кому и откажутся работать. Мы уже тестировали систему с Linux`ом на студентах, они пугаются. И это закалённые пьянками студенты-медики! Каково будет взрослым именитым докторам?!.. :-)
И, кажется, Matlab, который они будут запускать из-под виртуальной Винды, чтобы обрабатывать результаты расчётов, может работать медленнее, чем в "настоящей" системе.
Я сейчас как раз с подобным работаю, но для arm.
а можно чуть подробнее? там в VM выньда тоже будет arm, или эмуляция x86? просто у меня сложилось впечатление что arm версия винды максимально безполезна, под неё софта почти нет (даже родного мелкомягкого офиса не подвезли)..
и какие задачи этим решаются?
то кто и как будет заботиться об обновлениях внешнего Linux?
Из под Windows по SSH к нему управляющим софтом стучаться или через VNC показывать в окошке.
Всю физическую периферию включая встроенное видео, сетевой адаптер и USB-контроллер при этом пробросить в Windows чтобы люди не пугались.
Это надо будет сисадмину больницы объяснять. Причём не мне, я разработчик, а продажникам и техподдержке. Ни те, ни другие Линукса в глаза не видели, и не горят желанием смотреть... И я их прекрасно понимаю.
Так поставляйте программно-аппаратный комплекс целиком. Всё равно ведь в системник видеокарту и PCI-плату с FPGA втыкаете.
Нет, в одной из конфигураций мы продаём только плату, а покупатель собирает комп сам.
Ну самое простое решение пусть линуск проверяешь ключ (например флешку с определённым файлом). Если он присуствует-винда НЕ запускается.
Осталось еще для нормального RT использовать процессор , который это может. Я так понимаю тут используется x86 и своя обвязка. x86 RT по сути закончился на 80486 машинах.
А так надо убирать smm , me , psp и прочие плюшки от intel и от amd, которые они там продвигают.
P.S. По крайне мере я не увидел , на чем это реально работает и выводы сделан косвенные по фразе 10 винда
Реально там 64-битный Intel i7-9700 TE и 16 гигов памяти (из которых я кусок отрезал под свои игрища).
Да, Mac рассматривался в качестве основной платформы. Но когда я озвучил, сколько будет стоить оснащение отдела разработки новыми компьютерами, идею отложили до лучших времён :-(
Ну, так то Mini. А я затребовал для разработчиков Pro в ха-а-арошей такой конфигурации. Потому что если у нас одна секунда данных весит гигабайт, а на час нужно около 4 терабайт, то, чтобы сохранить данные с одного ночного прогона (а это обязательный элемент тестирования), нужно иметь хотя бы 32 терабайта свободного места на локально подключённых дисках. То есть нужен ОЧЕНЬ большой системник, чтобы напихать в него много дисков и собрать из них Raid. Из больших системников у Apple только Pro и остался. Ну, а раз уж я раскатал губу на Pro, то не улучшить слегка конфигурацию будет просто глупо.
А где в этой системе присутствует гальваническая изоляция мозга от цепей ПК? ПК же ведь прямо в сеть включен? Или от аккумуляторов питается?
ПК включён прямо в сеть, но FPGA запитана отдельно, через собственный источник питания, и изолирована от питания компьютера. Компьютер до мозгов не добьёт, если только не будет эпического пробоя, при котором уже неважно, что и как запитано.
В предыдущей версии FPGA находился в отдельном вынесенном устройстве в корпусе вместе с DSP и тоже был запитан через свой собственный источник питания.
О питании понятно. А с помощью каких технологий удается изолировать на 4кВ гигабитный поток данных? Я тоже конструирую по работе похожее, но не подобное - обычные энцефалографы и миографы, у них поток данных в 60Мбит/с убирается и время реакции не так критично.
оптический езернет, хотя и для медного есть трансформаторы и на более высокие напряжения, например https://pro-tek5.com/gigabit-ethernet-isolators/
может кто подскажет, а как "добраться" до отрезанных bceditом процессорных ядер и запустить на них что-нибудь baremetalьное параллельно с работающей виндой?
В задачах реального времени таки часто применяют Windows либо франкенштейнов на Windows. Насколько знаю, у KUKA (роботы-манипуляторы) свой.
Вроде как сейчас модно запускать гипервизор, в котором крутится несколько ОС, например, реалтайм-ОС и не реалтайм ОС (включая Windows) в качестве интерфейса.
Я не до конца знаю специфику Вашей предметной области, но если реалтайм-цикл (прием, запись, фильтрация, стимуляция) целиком работает без windows-специфики, то его можно делегировать на RT-ос (даже Linux), а интерфейс/постобработку оставить на винде.
Не вы первые, я думаю, вопросы, как реализовать обновления и сокрытие интерфейса, в промышленности реализованы.
В Intel занимается реалтаймом на линуксе (и немного на винде), в.т.ч. там есть какие-то наработки по гипервизорам. Из интересного: еще возможность оптимизировать передачу данных через Root Complex в разных направлениях (напр. PCIe<->memory) для приоритетного траффика с точки зрения уменьшения задержек.
Если интересно - напшите ЛС, сведу вас с командой, которая этим занимается.
Несколько вопросов по существу:
Поэтому всё это богатство данных, помимо показа на экране, придётся записывать на жёсткий диск. Все 1,3 гигабайта данных в секунду. И потом читать в Matlab`е, NeuroExplorer`е или другой программе.
То есть по факту реалтайм не нужен, достаточно регистрировать данные без потерь. Например сложить в большой буфер и выгребать 10-20 раз в секунду.
Они применяются к каждому входящему замеру, увеличивая количество данных, о которых система должна заботиться, вчетверо, и поднимая количество генерируемых данных до 1,3 гигабайта в секунду.
Если эти данные вычисляются из измерений, зачем это делать в реалтайме? Почему не сделать на постобработке?
полный цикл обработки данных за 200 микросекунд
5кгц, не так и много, приходилось обрабатывать на порядок большую частоту прерываний без особых проблемм и извратов.
Даже если я выделю реальную память при помощи MmAllocateContiguousMemory, я получу только виртуальный адрес, достучаться до которого плата не сможет.
Странное утверждение, а как же другие то делают? Про MmGetPhysicalAddress Вы не в курсе?
Однако процесс не может всё время бежать с запретом на любые прерывания, Винда за этим строго следит и может наглеца прибить.
А Ваша плата что, вообще прерываний не генерирует? Данные выгребаются опросом регистров в цикле? Попахивает хреновой архитектурой.
То есть по факту реалтайм не нужен, достаточно регистрировать данные без потерь.
Я несколько раз явно касался этого вопроса в комментариях. Нет, реалтайм нужен, потому что по регистрируемым данным может приниматься решение о стимуляции. Там ещё и ограничение latency в 1 миллисекунду между генерацией сигнала в мозге и началом ответной стимуляции. Без реалтайма никак. А решение принимается не по raw data, а по filtered data. Конкретно — по данным фильтра высоких частот. Поэтому фильтрацию придётся выполнять прямо внутри этого реалтайма.
Про MmGetPhysicalAddress Вы не в курсе?
Вот честно — нет. :) Я вообще не виндузятник, я программист DSP. Это мой первый код для Винды за очень-очень много лет, чуть ли не с окончания обучения.
5кгц, не так и много
40 килогерц, но данные, удобства ради, приходят сгруппированными в пакеты по 8 замеров.
А Ваша плата что, вообще прерываний не генерирует?
Конечно, нет!!! Прерывания — это зло. Вся архитектура решения построена так, чтобы в нём не было ни единого прерывания, только polling. Мы делали замеры, и в среднем на обработке прерывания теряется больше времени, чем на опросах.
Нет, реалтайм нужен, потому что по регистрируемым данным может приниматься решение о стимуляции.
А это решение принимается в том же драйвере что и опрос? Каким образом оно настраивается? Что делать если надо изменить критерии — драйвер переписать? Что будете делать если (когда) логика принятия решения не влезет по времени в 1 поток?
А регистрация и отображение как делается? Данные же нужно отдать на user level, или по крайней мере другому драйверу.
Прерывания — это зло
Которое генерит много разных устройств, например видеокарта или контроллер SATA. И DISPATCH_LEVEL не защищает от аппаратных прерываний.
А это решение принимается в том же драйвере что и опрос?
И да, и нет. В одном из путей принятия решения решение о стимуляции принимается прямо внутри драйвера, для чего прямо в драйвере есть функционал фильтрации, и драйвер принимает от управляющей программы параметры (через общую память): какой канал фильтровать с какой частотой среза и при каком значении начинать стимуляцию с предопределёнными параметрами. В другом пути сигнал о начале стимуляции приходит от управляющей программы, которая, в свою очередь, получает его либо от исследователя через нажатие кнопки (либо в UI, либо физической, на пульте дистанционного управления), либо программно, от пользовательского скрипта.
Но требование latency до одной миллисекунды не включает в себя время, которое затрачивает на работу пользовательский скрипт. Если пользователь сделает там бесконечный цикл до принятия решения, это не проблема.
Что будете делать если (когда) логика принятия решения не влезет по времени в 1 поток?
У нас очень сильно многопоточная система. Приём и передача данных — это уже два разных потока, и бегут они на двух разных ядрах, а уж в интерфейсе их вообще штук двадцать.
И DISPATCH_LEVEL не защищает от аппаратных прерываний.
Да, кое с чем придётся смириться. Но смириться с неизбежным злом и способствовать ему — это разные вещи. У нас в программе прерываний нет.
Я очень надеюсь, что эту дичь закроют на этапе сертификации. Использовать абсолютно непригодное решенеие в системе которая может реально нанести вред пациенту, это уже за гранью. Тем более что вред может быть отложенным, неявным и так далее.
Никто и никогда не даст гарантии что ваше ядро не пересечется по кэшам/MMU с остальными. Есть еще слабая такая надежда - вырезать полностью CPU socket, со всеми ядрами, доступом к локальной памяти и, в случае с AMD, локальным PCIe. Но вот когда проснется ME/PSP и решит что пора бы занятся чем то более интересным чем людей лечить не скажет никто.
Думаю что никто не станет утверждать что современная медицина хотя бы в общих чертах представляет себе процесс мышления. Не на уровне - сюда электрод и вот у пациента нога дернулась. И последствия сбоя timeline стимуляции наверняка предсказать невозможно. Те люди которые делали предыдущую систему наверняка о чем то таком задумывались.
Hard RT он на то и RT что не бывает второй свежести. Либо от начала до конца процесса должно быть X инструкций всегда, либо это уже soft RT а там можное еще memory allocations добавить и придумать еще какое нибудь звучное название.
В вашем случае, если ваши фильтры использующеся в принятии решений, по какой то причине не лезут в FPGA (что само по себе странно), то можете посмотреть в сторону скажем семейства Nvidia Jetson. Там и акселератор есть и ARM ядра и PCI-E. Не RT траффик можно вообще гнать через USB3.
Ну или Xilinx ultrascale+ mpsoc, FPGA + matlab пишите фильры, есть ядра ARM R5, есть А53, есть PCI-E, как базовый, так и IP.
Возможно я ошибаюсь, но описанное в статье очень похоже на забор из костылей, выстроенный вокруг непродуманной архитектуры изделия.
Тем не менее, это решение имеет то преимущество, что оно таки работает.
Однако, я хоть и далеко не специалист по архитектуре ядра Windows, но некоторое (очень некоторое, всего лишь на уровне многократного прочтения книги «Windows Internals» самых разных изданий) представление о ней имею, и в этом свете смотреть на это решение мне реально страшно. Я бы лично такое писать не взялся, так что автору, раз он смог — честь и хвала. Только вот, я бы добавил в статью ещё дисклеймер типа «не пытайтесь повторить это дома» — но это уже чисто личное мнение.
Странное утверждение, а как же другие то делают? Про MmGetPhysicalAddress Вы не в курсе?
Может, оно и лучше — быть не в курсе? Ибо в документации по MmGetPhysicalAddress сказано:
Do not use this routine to obtain physical addresses for use with DMA operations. For information about the proper techniques for performing DMA operations, see Adapter Objects and DMA.
(причину, почему так написано в документациии, врать не буду, не знаю).
А по ссылке из цитаты — весьма немаленький кусок про то, как надо писать драйверы устройств DMA под Windows по фэн-шую. IMHO разбираться в этом — не быстро (предполагаю, ибо сам не пробовал), а найти и нанять человека, который уже разобрался — не дешево, и опять же — не быстро.
Может, оно так даже и лучше, как автор сделал — максимально независимо от Windows: забрать себе кусок памяти, ядро процессора, и не сильно париться по поводу того, что там в остальной системе происходит?
так что автору, раз он смог — честь и хвала.
Тут как в том анекдоте: «Ша, уважаемый, ша. Вы знаете, что это за алмаз и сколько он стоит. Я знаю, что это за алмаз и сколько он стоит. А Моня не знает, и он-таки сделает». Я просто не знал, во что влезаю. Знал бы — подумал бы дважды и всё равно бы не полез.
забрать себе кусок памяти
К этому кстати тоже есть вопросы, у автора:
bcdedit /set removememory
А как потом найти отпиленный регион в адресном пространстве? Таки уверены что он ни с чем не перехлестнется?
Мы делали замеры, и в среднем на обработке прерывания теряется больше времени, чем на опросах.
Если не секрет, сколько проходит от момента генерации прерывания до входа в обработчик (средне/макс)?
А как потом найти отпиленный регион в адресном пространстве?
Через список ресурсов железа в registry. Да, он ни с чем не перехлестнётся, потому что находится за пределами доступной для Винды памяти. (Так адрес, в общем-то, и вычисляется, — берётся последний доступный Винде кусок памяти и к его адресу прибавляется его размер).
Если не секрет, сколько проходит от момента генерации прерывания до входа в обработчик (средне/макс)?
На нашем оборудовании 9-15 микросекунд.
Ибо в документации по MmGetPhysicalAddress сказано: Do not use this routine to obtain physical addresses for use with DMA operations
Вот только прикол в том, что «феншуйный» AllocateCommonBuffer как раз и состоит из MmAllocateContiguousMemorySpecifyCache + MmGetPhysicalAddress, проверил лично. Подозреваю, что использовать DMA API рекомендуют на случай систем с защитой системной памяти от «злонамеренного» DMA, где нужно будет не только выделить регион памяти, но и разрешить в него DMA. Но в таком случае и отпиленный кусок памяти, про который система не в курсе, также будет в пролёте.
Так адрес, в общем-то, и вычисляется, — берётся последний доступный Винде кусок памяти и к его адресу прибавляется его размер
Вот только про set removememory в документации сказано что его назначение — имитация систем с небольшим объемом памяти в целях тестирования, и соответственно нет никаких гарантий того, какой регион будет отрезан, и что он вообще будет один.
Вот только про set removememory в документации сказано
Тем не менее, это официальная инструкция программы WinDriver от Jungo, которая рассказывает, каким образом передавать в Винду очень много данных от PCIe устройства через DMA. Так что все вопросы к ним.
А в данном решении используется dma или rdma?
То есть мне кажется логичнее в описанной ситуации писать из fgpa сразу в память GPU и оттуда дальше куда-нибудь тем же rdma, например в сетевуху.
P.S. выше только моё предположение. У нас в универе хотели что-то такое сделать - melanox сетевуха + пачка видюх + Intel edison. Поэтому и подумал о таком варианте.
Я возможно, что-то упустил, но у меня никак не складываются цифры - с одной стороны, это потенциальный риск для здоровья человека (и страховые выплаты порядка 1 млн $), с другой суммы порядка 10к$ - это дорого (как за готовое решение, так и за девелоперские маки), использование дешёвого Intel Core со специально отключенным ECC для памяти вместо Xeon/любого AMD и т.д.
Ну и технический вопрос - как вы учитываете, что Windows может перезагрузить GPU драйвер в любой момент?
Это решение (пока) не для клиник и не для людей, а для исследователей и для животных, так что риски для здоровья нас волнуют мало. И сумма будет не 10к$, стоимость продукта начинается от 25к$ и, в максимальной конфигурации, хорошо превышает 250к$. При этом DSP пошёл под нож из-за подорожания на 60, кажется, долларов. Потому что в себестоимости буквально каждый цент на счету; никто не будет готовить и выпускать продукт, не обеспечив себе хотя бы 600-800% чистой прибыли.
Ну и технический вопрос - как вы учитываете, что Windows может перезагрузить GPU драйвер в любой момент?
Никак не учитываем. Просто пропишем это в мануале, и пусть у юзера голова болит.
"Драйвер бежит", "задачи бегут" - это что за ужас? Лексикон малограмотных пионеров, не осиливших адекватные эквиваленты англоязычной терминологии, овладевает и разработчиками ядерного уровня?
Как-то очень печально такое видеть.
Вы удивитесь, но очень многие употребляют этот термин, произошедший из дословного перевода с английского “running”. Сначала сам напрягался, потом привык.
Так я знаю, откуда он взялся, и что его употребляют всякие недоучки, не осилившие родного языка. Но у автора статьи речь вроде адекватная, откуда ж туда затесался этот словесный хлам?
Ну так я не из России, русский — далеко не основной мой язык, русскоязычные термины я не знаю и знать, в общем-то, не обязан. Перевёл, уж как сумел.
Всё же открыл профиль. Израиль. Да, те из моих знакомых, кто выражается аналогичными терминами, тоже в основном оттуда. Наверное, это локальная особенность…
Не за и не против такого перевода. Все поняли суть, хоть и не «устоявшееся» и кто-то словит секундный loading при первом прочтении. Я вот даже внимания не обратил…
Судя по тексту, у Вас отличный русский, потому и удивило такое сочетание. В техническом русском аналогами run будут "работать", "выполняться", "исполняться" и т.п.
Я действительно написал и опубликовал несколько произведений на русском, но русский всё-таки не мой основной язык.
Лексикон малограмотных пионеров, не осиливших адекватные эквиваленты англоязычной терминологии, овладевает и разработчиками ядерного уровня?
Неужели вам больше нравятся эти самые эквиваленты — не те, которые официальные, а те, которые реальные: «драйвер крутится», «задачи крутятся»?
Как интересно! Лет 20 назад решал похожую задачу, но в меньших масштабах. Надо было в режиме реального времени управлять платой ЦАП/АЦП со временем порядка 10 мкс. И конечно все умели пользоваться только windows. Решение было грубым но надёжным - просто обрывал прерывания через cli / sti и все. В win 98 можно было напрямую, при переходе на win 2000 пришлось драйвер написать
Подобные задачи уже были решены для звука уже 13 лет назад в виде готового решения.
https://www.kvraudio.com/news/solid_state_logic_announces_mx4_128_channel_madi_i_o_with_dsp_powered_ssl_software_mixer_11290
даже уже с фильтрами.
каждая карта 64in/64out - можно воткнуть несколько.
И конвертеры есть, тоже готовые (MADI-based)
Может уже и не выпускаются.
В том числе и по сетке (DANTE)
Готовый продукт, с уже готовый стандартом ASIO.
до максимального (DISPATCH_LEVEL)
Какая то билиберда в ключевом моменте. Проблема в том, что это не максимальный, а всего третий. Максимальный тридцать второй Это значит что ОС все же прерывает поток когда ей хочется. Кстати, физическую память выделить не сложно. IoAllocateMdl + MmBuildMdlForNonPagedPool без каких то там cli утилит. Все очень печально.
FIFINALLY
Это единственное что в статье понравилось scoped exit идиома. Даешь плюсы и лямбды в кернел.
Реальный Windows. Пишем realtime под окошками