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

nuclearcat · July 7, 2009

Пишу программу для "одностороннего" мониторинга. Т.к. по своей сути каналы передачи данных искусственно "обьединяются" величиной "пинга", и частенько какие-то выводы о некачественности делаются на основе 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: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. Возможно будет актуально многоногим друзьям, которые хотят увидеть каждый "канал" отдельно. В принципе даже симметричникам это может пригодится, чтоб четко увидеть "горлышко" на любом из направлений.

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

nuclearcat · July 7, 2009

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

nuclearcat · July 8, 2009

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

pety · July 8, 2009

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

chainick · July 8, 2009

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

nuclearcat · July 8, 2009

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

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

nuclearcat · July 8, 2009

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

tgz · July 8, 2009

Казалось бы, при чем тут hold-queue...

nuclearcat · July 8, 2009

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

tgz · July 8, 2009

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

nuclearcat · July 8, 2009

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

tgz · July 8, 2009

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

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

nuclearcat · July 8, 2009

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

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

pety · July 8, 2009

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

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

tgz · July 8, 2009

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

Дегтярев Илья · July 8, 2009

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

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

http://wlan.mipt.ru

nuclearcat · July 9, 2009

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

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

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

Дегтярев Илья · July 9, 2009

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

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

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

nuclearcat · July 9, 2009

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

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

tgz · July 10, 2009

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

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

nuclearcat · July 10, 2009

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

tgz · July 11, 2009

Что там у тебя от ухода часов зависит то?

nuclearcat · July 11, 2009

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

tgz · July 12, 2009

Такс... Давай тогда тезисно алгоритм.

nuclearcat · July 12, 2009

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

Есть точка А, есть точка 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.

Sign In

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

Recommended Posts

nuclearcat

nuclearcat

nuclearcat

pety

chainick

nuclearcat

nuclearcat

tgz

nuclearcat

tgz

nuclearcat

tgz

nuclearcat

pety

tgz

Дегтярев Илья

nuclearcat

Дегтярев Илья

nuclearcat

tgz

nuclearcat

tgz

nuclearcat

tgz

nuclearcat

Join the conversation