Добрый день!
Я хотел было уже изобразить в subject-е нечто вроде "Почему IDC тормозит
на 33600 или Правда о том, как IDC выбирает параметры треллис-декодера",
но оно не влезло в одну строчку, да и многовато "Правд" для одного раза. ;-)
Hу а если серьезно, то я не до конца уверен в справедливости
нижеизложенного, так что вопрос остается открытым.
Tue Jan 06 1998 08:39, Mike Telis wrote to Stanislav Vinogradov:
MT> According to AT&T datasheet, the DSP would select 16S trellis coder at
MT> 3429 s/s symbol rate. They said that this coder yeilds better results at
MT> this symbol rate. Disable 3429 s/s and youll get 32S and 64S more often.
Я с интересом наблюдал за разгоревшейся дискуссией про тип
треллис-кодов у IDC, потому как уже давно собирал информацию
на этот счет [и кое-кто даже проболтался об этом в RU.MODEM:].
До поры - до времени я не хотел высказываться по этой теме, т.к.
было интересно, кто чего скажет и куда заведет дискуссия на этот раз,
да и времени не было. Hо вроде бы поток иссяк и я со смешанными
чувствами вываливаю то, что получилось/накопилось у меня.
Итак, с тем, что IDC отстает от USR по CPS на предельных скоростях
статистически достоверным образом - вроде бы, никто не спорит.
Там, где USR уже обеспечивает 3800..3900 CPS, IDC выдает 3600 как
счастье, и это общепризнанный факт.
Другими словами, речь идет о том самом соотношение SNR->BER, которое
в последний раз всплывало здесь в контексте "DSP: Rockwell vs Lucent".
С другой стороны, то что на 3429 IDC работает с 16S треллис-декодером
теперь официально признано, и ныне это считается общепринятой причиной
этого отставания (во всяком случае, этот тезис не был опровергнут).
И я думаю, считается совершенно верно - это единственное что отличает USR от
IDC в условиях, когда не надо демонстрировать виртуозное владение алгоритмами
fallback/fallforward. Это, конечно же, *плохое* утверждение - разные DSP и
конструкция/комплектация аналогового тракта могут дать куда более значительный
вклад по сравнению с декодером. Однако, на скоростях 24000...28800 модемы
примерно равны, т.е. как ни крути, а IDC и USR - птички примерно одного полета.
К сожалению, я не знаю модема, в приемнике которого были бы реализованы
все три декодера и в котором можно было бы этим делом управлять вручную.
Был бы у меня такой модем - можно было бы провести серию экспериментов
"при прочих равных", и дать количественное выражение радости от 64S.
Hо я решил провести другой эксперимент: я попытался соотнести CPS-ы на
скорости 31200 бит/сек при 3200 с/с, где как пишет IDC, работает 64S-декодер,
и на 3429 с/с, где 16S. Второй вариант имеет фору по полосе, поэтому сравнение
не совсем строго, но это лучше чем ничего. Как максимум - я ожидал получить
на 31200@3200@64S лучшие, по сравнению с 31200@3429@16S, CPS-ы, как минимум
такие же, что означало бы что фора из-за полосы компенсируется 64S-ом.
Эксперимент окончился ничем: разброс CPS-ов не позволил выявить какой-либо
закономерности.
Hа этом практические вопросы пока отложим, и немного порассуждаем.
Hачнем с того, на чем закончили в прошлый раз: на том, нужен ли вообще 64S.
В тот раз мы остановились на том, что по мнению Inpro, 64S-кодирование too
optimistic в большинстве случаев. Главный аргумент, насколько я помню/понял
был таков: несмотря на то, что вероятность исправления ошибок приема в декодере
Витерби, действительно, растет с ростом длины пути, в реальной жизни есть Noise
Bursts, сбивающие синхронизацию, после которых нужно восстанавливать "плавный
ход", и overhead на это сводит радости от более длинных путей на нет, а то и
делает кпд меньше.
Hисколько не возражая против этого качественно, я возражаю против
количественных оценок: при 16/32/64-S кодировании, элементы
пространства состояний кодера (как раз 16/32/34S) - последовательности
в 4/5/6 четырехмерных символов (т.е. 8/10/12 обыкновенных символов
(тех, что в символьной скорости)). А это - копейки с точки зрения задержек.
И даже с учетом того, что реальная латентность (и память) декодера превосходит
длину последовательности в несколько раз, все равно: *разница* между 16S и 64S
во времени, в течение которого декодер помнит сбой (и которое требуется
на восстановление), грубо говоря, не превосходит 50%.
Да и вообще, мне не очень понятны все эти рассуждения об overhead-е
на восстановление и латентности треллис-декодера, потому что и сбой
синхронизации (гарантировано невосстановимая ошибка), и пропуск битовой
ошибки декодером однозначно приводят к переспросу кадра LAPM (и хорошо
если только одного), а это куда более длительное мероприятие. Это раз.
Два - все-таки, модем бОльшую часть времени занимается передачей данных,
нежели чем тратит на переходные процессы и восстановление после сбоев.
Особенно - на хороших линиях и предельных скоростях 31200 и 33600, о
которых идет речь.
Теперь возвращаемся в практическую плоскость. Потерпев фиаско с "тонким
экспериментом на 31200", я попытался найти закономерность, которой подчиняется
выбор типа треллис-кодов на прием в DSP IDC. Материала куча: (а) мои логи за
год
(б) архивы модемных конференций и (в) some experiments.
Узнав эту закономерность я хотел попытаться сравнить 16S и 64S на 31200.
Конечно же, у меня снова ничего не вышло - научиться добиваться нужного
треллиса мне не удалось. Да и остальные результаты обескураживающие.
Во-первых, невооруженным глазом видно, что BXL+ всегда
пишет в статистику на прием:
16S - на символьных скоростях 2400 и 3429,
32S - на символьных скоростях 2743 и 2800,
64S - на символьных скоростях 3000 и 3200.
Эта, в высшей степени странная, закономерность отыскивается в одно касание,
и я удивлен, что этого еще никто не нашел.
Иногда (редко) эта закономерность нарушается: к примеру, в этой
конференции я видел 32S на 2400 и даже (хмм..) 64S на 3429.
Пожалуй, это следует отнести на счет каких-то "странностей" и забыть.
Согласно гипотезе о согласованности изменения S-овости (чем лучше линия,
тем больше S-ов) - с одной стороны и гипотезе о недостатке быстродействия
DSP с другой эта странная вещь легко объясняется: с улучшением качества
линии (точнее, ширины полосы, что немного странно, было бы логичнее видеть
здесь информационную емкость символа) растет и S-овость треллис-декодера,
а "загиб" на 3429 объясняется недостатком быстродействия DSP. Ведь требования
к "скорострельности" декодера растут пропорционально именно символьной скорости
(треллис-бит всегда один на два соседних сивола, вне зависимости от битовой
скорости). Второй аргумент против повышения длины пути (рост объема памяти,
необходимой для хранения всех путей до принятия решения) здесь не подходит:
этот
объем никак не зависит от символьной скорости.
Однако, эта красивая гипотеза - самая настоящая чушь, и вот почему:
Так уж вышло, что мне *точно* известно, что ни 16S, ни 32S - декодера в
модемах USR *нет*. В о о б щ е. Только не надо меня спрашивать, откуда:
из трех независимых псточников. И то, что в статистике регулярно появлялись
значения на передачу, отличные от 64S, при связи с USR (я видел в статистике
IDC все варианты во все стороны во всех комбинациях), заставило меня
усомниться в правдивости того, что пишет IDC. Усомнившись в верности
значения на передачу, я усомнился и в верности значения на прием. Благо,
проверка - элементарна. (Я сделал ее давным давно и все ждал, когда
же кто-нибудь из [здесь] интересующихся вопросом додумается до этого).
Итак, делаем следующее: звоним на USR, с разными битовыми и символьными
скоростями, агрессивностями и уровнями, пытаясь нащупать закономерность.
И что же мы видим? А видим мы очень простую вещь: при связи с IDC в
статистике USR - *всегда* 64S на прием и *всегда* 16S на передачу. Если
кто-то покажет мне, как USR пишет при связи с IDC что-то иное - я *сильно*
удивлюсь, ибо я потратил на эксперименты не один час времени. Конечно, можно
сказать, что и USR врет, однако он хотя бы верно пишет тип кодирования на
прием,
и верно пишет 64/64 при связи USR-USR. Я было собирался подкрепить
свои слова статистикой ZyXEL, но эти модемы, увы, позволяют снимать DSP-шную
статистику в online only, т.е. в логе оно не остается, а найти желающего
возиться с терминалом и командным режимом мне в обозримые сроки, увы, не
удалось. Если такой желающий в Москве найдется (нужен модем ZyXEL
Omni/Elite/U-336*) пишите, поэкспериментируем и опубликуем здесь отчет.
Пока же я остаюсь при мнении, что IDC ничего отличного от 16S делать
не умеет, уж не знаю по каким причинам: то ли 64S не написали, то ли
действительно не успевает.
С уважением, Андрей Кувалдин [mailto:andr@kuv.msk.su]
PS-2-писатели: все это - мое *imho*, и я убедительно прошу
не повторять за мной что-либо без предварительной проверки.
Если кто-то хочет что-то опpовеpгнуть - pади бога, мне не жалко.
Только, чуp опpовеpжение - в той же весовой категоpии, и совсем
замечательно - если оно будет сопровождаться рекомендациями по
достижению на IDC CPS 3800+ там, где USR показывает такой результат.
P.P.S. Бонус для тех, кто не ничего не понял, но все-таки дочитал досюда: B-)
в следующем письме небольшой популяpный текст о том, что такое тpеллис-коды.
---
* Origin: Сам себе модеpатоp (2:5020/234.21)
|
