LINUX.ORG.RU

измерение задержек между двумя системами с точностью до единиц миллисекунд


0

1

Есть две системы: первая - ПК или ноутбук, вторая - допустим PandaBoard (ARM). Связаны по WiFi.

Задача: организовать измерение задержки с точностью до единиц миллисекунд, где разница между 18 и 21 миллисекундами - есть.

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

Вопрос: на что можно завязаться у ПК или ноутбука для того чтобы выдернуть из них синхроимпульс?

Вот мысль что PC-speaker можно взять, а на стороне PandaBoard я могу что-то другое придумать - те же GPIO меньше доли миллисекунды дрыгаются 100% я замерял.

Могу ли я взять например USB-COM преобразователь на обоих сторонах? Какова будет задержка если я в USB-COM преобразователь запишу байт? Я думаю взять спад при старте посылки байта а затем сравнить с появлением байта на другом преобразователе и увидеть задержку на осциллографе.

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

может spdif ?

lazyklimm ★★★★★
()
Ответ на: комментарий от true_admin

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

I-Love-Microsoft ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

я попробую, однажды на ЛОРе я уже интересовался мне сказали что точность невелика

но если это меньше миллисекунды точности - то это определенно мне подходит!

I-Love-Microsoft ★★★★★
() автор топика
Ответ на: комментарий от anonymous

USB-COM нельзя, на USB джиттер ппц.

больше нескольких миллисекунд? да, я в курсе как оно работает, но оценок у меня нет

джиттер - это проблема этого метода

вероятно выберу NTP

I-Love-Microsoft ★★★★★
() автор топика
Последнее исправление: I-Love-Microsoft (всего исправлений: 1)
Ответ на: комментарий от Eddy_Em

Судя по выхлопу многократного запуска ntpdate -q, точность где-то 10-20мкс.

чем ты проверял эту точность?

и как оно может так точно синхронизовать устройства по WiFi

I-Love-Microsoft ★★★★★
() автор топика
Ответ на: комментарий от I-Love-Microsoft

чем ты проверял эту точность?

То было на работе (меньше свичей и проксей по пути), дома так:

ntpdate -q 192.168.2.11 
server 192.168.2.11, stratum 2, offset 0.000138, delay 0.02628
24 Jan 20:36:04 ntpdate[2951]: adjust time server 192.168.2.11 offset 0.000138 sec

24 Jan 20:36:36 ntpdate[2954]: adjust time server 192.168.2.11 offset 0.000137 sec

24 Jan 20:36:57 ntpdate[2956]: adjust time server 192.168.2.11 offset 0.000148 sec

24 Jan 20:37:04 ntpdate[2957]: adjust time server 192.168.2.11 offset 0.000142 sec

octave:1> a = [0.000138 0.000137 0.000148 0.000142];
octave:2> mean(a)
ans =  1.4125e-04
octave:3> std(a)
ans =  4.9917e-06

Можно скриптик написать и подольше попарсить выхлоп. Но вряд ли больше 10-20мкс получится.

и как оно может так точно синхронизовать устройства по WiFi

ХЗ, проверь, что там на wifi получится.

Eddy_Em ☆☆☆☆☆
()
Последнее исправление: Eddy_Em (всего исправлений: 1)

подай на оба компа один сигнал. например на аудиовходы заведи сигнал с генератора ПСП.

А еще лучше - оба компа выдают на аудиовыход ПСП. Эти выходы объединяются так, что ПСП с компа А идет в левый канал, а ПСП с компа Б в правый. После чего это стерео заводится на оба компа и сравнивается набег фазы

ckotinko ☆☆☆
()
Ответ на: комментарий от ckotinko

Т.е. у тебя в канал поступает два сигнала, которые можно преобразовать в метки времени. Пусть это Та и Тб. А потом ты их видишь синхронно на каждом компе-в левом и правом каналах звуковхода

ckotinko ☆☆☆
()
Ответ на: комментарий от Eddy_Em

судя по IP у тебя был свой NTP сервер? в смысле на твоем сервере самостоятельно поднятый

меня интересует также синхронизация при условии что известные NTP сервера доступны например только через GPRS, а два компа оставлены один на один с ethernet или wifi между собой

I-Love-Microsoft ★★★★★
() автор топика
Ответ на: комментарий от I-Love-Microsoft

судя по IP у тебя был свой NTP сервер?

У меня-то, понятное дело, и дома, и на работе ntp-сервер стоит (без него никак), но этот айпишник — не моего ntp-сервера, я этот сервер использую как материнский (он по GPS синхронизируется). Но ntpdate работает и без сервера. На разницу времени можно внимания не обращать, тебе только задержка важна.

Подними на одном из компьютеров ntp-сервер, да измеряй задержку. Делов-то? Он настраивается элементарнейше.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

Подними на одном из компьютеров ntp-сервер, да измеряй задержку. Делов-то? Он настраивается элементарнейше.

я боялся что у меня борода и свитер отрастут при попытке настройки NTP, но если это просто делается - тогда пожалуй подниму :)

I-Love-Microsoft ★★★★★
() автор топика
Ответ на: комментарий от I-Love-Microsoft

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от I-Love-Microsoft

GPS через usb<->com (pl2303) давал в районе 10мс. Но тут, вестимо, от реализации usb тоже зависит (/me тестировал на встроенном в чипсет amd 7xx).

anonymous
()
Ответ на: комментарий от Eddy_Em

Охеренная проверка. Вообще-то нормальным считается соединять два конпьютера с gps/pps через ethernet и мониторить выхлоп ntpd -p.

anonymous
()
Ответ на: комментарий от I-Love-Microsoft

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

ckotinko ☆☆☆
()

По UDP пакетам смотреть, там для их синхронизации в каждом время указано вплоть до милмисекунд

Dron ★★★★★
()
Ответ на: комментарий от Dron

По UDP пакетам смотреть, там для их синхронизации в каждом время указано вплоть до милмисекунд

подробнее

откуда там изначально возьмется синхронизация, тем более у UDP?

I-Love-Microsoft ★★★★★
() автор топика

Ну раз зашел разговор про ntp рекомендую почитать man ping, ибо там из под рута точность не меньше микросекунд.

gh0stwizard ★★★★★
()
Ответ на: комментарий от Dron

По UDP пакетам смотреть, там для их синхронизации в каждом время указано вплоть до милмисекунд

Какой синхронизации? %) Roundtrip там ниже миллисекунды обычно, это да.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Ой блин извиняюсь, но время там указано.

Dron ★★★★★
()
Ответ на: комментарий от tailgunner

А если взять что-нибудь из железа http://linuxptp.sourceforge.net/ которое с Hardware Timestamping то теоретически можно достичь единиц наносекунд. Правда без возможности получить с этих синхронизированных часов хотя бы сигнал PPS заюзать эту точность не удастся

alx777 ★★
()
Ответ на: комментарий от I-Love-Microsoft

Получить то конечно можно, но я бы советовал начать с NTP и только если не хватит точности задуматься о PTP

alx777 ★★
()

ТС, ты бы уже давно свой протокол реализовал на обычных сокетах, посылая серию «пингов» туда-сюда и измеряя задержки (эдакий «облегченный» NTP).

Поясню: А отправляет Б пакет с временной меткой Х; Б, получив пакет, "эхует" его обратно. И так несколько раз.

Eddy_Em ☆☆☆☆☆
()
Последнее исправление: Eddy_Em (всего исправлений: 1)
Ответ на: комментарий от Eddy_Em

я специально оговорил что связь по WiFi - неужели посылая туда обратно пакеты можно установить синхронизацию менее 5 мс в случае беспроводного соединения?

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

I-Love-Microsoft ★★★★★
() автор топика
Последнее исправление: I-Love-Microsoft (всего исправлений: 1)
Ответ на: комментарий от I-Love-Microsoft

неужели посылая туда обратно пакеты можно установить синхронизацию менее 5 мс в случае беспроводного соединения?

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

А вообще, если тебе нужен серьезный протокол, не стоит wifi использовать. Проложи хотя бы витуху.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

задача не позволяет... но не суть

согласен, попробую для начала просто по WiFi как есть твой метод

I-Love-Microsoft ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.