[Myron 0]

Как вообще можно говно мастдайное как операционную систему рассматривать? Она же только для игрулек годится! И создавалась изначально как пускалка игр!!!

Да все в жизни начинается с игр. Дальше развитие к спутникам, станкам, связи и т.д.

 

[@Ark 0]

Еще несколько вопросов, если позволите. Раз уж Вы такой знаток данной темы. :rolleyes:

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

а "чистое время" выполнения некоторой последовательности команд. Которое, как предполагается,

теоретически может быть прервано разнообразными прерываниями, в том числе, системными.

Как это решается?

 

[Gruffly 0]

Еще несколько вопросов, если позволите. Раз уж Вы такой знаток данной темы. :rolleyes:

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

а "чистое время" выполнения некоторой последовательности команд. Которое, как предполагается,

теоретически может быть прервано разнообразными прерываниями, в том числе, системными.

Как это решается?

 

Переключение задач происходит в соответствии с system-slice. Как сказано выше, это время зависит от Win - платформы

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

Если нет - надо принимать меры по снижению задач на переключение.

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

Еще один пример показан в коде выше - переключить текущий контент на real-time и не забыть вернуть его обратно в текущий или normal.

 

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

К примеру - LatencyMonitor называется.

Основная задача - проследить на затраты interrupt service routine (ISR) и Deferred Procedure Call (DPC) и, что не критично для работы - отключить.

 

P.S.

На самом деле, не все так плохо. Если явно не запущены затратные приложения, то измерения по rdts и QPC дают правдивые и релевантные значения без специальной настройки тестовой машины.

 

P.P.S.

У Майкрософт, есс-но, есть свои инструменты для тестирования ISR & DPC:

 

tracelog -start -f test01.etl -dpcisr -UsePerfCounter -b 64
tracelog -q
tracelog -update -b 128 -max 40
tracelog -stop
tracerpt test01.etl -report dpcisr.txt -df
или
tracerpt test01.etl -report dpcisr.txt -f HTML

Изменено 8 апреля, 2017 пользователем Gruffly

[@Ark 0]

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

Если нет - надо принимать меры по снижению задач на переключение...

Погодите. Переключения между задачами - это одна проблема.

Но ведь есть еще низкоуровневые аппаратные прерывания, которые "съедают" определенное время.

И повлиять на них никак нельзя, поскольку они имеют наивысший приоритет.

Как это учитывается?

 

[Gruffly 0]

Погодите. Переключения между задачами - это одна проблема.

Но ведь есть еще низкоуровневые аппаратные прерывания, которые "съедают" определенное время.

И повлиять на них никак нельзя, поскольку они имеют наивысший приоритет.

Как это учитывается?

Это следующий уровень, Вы к нему готовы? :)

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

 

[@Ark 0]

Это следующий уровень, Вы к нему готовы? :)

А, Вы?

Меня, собственно, только именно этот уровень и интересует.

Я Вам задавал "наводящие вопросы", чтобы выйти на эту тему. Прикидываясь "чайником". :)

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

Как быть с конвейером команд и данных? Перестановкой команд при выполнении их процессором из конвейера?

Ненормированным временем выполнения отдельных команд процессора? Это еще не все вопросы...

Вы готовы на них ответить?

Или хотя бы обсудить?

 

 

[Gruffly 0]

Уровень углубления зависит от того, что нам нужно.

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

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

Только, что провел тест на стандартной Win7 (не отключал ресурсные сервисы типа анивиря и пр., не маскировал прерывания, не переводил в реал-тайм и тд)

Тестовое время работы приложения 60 сек.

Из них:

ISR max = 42 мкс, всего 0.036% (DirectX)

DPC max = 483 мкс, всего 0.11 % (Nvidia driver)

HPF (hard page faults) = 0.08% (AVP подгадил)

Итого: 0.23%

 

По процессорам время на прерывания:

CPU0 = 0.345 ms

CPU1 = 0.013 ms

CPU2 = 0.013 ms

CPU3 = 0.018 ms

Итого: 0.65%

 

Вывод:

Ничего особо не предпринимая в части снижения затрат на системные вызовы (административно или программно),

мы получили погрешность 0.65% замера времени исполнения (60 сек) нашей программы.

Много это или мало - каждый решает за себя.

Если много - сначала идут административные действия, затем программные.

Из программных - подсчет статистики по системным вызовам, повышения статуса, маскирование доступных для этого прерываний.

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

[Eddy_Em 1]

Да все в жизни начинается с игр. Дальше развитие к спутникам, станкам, связи и т.д.

Вот только там уже не до игр. Это как с ардуиной: детям очень удобно начинать знакомиться с робототехникой с абдурины. Важно лишь, чтобы они не застряли на этом уровне. Даже ненавистная мне бубунта намного больше возможностей для реальной работы дает, нежели голимая мастдайка.

[yanvasilij 0]

...

Список специальных релизов реал-тайм Windows достаточно большой:

 

Windows 7 Professional for Embedded Systems and Windows 7 Ultimate for Embedded Systems

...

 

Разрешите и мне глупый вопрос, уж больно интересна тема. Были упомянуты инструменты и ОСи для реал-тайм и эмбед. Какие времена циклов может обеспечить Windows Embedded? И вообще насколько это актуально применение Windows Embedded в задачах с жесткими требования ко времени, например в автоматизации (есть примеры применения?)? Может ли она конкурировать, например, с QNX по совокупности факторов (цена, легкость в освоении, время на разработку, надежность и пр.)? Как там с портированием на самодельные аппаратные платформы?

[Gruffly 0]

Как там с портированием на самодельные аппаратные платформы?

На Arduino? :)

 

[Myron 0]

Да все в жизни начинается с игр. Дальше развитие к спутникам, станкам, связи, мечтам и т.д.

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

Для детей это никак не работа. Потом с появлением заинтересованности, успехов и мотивации это может перерасти в любимую работу. Но не всегда.

[Eddy_Em 1]

Для детей это никак не работа.

А при чем здесь работа? Я вообще не понимаю, как можно ходить на работу, как на каторгу! Работа должна приносить удовольствие. Самым идеальным вариантом является работа==хобби.

[Myron 0]

А при чем здесь работа? Я вообще не понимаю, как можно ходить на работу, как на каторгу! Работа должна приносить удовольствие. Самым идеальным вариантом является работа==хобби.

Я это и имел ввиду, когда возражал - см. выше ваши заметки.

[V_G 8]

Были упомянуты инструменты и ОСи для реал-тайм и эмбед. Какие времена циклов может обеспечить Windows Embedded?

Смотря в какие приборы эмбедируют. У нас автоматы поверхностного монтажа работают под управлением Винды XP. У меня векторный анализатор Rohde&Schwarz работает под виндой 7. Все вполне себе риалтайм.

[Eddy_Em 1]

Я это и имел ввиду, когда возражал - см. выше ваши заметки.

Вот поэтому мастдайка и работа — несовместимые вещи. Мне вот понадобилось чертеж сделать в 3D, пришлось запускать эмулятор, а в нем "компас-3D". И хоть мастдайка в данном случае свою непосредственную роль выполняет — роль пускалки игрушек, а не операционной системы, все равно как-то коробит...

А еще мне нравится в коде ковыряться. Мне вот говорят: "пиши на пхытоне", на что я отвечаю, что роднее С ничего себе представить не могу. И, в отличие от пхытона, С значительно меньше косяков может вызывать при переходе, скажем, на новую версию gcc. Хотя, некоторые проблемы и возникают: скажем, свежий gcc матюкается на код, который раньше считался корректным — и приходится добавлять -Wno-trampolines и подобные флаги, чтобы оставить -Wall -Wextra…