Добрый день! Возникла такая проблема, стабильно принимать сообщения раз в 1 мс. Операционная система Windows, пишу на Qt, протокол передачи UDP. Размер сообщения 13 байт. Сообщения стабильно посылает контроллер устройств раз в 1 мс. Выносил в отдельный поток с высоким приоритетом прием сообщений с контроллера устройств, но все равно появляются задержки. Может кто нибудь скажет, как справиться с этой проблемой? Буду очень рад, если предложите свои мысли, решения.

Здравствуйте, leonneon, Вы писали:

L>Добрый день! Возникла такая проблема, стабильно принимать сообщения раз в 1 мс. Операционная система Windows, пишу на Qt, протокол передачи UDP. Размер сообщения 13 байт. Сообщения стабильно посылает контроллер устройств раз в 1 мс. Выносил в отдельный поток с высоким приоритетом прием сообщений с контроллера устройств, но все равно появляются задержки. Может кто нибудь скажет, как справиться с этой проблемой? Буду очень рад, если предложите свои мысли, решения.

А в чем проблема? Сообщения теряются или вам хочется точно раз в 1мс еще какие то действия предпринять? Типа ответ отправить?
В любом случае, Windows это не Real Time система, соответственно время выполнения операций не гарантируется.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, leonneon, Вы писали:

L>>Добрый день! Возникла такая проблема, стабильно принимать сообщения раз в 1 мс. Операционная система Windows, пишу на Qt, протокол передачи UDP. Размер сообщения 13 байт. Сообщения стабильно посылает контроллер устройств раз в 1 мс. Выносил в отдельный поток с высоким приоритетом прием сообщений с контроллера устройств, но все равно появляются задержки. Может кто нибудь скажет, как справиться с этой проблемой? Буду очень рад, если предложите свои мысли, решения.

А>А в чем проблема? Сообщения теряются или вам хочется точно раз в 1мс еще какие то действия предпринять? Типа ответ отправить?
А>В любом случае, Windows это не Real Time система, соответственно время выполнения операций не гарантируется.

Мне нужно принимать сообщения точно раз в 1 мс. Ответ отправлять не обязательно.

L>Мне нужно принимать сообщения точно раз в 1 мс. Ответ отправлять не обязательно.

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

Здравствуйте, Аноним, Вы писали:


L>>Мне нужно принимать сообщения точно раз в 1 мс. Ответ отправлять не обязательно.

А>А что вам должна эта точность дать? В чем фишка? Время точно узнать, когда датаграмма прибудет?

Отвечу поподробней. В общем контроллер устройств управляет фазовращателями(не особо важно в этом контексте). В нем имеется 2 генератора состояний: 1, 0, -1, 0 и 0, 1, 0, -1, которые изменяются циклически.
Первый генератор изменяет свои состояния раз в 1 мс. За 8мс будет такая последовательность 1 0 -1 0 1 0 -1 0. Второй генератор изменяет состояние раз в 1,25 мс. За 10 мс. будет такая последовательность 0 1 0 -1 0 1 0 -1.
Сам контроллер устройств работает на частоте 125 микросекунд. Назовем изменение контроллера устройств за 125 микросек. — тактом. Так вот, каждые 8 тактов будет изменяться положение первого генератора. А каждые 10 тактов изменяется положение второго генератора. 8 — тактов это 1 мс. 10 тактов это 1.25 мс. В программе мне нужно получать точно заданную во времени последовательность генераторов. Например первого генератора, который изменяет состояния с частотой 1 мс. должен получить такую последовательность 1 0 -1 0 1 0 -1 0 1 0 -1 0 за 12 мс. Контроллер устройств шлет сообщения каждые 8 тактов. В сообщении посылается количество тактов и другие показатели(напряж. сила тока). В итоге получив количество тактов я могу восстановить последовательность состояний генераторов, разделив на 32 и 40. Эти числа значат полный оборот генератора состояний. В общем для этого и нужна такая точность при приеме сообщения.

L>Отвечу поподробней. В общем контроллер устройств управляет фазовращателями(не особо важно в этом контексте). В нем имеется 2 генератора состояний: 1, 0, -1, 0 и 0, 1, 0, -1, которые изменяются циклически.
Ох, я надеюсь это не софт для АЭС или спутника какого? Ибо использование стоковой железяки с виндой для таких задач — большая ошибка.

Здравствуйте, ononim, Вы писали:

L>>Отвечу поподробней. В общем контроллер устройств управляет фазовращателями(не особо важно в этом контексте). В нем имеется 2 генератора состояний: 1, 0, -1, 0 и 0, 1, 0, -1, которые изменяются циклически.
O>Ох, я надеюсь это не софт для АЭС или спутника какого? Ибо использование стоковой железяки с виндой для таких задач — большая ошибка.

Если поточнее, то для слежения и наведения антенны в реальном времени.

Здравствуйте, leonneon, Вы писали:

L>В общем для этого и нужна такая точность при приеме сообщения.

Все равно не понятно. Что вы делаете с принятыми сообщениями?

Здравствуйте, leonneon, Вы писали:

L>Отвечу поподробней. В общем контроллер устройств управляет фазовращателями(не особо важно в этом контексте). В нем имеется 2 генератора состояний: 1, 0, -1, 0 и 0, 1, 0, -1, которые изменяются циклически.

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

L>Добрый день! Возникла такая проблема, стабильно принимать сообщения раз в 1 мс. Операционная система Windows, пишу на Qt, протокол передачи UDP

В (обычной) версии Windows эта проблема не имеет надёжного решения.
Обратите внимание на QNX, заточенной под решение таких задач. Qt for QNX ЕМНИП существует и развивается.

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, leonneon, Вы писали:

L>>В общем для этого и нужна такая точность при приеме сообщения.

Pzz>Все равно не понятно. Что вы делаете с принятыми сообщениями?

Если более подробней вдаваться в подробности, то есть один из вариантов решения задачи. У себя в программе я реализовал, подобие контроллера устройств, с такой же частотой вращения 125 микросек, где так же имеется счетчик тактов. Через каждые 1 и 1,25 мс изменяется положение генераторов. Такт как и в контроллере устройств, изменяется от 0 до 65536. Вся суть такая, чтобы контроллер устройств и опорный контроллер вращались на одной частоте, т.е. у них должны совпадать количества тактов. Если как то синхронизировать их работу, то задача будет решена. На Windows можно обеспечить микросекундные задержки, это можно сделать при помощи Boost chrono, это мне подсказали в форуме.

Здравствуйте, leonneon, Вы писали:

L>Если более подробней вдаваться в подробности, то есть один из вариантов решения задачи. У себя в программе я реализовал, подобие контроллера устройств, с такой же частотой вращения 125 микросек, где так же имеется счетчик тактов. Через каждые 1 и 1,25 мс изменяется положение генераторов. Такт как и в контроллере устройств, изменяется от 0 до 65536. Вся суть такая, чтобы контроллер устройств и опорный контроллер вращались на одной частоте, т.е. у них должны совпадать количества тактов. Если как то синхронизировать их работу, то задача будет решена. На Windows можно обеспечить микросекундные задержки, это можно сделать при помощи Boost chrono, это мне подсказали в форуме.

Ваш контроллер что делает, и с какой скоростью должен реагировать?

Здравствуйте, SkyDance, Вы писали:

L>>Добрый день! Возникла такая проблема, стабильно принимать сообщения раз в 1 мс. Операционная система Windows, пишу на Qt, протокол передачи UDP

SD>В (обычной) версии Windows эта проблема не имеет надёжного решения.
SD>Обратите внимание на QNX, заточенной под решение таких задач. Qt for QNX ЕМНИП существует и развивается.

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

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, leonneon, Вы писали:

L>>Если более подробней вдаваться в подробности, то есть один из вариантов решения задачи. У себя в программе я реализовал, подобие контроллера устройств, с такой же частотой вращения 125 микросек, где так же имеется счетчик тактов. Через каждые 1 и 1,25 мс изменяется положение генераторов. Такт как и в контроллере устройств, изменяется от 0 до 65536. Вся суть такая, чтобы контроллер устройств и опорный контроллер вращались на одной частоте, т.е. у них должны совпадать количества тактов. Если как то синхронизировать их работу, то задача будет решена. На Windows можно обеспечить микросекундные задержки, это можно сделать при помощи Boost chrono, это мне подсказали в форуме.

Pzz>Ваш контроллер что делает, и с какой скоростью должен реагировать?

Вообще мой контроллер это бесконечный цикл, счетчик которого является — такт, который изменяется от 0 до 65536 циклически. В цикле стоит задержка sleep(125 микросекунд). В итоге такт изменяется каждые 125 микросекунд. Когда такт становится равным 8(это 1 мс). То изменяем значение первого генератора. Например у него была 1 меняем на 0, затем еще через 8 тактов, 0 на -1, потом -1 на 0. При каждом изменении состояния посылаем сигнал c измененным значением. То же самое и для второго генератора, который меняется раз в 10 тактов. Так же каждый 8 такт, посылаем сигнал со значением такта, т.е. последовательность сигналов будет такая 0 8 16 24 32 40.... и т.д. В итоге нужно количество тактов в моем контроллере приравнять с контроллером устройств, чтобы они изменяли положения своих генераторов синхронно.

Все внимательно прочел.
И так: управлять чем либо real time, windows не может. Вам могут много насоветовать всякой ерунды ( изменить разрешение системного таймера, пользовать высокоточным таймером и.т.д ). Все это херня — Windows не система реального времени ( по сути а ней более менее в реальном времени работает только обработчик таймерных прерываний ) и не надо на нее навешивать несвойственные задачи. Windows (не)нужен: для организации рабочего места оператор а (GUI), для организации высокоскоростных расчетов, как сервер (БД, подключение удаленных клиентов и.т.п) *. Для задач, о которых вы говорите — нужна специализированная железка работающая в RT ( неважно, контроллер со свое прошивкой или однокристаллка с QNX ).

* Вместо слова Windows подставьте по вкусу Linux, MacOS, OpenBSD да хоть Android.

Здравствуйте, leonneon, Вы писали:

L>Вообще мой контроллер это бесконечный цикл, счетчик которого является — такт, который изменяется от 0 до 65536 циклически. В цикле стоит задержка sleep(125 микросекунд). В итоге такт изменяется каждые 125 микросекунд. Когда такт становится равным 8(это 1 мс). То изменяем значение первого генератора. Например у него была 1 меняем на 0, затем еще через 8 тактов, 0 на -1, потом -1 на 0. При каждом изменении состояния посылаем сигнал c измененным значением. То же самое и для второго генератора, который меняется раз в 10 тактов. Так же каждый 8 такт, посылаем сигнал со значением такта, т.е. последовательность сигналов будет такая 0 8 16 24 32 40.... и т.д. В итоге нужно количество тактов в моем контроллере приравнять с контроллером устройств, чтобы они изменяли положения своих генераторов синхронно.

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

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

Здравствуйте, leonneon, Вы писали:

L>Тут проблема еще в том, что есть быстродействующий спектроанализатор, который общается с программой при помощи usb и у него драйвер написан под Windows. Скорость получения от него данных меньше 1 мс. В общем получается процессор сильно нагружается при работе всего этого.

Вы недооцениваете производительность современных процессоров. За 1 мс он успевает не представляете сколько всего сделать.

Здравствуйте, Аноним, Вы писали:

А>И так: управлять чем либо real time, windows не может. Вам могут много насоветовать всякой ерунды ( изменить разрешение системного таймера, пользовать высокоточным таймером и.т.д ). Все это херня — Windows не система реального времени ( по сути а ней более менее в реальном времени работает только обработчик таймерных прерываний ) и не надо на нее навешивать несвойственные задачи. Windows (не)нужен: для организации рабочего места оператор а (GUI), для организации высокоскоростных расчетов, как сервер (БД, подключение удаленных клиентов и.т.п) *. Для задач, о которых вы говорите — нужна специализированная железка работающая в RT ( неважно, контроллер со свое прошивкой или однокристаллка с QNX ).

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

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, leonneon, Вы писали:

L>>Вообще мой контроллер это бесконечный цикл, счетчик которого является — такт, который изменяется от 0 до 65536 циклически. В цикле стоит задержка sleep(125 микросекунд). В итоге такт изменяется каждые 125 микросекунд. Когда такт становится равным 8(это 1 мс). То изменяем значение первого генератора. Например у него была 1 меняем на 0, затем еще через 8 тактов, 0 на -1, потом -1 на 0. При каждом изменении состояния посылаем сигнал c измененным значением. То же самое и для второго генератора, который меняется раз в 10 тактов. Так же каждый 8 такт, посылаем сигнал со значением такта, т.е. последовательность сигналов будет такая 0 8 16 24 32 40.... и т.д. В итоге нужно количество тактов в моем контроллере приравнять с контроллером устройств, чтобы они изменяли положения своих генераторов синхронно.

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

Pzz>Вот у вас есть компьютер. В него каждую миллисекунду приходят по UDP некие данные. А что из него наружу выходит, кроме картинки на экране?

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

Здравствуйте, leonneon, Вы писали:

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

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

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, leonneon, Вы писали:

L>>Тут проблема еще в том, что есть быстродействующий спектроанализатор, который общается с программой при помощи usb и у него драйвер написан под Windows. Скорость получения от него данных меньше 1 мс. В общем получается процессор сильно нагружается при работе всего этого.

Pzz>Вы недооцениваете производительность современных процессоров. За 1 мс он успевает не представляете сколько всего сделать.

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

Здравствуйте, leonneon, Вы писали:

L>Я получаю данные путем поллинга. Т.е. в цикле вызываю функцию, которая ждет получения данных, и функция которая принимает данные. В итоге процессор нагружается. Мне на форуме говорили, что поллинг плохой прием, который неоправданно жрет процессор, и у usb имеется библиотеки приема данных с нормальными callback, но я в эту тему плохо понимаю.

Что значит "ждет получения данных"?

Если вы создали обычный блокирующийся сокет и в цикле зовете recv()/recvfrom(), то эти функции блокируют вызвавший их поток до того момента, пока данные не придут. В заблокированном состоянии поток не жрет процессор.

Если же вы зачем-то перевели сокет в неблокирующийся режим, то recv()/recvfrom() действительно завершатся сразу, даже если данных пока нет. В таком случае, непонятно, зачем вы это сделали.

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, leonneon, Вы писали:

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

Pzz>Еще раз. Есть ваш компьютер с вендой. В него приходят пакеты, как вы выше объяснили. А что из него выходит? Из компьютера с вендой, а не из контроллера устройств.

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

Здравствуйте, leonneon, Вы писали:

Pzz>>Еще раз. Есть ваш компьютер с вендой. В него приходят пакеты, как вы выше объяснили. А что из него выходит? Из компьютера с вендой, а не из контроллера устройств.

L>Из него выходят посылки запроса контроллеру устройств на изменение значения аттенюаторов.

А вот это, пожалуйста, чуть подробнее.

Аттеньюатор — это механическое устройство? Каково время его реакции?

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, leonneon, Вы писали:

Pzz>>>Еще раз. Есть ваш компьютер с вендой. В него приходят пакеты, как вы выше объяснили. А что из него выходит? Из компьютера с вендой, а не из контроллера устройств.

L>>Из него выходят посылки запроса контроллеру устройств на изменение значения аттенюаторов.

Pzz>А вот это, пожалуйста, чуть подробнее.

Pzz>Аттеньюатор — это механическое устройство? Каково время его реакции?

Аттенюаторы относятся к малошумящим преобразователям(МШПр), с их помощью мы подавляем мощность входного сигнала, принимаемого антенной, как я понял. Время реакции не знаю.

L>>>Тут проблема еще в том, что есть быстродействующий спектроанализатор, который общается с программой при помощи usb и у него драйвер написан под Windows. Скорость получения от него данных меньше 1 мс. В общем получается процессор сильно нагружается при работе всего этого.
Pzz>>Вы недооцениваете производительность современных процессоров. За 1 мс он успевает не представляете сколько всего сделать.
L>Я получаю данные путем поллинга. Т.е. в цикле вызываю функцию, которая ждет получения данных, и функция которая принимает данные. В итоге процессор нагружается. Мне на форуме говорили, что поллинг плохой прием, который неоправданно жрет процессор, и у usb имеется библиотеки приема данных с нормальными callback, но я в эту тему плохо понимаю.
Если нет ограничений на версию винды (и можно поставить восьмерку) — возможно вам будет полезно RIO
Но в любом случае натягивание совы на глобус винды на реалтайм — изначально плохая задумка и гарантированного решения на выходе вы не получите.
+ если совсем ничего не поможет стоит заглянуть в настройки сетевой карты и поотключать всякие 'interrupt moderation', burst-ы и т.п.

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, leonneon, Вы писали:

L>>Я получаю данные путем поллинга. Т.е. в цикле вызываю функцию, которая ждет получения данных, и функция которая принимает данные. В итоге процессор нагружается. Мне на форуме говорили, что поллинг плохой прием, который неоправданно жрет процессор, и у usb имеется библиотеки приема данных с нормальными callback, но я в эту тему плохо понимаю.

Pzz>Что значит "ждет получения данных"?

Pzz>Если вы создали обычный блокирующийся сокет и в цикле зовете recv()/recvfrom(), то эти функции блокируют вызвавший их поток до того момента, пока данные не придут. В заблокированном состоянии поток не жрет процессор.

Pzz>Если же вы зачем-то перевели сокет в неблокирующийся режим, то recv()/recvfrom() действительно завершатся сразу, даже если данных пока нет. В таком случае, непонятно, зачем вы это сделали.

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

Здравствуйте, ononim, Вы писали:

L>>>>Тут проблема еще в том, что есть быстродействующий спектроанализатор, который общается с программой при помощи usb и у него драйвер написан под Windows. Скорость получения от него данных меньше 1 мс. В общем получается процессор сильно нагружается при работе всего этого.
Pzz>>>Вы недооцениваете производительность современных процессоров. За 1 мс он успевает не представляете сколько всего сделать.
L>>Я получаю данные путем поллинга. Т.е. в цикле вызываю функцию, которая ждет получения данных, и функция которая принимает данные. В итоге процессор нагружается. Мне на форуме говорили, что поллинг плохой прием, который неоправданно жрет процессор, и у usb имеется библиотеки приема данных с нормальными callback, но я в эту тему плохо понимаю.
O>Если нет ограничений на версию винды (и можно поставить восьмерку) — возможно вам будет полезно RIO
O>Но в любом случае натягивание совы на глобус винды на реалтайм — изначально плохая задумка и гарантированного решения на выходе вы не получите.
O>+ если совсем ничего не поможет стоит заглянуть в настройки сетевой карты и поотключать всякие 'interrupt moderation', burst-ы и т.п.

Можно пожалуйста поподробней, про RIO, в чем его основная задача?

L>>>>>Тут проблема еще в том, что есть быстродействующий спектроанализатор, который общается с программой при помощи usb и у него драйвер написан под Windows. Скорость получения от него данных меньше 1 мс. В общем получается процессор сильно нагружается при работе всего этого.
Pzz>>>>Вы недооцениваете производительность современных процессоров. За 1 мс он успевает не представляете сколько всего сделать.
L>>>Я получаю данные путем поллинга. Т.е. в цикле вызываю функцию, которая ждет получения данных, и функция которая принимает данные. В итоге процессор нагружается. Мне на форуме говорили, что поллинг плохой прием, который неоправданно жрет процессор, и у usb имеется библиотеки приема данных с нормальными callback, но я в эту тему плохо понимаю.
O>>Если нет ограничений на версию винды (и можно поставить восьмерку) — возможно вам будет полезно RIO
O>>Но в любом случае натягивание совы на глобус винды на реалтайм — изначально плохая задумка и гарантированного решения на выходе вы не получите.
O>>+ если совсем ничего не поможет стоит заглянуть в настройки сетевой карты и поотключать всякие 'interrupt moderation', burst-ы и т.п.
L>Можно пожалуйста поподробней, про RIO, в чем его основная задача?
сори, ссылочку забыл вставить: http://www.serverframework.com/asynchronousevents/2011/10/windows-8-registered-io-networking-extensions.html

Здравствуйте, ononim, Вы писали:

L>>>>>>Тут проблема еще в том, что есть быстродействующий спектроанализатор, который общается с программой при помощи usb и у него драйвер написан под Windows. Скорость получения от него данных меньше 1 мс. В общем получается процессор сильно нагружается при работе всего этого.
Pzz>>>>>Вы недооцениваете производительность современных процессоров. За 1 мс он успевает не представляете сколько всего сделать.
L>>>>Я получаю данные путем поллинга. Т.е. в цикле вызываю функцию, которая ждет получения данных, и функция которая принимает данные. В итоге процессор нагружается. Мне на форуме говорили, что поллинг плохой прием, который неоправданно жрет процессор, и у usb имеется библиотеки приема данных с нормальными callback, но я в эту тему плохо понимаю.
O>>>Если нет ограничений на версию винды (и можно поставить восьмерку) — возможно вам будет полезно RIO
O>>>Но в любом случае натягивание совы на глобус винды на реалтайм — изначально плохая задумка и гарантированного решения на выходе вы не получите.
O>>>+ если совсем ничего не поможет стоит заглянуть в настройки сетевой карты и поотключать всякие 'interrupt moderation', burst-ы и т.п.
L>>Можно пожалуйста поподробней, про RIO, в чем его основная задача?
O>сори, ссылочку забыл вставить: http://www.serverframework.com/asynchronousevents/2011/10/windows-8-registered-io-networking-extensions.html

Спасибо посмотрю.

Здравствуйте, leonneon, Вы писали:


L>Тут проблема еще в том, что есть быстродействующий спектроанализатор, который общается с программой при помощи usb и у него драйвер написан под Windows.

Здравствуйте, Eugeny__, Вы писали:

L>>Тут проблема еще в том, что есть быстродействующий спектроанализатор, который общается с программой при помощи usb и у него драйвер написан под Windows.

E__>

Это такой осцилограф, ручки которого можно крутить не только на его передней панели, но и через USB. И скриншоты получать.

Все проблемы от жадности и глупости

Здравствуйте, leonneon, Вы писали:

L>Здесь немного про другое. По сокету я работаю с контроллером устройств. А при помощи usb я получаю данные со спектроанализатора, и чтобы получить от него данные я использую поллинг.

По UDP вы тоже работаете через сокет, потому что никак по-другому с UDP не поработаешь.

Pzz>Я очень подозреваю, что товарищу и не нужен никакой RT. Если ему надо просто аккуратно собирать информацию и показывать ее на экране, времянка вообще особого значения не имеет. Если же он там крутит тяжелыми механическими устройствами, вряд ли ошибка в несколько миллисекунд при воздействии на такое устройство хоть как-то будет заметна. Лишь бы не накапливалась систематическая погрешность (когда ошибка всегда в одну сторону, грубо говоря).
А вдруг это система автоматического слежения за целью в РЛС? Чуть зазевался — и потерял цель

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, leonneon, Вы писали:

L>>Здесь немного про другое. По сокету я работаю с контроллером устройств. А при помощи usb я получаю данные со спектроанализатора, и чтобы получить от него данные я использую поллинг.

Pzz>По UDP вы тоже работаете через сокет, потому что никак по-другому с UDP не поработаешь.

Так это я и подразумевал, по udp я принимаю через сокет сообщения от контроллера устройств, а для работы со спектроанализатором имеется библиотека, и заголовочный файл, в котором описаны функции для работы с ним. Спектроанализатор общается с компьютером через usb.

Здравствуйте, leonneon, Вы писали:

L>На Windows можно обеспечить микросекундные задержки, это можно сделать при помощи Boost chrono, это мне подсказали в форуме.

Очень легко сделать микросекундные (да, в принципе, и наносекундные) задержки, то есть гарантировать, что следующий оператор в рабочем потоке выполнится не ранее, чем через заданное время задержки. И даже никакой boost для этого не нужен (см QueryPerformanceCounter). Но невозможно гарантировать, что оператор выполнится сразу же за предыдущим. Любой поток имеет полное право (и вовсю пользуется этим правом) заснуть хорошо если на десятки, а то и на сотни миллисекунд в любой момент. То есть, Вы устанавливаете задержку в программе, допустим, 500мкс. На 1000 вызовов у Вас в 900 случаях реальная задержка будет 500мкс, в 98 — 10500мкс, а в 2 случаях — 100500мкс.

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

S> Ваша задача на обычном компьютере выглядит совершеннейшей утопией, Вы зря тратите время. И даже QNX тут не поможет, точнее, это будет из пушки по воробьям. Вам нужен специализированный контроллер.
qnx поможет, как и любая ось жесткого реального времени, типа вот. Пример с пушкой врядли подходит. Контроллер поможет конечно под полностью своим софтом, как и скажем, обычный писюк по досом

А>* Вместо слова Windows подставьте по вкусу Linux, MacOS, OpenBSD да хоть Android.

А вот тут вы заблуждаетесь — с помощью нехитрых настроек (современные версии) Linux становится в достаточной мере realtime. SHED_FIFO и rtprio > всего кроме net interrupt и timer interrupt. В общем, я на этом не только собаку съел, и, уверяю, это вполне реально.

Здравствуйте, ononim, Вы писали:

O>А вдруг это система автоматического слежения за целью в РЛС? Чуть зазевался — и потерял цель

Вряд ли. Там еще спектроанализатор есть. Разве что с целью измерить спектр уже после попадания ракеты в цель

Здравствуйте, sz36, Вы писали:

S>Здравствуйте, leonneon, Вы писали:

L>>Отвечу поподробней. В общем контроллер устройств управляет фазовращателями(не особо важно в этом контексте). В нем имеется 2 генератора состояний: 1, 0, -1, 0 и 0, 1, 0, -1, которые изменяются циклически.

S> В такой постановке задача нереальная, а уж тем более под гражданской ОС, типа Windows. Контроллеры должны ставить отметки времени в своих пакетах, тем или иным образом, тогда можно будет попытаться их как-то синхронизировать.

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

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

L>>>Отвечу поподробней. В общем контроллер устройств управляет фазовращателями(не особо важно в этом контексте). В нем имеется 2 генератора состояний: 1, 0, -1, 0 и 0, 1, 0, -1, которые изменяются циклически.
S>> В такой постановке задача нереальная, а уж тем более под гражданской ОС, типа Windows. Контроллеры должны ставить отметки времени в своих пакетах, тем или иным образом, тогда можно будет попытаться их как-то синхронизировать.
L>При принятии сообщения возникла проблема, пакеты идут неупорядоченно, так есть какая-нибудь возможность получать пакет по порядку, не дожидаясь других пакетов, т.е. сразу. Как отправил контроллер устройств сообщение, так у себя в программе получить сразу же этот пакет?
Интересно, те кто изначально проектировал вашу систему чем вообще руководствовались? Явно не спецификациями тех средств, которые они использовать решили.
ЗЫ UDP не гарантирует ни порядок, ни сам факт доставки пакетов
ЗЗЫ по хорошему вам нужна своя реализация UDP и всего что под ним. + про реалтайм уже много чего написано.

Здравствуйте, Figaro, Вы писали:

F>Более того в контроллере для таких случев нужен буффер памяти и видимо генератор стробирующего сигнала с другими временными параметрами, подходящими под обычный комп.

А какая задача будет стоять у контроллера? Как можно будет обеспечить правильный порядок следования сообщений?

Здравствуйте, ononim, Вы писали:

L>>>>Отвечу поподробней. В общем контроллер устройств управляет фазовращателями(не особо важно в этом контексте). В нем имеется 2 генератора состояний: 1, 0, -1, 0 и 0, 1, 0, -1, которые изменяются циклически.
S>>> В такой постановке задача нереальная, а уж тем более под гражданской ОС, типа Windows. Контроллеры должны ставить отметки времени в своих пакетах, тем или иным образом, тогда можно будет попытаться их как-то синхронизировать.
L>>При принятии сообщения возникла проблема, пакеты идут неупорядоченно, так есть какая-нибудь возможность получать пакет по порядку, не дожидаясь других пакетов, т.е. сразу. Как отправил контроллер устройств сообщение, так у себя в программе получить сразу же этот пакет?
O>Интересно, те кто изначально проектировал вашу систему чем вообще руководствовались? Явно не спецификациями тех средств, которые они использовать решили.
O>ЗЫ UDP не гарантирует ни порядок, ни сам факт доставки пакетов
O>ЗЗЫ по хорошему вам нужна своя реализация UDP и всего что под ним. + про реалтайм уже много чего написано.

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

L>>>>>Отвечу поподробней. В общем контроллер устройств управляет фазовращателями(не особо важно в этом контексте). В нем имеется 2 генератора состояний: 1, 0, -1, 0 и 0, 1, 0, -1, которые изменяются циклически.
S>>>> В такой постановке задача нереальная, а уж тем более под гражданской ОС, типа Windows. Контроллеры должны ставить отметки времени в своих пакетах, тем или иным образом, тогда можно будет попытаться их как-то синхронизировать.
L>>>При принятии сообщения возникла проблема, пакеты идут неупорядоченно, так есть какая-нибудь возможность получать пакет по порядку, не дожидаясь других пакетов, т.е. сразу. Как отправил контроллер устройств сообщение, так у себя в программе получить сразу же этот пакет?
O>>Интересно, те кто изначально проектировал вашу систему чем вообще руководствовались? Явно не спецификациями тех средств, которые они использовать решили.
O>>ЗЫ UDP не гарантирует ни порядок, ни сам факт доставки пакетов
O>>ЗЗЫ по хорошему вам нужна своя реализация UDP и всего что под ним. + про реалтайм уже много чего написано.
L>Проектировал не я, мне просто дали задание это сделать. Своя реализация это грубо говоря каждое сообщение помечать при отправке и при приеме проверять, чтобы в общем потом совпадал порядок следования сообщений?
Ну это не своя реализация, а как правильно юзать UDP. + контроль того что все дошло, если надо что все дошло
А под своей реализацией я подразумевал свой стек tcp(udp)/ip дабы гарантировать что все что пришло физически по кабелю пришло в лучшем виде к вам в апликуху. Потому как разработчики _стандартных_ стеков вольны делать с UDP пакетами все что угодно. И делают. Скажем не успела апликуха вовремя чтото вычитать — ну и фиг с ним. Или сделать некий кольцевой буфер и складывать в него пакеты, а вычитывать разумеется тоже в любом порядке могут. Причем так могут делать еще и производители драйверов сетевых карт с эзернет фреймами. То есть если в вашей задаче требуется передавать UDP пакеты с фиксированными задержками, гарантированной передачей и порядком — вам по сути не UDP нужно, а совсем другой протокол, который лишь использует формат пакетов UDP
Ну или научите свой софт мириться с ограничениями стандартного UDP — путем введения порядковых номеров пакетов.

SD>. В общем, я на этом не только собаку съел, и, уверяю, это вполне реально.
В собаку охотно верю.

Здравствуйте, ononim, Вы писали:

Pzz>>Я очень подозреваю, что товарищу и не нужен никакой RT. Если ему надо просто аккуратно собирать информацию и показывать ее на экране, времянка вообще особого значения не имеет. Если же он там крутит тяжелыми механическими устройствами, вряд ли ошибка в несколько миллисекунд при воздействии на такое устройство хоть как-то будет заметна. Лишь бы не накапливалась систематическая погрешность (когда ошибка всегда в одну сторону, грубо говоря).
O>А вдруг это система автоматического слежения за целью в РЛС? Чуть зазевался — и потерял цель

Вы очень проницательны, =).

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, ononim, Вы писали:

O>>А вдруг это система автоматического слежения за целью в РЛС? Чуть зазевался — и потерял цель

Pzz>Вряд ли. Там еще спектроанализатор есть. Разве что с целью измерить спектр уже после попадания ракеты в цель

При помощи спектроанализатора, я получаю мощность сигнала.

Здравствуйте, leonneon, Вы писали:

L>Здравствуйте, sz36, Вы писали:

S>>Здравствуйте, leonneon, Вы писали:

L>>>Отвечу поподробней. В общем контроллер устройств управляет фазовращателями(не особо важно в этом контексте). В нем имеется 2 генератора состояний: 1, 0, -1, 0 и 0, 1, 0, -1, которые изменяются циклически.

S>> В такой постановке задача нереальная, а уж тем более под гражданской ОС, типа Windows. Контроллеры должны ставить отметки времени в своих пакетах, тем или иным образом, тогда можно будет попытаться их как-то синхронизировать.

L>При принятии сообщения возникла проблема, пакеты идут неупорядоченно, так есть какая-нибудь возможность получать пакет по порядку, не дожидаясь других пакетов, т.е. сразу. Как отправил контроллер устройств сообщение, так у себя в программе получить сразу же этот пакет?

Прочитал тему. Кажется что вы вообще нето что нужно делаете.
1. Под виндой вы никак не добьетесь стабильной работы.
2. Вам нужно маркировать пакеты, что бы знать их порядок. И тчо вы будете делать если один из пакетов пропадет?

Здравствуйте, BlackEric, Вы писали:

BE>Здравствуйте, leonneon, Вы писали:

L>>Здравствуйте, sz36, Вы писали:

S>>>Здравствуйте, leonneon, Вы писали:

L>>>>Отвечу поподробней. В общем контроллер устройств управляет фазовращателями(не особо важно в этом контексте). В нем имеется 2 генератора состояний: 1, 0, -1, 0 и 0, 1, 0, -1, которые изменяются циклически.

S>>> В такой постановке задача нереальная, а уж тем более под гражданской ОС, типа Windows. Контроллеры должны ставить отметки времени в своих пакетах, тем или иным образом, тогда можно будет попытаться их как-то синхронизировать.

L>>При принятии сообщения возникла проблема, пакеты идут неупорядоченно, так есть какая-нибудь возможность получать пакет по порядку, не дожидаясь других пакетов, т.е. сразу. Как отправил контроллер устройств сообщение, так у себя в программе получить сразу же этот пакет?

BE>Прочитал тему. Кажется что вы вообще нето что нужно делаете.
BE>1. Под виндой вы никак не добьетесь стабильной работы.
BE>2. Вам нужно маркировать пакеты, что бы знать их порядок. И тчо вы будете делать если один из пакетов пропадет?

По идее для этого нужно сделать дублирующий контроллер устройств, который имитирует работу настоящего, и каждые 1 и 1,25мс изменяет значение генераторов. Он так же будет работать на частоте 125 микросек. В итоге надо будет их синхронизировать чтобы одновременно выдавали положения генераторов. А для этого не надо будет каждое сообщение проверять. Если использовать tcp, то насколько будет он медленный?

Здравствуйте, leonneon, Вы писали:

L>По идее для этого нужно сделать дублирующий контроллер устройств, который имитирует работу настоящего, и каждые 1 и 1,25мс изменяет значение генераторов. Он так же будет работать на частоте 125 микросек. В итоге надо будет их синхронизировать чтобы одновременно выдавали положения генераторов. А для этого не надо будет каждое сообщение проверять. Если использовать tcp, то насколько будет он медленный?
Не даст вам винда точность в микросекунды. Даже не думайте.
Я не думаю что при гигабитной сети разница будет заметна.

Здравствуйте, BlackEric, Вы писали:

BE>Здравствуйте, leonneon, Вы писали:

L>>По идее для этого нужно сделать дублирующий контроллер устройств, который имитирует работу настоящего, и каждые 1 и 1,25мс изменяет значение генераторов. Он так же будет работать на частоте 125 микросек. В итоге надо будет их синхронизировать чтобы одновременно выдавали положения генераторов. А для этого не надо будет каждое сообщение проверять. Если использовать tcp, то насколько будет он медленный?
BE>Не даст вам винда точность в микросекунды. Даже не думайте.
BE>Я не думаю что при гигабитной сети разница будет заметна.

Точно микросекунду возможно и не даст, но близко к микросекунде 1-2 микросекунда, если машина сильная и не загруженная дает, boost chrono нужно использовать.

Здравствуйте, leonneon, Вы писали:

L>Точно микросекунду возможно и не даст, но близко к микросекунде 1-2 микросекунда, если машина сильная и не загруженная дает, boost chrono нужно использовать.

Вы можете огрести проблем когда комплекс в серию пойдет на разном железе.

Здравствуйте, BlackEric, Вы писали:

BE>Здравствуйте, leonneon, Вы писали:

L>>Точно микросекунду возможно и не даст, но близко к микросекунде 1-2 микросекунда, если машина сильная и не загруженная дает, boost chrono нужно использовать.

BE>Вы можете огрести проблем когда комплекс в серию пойдет на разном железе.

Согласен, что лучше использовать реал тайм системы.

Здравствуйте, leonneon, Вы писали:

l> F>Более того в контроллере для таких случев нужен буффер памяти и видимо генератор стробирующего сигнала с другими временными параметрами, подходящими под обычный комп.

l> А какая задача будет стоять у контроллера? Как можно будет обеспечить правильный порядок следования сообщений?

Внутренний кэш... Сброс по прерыванию, вместо поллинга (по стробу)...

Здравствуйте, ononim, Вы писали:

L>>>>>>Отвечу поподробней. В общем контроллер устройств управляет фазовращателями(не особо важно в этом контексте). В нем имеется 2 генератора состояний: 1, 0, -1, 0 и 0, 1, 0, -1, которые изменяются циклически.
S>>>>> В такой постановке задача нереальная, а уж тем более под гражданской ОС, типа Windows. Контроллеры должны ставить отметки времени в своих пакетах, тем или иным образом, тогда можно будет попытаться их как-то синхронизировать.
L>>>>При принятии сообщения возникла проблема, пакеты идут неупорядоченно, так есть какая-нибудь возможность получать пакет по порядку, не дожидаясь других пакетов, т.е. сразу. Как отправил контроллер устройств сообщение, так у себя в программе получить сразу же этот пакет?
O>>>Интересно, те кто изначально проектировал вашу систему чем вообще руководствовались? Явно не спецификациями тех средств, которые они использовать решили.
O>>>ЗЫ UDP не гарантирует ни порядок, ни сам факт доставки пакетов
O>>>ЗЗЫ по хорошему вам нужна своя реализация UDP и всего что под ним. + про реалтайм уже много чего написано.
L>>Проектировал не я, мне просто дали задание это сделать. Своя реализация это грубо говоря каждое сообщение помечать при отправке и при приеме проверять, чтобы в общем потом совпадал порядок следования сообщений?
O>Ну это не своя реализация, а как правильно юзать UDP. + контроль того что все дошло, если надо что все дошло
O>А под своей реализацией я подразумевал свой стек tcp(udp)/ip дабы гарантировать что все что пришло физически по кабелю пришло в лучшем виде к вам в апликуху. Потому как разработчики _стандартных_ стеков вольны делать с UDP пакетами все что угодно. И делают. Скажем не успела апликуха вовремя чтото вычитать — ну и фиг с ним. Или сделать некий кольцевой буфер и складывать в него пакеты, а вычитывать разумеется тоже в любом порядке могут. Причем так могут делать еще и производители драйверов сетевых карт с эзернет фреймами. То есть если в вашей задаче требуется передавать UDP пакеты с фиксированными задержками, гарантированной передачей и порядком — вам по сути не UDP нужно, а совсем другой протокол, который лишь использует формат пакетов UDP
O>Ну или научите свой софт мириться с ограничениями стандартного UDP — путем введения порядковых номеров пакетов.

А если использовать другой вид передачи, например rs422. У него скорость передачи и чтения может обеспечить 1 мс? Или can? Просто с udp пока, что пришел в тупик.

Здравствуйте, leonneon, Вы писали:

L>А если использовать другой вид передачи, например rs422. У него скорость передачи и чтения может обеспечить 1 мс? Или can? Просто с udp пока, что пришел в тупик.

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

Здравствуйте, leonneon, Вы писали:

Смотрю я на эту тему, и что-то очкую. Раз РЛС, то это что-то либо военное, либо авиационное. И если второе, то через несколько лет мы все имеем шанс с "этим" столкнуться. ТС то ладно, ему задание дали, он и корячится. Но ведь должен же быть и какой-то архитектор у этой системы. Который придумал два интерфейса по UDP и плюс еще USB синхронизировать с погрешностью менее миллисекунды, да еще и под под Windows . А после этого вы удивляетесь, что ракеты падают.

Здравствуйте, leonneon, Вы писали:

L>Здравствуйте, ononim, Вы писали:

L>>>Отвечу поподробней. В общем контроллер устройств управляет фазовращателями(не особо важно в этом контексте). В нем имеется 2 генератора состояний: 1, 0, -1, 0 и 0, 1, 0, -1, которые изменяются циклически.
O>>Ох, я надеюсь это не софт для АЭС или спутника какого? Ибо использование стоковой железяки с виндой для таких задач — большая ошибка.

L>Если поточнее, то для слежения и наведения антенны в реальном времени.
Надеюсь, не антенн для нашего ПРО?

S>Смотрю я на эту тему, и что-то очкую. Раз РЛС, то это что-то либо военное, либо авиационное. И если второе, то через несколько лет мы все имеем шанс с "этим" столкнуться. ТС то ладно, ему задание дали, он и корячится. Но ведь должен же быть и какой-то архитектор у этой системы. Который придумал два интерфейса по UDP и плюс еще USB синхронизировать с погрешностью менее миллисекунды, да еще и под под Windows . А после этого вы удивляетесь, что ракеты падают.
Насколько мне знается, в гражданской авиации РЛС с автоматическим слежением не делают, ибо целей там много, они все вокруг и сбежать от радара не стремятся Так что остается или ПРО, или какая нить экзотика типа подлодки.