©2002, INPRO Development Corporation
 
 FAQFAQ   ПоискПоиск   ПользователиПользователи   ГруппыГруппы   РегистрацияРегистрация
 ПрофильПрофиль   Войти и проверить личные сообщенияВойти и проверить личные сообщения   ВходВход

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

 
Начать новую тему   Ответить на тему    Список форумов Форум по модемам IDC -> General
Предыдущая тема :: Следующая тема  
Автор Сообщение
Dmitry Smirnov
Member


Зарегистрирован: 12.02.2003
Сообщения: 21

СообщениеДобавлено: Ср Фев 12, 2003 6:22 am    Заголовок сообщения: Тонкая настройка IDC-5614BXL/VR+ Ответить с цитатой

Тонкая настройка 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
Expert


Зарегистрирован: 31.10.2002
Сообщения: 6330

СообщениеДобавлено: Ср Фев 12, 2003 11:09 am    Заголовок сообщения: Ответить с цитатой

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

Цитата:

Что делает регистр S209?

Этот регистр служит для принудительного выбора режима работы K56Flex (версии K56Flex). По умолчанию, выбирается "старшая" версия K56Flex, которая является общей для серверного и клиентского модема. Регистр использовался для "отката" на предыдущую версию K56Flex и сравнения её работы с более новой. С принятием V.90 всё это потеряло актуальность.

Цитата:

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

Регистр используется для управления модемом в режиме регистрации разговоров. Документация доступна для разработчиков программного обеспечения.

Цитата:

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

Рекомендованное значение этого регистра - 72. И вообще, рекомендованные значения регистров соответствуют их значению по умолчанию. Этот регистр работает при выборе скорости во время начального соединения и ретрейнов. При пересогласованиях скорости значение регистра не учитывается. Он также не влияет на работу механизма fallback/fall-forward. Работает регистр (вопреки Вашему утверждению) плавно, как "масштабный коэффициент" таблицы выбора скорости приёма. Работа алгоритма выбора скорости может "перекрываться" более приоритетными факторами (ограничениями по команде +MS, регистром S120). И поскольку работа идёт за счёт масштабирования таблицы, то эффект от изменения S17 проявляется тогда, когда алгоритм попадает в следующую строчку таблицы (это к вопросу о "шаге 8"). Может потребоваться изменить значение регистра на 8, 12, или 1 - всё зависит от конкретной ситуации. Подбирать нужно экспериментально или консультируясь у нас (по статистике).

Цитата:

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

Нельзя. Алгоритм слишком тонкий и сложный, чтобы его можно было "отдать на откуп" пользователя.

Цитата:

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

Работает так, как описано в документации. У модема есть дополнительные критерии снижения скорости (например, большое количество ошибок при приёме данных) и дополнительные критерии, чтобы не снижать скорость (например, если приём данных продолжается и число ошибок невелико). Использование этих критериев позволяет избежать ненужных пересогласований скорости, особенно на "верхних" скоростях V.34 и в режиме V.90. Соотношение сигнал/шум и EQM не позволяют абсолютно точно рассчитать требуемую скорость, поэтому используются дополнительные критерии.

А теперь по "общим вопросам":

Цитата:

Я не хочу думать об строках инициализации, которые мне нужно прописывать в тех или иных случаях, а скорректировать настройки модема таким образом, чтобы строка инициализации была одна, универсальная, отвечающая потребностям стабильности при соединениях как по v90, так и по v34.

Универсальные настройки - заводские. Они, как правило, подходят для всех ситуаций. Если подстраиваете модем, то под конкретный случай. Например, под Cisco провайдера, которая любит ретрейниться по поводу каждого "чиха" в линии. Отсутствие возможности выставлять индивидуальные настройки под каждое соединение - недостаток операционной системы (который, впрочем, обходят в "звонилках").

Цитата:

Как же помочь модему создавать устойчивые соединения и не увлекаться retrains?

Для начала нужно посмотреть, какой из модемов инициирует перетренировки. Если это делает удалённый модем, то нужно ему "помочь" в выборе скорости: ограничить Вашу скорость передачи (т.е. его скорость приёма). Если это делает Ваш модем, то нужно прежде всего понять, почему (покажите статистику).

Цитата:

Но модем продолжает регулярно получать retrain после повышения скорости, по крайней мере в первые 10 мин. соединения.

Такое возможно в режиме V.90. Модему нужно накопить некоторую статистику соединения прежде, чем он сможет принять решение о прекращении дальнейших попыток повышения скорости. Если ситуация стабильна, то имеет смысл помочь модему, ограничив максимальную скорость соединение по команде +MS.

Команда %En никак не влияет на выбор скорости при начальном соединении и ретрейнах (это была чистая случайность).

Цитата:

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


Ограничение символьной скорости позволяет добиться более устойчивой работы на линиях с "завалом АЧХ по краям". Это происходит потому, что ширина полосы сигнала в Гц равна символьной скорости. Тем не менее, стоит проверить, не связан ли полученный эффект с простым ограничением скорости до 31200. В последнем случае лучше будет попробовать S55.3=1.
_________________
Inpro
Technical Support
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail Посетить сайт автора
Dmitry Smirnov
Member


Зарегистрирован: 12.02.2003
Сообщения: 21

СообщениеДобавлено: Чт Фев 13, 2003 5:31 am    Заголовок сообщения: Thanks Ответить с цитатой

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


Зарегистрирован: 12.02.2003
Сообщения: 21

СообщениеДобавлено: Чт Фев 13, 2003 7:20 am    Заголовок сообщения: Incorrect fallforward? Ответить с цитатой

Тестируя соединения по 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
Expert


Зарегистрирован: 31.10.2002
Сообщения: 6330

СообщениеДобавлено: Чт Фев 13, 2003 11:14 am    Заголовок сообщения: Ответить с цитатой

Цитата:

Тестируя соединения по v90 при S120=1 обнаружилось, что модем может поднимать скорость "до небес", то есть на много шагов от начальной скорости.

Да. Модем будет поднимать скорость, пока это позволяют его настройки (ограничения +MS) и пока ситуация на линии говорит о том, что повышение скорости возможно.

Цитата:

Прилагаю статистику одного соединения, для которого характерны retrains после повышения скорости.

Не совсем понятно, как это сочетается с S120=1 (начальная скорость в этом соединении 37333, что соответствует S120=Cool. В любом случае, перетренировок сразу же после fall-forward было не более 2:

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

Судя по хорошему значению EQM м отсутствию попытки сделать fall-forward:

EQM Last 10 Readings : 15 15 14 14 18 15 14 16 14 17
Last Retrain/Reneg requested : Remote Rate Renegotiation
Minutes Since Last Retrain/Reneg : 1

Ваш модем сообразил, что ему не стоит поднимать скорость выше 36000 (Last rx rate).

Цитата:

Как я уже писал, ограничивать скорость в такой ситуации я не хочу, так как эту картину я наблюдал на разных скоростях

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

Цитата:

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

Поверьте богатому опыту: при работе на аналоговых АТС скорость приходится ограничивать НИЖЕ уровня, выбираемого при начальном соединении (приведённая Вами статистика - ещё одно подтверждение). Если же Вы принудительно "зажимаете" начальную скорость соединения с помощью S120, то в этом случае предлагаемая Вами настройка ничем не отличается от уже имеющейся команды +MS.
_________________
Inpro
Technical Support
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail Посетить сайт автора
Dmitry Smirnov
Member


Зарегистрирован: 12.02.2003
Сообщения: 21

СообщениеДобавлено: Чт Фев 13, 2003 8:06 pm    Заголовок сообщения: Incorrect fallforward? Ответить с цитатой

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

Technical Support писал(а):

Не совсем понятно, как это сочетается с S120=1 (начальная скорость в этом соединении 37333, что соответствует S120=8).

Статистика, что прислал, вовсе не сочетается с S120. :) Однажды, я намеренно установил S120=1, чтобы проверить, насколько высоко модем поднимет скорость. Эта статистика была собрана при S120=0.

Определённо для демонстрации этой проблемы данная статистика не самая показательная. Я наблюдал соединения, при которых число fallforward ровно в 2 или 3 раза больше чиста retrains, при том, что удалённый модем не запрашивал ни retrain, ни изменений скорости. К счастью, похоже, не более трети соединений страдают от такого эффекта.

Technical Support писал(а):

В любом случае, перетренировок сразу же после fall-forward было не более 2:

Действительно, потому что после fall-forward сразу же шёл retrain. Именно об этой проблеме я и говорю.

Technical Support писал(а):

Ваш модем сообразил, что ему не стоит поднимать скорость выше 36000 (Last rx rate).

О, да он сообразил. :) Но сделал это примерно за час - только к 57 минуте соединения. Только один или два последних retrain не походили на все предыдущие. Обратите внимание, что он добрался до 42667, что явно завышено. Ограничение в Один-два fallforward, относительно начальной скорости решили бы проблему. Проблема иногда начинается, к примеру, через 30 минут после соединения. Иногда не начинается вовсе. Иногда начинается сразу, и не проходит по несколько часов.


Technical Support писал(а):

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

Увы, бывает, что и нет. Или процесс слишком долог, а порой он возобновляется через некоторое время.



Technical Support писал(а):

Поверьте богатому опыту: при работе на аналоговых АТС скорость приходится ограничивать НИЖЕ уровня, выбираемого при начальном соединении (приведённая Вами статистика - ещё одно подтверждение). Если же Вы принудительно "зажимаете" начальную скорость соединения с помощью S120, то в этом случае предлагаемая Вами настройка ничем не отличается от уже имеющейся команды +MS.

OK, давайте говорить не об ограничении относительно скорости начального соединения, а ограничении относительно скорости, полученной во время последнего retrain - так лучше. Кроме того есть огромная разница между тем, что я предлагаю, и что есть. Сейчас, возможно единственная адаптивная настройка - это регистр S120. И какой в нем толк, в случае с моей проблемой, если каков бы он ни был, модем пойдёт к 56000 и получит retrain, и притом не один раз? Нужен не потолок скорости, а потолок модемного оптимизма в отношении fallforward, чтобы предотвратить многочисленные попытки перейти на недостижимо высокую скорость. Как видите, автоматика иногда не срабатывает, да и трудно ждать целый час, пока она сообразит.

Кстати, с каким интервалом снимаются показания EQM Last 10 Readings?

Спасибо.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Technical Support
Expert


Зарегистрирован: 31.10.2002
Сообщения: 6330

СообщениеДобавлено: Пт Фев 14, 2003 9:42 am    Заголовок сообщения: Ответить с цитатой

Цитата:

Определённо для демонстрации этой проблемы данная статистика не самая показательная. Я наблюдал соединения, при которых число fallforward ровно в 2 или 3 раза больше чиста retrains, при том, что удалённый модем не запрашивал ни retrain, ни изменений скорости. К счастью, похоже, не более трети соединений страдают от такого эффекта.

2-х или 3-кратное превышение числа fall-forwards над числом retrains - скорее норма. Хуже, когда получаешь одни перетренировки, они отбирают существенно больше времени (и снижают производительность), чем изменения скорости. Ещё раз: в Вашей статистике было всего 2 ситуации, когда перетренировка случилась сразу же после fall-forward (см. счётчик "FB after FF"). Модем скорость ограничил.

Цитата:

Обратите внимание, что он добрался до 42667, что явно завышено

А почему? Ведь перед тем, как он поднялся на 42667, был приём (и успешный, иначе бы модем не пошёл вверх) на 41333.

Цитата:

Сейчас, возможно единственная адаптивная настройка - это регистр S120. И какой в нем толк, в случае с моей проблемой, если каков бы он ни был, модем пойдёт к 56000 и получит retrain, и притом не один раз? Нужен не потолок скорости, а потолок модемного оптимизма в отношении fallforward, чтобы предотвратить многочисленные попытки перейти на недостижимо высокую скорость.

Вы исходите из неверной предпосылки. Модем не делает попыток поднять скорость "на голом месте". Он не будет "слепо идти к 56000". Помимо EQM используются и другие критерии, в том числе и достоверный (без ошибок) приём на текущей скорости. Да, часто бывает так, что качество связи со временем снижается. В таких случаях модему приходится двигать свои ограничения скорости вниз, и часто это сопровождается перетренировками после fall-forward. Работая на V.90 по аналоговой линии, такого эффекта не избежать.

Цитата:

OK, давайте говорить не об ограничении относительно скорости начального соединения, а ограничении относительно скорости, полученной во время последнего retrain - так лучше.

Так не лучше. Есть внутренние алгоритмы, ограничивающие скорость при перетренировках (они, кстати, и устанавливают S120). Какой смысл привязываться к искусственно поставленному барьеру?

Из опыта, на аналоговых линиях перетренировки часто следуют "пачками". Т.е. работаем нормально, потом несколько перетренировок практически одна за другой (длительные всплески шумов), потом опять нормально. При перетренировках подряд модем искусственно "сползает" вниз, пытаясь "нащупать дно". Какая уж тут привязка...

Что можно было бы предложить - некий алгоритм, который бы "задерживал" процесс поднятия скорости, если текущая скорость находится близко к пределу, достигнутому перед последней перетренировкой. Этот алгоритм действительно может помочь.
_________________
Inpro
Technical Support
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail Посетить сайт автора
Dmitry Smirnov
Member


Зарегистрирован: 12.02.2003
Сообщения: 21

СообщениеДобавлено: Пт Фев 14, 2003 6:35 pm    Заголовок сообщения: Ответить с цитатой

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

Ещё раз: в Вашей статистике было всего 2 ситуации, когда перетренировка случилась сразу же после fall-forward (см. счётчик "FB after FF"). Модем скорость ограничил.

Я уже подробно писал, что мониторинг, осуществляемый на слух, показал, что картина двух последних retrain отличается от предыдущих. Два последних retrain произошли после 57 минуты соединения. До этого, retrain происходил немедленно после повышения скорости, более десяти раз. Конечно, мне не сравниться с Вами в искусстве чтения логов, но посмотрите число перетренировок, получившихся в результате неудачно завершенного пересогласования! Да ещё 7 запрошенных retrain. Пусть я прослушал характер ещё двух retrain, но как возможно, чтобы всё было так хорошо, как Вы пишите, когда на деле подъём скорости-retrain по несколько раз? Согласен, иногда, модем перестаёт поднимать скорость (и провоцировать retrain), но иногда нет.


Technical Support писал(а):

А почему? Ведь перед тем, как он поднялся на 42667, был приём (и успешный, иначе бы модем не пошёл вверх) на 41333.

Потому что с этой скорости он тут же возвращался назад. Потому что увеличение до этой скорости было ошибкой, немедленно приводящей к retrain. Уже 41333 было слишком много. Потому что ограничение скорости в 40000 решает проблему, для данного соединения в это время суток. Возможно, проблема в том, что модем слишком быстро переходит к более высокой скорости.

Technical Support писал(а):

Да, часто бывает так, что качество связи со временем снижается. В таких случаях модему приходится двигать свои ограничения скорости вниз, и часто это сопровождается перетренировками после fall-forward. Работая на V.90 по аналоговой линии, такого эффекта не избежать.

Возможно именно это я и наблюдаю. Что с этим можно поделать? Ограничить максимальную скорость? Не лучший вариант. Давайте сделаем с этим что-нибудь, пусть не сейчас, но в следующих firmware.

Technical Support писал(а):

Какой смысл привязываться к искусственно поставленному барьеру?

Например такой: сейчас увеличение скорости может быть сколь угодно большим, но врядли соединившись на 36000 можно ускориться до 56000, а именно это модем _пытается_ сделать. Вы же обычно советуете ограничить скорость для повышения стабильности. Стабильность без ограничения скорости - это хорошо. Так давайте ограничивать ускорение!


Technical Support писал(а):

Что можно было бы предложить - некий алгоритм, который бы "задерживал" процесс поднятия скорости, если текущая скорость находится близко к пределу, достигнутому перед последней перетренировкой. Этот алгоритм действительно может помочь.

Да, конечно. Или механизм, аналогичный S117. Иногда это нужно. Автоматика - это хорошо, но Вы только выиграете от того, что такая настройка появится в Вашем firmware.

P.S. C каким временным интервалом снимаются показания EQM? Какое время покрывает EQM Last 10 Readings?
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Technical Support
Expert


Зарегистрирован: 31.10.2002
Сообщения: 6330

СообщениеДобавлено: Пт Фев 14, 2003 7:44 pm    Заголовок сообщения: Ответить с цитатой

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

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

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

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

Цитата:

Например такой: сейчас увеличение скорости может быть сколь угодно большим, но врядли соединившись на 36000 можно ускориться до 56000, а именно это модем _пытается_ сделать.

А где видны это 56000 ? Модем не пытался подняться выше 42667, что является вполне достижимой скоростью при начальной в 37333.

Давайте расставим точки над 'i':

1. При работе на V.90 во многих случаях невозможно априори узнать, сможет ли модем работать на скорости, которая на шаг превышает текущую. Поэтому приходится действовать методом проб и ошибок. В модеме IDC/VR, в отличии от других, есть механизм анализа истории перетренировок.

2. Можно сделать критерии подъёма скорости более жёсткими. Можно "уменьшить ускорение", выражаясь Вашим языком. В некоторых случаях это приведёт к увеличению производительности. В большинстве случаев - к бессмысленному топтанию на маленькой скорости (хотя можно было бы принимать побыстрее). Выбранные в модеме критерии - "разумный компромисс".

Цитата:
Цитата:

А почему? Ведь перед тем, как он поднялся на 42667, был приём (и успешный, иначе бы модем не пошёл вверх) на 41333.

Потому что с этой скорости он тут же возвращался назад. Потому что увеличение до этой скорости было ошибкой, немедленно приводящей к retrain. Уже 41333 было слишком много. Потому что ограничение скорости в 40000 решает проблему, для данного соединения в это время суток. Возможно, проблема в том, что модем слишком быстро переходит к более высокой скорости.

Можем только повториться: модем успешно принимал на 41333, EQM было хорошим. Это - обязательные условия для fall-forward, который мог случиться не раньше, чем через 20 сек (а на практике, ещё позже) после того, как модем установил скорость 41333. Поэтому у модема были все основания для попытки подъёма скорости.

Цитата:

P.S. C каким временным интервалом снимаются показания EQM? Какое время покрывает EQM Last 10 Readings?

Простите, проглядели вопрос в предыдущем письме. Отсчёты EQM запоминаются каждую секунду. Т.е. Вы видите отсчёты за 10 секунд, предшествующих текущей. Отсчёт "последней секунды" здесь:

Line Quality................. 16
_________________
Inpro
Technical Support
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail Посетить сайт автора
Dmitry Smirnov
Member


Зарегистрирован: 12.02.2003
Сообщения: 21

СообщениеДобавлено: Ср Фев 19, 2003 6:39 am    Заголовок сообщения: Ответить с цитатой

Technical Support писал(а):

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

Это был действительно очень полезный совет, спасибо.

Technical Support писал(а):

Давайте расставим точки над 'i':

1. При работе на V.90 во многих случаях невозможно априори узнать, сможет ли модем работать на скорости, которая на шаг превышает текущую. Поэтому приходится действовать методом проб и ошибок. В модеме IDC/VR, в отличии от других, есть механизм анализа истории перетренировок.

Это многое объясняет, ведь для неспециалиста это не очевидно.

Technical Support писал(а):

2. Можно сделать критерии подъёма скорости более жёсткими. Можно "уменьшить ускорение", выражаясь Вашим языком. В некоторых случаях это приведёт к увеличению производительности. В большинстве случаев - к бессмысленному топтанию на маленькой скорости (хотя можно было бы принимать побыстрее). Выбранные в модеме критерии - "разумный компромисс".

Думаю, Вы правы. Ситуация, когда подъём скорости ведёт к retrain более одного раза, нетипична.

Technical Support писал(а):

Простите, проглядели вопрос в предыдущем письме.

Пустяки, Вы очень внимательны.

Ещё один вопрос, если позволите: Как принимается решение о переходе от v.90 к v.34? Можно ли прокометнировать основные причины Fallback to V34 reason, такие как:
Data Pump decision to FB, EQM also bad
Data Pump decision to Fallback(in Phase 2)
Lowest PCM Speed, Prefer V.34
32k (Flex) or 28k(V90)

Спасибо.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Technical Support
Expert


Зарегистрирован: 31.10.2002
Сообщения: 6330

СообщениеДобавлено: Вс Мар 02, 2003 3:37 pm    Заголовок сообщения: Ответить с цитатой

Цитата:

Ещё один вопрос, если позволите: Как принимается решение о переходе от v.90 к v.34?

При установках "по умолчанию" переход на V.34 происходит при следующих обстоятельствах:

1. Обнаружено двойное преобразование аналог-цифра (dual PCM).

2. Соотношение сигнал/шум (SNR), сигнал/гармоники (SHR) хуже определённой границы.

3. Слишком узкая полоса пропускания.

В перечисленных выше случаях переход выполняется уже на стадии фазы 2 соединения (см. V.34 или V.90 Phase 2). Кроме того, модем может выполнить переход на V.34, если:

4. В результате тренировки выяснилось, что скорость приёма будет слишком низкой (28000 на V.90 или 32000 на K56Flex) или

5. ... что она будет ниже порога, заданного MinRX команды AT+MS

6. Не удалось добиться успешной тренировки на V.90 после двух попыток.

В последних трёх случаях модем будет выполнять две попытки "оттренироваться" на V.90, и переходить на V.34 только если обе попытки провалились.

Что касается возвращаемых кодов, то:

Data Pump decision to FB, EQM also bad

Причина 6.

Data Pump decision to Fallback(in Phase 2)

Одна из причин 1-3.

Lowest PCM Speed, Prefer V.34

Причина 5.

32k (Flex) or 28k(V90)

Причина 4.
_________________
Inpro
Technical Support
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail Посетить сайт автора
Показать сообщения:   
Начать новую тему   Ответить на тему    Список форумов Форум по модемам IDC -> General Часовой пояс: GMT + 3
Страница 1 из 1

 
Перейти:  
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах


Powered by phpBB © 2001, 2005 phpBB Group

Created this page in 0.033354 seconds : 16 queries executed : GZIP compression enabled : Debug Mode

©2002, INPRO Development Corporation

Rambler's Top100