Saab95 Posted September 8, 2012 Поступило ТЗ, с несколькими интересными пунктами: -Предоставить дуплексный канал связи на скорости 99 мбит/сек. -Обеспечить джиттер (колебание задержки) не более 10мс. Все бы ничего, но только этот канал будет проходить частично через публичные сети, где гарантировать указанные колебания задержки просто невозможно. В принципе если внести дополнительную задержку в 900мс, и буферизовывать принимаемые данные, можно удерживать джиттер в пределах 10мс. То есть задачу можно реализовать. Вопрос - на каких устройствах можно это сделать? Что бы отдавали трафик без буферизации, а принимаемые буферизовали и удерживали внутри себя 900мс? Подойдет на уровнях L2 или L3. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
s.lobanov Posted September 8, 2012 Вопрос - на каких устройствах можно это сделать? Что бы отдавали трафик без буферизации, а принимаемые буферизовали и удерживали внутри себя 900мс? Подойдет на уровнях L2 или L3. linux tc netem, но если тупо задерживать весь трафик на 900мс, то jitter от этого не уменьшиться, т.к. неизвестно на сколько надо задерживать тот или иной пакет, чтобы выравнять их по времени задача о jitterbuffer-е решается только в том случае, когда пакеты классифицированы по потокам и известно с каким интервалом они должны быть на выходе в каждом потоке. в случае voip это реализуют на L7 Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Saab95 Posted September 8, 2012 linux tc netem, но если тупо задерживать весь трафик на 900мс, то jitter от этого не уменьшиться, т.к. неизвестно на сколько надо задерживать тот или иной пакет, чтобы выравнять их по времени задача о jitterbuffer-е решается только в том случае, когда пакеты классифицированы по потокам и известно с каким интервалом они должны быть на выходе в каждом потоке. в случае voip это реализуют на L7 Там не телефония, а какой-то хитрый преобразователь одной среды в другую стоит, какая-то автоматика удаленного управления механизмами или станками, точно не говорят. Но расчитано на работу по кабелю Ethernet на расстоянии до 100 метров=) Интервал времени в принципе можно как-то по GPS синхронизировать. Весь инет перерыл ничего подобного не описывается. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
nuclearcat Posted September 8, 2012 Я писал свое, но выходит все с оверхедом. надо написать простой туннельчик и в пакеты добавлять relative timestamp, соответственно если пакет пришел слишком рано - придерживаем Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
MMM Posted September 8, 2012 А на какое расстояние всё это чудо будет? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Saab95 Posted September 8, 2012 А на какое расстояние всё это чудо будет? Порядка 1000 километров. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
dsk Posted September 8, 2012 Скорее всего это только на бумаге, на практике и так взлетит, тем более что в конечном итоге внутри этой гадости все равно будет эзернет. Возможно также сие написали для отсева "лишних" участников тендера, если таковой конечно имеет место быть. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
puh Posted September 9, 2012 если там будет что-то а-ля TDMoIP, то может и не взлететь. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
shafiev Posted September 9, 2012 Я писал свое, но выходит все с оверхедом. надо написать простой туннельчик и в пакеты добавлять relative timestamp, соответственно если пакет пришел слишком рано - придерживаем +1 . Такую вещь я как понимаю надо на уровне ядра модуль делать? Но походу это так взлетит , вообще надо поснифать что там идет , Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
s.lobanov Posted September 9, 2012 Я писал свое, но выходит все с оверхедом. надо написать простой туннельчик и в пакеты добавлять relative timestamp, соответственно если пакет пришел слишком рано - придерживаем +1 . Такую вещь я как понимаю надо на уровне ядра модуль делать? Но походу это так взлетит , вообще надо поснифать что там идет , вовсе не обязательно. можно взять какой-нибудь userspace openvpn и подправить под задачу, описанную топикстартером. модули ядра писать для production это весьма дорого, если сами не умеете Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
dima89 Posted September 10, 2012 а что, микротик такое не умеет? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
ichthyandr Posted September 10, 2012 Поступило ТЗ, с несколькими интересными пунктами: -Предоставить дуплексный канал связи на скорости 99 мбит/сек. -Обеспечить джиттер (колебание задержки) не более 10мс. ... Кхем ... периодически наши доблестные ФГУПы и НПО рождают в своих недрах чудо проекты :) Я так думаю вопрос решаем путем прокладки выделенной линии. Танцы с линуксом или же даже разработкой спецсофта требуемый джиттер в распределенной системе не обеспечат Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
nuclearcat Posted September 10, 2012 10ms - легко, даже в юзерспейсе Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
A79 Posted September 11, 2012 Поступило ТЗ, с несколькими интересными пунктами: -Предоставить дуплексный канал связи на скорости 99 мбит/сек. -Обеспечить джиттер (колебание задержки) не более 10мс. В принципе если внести дополнительную задержку в 900мс, и буферизовывать принимаемые данные, можно удерживать джиттер в пределах 10мс. То есть задачу можно реализовать. Дуплексный канал, пром. оборудование, наверняка что нибуть с хитрой обратной связью, а Вы им буфер на 900мс? Мне кажется надо уточнить у разработчика ТЗ и обьяснить про джиттер с буфером. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Saab95 Posted September 11, 2012 Вот пытаемся уточнить. Но проблема в том, что между разработчиками и нами есть промежуточное звено в виде руководства заказчика, которое как всегда самое умное=) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
ichthyandr Posted September 12, 2012 Поступило ТЗ, с несколькими интересными пунктами: -Предоставить дуплексный канал связи на скорости 99 мбит/сек. -Обеспечить джиттер (колебание задержки) не более 10мс. В принципе если внести дополнительную задержку в 900мс, и буферизовывать принимаемые данные, можно удерживать джиттер в пределах 10мс. То есть задачу можно реализовать. Дуплексный канал, пром. оборудование, наверняка что нибуть с хитрой обратной связью, а Вы им буфер на 900мс? Мне кажется надо уточнить у разработчика ТЗ и обьяснить про джиттер с буфером. Сто пудов, если оборудование и требования к задержкам - телеметрия, моя имха :) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Butch3r Posted September 12, 2012 Что-то мне кажется что с проходом по public'у не получится ничего. Это больше похоже на "отпугивалку" конкурентов, чтоб тот кто надо выиграл тендр. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
ichthyandr Posted September 12, 2012 Что-то мне кажется что с проходом по public'у не получится ничего. Это больше похоже на "отпугивалку" конкурентов, чтоб тот кто надо выиграл тендр. та нии, обычный разброд и шатание, сплошь и рядом, продукт "современного менеджмента" Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Tosha Posted September 19, 2012 (edited) Автоматика удаленного управления от задержки в 900 мс будет тоже не в восторге, я считаю... И вообще я удивлен, что Вам не поставили в условие еще и предельную задержку. Я думаю, что они имели в виду, что масимальная задержка пакета = 10 мс. Edited September 19, 2012 by Tosha Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
OlegStr Posted September 19, 2012 > если там будет что-то а-ля TDMoIP, то может и не взлететь как вариант, можно посмотреть какое-либо оборудование с поддержкой Synchronous Ethernet http://www.cisco.com/en/US/prod/collateral/routers/ps9853/white_paper_c11-500360.pdf Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Stak Posted September 20, 2012 > если там будет что-то а-ля TDMoIP, то может и не взлететь как вариант, можно посмотреть какое-либо оборудование с поддержкой Synchronous Ethernet http://www.cisco.com..._c11-500360.pdf SyncE не решает задачу уменьшения джиттера. Он предназначен для передачи синхронизации по езернет сети. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
MMM Posted September 21, 2012 Автоматика удаленного управления от задержки в 900 мс будет тоже не в восторге, я считаю... И вообще я удивлен, что Вам не поставили в условие еще и предельную задержку. Я думаю, что они имели в виду, что масимальная задержка пакета = 10 мс. На 1000км будет явно больше 10 мс? Хотя, это пинг, а так - делим на 2, вроде бы то и получаем. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
