Тема: Зависание внутренних линий на TDA
Не путайте сигнализацию с синхронизацией (мастер-слейв по барабану). Если в 1.4 везде стоит NONE TDA будет отдавать синхронизацию встречной АТС.
Тем не менее, практика показала, что при любой установке синхронизации в 1.4 МС, поток работает и не валится (про зависания аналоговых линий пока молчим). Причём вне зависимости от того, как настроена синхронизация со стороны * - как NORMAL или как MASTER
С чего бы ему валиться? 🐛 У каждой станции имеется свой клокинг-генератор. Вот только только слипы будут донимать, если их друг на друга натравить.
2 Master001
Это порочная практика, синхра должна передаваться как в паре так и по цепочке - или типа если * , то факсы ф топку?
Ну я и не утверждаю что это правильно и так должно быть =)
В общем SLC порт опять отвалился. Эксперименты продолжаются ....
С чего бы ему валиться? 🐛 У каждой станции имеется свой клокинг-генератор. Вот только только слипы будут донимать, если их друг на друга натравить.
В свое время с синхрой подолбался. “Дружил” Самсуг с Панасом 500-ткой. Каждая из станций имеет подключение внешнего потока от разных провайдеров. Станции провов должны быть засинхронизированы между собой. На деле оказалось не так. Пришлось Панаса синхронизировать от “Фарлепа”, Самсунга от “Велтона”. Пробовал засинхронизировать их между собой хоть в напр. Панас-Самсунг, хоть Самсунг-Панас слипы ДОСТАЛИ. Расцепили, сделали СО на Панасе, Network на Самсунге. Панасу синхру не принимать и не отдавать - слипы ушли и не вернулись. Одиночная ошибка при таком раскладе накопится месяца за 3 и её никто не заметит. NONE - не принимать синхру(Наблюдатель чуть-чуть ошибся) Мастер её отдает слейв прнимает если надо. Если поставить NONE везде, то синхронизироваться будет от внутреннего генератора АТС. Обычно синхра должна передаваться по цепочке( ам ) через транзитные АТС
NONE это значит отдавать синхронизацию, и Master/Slave здесь не причем.
Как и говорил выше наблюдатель, это из другого уровня оси.
Еще, если карта Sangoma, наберите в системе ifconfig. см. w1g1
параметр overruns не должен увеличиваться. у меня растёт постоянно.
У меня когда синхронизация криво настроена была, то overrans набегал и довольно много, сейчас есть чуть-чуть, но за день около 100 набежало.
А до настройки синхронизации постоянно росло, до нескольких тысяч набиралось.
сейчас так сделано: порт 1 PRI CPE, синхр. нормал, EuroISDN
порт 2 PRI NET, синхр мастер от порта 1, QSIG.
ошибки растут и там и там.
при других настройках синхронизации всё то же самое.
могу предположить глюк ОС (CentOS) либо драйверов / прошивки карты.
сейчас так сделано: порт 1 PRI CPE, синхр. нормал, EuroISDN
порт 2 PRI NET, синхр мастер от порта 1, QSIG.
ошибки растут и там и там.
при других настройках синхронизации всё то же самое.
могу предположить глюк ОС (CentOS) либо драйверов / прошивки карты.
На астериске настройки “один в один”.
На TDA у меня стояло в 1.4 везде NONE, overrans рос, слипы были.
Теперь в 1.4 стоит “1:PRI30”, то есть что бы синхру брал с платы, и слипов нет, overrans не ростет.
[root@server ] wanrouter version
WANPIPE Release: 3.5.20
драйвер обновлял недавно. Дистрибутив Elastix 2.0.6
Собственно осталось 2 проблемы:
1) Зависают линии.
2) Отваливается транк.
Вот вы тут все настройками играетесь, а в чем проблема в логике или физике до сих пор не выяснили. Я так понял, что станции у вас рядом и соединены напрямую карта в карту. Попробуйте взять у какой-нить торгующей организации два SHDSL-модема на тестирование и соединить АТС через них. Если зависания пропадут, то дело в физике, если нет, то придется с сигнализацией разбираться.
Вот вы тут все настройками играетесь, а в чем проблема в логике или физике до сих пор не выяснили. Я так понял, что станции у вас рядом и соединены напрямую карта в карту. Попробуйте взять у какой-нить торгующей организации два SHDSL-модема на тестирование и соединить АТС через них. Если зависания пропадут, то дело в физике, если нет, то придется с сигнализацией разбираться.
Модемы просил на тестирование, пока никто не дал, попробую поискать еще.
А по поводу сигнализации не могли бы пояснить. Допустим проблема не в физике, тогда что делать с сигнализацией? куда смотреть? Интересуюсь, так как пока выяснить физика это или нет, не получается, и хочется опробовать решение, которое возможно, то есть “настройки”.
А может быть такая проблема в плохой/кривой/косой синхронизации города?
2 Savin Evgenii
Поскольку вы берете поток у гатс, то и попробуйте порешать проблему с ними - попросите у оператора контактный тел. спецов траспортников или измерителей, у них обязательно найдется и пара модемов и тестер анализатор потока Е1, с помощью последнего можно просмотреть буквально всё, форму и искажения импульсов, кодовые и битовые ошибки, проверить работу плат Е1 как в режиме терминала, так и в режиме мониторинга рабочей связки */ панасоник. Кстати и связку с городом, проверите на вшивость.
Понятно что если у опера ошибок и аварий нет, то он вам ничем не обязан, но ведь можно договорится частным образом.
А если контору лихорадит, то оплату под это дело можно выбить.
Буферизация на плате растет вне зависимости от CRC, синхронизаций и прочего. После смены ОС и железа, удалось сделать так, чтобы overrun рос только на одном из 2х портов. Причем после перезапуска, он начинает расти то в сторону ГАТС, то в сторону Панаса. Полная мистика. Также, удается установить работоспособность, к примеру если на сервере CRC4 включен, а на панасонике выключен. Чего быть в принципе не должно.
... эксперименты продолжаются.
