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