Перейти к содержимому
Калькуляторы

jitter и асимметричные замеры каналов экспериментирую

Пишу программу для "одностороннего" мониторинга. Т.к. по своей сути каналы передачи данных искусственно "обьединяются" величиной "пинга", и частенько какие-то выводы о некачественности делаются на основе RTT (т.е. полного кольца пакета).

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

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

 

Как это выглядит.

 

Вывод обычного пинга:

64 bytes from gxinsat (x.x.x.x): icmp_seq=1 ttl=62 time=320 ms

64 bytes from gxinsat (x.x.x.x): icmp_seq=2 ttl=62 time=320 ms

64 bytes from gxinsat (x.x.x.x): icmp_seq=3 ttl=62 time=322 ms

64 bytes from gxinsat (x.x.x.x): icmp_seq=4 ttl=62 time=320 ms

64 bytes from gxinsat (x.x.x.x): icmp_seq=5 ttl=62 time=319 ms

64 bytes from gxinsat (x.x.x.x): icmp_seq=6 ttl=62 time=322 ms

64 bytes from gxinsat (x.x.x.x): icmp_seq=7 ttl=62 time=355 ms

64 bytes from gxinsat (x.x.x.x): icmp_seq=8 ttl=62 time=320 ms

64 bytes from gxinsat (x.x.x.x): icmp_seq=9 ttl=62 time=320 ms

64 bytes from gxinsat (x.x.x.x): icmp_seq=10 ttl=62 time=320 ms

64 bytes from gxinsat (x.x.x.x): icmp_seq=11 ttl=62 time=321 ms

64 bytes from gxinsat (x.x.x.x): icmp_seq=12 ttl=62 time=321 ms

64 bytes from gxinsat (x.x.x.x): icmp_seq=13 ttl=62 time=321 ms

64 bytes from gxinsat (x.x.x.x): icmp_seq=14 ttl=62 time=321 ms

64 bytes from gxinsat (x.x.x.x): icmp_seq=15 ttl=62 time=323 ms

 

Информативно, но не очень.

 

Вывод моей программы. Отклонения на "прием" с точки замера:

Качественный спутниковый канал, сервер "замера" находится на площадке оператора

 

Jul 8 02:26:01 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 1, max_rtt 384

Jul 8 02:26:02 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 0, max_rtt 384

Jul 8 02:26:03 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 0, max_rtt 384

Jul 8 02:26:04 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 0, max_rtt 384

Jul 8 02:26:05 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 0, max_rtt 384

Jul 8 02:26:06 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 0, max_rtt 384

Jul 8 02:26:07 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 1, max_rtt 384

Jul 8 02:26:08 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 1, max_rtt 384

Jul 8 02:26:09 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 0, max_rtt 384

Jul 8 02:26:10 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 0, max_rtt 385

Jul 8 02:26:11 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 0, max_rtt 385

Jul 8 02:26:12 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 1, max_rtt 385

Jul 8 02:26:13 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 1, max_rtt 385

Jul 8 02:26:14 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 1, max_rtt 387

Jul 8 02:26:15 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 1, max_rtt 387

Jul 8 02:26:16 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 1, max_rtt 395

Jul 8 02:26:17 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 2, max_rtt 395

Jul 8 02:26:18 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 1, max_rtt 395

Jul 8 02:26:19 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 2, max_rtt 395

Jul 8 02:26:20 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 1, max_rtt 395

Jul 8 02:26:21 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 1, max_rtt 395

Jul 8 02:26:22 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 1, max_rtt 395

Jul 8 02:26:23 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 1, max_rtt 395

Jul 8 02:26:24 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 1, max_rtt 395

Jul 8 02:26:25 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 1, max_rtt 395

 

А это на передачу, через ливанских горе-провайдеров (Alcatel wireless с Half-Duplex 10Mbit/s интерфейсом, про остальное хозяйство молчу)

 

Jul 8 01:28:03 globax2 distnetmond: <carrier1leb> 4 max jitter, last 4, max_rtt 389

Jul 8 01:28:03 globax2 distnetmond: <carrier1leb> 4 max jitter, last 0, max_rtt 389

Jul 8 01:28:04 globax2 distnetmond: <carrier1leb> 4 max jitter, last 3, max_rtt 389

Jul 8 01:28:04 globax2 distnetmond: <carrier1leb> 4 max jitter, last 2, max_rtt 389

Jul 8 01:28:05 globax2 distnetmond: <carrier1leb> 5 max jitter, last 5, max_rtt 389

Jul 8 01:28:05 globax2 distnetmond: <carrier1leb> 5 max jitter, last 2, max_rtt 389

Jul 8 01:28:06 globax2 distnetmond: <carrier1leb> 5 max jitter, last 4, max_rtt 389

Jul 8 01:28:06 globax2 distnetmond: <carrier1leb> 5 max jitter, last 3, max_rtt 389

Jul 8 01:28:07 globax2 distnetmond: <carrier1leb> 5 max jitter, last 3, max_rtt 389

Jul 8 01:28:07 globax2 distnetmond: <carrier1leb> 5 max jitter, last 4, max_rtt 389

Jul 8 01:28:08 globax2 distnetmond: <carrier1leb> 5 max jitter, last 3, max_rtt 389

Jul 8 01:28:08 globax2 distnetmond: <carrier1leb> 5 max jitter, last 5, max_rtt 389

Jul 8 01:28:09 globax2 distnetmond: <carrier1leb> 5 max jitter, last 3, max_rtt 389

Jul 8 01:28:09 globax2 distnetmond: <carrier1leb> 5 max jitter, last 3, max_rtt 389

Jul 8 01:28:10 globax2 distnetmond: <carrier1leb> 5 max jitter, last 2, max_rtt 389

Jul 8 01:28:10 globax2 distnetmond: <carrier1leb> 5 max jitter, last 0, max_rtt 389

Jul 8 01:28:11 globax2 distnetmond: <carrier1leb> 5 max jitter, last 1, max_rtt 389

Jul 8 01:28:11 globax2 distnetmond: <carrier1leb> 5 max jitter, last 2, max_rtt 389

Jul 8 01:28:12 globax2 distnetmond: <carrier1leb> 6 max jitter, last 6, max_rtt 389

Jul 8 01:28:12 globax2 distnetmond: <carrier1leb> 6 max jitter, last 2, max_rtt 389

Jul 8 01:28:13 globax2 distnetmond: <carrier1leb> 9 max jitter, last -3, max_rtt 389

Jul 8 01:28:13 globax2 distnetmond: <carrier1leb> 9 max jitter, last 1, max_rtt 389

Jul 8 01:28:14 globax2 distnetmond: <carrier1leb> 9 max jitter, last 4, max_rtt 389

Jul 8 01:28:14 globax2 distnetmond: <carrier1leb> 9 max jitter, last 2, max_rtt 389

Jul 8 01:28:15 globax2 distnetmond: <carrier1leb> 9 max jitter, last 4, max_rtt 389

Jul 8 01:28:15 globax2 distnetmond: <carrier1leb> 9 max jitter, last 3, max_rtt 389

Jul 8 01:28:16 globax2 distnetmond: <carrier1leb> 9 max jitter, last 3, max_rtt 389

Jul 8 01:28:16 globax2 distnetmond: <carrier1leb> 9 max jitter, last 4, max_rtt 389

Jul 8 01:28:17 globax2 distnetmond: <carrier1leb> 9 max jitter, last 3, max_rtt 389

Jul 8 01:28:17 globax2 distnetmond: <carrier1leb> 9 max jitter, last 5, max_rtt 389

Jul 8 01:28:18 globax2 distnetmond: <carrier1leb> 9 max jitter, last 0, max_rtt 389

Jul 8 01:28:18 globax2 distnetmond: <carrier1leb> 9 max jitter, last -2, max_rtt 389

Jul 8 01:28:19 globax2 distnetmond: <carrier1leb> 9 max jitter, last -1, max_rtt 389

Jul 8 01:28:19 globax2 distnetmond: <carrier1leb> 9 max jitter, last 3, max_rtt 389

Jul 8 01:28:20 globax2 distnetmond: <carrier1leb> 9 max jitter, last 1, max_rtt 389

Jul 8 01:28:20 globax2 distnetmond: <carrier1leb> 9 max jitter, last 5, max_rtt 389

Jul 8 01:28:21 globax2 distnetmond: <carrier1leb> 9 max jitter, last 3, max_rtt 389

Jul 8 01:28:21 globax2 distnetmond: <carrier1leb> 9 max jitter, last 1, max_rtt 389

Jul 8 01:28:22 globax2 distnetmond: <carrier1leb> 9 max jitter, last -2, max_rtt 389

 

Хорошо видно, что даже на этом маленьком отрезке, при очень малой загрузке (ночь), jitter составляет ~10ms. Днем этот канал кошмарит по черному. Конечно может быть там еще дисперсия от шейпера, который не позволяет "превышать" доступную полосу, но я это скорее всего проработаю через мониторинг "после шейпера".

 

Т.к. опорный оффсет часов для точек замера берется случайным образом (из первого полученного значения), возможны минусовые минимальные значения, это нормально и учитывается. Еще есть проблема связанная с "уходом" частоты практически на любом компе, потому желательно засинхронизировать часы, а точнее подстроить частоту часов, чтоб часы "не отставали" и "не спешили". В некоторых случаях уход часов может составлять до 20ms на 1 минуту(TSC, это около 333ppm, возможно конечно и в пределах нормы), в случае HPET это было 3ms (соответственно это и составит погрешность показаний). Но методом несложных вычислений (еще дополню программу по этому поводу) и визуального наблюдения результатов можно вычислить взаимный "уход" часов точек замера. Замечание: уход нетермостатированного кварца, который установлен в компе, зависит от его температуры.

 

P.S.S. NTP по асинхронным каналам, с разной задержкой на прием и на передачу IMHO ошибается, т.к. рассчитывает на задержку по симметричному алгоритму. Получить точное время в случае ассимметрии похоже можно только с помощью хорошего GPS приемника на realtime системе.

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Забыл добавить. Программа позволяет определить перегрузку канала оператора в определенном направлении. Т.к. пакеты скорее всего будут буферизоваться не всегда - велика вероятность что прийдет пакет с минимальной и с максимальной задержкой. Скажем для Cisco hold-queue в 75 пакетов (вроде оно обычно по умолчанию), среднем размере пакета в 500 байт, и канале в мегабит задержка может составить до 300ms, что программа и покажет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Дурная мысль: если пинг до нью-йорка из Москвы (RTT) 140ms, расстояние ~7505 км (итого 15010) получается скорость передвижения данных составит 107214 км/ч. Это всего лишь в ~10000 раз медленнее скорости света. Пора применять специальную теорию относительности по отношению к данным? :-D

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А где сама программа? ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Почему 107214 - километры в ЧАС?

Буквы перепутал, км/c

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну, хотя исходники не готовы на публичное выкладывание.... но их там немного, посему: http://www.nuclearcat.com/files/distchanmon-0.2.tgz

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

что будет при перегрузке интерфейса? где будут "задерживаться" пакеты?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Точно не в ней, поверь мне. В общем то тебе это не так и важно. Ты пиши, пиши, посмотрим что получится.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

tgz - реалии жизни. E1 - 2 Mbps у аплинка, нам выделен мегабит. Бендвич как оказалось шарится и не dedicated, хотя платим по полной. Программка помогла.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1. При чем тут асимметрия? Была ли она?

2. Православный iperf вам тут бы не помог?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1)перегруз был на upload

2)Нет, с помощью iperf можно проводить только периодический мониторинг канала, и расчет идет на то, что гонишь поток с определенной скоростью, эта программа складывает логи за весь период работы,обьем данных для замеров очень мал, и реагирует только тогда, когда мне нужно, т.е. когда подрос rtt/jitter выше нормы - шлет sms (в текущем публичном снапшоте этой функции нет). Кроме того мне очень не нравится gettimeofday и еще несколько вещей :-)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Почему 107214 - километры в ЧАС?
Буквы перепутал, км/c

Это я к "Это всего лишь в ~10000 раз медленнее скорости света".

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А я вот как-то к smokeping привык, и вполне его хватает.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А у меня уже давно меряет зависимость rtt от заюзанной полосы.

Только при большом джиттере в ответ дает не совсем среднее rtt по всем пакетам, последние идут с большим весом. По icmp кстати тестировать бесполезно.

 

http://wlan.mipt.ru

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Считать jitter с помощью TCP, надеясь на "трезвость" tcp стека и браузера - вообще помоему наивно. Если я включу CORK, результаты уже будут искажены. А он у меня частенько включен на некоторых прокси.

На ICMP надеятся можно, но не всегда. В моем случае используется UDP, плюс я подстраиваю шедулер с обоих сторон.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В том и фича, что действие алгоритма нагла легко обойти. TCP стек гарантированно трезв для одного пакета из cwnd штук, и этого достаточно.

 

Мешает прокся - http://wlan.mipt.ru:любой порт.

 

А мерять по tcp правильнее всего - его 80 % по каналам идет. И никто не гарантирует, что для tcp, udp, icmp разные очереди где-нибудь не настроены.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А вы тестировали с включенным TCP_CORK и(или) TCP_QUICKACK ?

 

Я могу сделать "коннектилку" и протестировать, но если как-то можно просто tcp коннектом.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А мерять по tcp правильнее всего - его 80 % по каналам идет. И никто не гарантирует, что для tcp, udp, icmp разные очереди где-нибудь не настроены.

Так же никто не гарантирует, что в разные очереди не попадает TCP разных портов, размеров пакетов и прочее. Мерять надо только по UDP, TCP опционально, когда UDP по каким-то причинам невозможен.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У меня текущая точность +-1.5ms, иногда выше. Все зависит от ухода часов на компах... этот вопрос тоже проработаю, хотя нетермостатированные часы синхронизировать - гиблое дело.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Там проще пареной репы все

Есть точка А, есть точка B

Условно часы в точке A идут с равной скоростью как и в точке B но смещены на величину X. Смещение включает в себя как просто разницу так и величину Tdist, которая равна минимальному количеству времени необходимому для перемещения пакета из одной точки в другую.

Так как каналы связи не идеальны, есть еще Toverload возникающий по причине перегрузки оборудования по пути следования пакета. Соответственно мы отправляем скажем 60 пакетов и минимальное время прохождения пакета из А до B будут предположительно равны Tdist. Отклонения от Tdist соответственно составят jitter.

Измерения производятся в одну сторону, т.к. RTT (время передвижения пакета из А и B и снова назад в A) слишком непостоянная и неточная величина. Кроме того есть вероятность что связь в разные стороны проходит по разным линиям связи, с разными характеристиками.

 

НО! У каждого осциллятора(кварц) компьютера есть смещение частоты часов. Это смещение может достигать 500ppm(эта цифра взята из даташитов HPET), т.е. в худщем случае за 60 секунд взаимный разброс часов составит 3.6ms. Можно конечно (и видимо попробую сделать в будушем) подсчитать этот уход подсчетом т отклонения минимумов каждую минуту и где-то за 5 минут мы получим Foffset. Но т.к. в компах применяются нетермостатированные генераторы эта величина может колебаться. Поэтому пока я поступил проще, каждые 60 секунд я сбрасываю Tdist.

К слову уход часов основанных на TSC (core 2 duo архитектура, constant_tsc в наличии) составлял около 333ppm, а HPET около 50ppm.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.