Тонкая настройка IDC-5614BXL/VR+

[Dmitry Smirnov]

Тонкая настройка IDC-5614BXL/VR+ (firmware 2.22; 2.23 beta)

Эта история началась с модема USR Courier 3453, который более года использовался перед заменой на IDC5614. В USR Courier мало чем можно повлиять на поведение модема, и многочисленные обрывы связи в самых разных ситуациях переполнили чашу терпения. Для любителей дискуссий "Courier против IDC" добавлю, что у Courier тоже есть свои изюминки, как например, встроенная в firmware документация, что очень и очень удобно.

Замена прошла успешно, и первая неделя активных испытаний выявила, что в сравнении с предшественником, IDC надёжно удерживает линию при соединениях по v90 и v34 при звонках как на модемные пулы MTU в Москве (практически по всем телефонам, а не только по двум-трём; днём Courier3453 не соединялся по большинству телефонов MTU вовсе), так и при звонках на USR Courier(AVC firmware) моего друга, с которым прежде мы могли соединиться не более чем, на 4800 и то ненадёжно. Интересная деталь: раньше, если во время попытки соединиться с интернет посредством Courier 3453, моя мама разговаривала по телефону, последний, услышав её голос, нередко принимал его за DIAL TONE, и деловито приступал к набору номера, разъединяя собеседников. Благодаря специальному датчику в IDC, эта проблема решена, и модем теперь не мешает разговорам.

Однако, IDC с настройками по-умолчанию, во многих случаях не обеспечивает равномерной передачи данных. Прослушивание линии по M4 выявило большое количество retrains, особенно при звонках днём, когда retrains иногда могли следовать один за другим более десяти раз подряд, блокируя передачу информации. Ночью же, когда состояние линий заметно лучше, наблюдались retrains "на ровном месте", как правило запрошенные локальным модемом сразу после Fallforward. Типичное поведение выглядит как повышение скорости, затем ещё одно, и retrain сразу после третьего. После, с некой периодичностью, снова повышение скорости, и снова retrain. Таким образом может набираться 5 и более retrains на десять минут соединения, причём первый retrain следует уже на первой минуте.

Читая форум и FAQ, я не нашёл для себя подходящего совета. Technical Support как правило, рекомендует ограничить максимальную скорость приёма, и передачи, как +MS=12,,,40000,,,28000 например. Также встречался совет по отмене автоматического регулирования уровня выходного сигнала и установке его в некое, определяемое экспериментально, значение. Все эти советы хороши, если Вы звоните по одному и тому же телефону, когда характеристики линии могут быть хорошо изучены. Однако эти характеристики значительным образом меняются в течении суток, что уж говорить о разных телефонах. Так например, чтобы избавится от retrains, запрашиваемых удалённым модемом при соединениях на v90, я ограничил скорость передачи 28800 и это привело к определённому улучшению. Однако модем моего друга на v34 немедленно разорвал связь при первой же попытке пересогласовать скорость на увеличение. Я убеждён, что непосредственная настройка конкретных параметров соединения - это обязанность модема, а не моя. Я не хочу думать об строках инициализации, которые мне нужно прописывать в тех или иных случаях, а скорректировать настройки модема таким образом, чтобы строка инициализации была одна, универсальная, отвечающая потребностям стабильности при соединениях как по v90, так и по v34.

Как же помочь модему создавать устойчивые соединения и не увлекаться retrains? Казалось, очевидное решение - снизить агресивность выбора начальной скорости соединения с помощью S17. На практике это не столь просто. Действительно, при уменьшении значения этого регистра от 72(by default) наблюдается выбор меньших скоростей при соединении, но при значении 76 прекратились соединения на v90, а при значении 80 содинения на v90 возобновились с ожидаемым эффектом. Складывается впечатление, что документация неполна: в ней сказано о назначении регистра, но непонятно почему его действие отвечает описанию лишь при значениях, отличающихся примерно на 8*n от стандартных, то есть если значение регистра изменять с шагом 8. Кто понимает - поясните.

Итак, установив S17=80 - получилось существенное улучшение поведения модема в ситуациях "retrain, retrain ещё retrain". Но модем продолжает регулярно получать retrain после повышения скорости, по крайней мере в первые 10 мин. соединения. Попробовав повлиять на это с помощью %E2 (%E3 by default) обнаружилось, что разница между двумя этими режимами не только та, что описана в документации. Почему интересно, меняется скорость начального соединения? При %E2 она чуть меньше, чем при %E3. В остальном %E2 скромнее при повышениях скорости и иногда, позволяет снизить общее количество retrains, при том, что по документации, %E3 как раз то и должен был снижать их число. На практике иногда получается наоборот. Ещё любопытным кажется тот факт, что для %E2 могут не подходить значения S17, подобранные для %E3.

В теории, было бы замечательно влиять на время, после которого модем будет повышать скорость (по аналогии с S117), или на максимальное число шагов изменения скорости вверх. Увы, в документации ничего подобного не обнаружилось. Тем не менее, можно снизить значение S117 (100 by default) до 40, 60 или 80, помогая модему снижать скорость при ухудшениях в линии, не мешкая и не дожидаясь retrain.

Эти действия хороши для v90, а для v34 есть простой и эффективный способ - S118=250 (251 by default). К примеру, вместо неуверенного connect на 33600 мы получим более стабильный 31200. Это хорошо и для тех случаев, когда модем переходит с v90 на v34, где может продолжаться свистопляска retrains.

Один из интересных способов адаптации модема к соединениям по v90 является регистр S120, значение которого может оказаться слишком низким, для хороших соединений, поэтому можно запретить регистр, или устанавливать его равным 0, особенно при более консервативном выборе скорости по S17.

Ну и конечно, несколько слов о статистике. IDC Diagnostics с сайта http://idcdiag.narod.ru - неплохая программа по замыслу, но не по реализации. Последняя версия 1.0.1.30 у меня не могла установиться, потом найти модем, опрашивая TAPI, порой блокировала Dial-up. Найденная с помощью ftp search версия 1.0.29 работала много лучше. Я даже написал программу для преобразования её логов в .CSV формат, для последующего анализа в Access. Но так как строка инициализации модема не попадает в лог, статистику приводить не стану. Кроме того, подготовка статистики для подобной публикации - дело кропотливое, а времени и так уже затрачено немало.

Настоящий прорыв в анализе поведения модема - это программа ModemSpd - http://temperton.cjb.net с помощью которой можно отслеживать traffic в течении всего сеанса (и после) в графической форме, собирать статистику соединений, создавать по ней отчёты, управлять строками инициализации и т.д. С помощью этой программы можно видеть картину retrains, их периодичность, сопутствующие факторы. Эта программа не имеет себе равных.

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

P.S. Вопросы:
Что делает регистр S209?

Где информация по регистру S55?

Какие параметры для S17 может рекомендовать technical support? Как учитывается значение этого регистра при выборе скорости?

Можно ли управлять инициированием Fallforward?

Как именно работает S117, если ли что-то, что можно добавить к сказанному в документации?

[Technical Support]

Начнём с вопросов:

[Dmitry Smirnov]

Благодарю Вас за внимательный и компетентный ответ. У Вас отличные модемы, их настройки по умолчанию хороши, а поддержка - великолепна.
Все мои заблуждения развеяны. :-)

[Dmitry Smirnov]

Тестируя соединения по v90 при S120=1 обнаружилось, что модем может поднимать скорость "до небес", то есть на много шагов от начальной скорости. Прилагаю статистику одного соединения, для которого характерны retrains после повышения скорости. По звуку это наблюдалось отчётливо, а на графике соединения скорость приёма данных выглядит как "лесенка" из нескольких ступенек вверх (обычно не более трёх) и завал во время retrain. С завидной регулярностью эта ситуация повторялась на протяжении часа, а через пол-часа с момента соединения произошла серия из нескольких повышений скорости и retrains каждую минуту. Как я уже писал, ограничивать скорость в такой ситуации я не хочу, так как эту картину я наблюдал на разных скоростях, а если учесть, что максимальная скорость, достижимая для этого соединения меняется с течением суток, мне понадобятся несколько строк инициализации, в зависимости от времени. Боюсь, "звонилка" тут не поможет, и сам подход к решению этой проблемы мне представляется неверным. Я бы ограничил число возможных fallforward относительно начальной скорости соединения. Именно это, наверное, вполне возможно "отдать на откуп".


Time Online.................. 01:01:04
Termination Reason........... LINK DISCONNECT
Tx Rate (Last/Init/Min/Max).. 28800/26400/26400/28800 bps
Rx Rate (Last/Init/Min/Max).. 36000/37333/36000/42667 bps
Modulation................... V.90
Protocol/Compression......... LAP-M/V.42bis
Line Quality................. 16
Tx/Power Drop/Rx Level....... 15/0/18
SNR Last/Min/Max............. 37/36/37
Highest Rx/Tx State.......... 67/87
EQM Sum...................... 0102
RBS Pattern.................. 00
Rate Drop.................... 0
Digital Loss................. 2000
Retrains Issued/Granted/Auto. 7/0/12
Renegs Issued/Granted........ 33/19
FForwards/FBacks/Denied...... 21/19/0
Forced FB/FB after FF/MaxREJ. 0/2/2
Last dialed number........... PP9955556
V90

Rockwell Diagnostics/W32, version 1.3.0.0, compiled at Jun 13 2002 22:35:06
(c) 2000 Stanislav V. Mekhanoshin (rampitec@tu.spb.ru, 2:5030/172.9@fidonet)
----------------------------------------------------------------------------
Connection time : 01:01:04
Handshake Time/Retries : 24 sec/0
TX Rate (Last/Init/Min/Max) : 28800/26400/26400/28800
RX Rate (Last/Init/Min/Max) : 36000/37333/36000/42667
Modulation/Protocol/Compression : V.90/LAPM/V.42bis
TX Symbol rate : 3200
Signal Level (TX/Power Drop), -dB : 15/0
RX Signal Level (Last/Min/Max), -dB : 18/18/18
Band Edge Lower/Upper, Hz : 150/3825
Round trip delay, ms : 3.813
EQM Value (Last/Min/Max/Negative) : 16/13/127/0
EQM Samples Running Sum : 0102
EQM Last 10 Readings : 15 15 14 14 18 15 14 16 14 17
SNR Ratio (Last/Min/Max), dB : 37/36/37
TX Non-linear Encoding : ON
TX Precoding : ON
TX/RX Constellation Shaping : OFF/OFF
TX Trellis Encoding : 64 state
TX Pre-emphasis : 6
TX/RX state (Max TX/RX, Last TX/RX) : 87H/67H, 87H/67H
Error Correction Status : ODP:T ADP:R SABME:T UA:T,R XID:T,R SYNC
Dual PCM/120 Hz detection : No/Yes
Energy at 3750Hz/Average Energy : 248/125
RBS Pattern/Alternating RBS Pattern : 00/00
V.90 Digital Pad/A-law/HighPowerSrv : 0dB/No/No
Retrains (Issued/Granted/Fast) : 7/0/33
Renegs (Issued/Granted) : 0/19
Retrans per frame/Frames rejected : 1/82
Total number of REJ sent/received : 82/2
Last Retrain/Reneg reason : Remote initiated a reneg
Last Retrain/Reneg requested : Remote Rate Renegotiation
Minutes Since Last Retrain/Reneg : 1
Disconnect reason : LINK DISCONNECT
Remote supports symbol rate (1,2,5) : 2743:ON 2800:OFF 3429:ON 3429-TX:ON
Remote supports symbol rate (3,4) : 3000-L:ON 3000-H:ON 3200-L:ON 3200-H:ON
Remote power drop support : ON
Remote max symbol rate difference : 0 steps
Remote is a CME modem : No
Remote supports V.34bis : Yes
Remote frequency source : Internal
Remote is ITU/K56Flex neg/High IMD : No/No/No
V.8 bis CRe detected/early : No/No
CRe/CRd/CL/MS/ACK/NAK received : No/No/No/No/No/No
V.8bis success/V.8bis neg started : No/Yes


Unimodem Diagnostics/W32, version 1.1.0.1, compiled at Nov 20 2002 22:29:58
(c) 2000 Stanislav V. Mekhanoshin (rampitec@tu.spb.ru, 2:5030/172.9@fidonet)
----------------------------------------------------------------------------
Diag Command Specification rev.: 1.0
Call Setup Result code : Data Answering signal detected
Multi-media mode : Data Only
DTE-DCE interface mode : Async data
TX/RX signal power level, -dBm : 15/18
Estimated noise level, -dBm : 55
TX/RX Negotiation : V.34/V.90 Issue 1 (asymmetric)
TX/RX Symbol Rate : 3200/8000
TX/RX Carrier frequency, Hz : 1829/0
TX data rate (Last/Init) : 28800/26400
RX data rate (Last/Init) : 36000/37333
Temporary carrier loss count : 0
Carrier Rate Re-neg count : 52
Retrains Requested/Granted : 7/0
Protocol/Compression : V.42 LAPM/V.42bis
Error control frame size, bytes: 128
Error control timeouts in TX : 198
Error control NAKs received : 3
Compression dict. size, bytes : 2048
TX/RX flow control : V.24 ckt 106/133 / V.24 ckt 106/133
TX/RX chars sent : 6984994/12438876
TX/RX chars lost (data overrun): 0/0
TX/RX I-Frame count : 52584/102112
TX/RX I-Frame error count : 3/82
Termination Cause : Disconnect Frame Received

[Technical Support]

[Dmitry Smirnov]

Уважаемый Technical Support!
Спасибо за ответ.

[Technical Support]

[Dmitry Smirnov]

Спасибо за ответ. Надеюсь, я ещё не злоупотребил вашим вниманием. :)

[Technical Support]

Мониторинг на слух - вещь хорошая, но не всегда достоверная. Лучше призывать на помощь статистику или (хотя бы) визуальный контроль (S13.7=1, и следить за индикаторами SVD, AA).

"Беспристрастная статистика" свидетельствует об обратном: падений вниз вскоре (в течении 15 секунд после) fall-forward было всего два:

Forced FB/FB after FF/MaxREJ. 0/2/2

Неудачных fall-forward вообще не было (если бы были, то они бы "сосчитались" в FForwards/Denied).

[Dmitry Smirnov]

[Technical Support]