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

Выравнители задержки Требуется поддерживать гарантированную задержку в канале

Поступило ТЗ, с несколькими интересными пунктами:

 

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

-Обеспечить джиттер (колебание задержки) не более 10мс.

 

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

 

В принципе если внести дополнительную задержку в 900мс, и буферизовывать принимаемые данные, можно удерживать джиттер в пределах 10мс. То есть задачу можно реализовать.

 

Вопрос - на каких устройствах можно это сделать? Что бы отдавали трафик без буферизации, а принимаемые буферизовали и удерживали внутри себя 900мс? Подойдет на уровнях L2 или L3.

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


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

Вопрос - на каких устройствах можно это сделать? Что бы отдавали трафик без буферизации, а принимаемые буферизовали и удерживали внутри себя 900мс? Подойдет на уровнях L2 или L3.

 

linux tc netem, но если тупо задерживать весь трафик на 900мс, то jitter от этого не уменьшиться, т.к. неизвестно на сколько надо задерживать тот или иной пакет, чтобы выравнять их по времени

 

задача о jitterbuffer-е решается только в том случае, когда пакеты классифицированы по потокам и известно с каким интервалом они должны быть на выходе в каждом потоке. в случае voip это реализуют на L7

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


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

linux tc netem, но если тупо задерживать весь трафик на 900мс, то jitter от этого не уменьшиться, т.к. неизвестно на сколько надо задерживать тот или иной пакет, чтобы выравнять их по времени

 

задача о jitterbuffer-е решается только в том случае, когда пакеты классифицированы по потокам и известно с каким интервалом они должны быть на выходе в каждом потоке. в случае voip это реализуют на L7

 

Там не телефония, а какой-то хитрый преобразователь одной среды в другую стоит, какая-то автоматика удаленного управления механизмами или станками, точно не говорят. Но расчитано на работу по кабелю Ethernet на расстоянии до 100 метров=)

 

Интервал времени в принципе можно как-то по GPS синхронизировать. Весь инет перерыл ничего подобного не описывается.

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


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

Я писал свое, но выходит все с оверхедом. надо написать простой туннельчик и в пакеты добавлять relative timestamp, соответственно если пакет пришел слишком рано - придерживаем

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


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

А на какое расстояние всё это чудо будет?

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


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

А на какое расстояние всё это чудо будет?

 

Порядка 1000 километров.

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


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

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

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

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


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

если там будет что-то а-ля TDMoIP, то может и не взлететь.

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


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

Я писал свое, но выходит все с оверхедом. надо написать простой туннельчик и в пакеты добавлять relative timestamp, соответственно если пакет пришел слишком рано - придерживаем

 

+1 . Такую вещь я как понимаю надо на уровне ядра модуль делать?

Но походу это так взлетит , вообще надо поснифать что там идет ,

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


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

Я писал свое, но выходит все с оверхедом. надо написать простой туннельчик и в пакеты добавлять relative timestamp, соответственно если пакет пришел слишком рано - придерживаем

 

+1 . Такую вещь я как понимаю надо на уровне ядра модуль делать?

Но походу это так взлетит , вообще надо поснифать что там идет ,

 

вовсе не обязательно. можно взять какой-нибудь userspace openvpn и подправить под задачу, описанную топикстартером. модули ядра писать для production это весьма дорого, если сами не умеете

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


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

а что, микротик такое не умеет?

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


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

Поступило ТЗ, с несколькими интересными пунктами:

 

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

-Обеспечить джиттер (колебание задержки) не более 10мс.

...

Кхем ... периодически наши доблестные ФГУПы и НПО рождают в своих недрах чудо проекты :) Я так думаю вопрос решаем путем прокладки выделенной линии. Танцы с линуксом или же даже разработкой спецсофта требуемый джиттер в распределенной системе не обеспечат

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


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

Поступило ТЗ, с несколькими интересными пунктами:

 

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

-Обеспечить джиттер (колебание задержки) не более 10мс.

 

В принципе если внести дополнительную задержку в 900мс, и буферизовывать принимаемые данные, можно удерживать джиттер в пределах 10мс. То есть задачу можно реализовать.

Дуплексный канал, пром. оборудование, наверняка что нибуть с хитрой обратной связью, а Вы им буфер на 900мс? Мне кажется надо уточнить у разработчика ТЗ и обьяснить про джиттер с буфером.

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


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

Вот пытаемся уточнить. Но проблема в том, что между разработчиками и нами есть промежуточное звено в виде руководства заказчика, которое как всегда самое умное=)

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


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

Поступило ТЗ, с несколькими интересными пунктами:

 

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

-Обеспечить джиттер (колебание задержки) не более 10мс.

 

В принципе если внести дополнительную задержку в 900мс, и буферизовывать принимаемые данные, можно удерживать джиттер в пределах 10мс. То есть задачу можно реализовать.

Дуплексный канал, пром. оборудование, наверняка что нибуть с хитрой обратной связью, а Вы им буфер на 900мс? Мне кажется надо уточнить у разработчика ТЗ и обьяснить про джиттер с буфером.

Сто пудов, если оборудование и требования к задержкам - телеметрия, моя имха :)

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


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

Что-то мне кажется что с проходом по public'у не получится ничего. Это больше похоже на "отпугивалку" конкурентов, чтоб тот кто надо выиграл тендр.

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


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

Что-то мне кажется что с проходом по public'у не получится ничего. Это больше похоже на "отпугивалку" конкурентов, чтоб тот кто надо выиграл тендр.

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

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


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

Автоматика удаленного управления от задержки в 900 мс будет тоже не в восторге, я считаю... И вообще я удивлен, что Вам не поставили в условие еще и предельную задержку.

Я думаю, что они имели в виду, что масимальная задержка пакета = 10 мс.

Изменено пользователем Tosha

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


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

> если там будет что-то а-ля TDMoIP, то может и не взлететь

 

как вариант, можно посмотреть какое-либо оборудование с поддержкой Synchronous Ethernet http://www.cisco.com/en/US/prod/collateral/routers/ps9853/white_paper_c11-500360.pdf

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


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

> если там будет что-то а-ля TDMoIP, то может и не взлететь

 

как вариант, можно посмотреть какое-либо оборудование с поддержкой Synchronous Ethernet http://www.cisco.com..._c11-500360.pdf

 

SyncE не решает задачу уменьшения джиттера. Он предназначен для передачи синхронизации по езернет сети.

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


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

Автоматика удаленного управления от задержки в 900 мс будет тоже не в восторге, я считаю... И вообще я удивлен, что Вам не поставили в условие еще и предельную задержку.

Я думаю, что они имели в виду, что масимальная задержка пакета = 10 мс.

 

На 1000км будет явно больше 10 мс? Хотя, это пинг, а так - делим на 2, вроде бы то и получаем.

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


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

Join the conversation

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

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

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

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

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

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

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