Russian Qt Forum
Ноябрь 01, 2024, 07:27 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: [1] 2   Вниз
  Печать  
Автор Тема: Время прохождения пакета по сети  (Прочитано 14776 раз)
juvf
Программист
*****
Offline Offline

Сообщений: 570


Просмотр профиля
« : Декабрь 24, 2009, 09:36 »

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

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

Сообщений: 570


Просмотр профиля
« Ответ #2 : Декабрь 24, 2009, 09:48 »

Цитировать
* В пакет включать время отправки из точки А
были бы часыв точке А, вопросов бы не было. На самом деле нужно в Б зафиксировать событие произошедшее в А, но в часы есть только в Б.
Записан
niXman
Гость
« Ответ #3 : Декабрь 24, 2009, 09:55 »

протокол ICMP: http://ru.wikipedia.org/wiki/Icmp
на *nix машинах, требуются права супер-юзера для его использования.
Записан
BRE
Гость
« Ответ #4 : Декабрь 24, 2009, 10:06 »

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

Записан
juvf
Программист
*****
Offline Offline

Сообщений: 570


Просмотр профиля
« Ответ #5 : Декабрь 24, 2009, 10:17 »

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

Цитировать
Хмм. А сторона А сможет отправлять данные с определенной периодичностью? Таймер или еще как?
Нет. Передача спорадическая. Можно сделать программные часы в А и синхронизировать их с Б. Например раз в час передавать показатель времени Б в А. Но тогда А должно точно вычислить прохождение данных из Б в А. Теже яйца, только сбоку. ((
Записан
BRE
Гость
« Ответ #6 : Декабрь 24, 2009, 10:47 »

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

P.S. А что там на стороне А с алгоритмом Nagle?
Записан
niXman
Гость
« Ответ #7 : Декабрь 24, 2009, 10:58 »

Цитировать
- по мойму мимо. С помощью этого протокола можно вычислить время прохождения пакета туда-обратно. А нужно время только туда.
протокол используется не только для этого. в общем...читай.
Записан
BRE
Гость
« Ответ #8 : Декабрь 24, 2009, 11:02 »

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

Сообщений: 570


Просмотр профиля
« Ответ #9 : Декабрь 24, 2009, 11:39 »

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

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

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

Записан
lit-uriy
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 3880


Просмотр профиля WWW
« Ответ #10 : Декабрь 24, 2009, 13:08 »

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

Юра.
juvf
Программист
*****
Offline Offline

Сообщений: 570


Просмотр профиля
« Ответ #11 : Декабрь 24, 2009, 13:54 »

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


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

Сообщений: 3880


Просмотр профиля WWW
« Ответ #12 : Декабрь 24, 2009, 15:35 »

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

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

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

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

Юра.
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #13 : Декабрь 24, 2009, 20:00 »

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

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

Сообщений: 570


Просмотр профиля
« Ответ #14 : Декабрь 25, 2009, 07:06 »

Цитировать
при любой посылке в пакет вписывается время ее начала. При любом приеме запоминается время конца приема.
еще раз повторюсь, что изначально условия таковы, что часы есть только на стороне получателя.

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


Страница сгенерирована за 0.254 секунд. Запросов: 22.