Jump to content
Калькуляторы

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites
Почему 107214 - километры в ЧАС?
Буквы перепутал, км/c

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

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

 

http://wlan.mipt.ru

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

 

Share this post


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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this