Russian Qt Forum

Я в сетях новичок, вопрос теоретический.... Отправили данные фиксированной длинны, например 100 байт, из точки А в точку Б по TCP/IP. В точку Б эти 100 б пришли (причём, возможно они пришли частями, т.е. побились на несколько пакетов). Как только пришли все 100 б в точку Б, фиксируется время с высокой точностью (e.g. ~1 мкс). Необходимо в точке Б вычислить время отправки данных из А с погрешностью ....... заказчик требует <10 мкс. Теоретически возможно определить время прохождения этих 100 байт в точке Б и с какой точностью?

Мысли вслух....
* Синхронизировать часы в точках А и Б
* В пакет включать время отправки из точки А
* При приеме пакета в точке Б сравнивать время отправки с текущем временем

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

протокол ICMP: http://ru.wikipedia.org/wiki/Icmp
на *nix машинах, требуются права супер-юзера для его использования.

Хмм. А сторона А сможет отправлять данные с определенной периодичностью? Таймер или еще как?

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

Нет. Передача спорадическая. Можно сделать программные часы в А и синхронизировать их с Б. Например раз в час передавать показатель времени Б в А. Но тогда А должно точно вычислить прохождение данных из Б в А. Теже яйца, только сбоку. ((

А если перед отправкой основного пакета, сторона А сначала отправляет синхро-пакет, а потом, через определенное время Ti, основной пакет.
Сторона Б после получения синхро-пакета засекает время (Ts) и ждет получение основного пакета (Td).
T = Td - Ts - Ti.

P.S. А что там на стороне А с алгоритмом Nagle?

протокол используется не только для этого. в общем...читай.

2 juvf
Кстати, прислушайся к niXman, проверь какой штамп времени будет возвращаться при ICMP с типом 13, как с одной стороны, так и с другой.

Nagle вообще отключается в реалтайм системах.

ну понятно что не только для этого. А как с помощью него определить время прохождения данных в одну сторону? типом 13 или 14? а как? часы (реальное время) есть только в точке Б. Например А отправляет пакет типа 13. В поле "Originate Timestamp" А должена выставить время в мс по UT. Но где возьмёт это время А?

И далее, ну допустим каким-то образом определил время прохождения ICMP пакета. оно составило 1,5 мс. Ещё раз определили - получили 516 мкс, еще раз, получили 3,51 мс. Каждый раз пакет идет с разным временем. Если после этого передать свои данные (а они уже пойдут не как ICMP пакет, мне кажется), то за какое время они будут доставлены?

я в контроллерах так делаю:
1) "Умный" шлёт установку времени в "глупого"
2) "Умный" спрашивает у "глупого" время, тут можно определить ошибку (смещение), "умный" её учитывает и опять устанавливает время "глупого"

Ну я тоже склоняюсь пока к такому алгоритму. Правда для усреднения погрешности можно несколько раз "умному" эхо засечь и вычислить среднее время доставки пакета. Или к "глупому" прикрутить GPS. В общем будем думать...
Я просто думал, что может есть какие-нибудь свойства tcp/ip чтоб гарантированно знать время прохождения пакета, как например в RS-485 или 232. В очередной раз много нового узнал.  :)
Всем спасибо.

>>как например в RS-485 или 232
в них нет никаких гарантий, изменились эл. характеристики линии, изменилась задержка. Чем больше скорость передачи, тем заметнее.

Я ещё экспериментировал с одним способом, и считаю, что он более рациональный. Просто переводить уже сделанное лениво. Суть:
1) "Умный" посылает широковещательную установку времени.
2) Он же собирает со всех индивидуально, что получилось.
3) Вычисляет ошибку и помещает её в БД
4) Время от времени, проверяется текущее время в каждом "глупом", если уплыло больше положенного делает п.1

В БД накапливается статистика.
Реальное время в БД = время "умного" +/- записанной в неё ошибки данного "глупого".
На основе статистики об изменении величины ошибки можно прогнозировать проблемы со связью.

П.С. Факт: весной и осенью задержка растёт, иногда появляются битые пакеты.

Один раз мне приходилось это делать (правда это было на жабе и уже лет 10 назад, помню смутно). Я крутил так: при любой посылке в пакет вписывается время ее начала. При любом приеме запоминается время конца приема. На каждый принятый пакет посылается подтверждение "принят", в нем же записано время конца приема. На стороне отправителя все на руках, накапливается статистика (для каждого принимающего).

С обработкой много разумных ходов. Когда пакетов мало (напр. 32 и меньше) - тупо осредняем. Для большего числа: осредняем, затем отбрасываем значения меньше среднего в 2(N) раз и опять осредняем. Разумеется, каждый пакет знает свою длину, осредняем скорости. Если пакет не прошел (подтверждение не получено) - накапливаем это для др. статистики (кол-во сбойных пакетов), сюда не вмешиваем

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

2 lit-uriy & Igors
Конечно можно держать какую-то статистику, обновлять её и прогнозировать время передачи. Но пару дней назад экспериментировал с GPRS. Подключил обе точки к интернету через GPRS, причем к разным операторам. Пинг был от 1 до 1,5 секунд. Стал посылать данные. Отправитель посылает слово "STATUS", получатель получатель получает через пару секунд. Но иногда бывает так: Посылаю слово с А, Б не принимает. Жду секунд 10. Еще раз посылаю. Опять тишина. Ну и так раз 5. Нет связи. Сижу думаю, в чём дело??? Вдруг, примерно через минуту Б получает " STATUSSTATUSSTATUSSTATUSSTATUSSTATUS". Т.е. все мои команды пришли разом. Получается первое слово пришло через минуту-две, последнее, через 10- 20 сек. А заказчик требует точность до 10 мс (описался в первом посте). О какой статистике и прогнозе может идти речь при таких задержках?

При работе через ethernet нужно всё таки задействовать ICMP (как писалось выше).
Точности в ethernet'е не было и быть не может, особенно при хождении пакета чёрти где (GPRS).

Есть такая программа MTR (в Виндовозе WinMTR), попробуй ею посмотреть где шарахаются пакеты. Она маршрут рассказывает.

П.С. В сетевых технологиях,, я не силён. Но, вроде, управлять маршрутом нельзя.

traceroute же.
И в linux и в венде есть из коробки.

да при чем здесь traceroute и ICMP?. Как задействовать ICMP? Задача стоит не в том, чтоб определить маршрут и время передачи пакета ICMP, что делает traceroute рассчитывая время по формуле (t_ТУДА+t_ОБРАТНО)/2. Нужно передать данные без метки времени. получатель должен с точностью до 10 мс вычислить время, в которое отправитель отправил (и это не пакет ICMP, это пакет конкретного приложения, например "Mobdus TCP/IP"). GPRS - ну конечно тут нет ни каких гарантий по времени. Но даже по земле нет. tracert показал время передачи 30 мс. Где-нибудь нагрузка на промежуточный сервер увеличится и время возрастёт. Или маршрут поменяется, или провайдер какой-нибудь сменится, или провайдер оборудование сменит - и всё, время ушло. Нее.... я уже понял

Насчет traceroute, я писал lit-uriy о том, что есть утилита, которой можно просмотреть маршрут из коробки и в linux и в венде.
Насчет того как определяется время в ICMP. При отсылке пакета 13, отправитель (А) фиксирует время отправки, получатель изменяет тип сообщения на 14 и вписывает время приема сообщения и время отправки его обратно.  При приеме ответа на стороне А, она может узнать реальное время прохождения пакета туда и обратно, используя три поля со штампами времени.
Как будет вести себя твоя сторона А (что она будет заносить в штампы времени) - вопрос, который интересно проверить. Возможно, будут значение с единицей в старшем разряде, что говорит о нестандартном значении времени.

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

Насчет 10 миллисекунд. Спорить с заказчиком не нужно, 10 так 10. Но надо четко пояснить ему что программа не отвечает за скорость передачи, за качество канала связи и.т.п. Программа посылает/принимает данные в/из какого-то порта - это ВСЕ. Разборки с маршрутизацией и др. - все это другая задача, которая, разумеется, должна оплачиваться отдельно.

Примечания: (может пригодится)

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

- часто лучше сначала вылить посылаемый пакет в файл а затем этот файл лить в сокет

О!!! Подсказали приемлемый вариант решения. Можно у "глупого" запустить часы, (например замутить программные или поставить RTC) и синхронизировать их по NTP4.
http://ru.wikipedia.org/wiki/NTP

Вы адекватны?
Ваш пост?

>>Вы адекватны?
Просто выхода другого нет, поэтому происходит модернизация.