Поддержка настройки "Задержка перехода на резерв" для резервирования TDM.

[san]

В 13-й версии ПЛИС SW-01 появилась новая настройка для функции резервирования потоков TDM - "Задержка перехода на резервный поток с основного после появления аварии основного потока". Требуется добавить новую ПЛИС в SW-01 и в настройке резервирования потоков TDM добавить поле ввода "Задержка перехода на резерв".

В ПЛИС настройка хранится в регистре E1_goto_res_timer, описание и сама ПЛИС v13 лежат в engprogs.

[alx]

В чем состоит улучшение?

[san]

Переделаю в задачу.
Улучшение уже сделал Толя, реализовав настройку, которую просили пользователи.

p.s. В некоторых случаях пользователю удобнее, чтобы при кратковременных авария поток не переходил на резерв и обратно. Например, когда пользователю известно что несколько раз в день рядом с кабелем проходит электричка - при переключении на резервный поток будет потеряно больше данных, чем если остаться на основном.

[alx]

Replying to san:

Переделаю в задачу.

Это было не обязательно, достаточно было аргументировать предложение. :)

Улучшение уже сделал Толя, реализовав настройку, которую просили пользователи.

Это, конечно, замечательно. Но чтобы мне принять решение о включении сделанного Толей в код SW-01, мне же надо понимать, что в результате это действительно сделает нашу аппаратуру лучше! А из первоначального описания тикета я этого понять не смог - для меня было непонятно, для чего может потребоваться продолжать прием с неисправного направления, когда имеется исправное (и все еще не понятно - см. ниже)...

p.s. В некоторых случаях пользователю удобнее, чтобы при кратковременных авария поток не переходил на резерв и обратно. Например, когда пользователю известно что несколько раз в день рядом с кабелем проходит электричка - при переключении на резервный поток будет потеряно больше данных, чем если остаться на основном.

Спасибо за пояснение. Теперь идея в целом понятна. Но мне все-таки непонятны частности. Поясни, пожалуйста, как это возможно, что при переключении с неисправного тракта на исправный будет потеряно больше данных, чем если оставаться на неисправном. Мне казалось, что наоборот:

• при переключении на резервный тракт время отсутствия связи (считая от момента появления аварии, то есть выхода из синхронизма) равно времени вхождения в синхронизм.
• если же оставаться на основном тракте, время отсутствия связи равно времени действия помехи (из-за которой пропала связь) плюс времени вхождения в синхронизм.

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

[san]

Разве не так?

Ну это если не считать возврата обратно на основной тракт.
Часто по резервному тракту у пользователей тоже идут полезные данные, просто менее приоритетные, и поэтому они не хотят лишний раз(ложно) переходить на резервный тракт.

[alx]

Replying to san:

Ну это если не считать возврата обратно на основной тракт.

Есть же возможность настроить резервирование без возврата (пока другой тракт не сломается)...

Часто по резервному тракту у пользователей тоже идут полезные данные, просто менее приоритетные, и поэтому они не хотят лишний раз(ложно) переходить на резервный тракт.

А, прости за любопытство, как это возможно - передавать по резервному тракту какие-то посторонние данные - если в таблице коммутации для резервного потока записывается копия коммутации основного? Разве это не значит, что в оба направления всегда передается одно и то же? Я смутно припоминаю, что мы когда-то о чем-то таком говорили, но разве это было реализовано? В РЭ я ничего подобного не вижу...

[alx]

Не вижу улучшения в предложенном именении.

[san]

Replying to alx:

А, прости за любопытство, как это возможно - передавать по резервному тракту какие-то посторонние данные - если в таблице коммутации для резервного потока записывается копия коммутации основного? Разве это не значит, что в оба направления всегда передается одно и то же? Я смутно припоминаю, что мы когда-то о чем-то таком говорили, но разве это было реализовано? В РЭ я ничего подобного не вижу...

По какой-то причине я не заметил этот коммент, поэтому и не ответил.
Нет. В оба направление не передаётся одно и тоже. Пользователь для резервного потока настраивает свою коммутацию, которая работает пока не состоится переход на резерв. Это было реализовано достаточно давно, лет 7 назад(+-), практически сразу после появления функции резервирования.

[alx]

Replying to san:

Нет. В оба направление не передаётся одно и тоже. Пользователь для резервного потока настраивает свою коммутацию, которая работает пока не состоится переход на резерв.

Я правильно понял, что речь идет о резервировании средствами платы SW-01, которое описано в разделе 6.2.14? Если да, то в этом разделе есть такой текст:

При назначении резервного потока в него автоматически прописывается коммутация основного потока. Так, для примера, из рисунка Рис. 6.29 при назначении потока 6E1 резервным для 5E1 в поток 6E1 автоматически прописывается коммутация потока 5E1. Потоки 5E1 и 7E1 скоммутированы друг в друга, соответственно в поток 6E1 будет автоматически скоммутирован поток 7E1. Состояния коммутации приведены на Рис. 6.30

Далее на рисунке 6.30 нарисовано ровно то, о чем я писал выше - как один поток раздваивается сразу в два... Как это понимать? Это что - все вранье? Или у меня с пониманием прочитанного совсем плохо стало? :(

Это было реализовано достаточно давно, лет 7 назад(+-), практически сразу после появления функции резервирования.

Сейчас увидел в самом первом абзаце раздела 6.2.14 упоминание о том, что резервный поток может использоваться для передачи произвольных данных. Но где описано, как передавать произвольные данные в резервном потоке, в который автоматически прописывается коммутация основного потока?

[san]

Как это понимать? Это что - все вранье?

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

[alx]

Replying to san:

Это было реализовано достаточно давно, лет 7 назад(+-),

Ты прав, я нашел этот коммит. 8 лет назад. А вот соответствующий пост в блоге.

[alx]

Провел практический эксперимент - назначил в таблице коммутации один из потоков резервным. Теперь в этой строке попеременно отображается то его прежняя коммутация, то надпись "Поток включен в качестве резерва для 5E1". Это так и должно работать?

[san]

Должно работать так:
Когда данные основного потока передаются и принимаются с резервного(произошёл переход на резерв), то в строку резервного потока выводится "Поток включен в качестве резерва для 5E1", в остальное время таблице отображается коммутация пользователя.

[alx]

Replying to san:

Должно работать так:

...
В таком случае, вынужден констатировать, что работает не так, как должно... :(

[alx]

Replying to alx:

что работает не так, как должно...

Причем я вижу не одну, а сразу несколько разных проблем:

• резервный поток становится активным при отсутствии аварии основного потока (ожидал, что никогда не будет активным);
• резервный поток становится неактивным при наличии постоянной аварии основного потока (ожидал, что он всегда будет активным);
• в настройках резервного тракта установлен таймаут возврата на основной поток 50 секунд, однако время активности резервного потока много меньше 50 секунд (ожидал, что при данной настройке резервный тракт не может быть активным менее 50 секунд).

[san]

при отсутствии аварии основного потока

Тут всё таки авария есть - режим СЦС для потока выкл., значит СЦС нет = авария (насколько я понял твой эксперимент в Нижнем Самурае, я его подглядел)

[san]

Просто так этот баг у меня не воспроизвёлся, подозреваю что нужны какие-то особые значения в цикле или сверхцикле

[alx]

Replying to san:

Тут всё таки авария есть - режим СЦС для потока выкл., значит СЦС нет = авария (насколько я понял твой эксперимент в Нижнем Самурае, я его подглядел)

Ты шутишь? :) Искал смайлик, не увидел... :)

Конечно же нет! :) Настройка "СУВ" ничего не говорит (и не может говорить) о том, есть или нет СЦС в приходящем в блок потоке. Она лишь определяет, где мы этот СЦС ожидаем увидеть. Если мы не находим СЦС там, где ожидали - фиксируется авария. По-моему должно быть так. Когда настройка установлена в значение "выкл", мы вообще не ожидаем наличия СЦС в цикле (при этом де-факто СЦС вполне может в потоке присутствовать!), и, следовательно, не должны фиксировать аварию потока при его отсутствии (и, соответственно, никакого синхросигнала нигде не ищем).

В подтверждение приводу вывод аварий СЦС из ПЛИС:

root@sw01:~# spictl 01 03 00 00 00
0x0000: 00 00 00 a0 00
root@sw01:~# spictl 01 04 00 00 00
0x0000: 00 00 00 00 00
root@sw01:~#

Здесь два регистра флагов по 16 бит в каждом (два последних значения в выводе - я выделил жирным). Как видишь, из 32 потоков E1 авария СЦС зафиксирована только в двух - 16E1 и 14E1 - то есть только те, где установлен режим СУВ "КИ16", но потока не подано. Ни в одном потоке, для которых режим СУВ установлен в "выкл" (включая 5E1, для которого я сделал резерв), аварии СЦС не фиксируется, и это правильно.

Не хочешь же ты сказать, что для всех потоков, где установлен режим СУВ "выкл", должна отображаться авария потока! :) :) :)

[san]

Я говорил не про отображение аварии СЦС а о критерии перехода на резерв, вот тут я не знаю "выкл" это считается основанием для перехода на резерв или нет.

[alx]

Replying to san:

Я говорил не про отображение аварии СЦС а о критерии перехода на резерв,

Так я как раз и установил для резервного потока единственный критерий активации - авария СЦС!

[alx]

Вот тебе еще один эксперимент: практически одновременно читаю из ПЛИС регистр аварий СЦС (первых 16 потоков) и регистр состояния резервирования:

root@sw01:~# spictl 01 03 00 00 00; spictl 01 24 00 00 00
0x0000: 00 00 00 a0 00
0x0000: 00 00 00 00 11
root@sw01:~# spictl 01 03 00 00 00; spictl 01 24 00 00 00
0x0000: 00 00 00 a0 00
0x0000: 00 00 00 00 19
root@sw01:~# spictl 01 03 00 00 00; spictl 01 24 00 00 00
0x0000: 00 00 00 a0 00
0x0000: 00 00 00 00 11
root@sw01:~# spictl 01 03 00 00 00; spictl 01 24 00 00 00
0x0000: 00 00 00 a0 00
0x0000: 00 00 00 00 11
root@sw01:~# spictl 01 03 00 00 00; spictl 01 24 00 00 00
0x0000: 00 00 00 a0 00
0x0000: 00 00 00 00 11
root@sw01:~# spictl 01 03 00 00 00; spictl 01 24 00 00 00
0x0000: 00 00 00 a0 00
0x0000: 00 00 00 00 19
root@sw01:~# spictl 01 03 00 00 00; spictl 01 24 00 00 00
0x0000: 00 00 00 a0 00
0x0000: 00 00 00 00 11

Команды выполнялись с интервалами около 1 секунды. Как можно видеть, состояние аварий СЦС не меняется - в аварии всегда только 14E1 и 16E1. Однако резервный тракт почему-то активируется (см. бит 3 последнего прочитанного октета).

[alx]

Replying to san:

вот тут я не знаю "выкл" это считается основанием для перехода на резерв или нет.

А чего тут знать-то? Я же здесь выступаю в роли простого пользователя! Я настроил резервирование, отметив "Активировать при: СЦС". А теперь вижу, что авария СЦС не индицируется, а переход на резерв индицируется (я не знаю, произошел ли переход на резерв в действительности)! И у меня - когнитивный диссонанс! :( Разве это правильно? Разве так должно быть?

[alx]

Вот тебе еще один эксперимент: как и предыдущий, но режим СУВ для 5E1 установлен в "КИ16".

root@sw01:~# spictl 01 03 00 00 00; spictl 01 24 00 00 00
0x0000: 00 00 00 a0 10
0x0000: 00 00 00 00 11
root@sw01:~# spictl 01 03 00 00 00; spictl 01 24 00 00 00
0x0000: 00 00 00 a0 10
0x0000: 00 00 00 00 19
root@sw01:~# spictl 01 03 00 00 00; spictl 01 24 00 00 00
0x0000: 00 00 00 a0 10
0x0000: 00 00 00 00 11
root@sw01:~# spictl 01 03 00 00 00; spictl 01 24 00 00 00
0x0000: 00 00 00 a0 10
0x0000: 00 00 00 00 11
root@sw01:~# spictl 01 03 00 00 00; spictl 01 24 00 00 00
0x0000: 00 00 00 a0 10
0x0000: 00 00 00 00 11
root@sw01:~# spictl 01 03 00 00 00; spictl 01 24 00 00 00
0x0000: 00 00 00 a0 10
0x0000: 00 00 00 00 11

Как видим, авария СЦС 5E1 есть всегда, однако большую часть времени резервный поток деактивирован...

[alx]

А вот еще одна странность. Даже не одна а, две.

В экспериментах выше мы читали регистр 0x124 - состояние резервирования, бит 3 в котором сигнализирует, по какому потоку идет трафик - основном или резервному. Мне стало интересно, что означают другие биты в этом регистре, и я нашел его описание в документации. Оказалось, что бит 0 сигнализирует... потерю СЦС основного потока! А теперь см. commant:20 - там этот бит всегда 1, что означает потерю СЦС основного потока, однако в регистре 0x103 бит 4 всегда равен нулю (напоминаю, что основным потоком в моем эксперименте является 5e1)! Откуда взялась эта единица?

Но это еще не все. Бит 4 регистра 0x124 индицирует... потерю СЦС резервного потока, и он всегда 1, в то время как в регистре 0x103 бит 5 всегда 0 (напоминаю, что резервным потоком в моем эксперименте является 6e1)! Откуда взялась эта единица?

И третья странность: согласно документации, если резервный поток в аварии, он никогда не должен активироваться. Мы же видим, что поток активируется (бит 3 регистра 0x124 равен 1) при сигнализации аварии СЦС (хоть и ложной) резервного потока!

Сейчас проверю то же самое с новой прошивкой ПЛИС, и если в ней то же самое, придется создать соответствующий тикет для разработчика ПЛИС...

PS. Сигнализацию этих аварий мы видим в веб-интерфейсе как кравные надписи "LOM" в левом верхнем углу ячеек основного и резервного потоков. Я не сразу обратил на них внимание...

[alx]

Новая версия ПЛИС ведет себя так же (индицирует ложные аварии основного и резервного потоков), за исключением того, что в ПЛИС версии 13 всегда индицируется работа по резервному потоку (бит 3 регистра 0x124 всегда 1), то есть нет постоянной активации-деактивации резервного потока...

[alx]

Вернулся обратно на ПЛИС версии 12 и обнаружил, что сначала (секунд 30 наверное) резервный поток, как и прежде, активировался и деактивировался (я это видел и в веб-интерфейсе, и прямым чтением состояния из ПЛИС), а потом "застрял" в активированном состоянии. То же самое я видел в веб-интерфейсе после загрузки прошивки версии 13, но подумал, что мне показалось. Теперь понимаю, что не показалось, и прошивки ведут себя одинаково. Возможно, различие с первоначальной картиной каким-то образом связано с тем, что я переконфигурировал ПЛИС "на ходу"...

[alx]

Создал тикет #704.

[alx]

Replying to san:

подозреваю что нужны какие-то особые значения в цикле или сверхцикле

Возможно, что ты в чем-то прав. У меня поток 6E1 выдает плата VE-01 (правда там нет никакого сверхцикла). Так вот я заметил, что пока она не загрузится и не начнет работать, резервный поток обычно неактивен (один раз только видел как он активировался при отсутствии VE-01). Его первая активация как правило совпадает с появлением платы VE-01. Но как это объяснить, я не представляю - во-первых, это резервный поток, а на основном вообще никого нет, а во-вторы, VE-01 не делает сверхцикла в этом потоке, там ISDN PRI работает...

[alx]

Наверное надо с этими комментариями в #704 переходить. Здесь тикет не совсем об этом... :)