[Nickel]

Звучит, конечно, круто, но как-то совсем уж фантастично. Не поделитесь какой-нибудь историей про то, как такое бывает? Интересует что именно и как именно удавалось починить при таких исходных данных? Правда, очень интересно.

Ок, простейшие эпизоды:

1. мужики смонтировали систему пожарной сигнализации на нефтебазе и пытаются ее запустить. Шлейф системы в служебном режиме видит один датчик, в рабочем - ни одного. Причина: не прописаны адреса датчиков, система шинно-адресная, перед тем, как растаскивать датчики по территории в пять гектар - надо было их по одному подключать в служебном режиме к панели и прописывать им адреса. В документации к панели есть процедура как это делается с единичным датчиком, но в проектной документации на систему об этом ни слова. Пусконаладчики запустили в своей жизни сотни систем, но с этой столкнулись впервые. У них тупик. Я же просто понимаю, как работает шинно-адресная конструкция, поэтому мне хватило 10 минут и двух страниц доки, чтобы понять в чем проблема. Это было мой первый и последний опыт общения с контрольными панелями пожароохранных систем.

 

2. Промавтоматизация, сеть Profibus. Мы тянули кабели вкупе с множеством других проводов, разделали, прогнали специальным тестером. Все в норме. Наладчики жалуются - чуть ни половину устройств не видно. Отправил их перепроверять адреса на подключенных устройтвах. Все появились. Но сеть на заданной скорости не работает, работает на меньшей. Они чего с ней не делают, быстро не хочет, отваливаются устройства и становится нестабильной, при этом в физике все ОК. А она, сцуко, местами оптическая, местами медная, с узлами из потики в медь. Проверил длины сегментов vs скорость, посчитал длины трасс по кабелю, оказалось - и не может работать быстрее. Они длины считали на глаз и от шкафа к шкафу, а кабели идут через техэтаж, вдвое почти длиннее. Разобрались.

 

3. Криво работает ВКС, в одну сторону картинка идеальная, в другую - 128К, квадраты, хрюкает. Перегруза канала нет, нагрузочный тест канал держит отлично, ВКС показывает небольшой (не существенный) дроп на конце с плохой картинкой. Задумался, отправил инженеров искать duplex mismatch на каком-то из езернетовских стыков, даже обяснил с какого конца стоит half, ф с какого full. За 10 минут нашли и исправили, все заработало. Надо объяснять логику? ;) Кстати, с последним я сталкивался в жизни 3 раза :)

 

Все три кейса строятся на ПОНИМАНИИ принципов и протоколов, а не на знании команд и правил.

Спасибо, действительно интересно.

По третьему кейсу - можно предположить, что с стой стороны, где стоит железка с портом в Full картинка должна быть более-менее, т.к. порт half делает ретрансмиты в случае коллизий, и если канал сравнительно узкий и трафика мало, то трафик должен проходить в достаточном объеме, чтобы было видно/слышно. А со стороны, где выставлен half - наоборот картинка плохая, т.к. все данные от порта full приходят с потерями и коллизий порт не видит, только CRC ошибки. Нагрузочный тест, предположим, мог пройти нормально из-за того, что канал всего 320К, и даже при диких потерях между портами FE такой трафик им удается пропихнуть. Но пингом же должно быть видно потери, хотя бы 3-5%, а это уже не "несущественный" и тем более не "дроп". Причем здесь дропы вообще не понял, кстати.

[izuware]

Прохожий когда понимаешь как работает - не так интересно, гораздо прикольнее учить литейщиков литью по инструкции на станок. Вся беда в том что у станка оказался компьютер и весь цех с присутвующим на запуске Главным Конструктором оказались не способны отмерять пластикат и время инжекции в процентах от цикла. Я за полдня узнал много интересного про литьё вообще, литьё горячее в частности и окружающий мир в целом ))

[Картуччо]

http://habrahabr.ru/post/151390/

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

[Прохожий]

Прохожий когда понимаешь как работает - не так интересно, гораздо прикольнее учить литейщиков литью по инструкции на станок. Вся беда в том что у станка оказался компьютер и весь цех с присутвующим на запуске Главным Конструктором оказались не способны отмерять пластикат и время инжекции в процентах от цикла. Я за полдня узнал много интересного про литьё вообще, литьё горячее в частности и окружающий мир в целом ))

Ну, собственно, в этом и заключается инжиниринг как область знания :)

 

По третьему кейсу - можно предположить, что с стой стороны, где стоит железка с портом в Full картинка должна быть более-менее, т.к. порт half делает ретрансмиты в случае коллизий, и если канал сравнительно узкий и трафика мало, то трафик должен проходить в достаточном объеме, чтобы было видно/слышно. А со стороны, где выставлен half - наоборот картинка плохая, т.к. все данные от порта full приходят с потерями и коллизий порт не видит, только CRC ошибки. Нагрузочный тест, предположим, мог пройти нормально из-за того, что канал всего 320К, и даже при диких потерях между портами FE такой трафик им удается пропихнуть. Но пингом же должно быть видно потери, хотя бы 3-5%, а это уже не "несущественный" и тем более не "дроп". Причем здесь дропы вообще не понял, кстати.

Когда "кривой" езернет встроен участком в длинный составной канал, где самое узкое место - несколько мегабит, ты почти не увидишь дропа ;) И не увидишь дропа в счетчике пакетов, потому что интерфейс в НОРМАЛЬНОМ состоянии.

 

Объясняю.

 

Дроп образуется в направлении от фулл к халф при коллизии. Ведь фулл не реагирует на джам-посылку и не ретрансмитит. Коллизия на халфе - вероятностное явление, вероятность которого зависит нелинейно от нагрузки на канал в ОБЕ СТОРОНЫ. Поэтому никакой iperf сколько ни будь значимой проблемы проблемы не покажет. Пинг - так же, потому что ты же не будешь пинговать с рейтом хотя бы в 10% загрузки FE (14.4 kpps). Но именно с ВКС ситуация иная, она пораждает очень РАВНОМЕРНЫЙ поток пакетов (каждые 20 мс) в обоих направлениях, а дальше - физика, что такое "биения" в волнах слышал? Когда частота отличается не сильно? Вот такие "биения" из дропов и происходят на стыки, причем - в одном направлении. При этом система ВКС, видя дропы полагает, что емкость канала - недостаточна, поэтому снижает битрейт. Но битрейт снижается не за счет количества пакетов в секунду, а за счет их размера! Поэтому проблема облегчается (вероятность коллизии НЕСКОЛЬКО снижается), но не уходит! Таким образом, один из концов ВКС (который ловит дропы, т.е. на стороне халф-интерфейса) получает сигнал с минимальным битрейтом, от чего качество становится ужастным гавном. И таки же с продолжающимися дропами, поскольку пакетрейт как был 50pps, так и остался, и частота посылки встречных пакетов остается близкой. Пинг же не обеспечивает очень "ровной" посылки пакетов, ибо следующий запрос посылается не ранее получения ответа на предыдущий, т.е. нет "равномерности".

 

Таким образом, данный баг успешно "сглатывается" почти всеми протоколами, кроме псевдо-синхронных типа RDP, а его влияние нелинейно растет с увеличением скоростей встречных RDP потоков.

 

"Понятна мысль моя неглубокая?" (с) Раневская

[Картуччо]

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

Не согласен. Как писал, c "duplex mismatch" сталкивался очень много раз. Хреново всё работает по такому каналу. Проблемы вылезает мгновенно и без всяких видеоконференций. Регистируется пингом до 10% потерь запросто.

[Прохожий]

 

Не согласен. Как писал, c "duplex mismatch" сталкивался очень много раз. Хреново всё работает по такому каналу. Проблемы вылезает мгновенно и без всяких видеоконференций. Регистируется пингом до 10% потерь запросто.

Это в том случае, если у тебя сотка из конца в конец. А если у тебя два метра через всю страну - то как раз и не видно никаких последствий на других протоколах ;) У тебя просто дефектный стык не выходит в те области загрузки, где коллизии начинают сколько ни будь значимым образом влиять. А на ВКС получается эффект синхронности.

[Картуччо]

Пусть не 2 метра, но с 10-20 при мисматче на участке CE-PE IP VPN сразу видно. Через всю страну.

[Прохожий]

Пусть не 2 метра, но с 10-20 при мисматче на участке CE-PE IP VPN сразу видно. Через всю страну.

Так и должно быть, это в стародавние времена было исследовано ;) Процентов до 10 нагрузки вероятность коллизий минимальная. Еще раз акцентирую: для RDP этот эффект наблюдается для ЛЮБЫХ загрозок, за счет "синхронности" потока пакетов.

Зависимость пропускной способности разделяемого сегмента от нагрузки

[White_Alex]

Еще раз акцентирую: для RDP этот эффект наблюдается для ЛЮБЫХ загрозок, за счет "синхронности" потока пакетов.

 

наверно все-таки RTP (http://ru.wikipedia.org/wiki/RTP), раз уж речь про ВКС, прошу прощения, что вмешиваюсь :-)

[Прохожий]

 

наверно все-таки RTP (http://ru.wikipedia.org/wiki/RTP), раз уж речь про ВКС, прошу прощения, что вмешиваюсь :-)

Конечно! :) Это я заговариваюсь по склерозу своему :(((((((

[Картуччо]

Ну вот, то не заметно никому кроме видео и рдп, то теперь заметно.

Ещё раз. Последняя миля, которая реально может состоять хрен знает из чего, может быть чисто оптика, может участок синхры с нарезанными vc12 или вообще солянка.

Физически порты 100 мегабит.

Вот там вкрадывается дуплекс мисматч. Провайдер на своём PE маршрутизаторе ограничивает полосу.

На участке CE-PE без наличия полезного трафика уже фиксируются потери пингов во всех вариантах последних миль.

Запуск трафика ни к чему хорошему тоже не приводит.

[Zausenic]

Истина как всегда находится не в крайностях. Разумнее обращать внимание и не диплом и на уменя без диплома. Все люди учатся по разному. Один в институте просто пережидает время другой действительно пытается получить максимум знаний и умений. Другой же самостоятельно приобретает достаточно чтобы быть проффесионалом высокого уровня. Надо быть достаточно гибким по отношению к людям.