[MaxSavin]

Господа,

 

имеется сугубо технический вопрос... Соорудили следующую 2mbps поделку между двумя точками (географическое расстояние - примерно 37 км):

 

ethernet <-> eth-to-v.35 (RAD TinyBridge) <-> v.35-to-g.shdsl (nateks flexdsl) <-> g.shdsl-to-?? <-> SDH network <-> ??-to-g.shdsl <-> g.shdsl-to-v.35 (nateks flexdsl) <-> v.35-to-eth (RAD TinyBridge).

 

Т.е., технологически ethernet заворачивается на синхронку, через shdsl долетает до телефонистов и далее по sdh транспортируется на противоположную точку где совершенно аналогично демультиплексируется и предстает во всей красе.

 

В общем и целом, путь и центральное оборудование не особенно ясно, да и не суть. Разве что на на dsl-"last mile" можно особо не грешить, кабели с обоих сторон каналов известны и с ним все очень хорошо (оба стопарникап проложены по нашему же заказу, так что никаких соплей там нет и в помине). Но вот что имеем в итоге: скорость в канале близка к номинальной (1850-1900Kbps, что за вычетом накладных расходов на инкапсуляцию похоже на правду), но вот задержки ведут себя как заправские козлы:

 

------------------- cut -------------------

$ ping -c 100 other.side

PING other.side (10.10.10.2): 56 data bytes

64 bytes from 10.10.10.2: icmp_seq=0 ttl=64 time=17.174 ms

64 bytes from 10.10.10.2: icmp_seq=1 ttl=64 time=104.338 ms

64 bytes from 10.10.10.2: icmp_seq=2 ttl=64 time=91.107 ms

.....

64 bytes from 10.10.10.2: icmp_seq=97 ttl=64 time=20.307 ms

64 bytes from 10.10.10.2: icmp_seq=98 ttl=64 time=7.060 ms

64 bytes from 10.10.10.2: icmp_seq=99 ttl=64 time=93.521 ms

 

--- other.side ping statistics ---

100 packets transmitted, 100 packets received, 0% packet loss

round-trip min/avg/max/stddev = 6.175/56.391/105.231/29.288 ms

------------------- cut -------------------

 

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

 

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

 

Вот и возникает вопрос - насколько данное характерно для sdh? Или все же конечное оборудование развлекается?

 

PS: в целом схемка, конечно, оставляет желать лучшего, но классическая вторая российская беда (которая после дураков): стоит только высунуться за пределы города - как инфраструктурный швах во всей красе. Вот и приходится телефонистам на хвост падать.

[GonZO]

о боги... вот это извращение... :0

 

сократите, как минимум "eth-to-v.35 (RAD TinyBridge) <-> v.35-to-g.shdsl (nateks flexdsl)". поставив тот же flexDSL, только 4Eth...

 

немудрено, что такие задержки -- подсчитай этапы конвертирования...

 

зы. у нас лан гоняется через конвертеры rad FCD-IP, сразу на триб. нортелевского SDH. задержки есть, но не такие.

[A1ik]

Не факт, что дело в количестве конвертирования. Скорее даже не в том дело. Надо проверить синхронизацию по всему тракту - кто от кого ее берет. У нас была еще более хитрая и навороченная комбинация - были потери пакетов от 5 до 50%. Оказалось лишь в одной точке были "слипы" - Nateks`ы мастер со слэйвом поменяли местами и установили синхронизацию от потока SDH кольца - потерь стало 0%.

[MaxSavin]

о боги... вот это извращение... :0

Этого не отнять, но бывает и хуже :)

 

сократите, как минимум "eth-to-v.35 (RAD TinyBridge) <-> v.35-to-g.shdsl (nateks flexdsl)". поставив тот же flexDSL, только 4Eth...

1. А можно уточнить название модели? Что-то не пропомню такого, чтобы на одной стороне был Eth + dsl(для последней мили), а с другой - dsl + интерфейс к SDH. Т.е., таких "комбо-приводов-с-мостом" у натекса не встречал.

2. Телефонисты предложили только вышеприведенную схему (впрочем, на выходе предлагались v.35 или g.703 по вкусу). И "клали яйца на стол", что по другому в разумные деньги не вписаться.

 

немудрено, что такие задержки -- подсчитай этапы конвертирования...

Ну, как бы, совет немного "риторичен", имхо. Для подсчетов нужны детальные спеки на РАДы и flexDSL, и если у последних их еще достать можно, то первые...

 

Да и вообще, я бы еще понял даже задержки в 50-100ms., но с джиттером в пределах погрешности. Но тут же колебания в диапазоне 5-110ms, что весьма странно.

 

зы. у нас лан гоняется через конвертеры rad FCD-IP, сразу на триб. нортелевского SDH. задержки есть, но не такие.

А это чудо имеет ССС-сертификат? :) Ибо девайсов-то в мире много, но в ВСС их не пустят...

[MaxSavin]

Не факт, что дело в количестве конвертирования. Скорее даже не в том дело. Надо проверить синхронизацию по всему тракту - кто от кого ее берет. У нас была еще более хитрая и навороченная комбинация - были потери пакетов от 5 до 50%. Оказалось лишь в одной точке были "слипы" - Nateks`ы мастер со слэйвом поменяли местами и  установили синхронизацию от потока SDH кольца - потерь стало 0%.

Спасибо, отправлю телефонистам, пусть думают/пробуют.

 

Кстати, а есть ли способ каким-либо образом проверить, эээ, "качественность" (если такое понятие применимо) потока? Доступ к консоли flexDSL'ей на клиентских сторонах стороне имеется. Пока из мыслей только подключить какие-нибудь альтернативные allied-telesyn'ы, дабы убедиться что не РАД'ы вносят эту самую задержку.

[GonZO]

MaxSavin, FlexDSL FG-PAM-SAN-E1B со стороны "интерфейса с SDH" (он же g.703), а со стороны локалки -- PG-PAM-SAN-4Eth. лучше позвонить в натекс, у них там мощная техподдержка -- объяснят.

 

и ваши волосы мягкие и шелковистые.

[Так себе]

Ну во-первых, g.shdsl в sdh такого в природе не бывает, также как и

"интерфейса с SDH" (он же g.703) это не он же.

 

То что у Вас после V.35, это просто два модема, с одной стороны (у Вас) V.35 и на станционной стороне (у телефонистов как Вы их называете) G.703 (E1 так называемый), а вот между модемами xDSL. Вот имено этот Е1 они упаковывают в STM(т.е. SDH) и соответствено ровно тоже с другой.

 

Сразу откажитесь от мысли что у Вас проблемы где-то в SDH этого быть не может, это самое сильное звено в Вашей цепи.

Так что ищите BUG начиная с последней мили и к себе.

 

Теперь как избавиться от такой чехарды...

 

"ethernet <-> eth-to-v.35 (RAD TinyBridge) <-> v.35-to-g.shdsl (nateks flexdsl) <-> g.shdsl-to-?? и с другой стороны

 

??-to-g.shdsl <-> g.shdsl-to-v.35 (nateks flexdsl) <-> v.35-to-eth (RAD TinyBridge). "

 

---------------------------------------------------------------------------------

"сократите, как минимум "eth-to-v.35 (RAD TinyBridge) <-> v.35-to-g.shdsl (nateks flexdsl)". поставив тот же flexDSL, только 4Eth..."

 

Совершено правельное предложение.

 

-----------------------------------------------------------------------------------

"А можно уточнить название модели? Что-то не пропомню такого, чтобы на одной стороне был Eth + dsl(для последней мили), а с другой - dsl + интерфейс к SDH. Т.е., таких "комбо-приводов-с-мостом" у натекса не встречал"

 

А на это я ответил в самом начале, что такого вообще в природе не бывает и делается это через Е1 а вот Ethernet - dsl - E1 это так как доктор прописал:-))

----------------------------------------------------------------------------------

 

Да это не только на Натаксе можно сделать, ещё знаю Schmid telecom (Watson 5), тоже самое

 

Ethernet - xDSL - ( E1 - SDH - E1 ) - xDSL - Ethernet

 

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

[MaxSavin]

Ну во-первых' date=' g.shdsl в sdh такого в природе не бывает, также как и "интерфейса с SDH" (он же g.703) это не он же.

 

То что у Вас после V.35, это просто два модема, с одной стороны (у Вас) V.35 и на станционной стороне (у телефонистов как Вы их называете) G.703 (E1 так называемый), а вот между модемами xDSL. Вот имено этот Е1 они упаковывают в STM(т.е. SDH) и соответствено ровно тоже с другой.[/quote']

 

В данном случае я просто описывал всю цепочку. Понятно, что xdsl применяется в данном случае просто для транспортировки потока до sdh-сети.

 

Ну а что делать, если они "телефонисты" и есть? :)

 

Сразу откажитесь от мысли что у Вас проблемы где-то в SDH этого быть не может, это самое сильное звено в Вашей цепи.

Так что ищите BUG начиная с последней мили и к себе.

"В этом мире я доверяю только одному человеку, и сейчас ты с ним говоришь" (с) Халей&Мальборо, как мне помнится.

 

С учетом того, что "телефонистами" является ПТС (а-ля "Северо-Западный Телеком"), вышеприведенный скепсис в отношении "кристальной чистоты сети" только укрепляется.

 

Теперь как избавиться от такой чехарды...

"сократите, как минимум "eth-to-v.35 (RAD TinyBridge) <-> v.35-to-g.shdsl (nateks flexdsl)". поставив тот же flexDSL, только 4Eth..."

 

Совершено правельное предложение.

Правильность есть понятие очень относительное и субъективное. В особенности когда сеть собрана и уже работает. Хотя сейчас попробуем заказать "на потестить" FG-PAM-SAN-4Eth-R.

 

"А можно уточнить название модели? Что-то не пропомню такого, чтобы на одной стороне был Eth + dsl(для последней мили), а с другой - dsl + интерфейс к SDH. Т.е., таких "комбо-приводов-с-мостом" у натекса не встречал"

 

А на это я ответил в самом начале, что такого вообще в природе не бывает и делается это через Е1 а вот Ethernet - dsl - E1 это так как доктор прописал:-))

Я и имел ввиду проброс потока через dsl, хотя признаю, описал криво :)

 

Ethernet - xDSL - ( E1 - SDH - E1 ) - xDSL - Ethernet

 

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

Ну концептуально такая схема реализована и сейчас, просто заворачивалка eth в поток реализована отдельным устройством.