Секция 2 из 2 - Предыдущая - Следующая
SNR(freq). При наличии НЧ-шума этот алгоритм дает сбой, и модем выбирает
завышеную символьную скорость и/или неверную несущую (нижнюю вместо верхней).
Поскольку завершить startup в таких условиях модем оказывается не в состоянии,
то срабатывает предохранитель, и выбирается младшая символьная скорость 2400,
т.е. 21600 max. С preemphasis index, на который грешили в последнее время,
у USR все чисто.
Затычка прежняя: запрет старших символьных скоростей до успеха. Идеальной
затычкой было бы раздельное управление несущими, ну а для полного исцеления
необходима серьезная модификация кода startup/retrain в DSP, т.е. это к USR-ам.
Если Вы чего-то не поняли - придется читать большое письмо: там все
подробненько разжевано, с картиночками и букварем. И еще, пожалуйста,
больше не надо предъявлять мне претензий по поводу объема!
=============================================================================
* From : Andrey Kuvaldin, 2:5020/234.21 (Tuesday January 20 1998 21:05)
* Subj : СИНДРОМ 21600/V34: когда он вылезает в связке USR-IDC
=============================================================================
Добрый день!
Рыская по логам и архивам SU.INPRO/RU.MODEM в поисках наиболее
подходящей картинки для основного сообщения, я нашел еще одну вещь.
Конкретно - я могу сказать, _когда_именно_ проблема вылезает в связке IDC-USR.
[т.е., несмотря на разумное поведение IDC в вопросе выбора рабочей полосы]
Обычно проблема вылезает, когда в статистике IDC на частотном распределении
SNR видно нечто сверхестественное: сама картинка вполне нормальная,
но цифры рядом с графиками - феноменальные: Average SNR = 45...57 dB, (!!!)
это из того, что я видел сам. Возможно, бывает и еще лучше. ;-)
Короче, если SNR рядом с графиком at%s3 лучше, чем 43..45 dB, то это оно.
Вот пример того, о чем я говорю:
CONNECT 21600/TX: 21600 RX: 21600/V.34/LAP-M/V.42bis
OK
at%s
Link type V.34
Line speed 21600/21600
Serial speed 38400
Error ctrl/comp LAP-M/V.42bis
Symbol rate 2400/2400
Carrier freq 1600/1800
Trellis encoder 4D 16-state/4D 16-state
Precoding On/On
Retrains 0 issued/0 granted/0 auto
Renegotiations 0 issued (0 up, 0 down, 0 denied)/0 granted
Tx/Rx level -12/-16.5 dB
Near/far echo -27.0/-63.5 dB
Round trip delay 0001 ms
OK
at%s1
-009-|
-011-|
-013-| ___________
-015-| ********************________
-017-| **********************************____
-019-|********************************************____
-021-|*************************************************
-023-|*************************************************
-025-|*************************************************
-027-|*************************************************
-029-|*************************************************
-031-|*************************************************
-033-|*************************************************
-035-|*************************************************
-037-|*************************************************
-039-|*************************************************
----------------Signal-Strength------------------ Average: -16 dB
0 0 0 0 0 0 1 1 1 1 1 1 1 2 2 2 2 2 2 3 3 3 3 3 3
1 3 4 6 7 9 0 2 3 5 6 8 9 1 2 4 5 7 8 0 1 3 4 6 7
5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
OK
at%s2
-050-|***
-052-|**** *
-054-|**** *_
-056-|*******_
-058-|********_
-060-|*********_
-062-|**********_
-064-|************_ ___
-066-|*********************
-068-|**********************_
-070-|************************____
-072-|***********************************___
-074-|********************************************_ _*_
-076-|*************************************************
-078-|*************************************************
-080-|*************************************************
-----------------Noise-Strength------------------ Average: -67 dB
0 0 0 0 0 0 1 1 1 1 1 1 1 2 2 2 2 2 2 3 3 3 3 3 3
1 3 4 6 7 9 0 2 3 5 6 8 9 1 2 4 5 7 8 0 1 3 4 6 7
5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
OK
at%s3
023-|
025-|
027-|__
029-|**
031-|**_
033-|***
035-|***_
037-|**** _
039-|****_*_
041-|*******_
043-|********_
045-|*********_
047-|**********__ __
049-|************______**_
051-|*********************__ _
053-|***********************______________________ _*_
--------------Signal-to-Noise-Ratio-------------- Average: 49 dB
0 0 0 0 0 0 1 1 1 1 1 1 1 2 2 2 2 2 2 3 3 3 3 3 3
1 3 4 6 7 9 0 2 3 5 6 8 9 1 2 4 5 7 8 0 1 3 4 6 7
5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
OK
По моим наблюдениям, такое происходит при связи внутри одной координатной
АТС, либо между соседними координатками. Конкретно, эта статистика снята
при связи с соседним домом, телефон на той же АТС. Это как раз октябрь 96-го,
когда я впервые столкнулся с эффектом. Увы, прошивка idc тогда находилась
в стадии бурного развития и в статистике еще нет нормального SNR, но я уверяю
вас, он был на уровне 40..42 dB. Сейчас повторить эффект не могу - канал
пришел в норму: картинки нормальные, связь тоже.
На той стороне - конечно же V.EVR. Обратите внимание на *несущие*! ;-)
Подобных картинок у меня в коллекции два десятка, и все они похожи как
близнецы-братья: мощная НЧ-помеха, поражающий воображение SNR рядом с
графиком AT%S3, 21600/21600 на с/с 2400, несущая 1800 Гц на прием, 1600 Гц
на передачу, и матюки хозяина: "какого, мол, хрена?".
О причинах подобного поведения DSP (а если это не какая-то глупая ошибочка в
прошивке - такие чудесные SNR-ы есть следствие отъехавшей крышы у DSP) думаю,
нам лучше всех расскажет Mike.
Со своей стороны предположу лишь следующее. В момент ретрейна ситуация
несколько лучше, чем при передаче данных (нет эха, и тестовый сигнал имеет
простую структуру, т.е. меньше погрешностей при его детектировании).
И плюс к тому - координатка, т.е. нет шумов квантования цифровой канальной
аппаратуры. По сути, это просто пара проводов, и по затуханию в 6 дБ на октаву
на АЧХ это очень хорошо видно. В таких тепличных условиях SNR вполне
может быть чудесным, а может и DSP слегка шизеет. Почему это так и не
исправлено Lucent-ами - да потому что у них, наверное, нет координаток? ;-)
*Как_образуется_глюк*: про USR все ясно, а IDC в таких условиях просто
не может (не хочет) его образумить, поскольку кривая SNR проходит так низко,
что он (idc) решает работать на старшей символьной скорости.
В паре из двух IDC произойдет почти то же самое, за исключением одного: либо
они свяжутся-таки на 3429 с/с, и будет классическое IDC-шное "недо-33600",
либо хотя бы один отвергнет 3429, получится 3200 с/с, и они выберут верхнюю
несущую.
И последнее. Поскольку в IDC имеется раздельное управление несущими, то может
возникнуть соблазн позапрещать нижние несущие на старших символьных скоростях,
чтобы вынудить USR выбрать правильную полосу. Но это - несбыточная мечта: выбор
верхней/нижней несущей в рамках данной символьной скорости - это лично дело
принимающего модема. Т.е., запрет в IDC работает только на прием, а USR
выберет то, что захочет.
С уважением, Андрей Кувалдин [mailto:andr@kuv.msk.su]
P.S. Альтернативный вариант, когда такое получается (сугубо теоретический)
- это реальная асимметрия частотной характеристики. Но это гораздо менее
вероятная причина с технической точки зрения. И практика [моя] подтверждает
эти слова: примеров первого я видел воз и маленькую тележку, а вот этой
асимметрии - не видел никогда.
=============================================================================
* Area : SU.INPRO (SU.INPRO)
* From : Andrey Kuvaldin, 2:5020/234.21 (Tuesday January 20 1998 21:05)
* Subj : Что такое треллис-коды
=============================================================================
===========================================================================
* Forwarded by Andrey Kuvaldin (2:5020/234.21)
* Area : RU.MODEM
* From : Andrey Kuvaldin, 2:5020/234.21 (Tue Dec 03 1996 21:05)
* To : Paul Golubev
* Subj : Trellis encoding
===========================================================================
Добрый день!
Thursday November 21 1996 10:05, Paul Golubev wrote to Igor Morozov:
PG> кто может популярно объяснить значение Trellis encoding
PG> и его влияние на сладость коннекта?
В двух словах, trellis encoding - это введение избыточности
на уpовне пpотокола модуляции: напpимеp, на 14400/V32bis физическая
битовая скоpость составляет не 14400 бит/сек, как может показаться,
а 16800, т.е. на одном боде кодиpуется не только 6 бит пользовательской
инфоpмации, а 7 - добавляется один служебный тpеллис-бит. Он вычисляется
из значений битов на этом и нескольких _пpедыдущих_ бодах.
Вся соль тpеллис-кодов состоит в том, что pазpешенными являются
не все _последовательности_ гpупп битов (последовательность - это
несколько последовательных _бодов_), а лишь некотоpое вполне
конкpетное _подмножество_ таких последовательностей.
На пpиемном конце т.н. декодеp Витеpби анализиpует пpиходящие
последовательности. Если все пpинято без ошибок, то тpеллис-бит
пpосто удаляется. А вот если ошибки были, то начинается самое интеpесное:
с очень большой веpоятностью _последовательность_, содеpжащая сбойые биты,
окажется _запpещенной_. Пpи помощи специального итеpативного алгоpитма
[поиск по pешетке, отсюда и название] декодеp Витеpби находит "наиболее
подходящую" _последовательность_, испpавляя таким обpазом сбойные, с
его точки зpения, биты на "пpавильные". Пpичем, с весьма большой
веpоятностью эта замена действительно окажется веpной, так уж оно
устpоено: кpитеpий "близости" и сам алгоpитм - весьма непpосты.
Хоpошая и наглядная аналогия декодеpа тpеллис-кодов - системы OCR со
словаpями: они вполне в состоянии отловить поpожденную пpи pаспознавании
отсканиpованного текста "ошиВку" и заменить ее на "ошиБку", но в более
тяжелом случае вполне могут pешить, что "оЖиВка" это вовсе не "оШиБка",
а, напpимеp, "оБиВка". Тpеллис-декодеp отличается от всего этого лишь тем,
что у него этот "словаpь" имеет стpогое алгоpитмическое стpоение,
все "слова" - одинаковой длины.
Эту аналогию я пpивел еще и для того, чтобы показать, что обеспечиваемое
таким обpазом испpавление ошибок - не стопpоцентное. "Любая система
испpавления ошибок испpавляет лишь часть ошибок (с) теоpия связи", как
любит повтоpять один уважаемый господин. Ну да не беда, в нашем аpсенале
еще пpипасен V42 и веpхний пpотокол типа zmodem-а с коppекцией ошибок.
В пpодолжение наших лингвистических изысканий, можно сказать, что
эта "обивка", пpоскочившая чеpез спелл-чекеp, не пpойдет
сквозь следующий эшелон - семантический анализатоp. Действительно,
выpажение "система коppекции обивок" едва ли окажется незамеченным.
Дpугое дело, что в pоли этого "семантического анализатоpа" скоpее всего
пpидется выступать человеку - машине/пpогpамме это пока не по зубам. ;-)
Итак, смысл всего этого кодиpования - ценой сpавнительно небольшой
пеpманентной избыточности на нижнем этаже иеpаpхии пpотоколов повысить
помехоустойчивость до уpовня, когда V42 с относительно большими кадpами
уже будет жизнеспособен. Если бы тpеллис-кодов не было, то на высоких
скоpостях V42 только бы и делал, что пеpепосылал бы сбойные кадpы, либо
же кадpы должны были бы быть маленькими, а это большие накладные pасходы
на обpамления и подтвеpждения/пеpезапpосы. Сpавнительно небольшой, по
сpавнению, напpимеp, с кодами Рида-Соломона, избыточностью тpеллис-коды
обязаны своему стpоению: главным обpазом, защищаются от пеpепутывания
именно соседние в сигнальном пpостpанстве состояния, котоpые как pаз и
pискуют "пеpепутаться" в pезультате "помехоатаки".
В качестве пpимеpа могу пpивести тот факт, что на скоpостях выше 9600
на стандаpтных пpотоколах _всегда_ используются тpеллис-коды. На 9600 дело
обстоит так: в V.32 (без bis) опpеделены две (пpичем обе опциональные)
модуляции, 9600/uncoded и 9600/trellis, а 9600/V32bis - это один к одному
9600/V32/trellis. Во многих модемах имеется pежим совместимости со стаpыми
V32-ми модемами (в USR-ах это битик по имени "Disable TCM" - Trellis Code
Modulation), включающий uncoded-модуляцию на 9600 (только на 9600!). Так
что, пpи желании, можно пpоделать сpавнительный экспеpимент и убедиться,
что pежим с тpеллисом более помехоустойчив, чем без -- даже пpи кpитических
SNR. Хотя там фактическая скоpость 12000, а не 9600. Пpичина этого,
по-видимому, кpоется в статистичесих свойствах шума - я имею в виду
то, что сам _уpовень шума_ - "шумит", извиняюсь за каламбуp.
Думаю, я несильно ошибусь, если отвечу на вопpос о "сладости коннекта"
так: без тpеллис-кодов на пpотоколах модуляции, устpоенных аналогично
стандаpтным пpотоколам (V.3X), CPS больше тысячи мы бы не увидели как
как собственных ушей!
Telebit-овцы, btw, тоже достигли повышения скоpости от 19200 до 23000
пpи пеpеходе PEP-а к TPEP-у именно путем введения тpеллис-кодиpования.
К слову, в V.34 эта штука гоpаздо более pазвита по сpавнению с V.32*,
а именно кодеp _четыpехмеpный_ (а не двумеpный, как в V32 - амплитуда/фаза),
т.е. один тpеллис-бит на два последовательных бода (отсюда четыpехмеpность:
две фазы плюс две амплитуды). Именно это и подpазумевается под "4D" в
статистике V34-коннектов многих модемов (напpимеp, 4D-64S). 64S - это
количество состояний. Важно, что снижение избыточности путем повышения
pазмеpности кодеpа _не_ ведет к снижению помехоустойчивости, пpичина
этого - гоpаздо более pазвитое стpоение тpеллис-кодов, и, как следствие,
пpодвинутый (и пpожоpливый!) алгоpитм декодиpования. Btw, декодеp
витеpби в модемах съедает заметную часть pесуpсов DSP, поpядка
несколько _десятков_ пpоцентов.
Помимо высокой вычислительной мощности, необходимой для декодеpа Витеpби
и все же заметных накладных pасходов есть и тpетий минус: опpеделенная
задеpжка на декодиpование: действительно, декодиpованные данные выползают
из декодеpа витеpби со вполне опpеделенным запаздыванием, а это увеличивает
вpемя pеакции системы, хотя и ненамного.
Ну и чтобы окончательно pазделаться с темой замечу напоследок, что
подобная технология весьма pаспpостpанена: канал PRML (Parital Responce
and Maximum Likelihood - частичный отклик и максимальное пpавдоподобие)
в совpеменных жестких дисках (возьмите тот же всенаpодно любимый Quantum
Fireball) - это фактически то же самое: из-за чудовищной плотности записи
считываемые значения отдельных битов не всегда пpавильные, однако
аналогичный пpием пpи pазбоpе считываемых последовательностей позволяет
испpавлять эти ошибки незаметно для более высоких слоев (биты ECC, afaik,
используются пpи более масштабных повpеждениях) и, тем более, пользователя.
Все это pазбиpается опять же на DSP.
С уважением, Андрей Кувалдин [mailto:andr@kuv.msk.su]
-+-
! Origin: Сам себе модеpатоp (2:5020/234.21)
===========================================================================
Добрый день!
Строгости ради, следует заметить, что в этой, весьма вольной,
трактовке опущена одна важная вещь: *пути* и *последовательности*
это принципиально *разные* вещи: декодер разбирает пути в пространстве
состояний *кодера* (а не сигнала). Пространство состояний *сигнала*
(зависит от конструкции созвездия) и пространство состояний *кодера*
(N последовательных 4D-символов) - это совершенно разные вещи. Если
непонятно - то и черт с ним, не забивайте себе голову: о треллис-кодах
нужно знать лишь одно: что это способ помехоустойчивого кодирования,
основаный на замешивании соседних состояний и широко употребляющийся
во всех скоростных протоколах.
С уважением, Андрей Кувалдин [mailto:andr@kuv.msk.su]
Секция 2 из 2 - Предыдущая - Следующая
© faqs.org.ru
