Вопрос по поводу новой фичи 2.24.

[Peter Stoliarov]

Здравствуйте!
Возник вопрос по поводу запрета fallforward'ов при недостаточной загруженности канала на прием. Понятно, что модем в этом случае (если скорость принимаемого потока меньше текущей скорости модема на прием) по собственной воле на будет поднимать скорость, даже если EQM низок. Так вот, если при низком EQM пересогласование запросит УДЛЕННЫЙ модем, то будет ли IDC повышать скорость в свою сторону (насколько я знаю, IDC/VR умеют использовать "чужие" ренеги для своих нужд) ?

[Technical Support]

Да, будет. Запрет действует только на пересогласования, запрашиваемые самостоятельно. Сейчас этот подход кажется наилучшим, поскольку мы пытаемся сократить общее число пересогласований. С другой стороны, после повышения скорости во время пересогласования, запрошенного удалённым модемом, может возникнуть необходимость сделать fallback (и не факт, что это удастся сделать "за счёт удалённого пересогласования").

Но в общем, пока реализовано так. На то и бета-тестирование, чтоб выяснить пользу того или иного решения. Заметите что-нибудь плохое - пишите!
_________________
Inpro
Technical Support

[Peter Stoliarov]

Все понял.
Просто сама идея показалась мне очень полезной (тем более, что мне часто приходится передавать в направлении "от себя").
Попробовать эту возможность в полной мере пока не удалось, но эффект ощутил: подключившись к провайдеру по гостевому входу, "повис" на модемном пуле с нулевым трафиком. Дождался, пока мой модем сделает fallback; после этого загорелся индикатор SVD, и модем не поднимал скорость, пока я не начал открывать страницы. В общем, убедился, что алгоритм работает . Но было бы совсем хорошо, если бы запрет на подъем скорости действовал и при использовании спидшифтов удаленного модема.

[Technical Support]

Ваше "было бы совсем хорошо" пока базируется на умозаключениях, никак не подтверждённых на практике. А между тем практика - критерий истины. У нас есть (пока небольшой) опыт использования новой функции на практике, и мы не отметили каких-либо проблем из-за подъёма скорости во время удалённых пересогласований. Т.е. пока практика не подсказывает необходимость внесения изменений в алгоритм. Если понадобится, изменения будут внесены, это несложно.
_________________
Inpro
Technical Support

[Peter Stoliarov]

Ну что-ж... Будем пробовать дальше Когда удасться реально испытать алгоритм на практике и если при этом возникнут трудности, обязательно сообщу

[Peter Stoliarov]

Сегодня удалось испытать новый алгоритм на практике: закачивал файлы на ftp-сервер. И вот что у меня получилось (привожу статистику):

Inpro IDC 2814/5614 BXL/VR Diagnostics, Version 1.0.1.30
30.08.03 7:03:50 - Manual Diagnostics Request
--------------------------------------------------------
Modem type: IDC-5614BXL/VR+ (Plus) Firmware revision: V2.24

Time Online.................. 00:54:11
Termination Reason........... LOCAL REQUEST
Tx Rate (Last/Init/Min/Max).. 31200/28800/28800/31200 bps
Rx Rate (Last/Init/Min/Max).. 16800/28800/ 9600/28800 bps
Modulation................... V.34bis
Protocol/Compression......... LAP-M/V.42bis
Line Quality................. 127
Tx/Power Drop/Rx Level....... 2/0/39
SNR Last/Min/Max............. 41/39/43
Highest Rx/Tx State.......... 85/87
EQM Sum...................... 0092
RBS Pattern.................. NA
Rate Drop.................... NA
Digital Loss................. None
Retrains Issued/Granted/Auto. 2/0/0
Renegs Issued/Granted........ 5/5
FForwards/FBacks/Denied...... 0/6/0
Forced FB/FB after FF/MaxREJ. 3/0/9
Last dialed number........... P9955556
Flex fail

Symbol Rate.................. 3429
Carrier Frequency Hz, Rx/Tx.. 1959/1959
EQM Value (Last/Min/Max)..... 127/0/127
EQM Hits..................... 0
EQM Last 10 Readings......... 127 16 15 16 14 14 14 16 17 17
Last Retrain/Reneg Status.... Remote Rate Renegotiation
Last Retrain/Reneg Reason.... Remote Rate Renegotiation
Last Retrain/Reneg Time...... 34 minutes ago
Handshake Time/Retries....... 11 seconds/0
Non-linear Encoding, Rx/Tx... OFF/ON
Precoding, Rx/Tx............. ON/OFF
Shaping, Rx/Tx............... ON/OFF
Trellis Encoding, Tx......... 64 state
Pre-Emphasis Index, Tx....... 8
Band Edges Lower/Upper, Hz... 150/3825
Round trip delay, ms......... 3,5
Last Rx/Tx State............. 67/87
Energy at 3750Hz/Average .... 64/8
Detection of 120 Hz Tones.... No
Detection of Dual PCM........ No
V.8 Negotiation Started...... Yes
V.8bis Success............... No
V.8bis CRe,CRd,CL,MS,ACK,NAK. No/No/No/No/No/No
Remote supports Symbol Rates. 2743 3429 3000(L) 3000(H)
Remote supports Symbol Rates. 3200(L) 3200(H) 3429(Tx)
Remote supports Power Drop... Yes
Remote is CME Modem.......... No
Remote supports V.34bis...... Yes
Remote Max SR Difference..... 0 Symbol Rate Steps
Remote Frequency Source...... Internal
Error Correction Status Byte. ADP:R ODP:T
Error Correction Status Byte. SYNC UA:R SAMBE:T XID:T XID:R
Frames REJected, Last/Total.. 1/245
Frames Errors, Rx/Tx......... 245/30 (1,4%/0,0%)
Frames Count, Rx/Tx.......... 17985/78162
Error Control Frame Size..... V.42 LAPM (128)
Error Control Timeouts....... 215
Error Control Link NAKs...... 30
Compression Dictionary Size.. V.42bis (2048)
Characters Received.......... 346371
Characters Sent.............. 9286559
Average CPS, Rx/Tx........... 106/2856
Characters Lost, Rx/Tx....... 0/0
Estimated Noise Level, -dBm.. 80

Что касается "визуальных" наблюдений (M5S13.7=1) могу отметить следующее: сначала модем уверенно снижал скорость (2 ренега и ретрейн), потом модем два раза поднял скорость (перед каждым ренегом горел индикатор SVD). Затем модему пришлось снизить скорость. В последние пол-часа ситуация стабилизировалась, и стал ровно гореть индикатор SVD.

Так что мои опасения подтвердились на практике

P.S. На удаленном конце сервер 3Com (USR Hiper) TotalControl; С циской коннектиться не стал из-за ее любви к ретрейнам

[Technical Support]

Включённый индикатор SVD означает всего лишь, что текущее значение EQM лучше (меньше), чем табличный показатель, необходимый для fall-forward. Образно говоря, этот показатель из разряда "хотеть косточку". Но хотеть косточку и иметь её - разные вещи Судя по тому, что три из пяти запрошенных модемом снижений скорости (fallbacks) были из-за большого процента ошибок при приёме кадров:

Renegs Issued/Granted........ 5/5
Forced FB/FB after FF/MaxREJ. 3/0/9

и процент ошибок на приём довольно высок:

Frames Errors, Rx/Tx......... 245/30 (1,4%/0,0%)

возникают большие сомнения в поставленном Вами диагнозе. Особенно в свете того, что Вашему модему пришлось сделать две перетренировки. Судя по EQM sum, во время последней перетренировки была выбрана скорость 24000, и оттуда модем "падал вниз" на 16800. Поэтому вероятность того, что модем делал fall-forward в ответ на пересогласование скорости от удалённого модема, практически нулевая.
_________________
Inpro
Technical Support

[Peter Stoliarov]

Вообще-то в процесс сеанса была пара случаев, когда после горения индикатора SVD модем поднимал скорость в результате ренега. (SVD после этого гас).

P.S. А не стоит ли распространить запрет на поднятие скорости и в процессе ретрейнов тоже?

[Technical Support]

[Peter Stoliarov]

По поводу USR - я все помню

Но в пользу моего "грубого" предложения могу привести два аргумента:
1. Алгоритм в любом случае не препятствует повышению скорости вообще, ведь этот запрет снимется, когда канал на прием станет необходим и будет загружен. Кстати, AFAIK модемы HTS Express вроде могут вообще в этом случае принудительно снижать скорость, не дожидаясь ухудшения состояния линии или появления большого количества ошибок на прием.
2. Алгоритм можно спокойно отключить (или не включать в отсутствие надобности, - учитывая, что он отключен по умолчанию).

[Technical Support]

1. Максимальный "шаг" при повышении скорости - 3 ступени, поэтому не стоит позволять модему "проваливаться" много ниже оптимальной скорости приёма. Тогда он сможет очень быстро восстановить статус-кво после возобновления приёма с полной загрузкой канала.

Принудительное снижение скорости - не очень хорошая идея, ведь при пересогласованиях останавливается передача данных в обеих направлениях. Зачем же терять на них время?! Пересогласования - неизбежное зло, но зачем же его искусственно вызывать?

Особенно этот тезис касается искусственного снижения скорости передачи (т.е. скорости приёма удалённого модема), поскольку многие модемы не понимают, почему это вдруг ограничение скорости возникло посередине сессии, и безуспешно бьются головой в закрытую дверь, пытаясь сделать fall-forward. Про эту багофичу HTS-Express в своё время немало копий ломали.

2. Хотелось бы получить алгоритм, которым бы пользовались, а не запрещали В идеале, алгоритм должен быть разрешён по умолчанию. Именно поэтому так важно соблюсти баланс и сделать алгоритм действительно полезным всем. Судя по отзывам, это удаётся...
_________________
Inpro
Technical Support

[Peter Stoliarov]

[Technical Support]

Очень радостно услышать эту оценку именно от Вас. Дело в том, что Ваша линия малопригодна для данного алгоритма - уж слишком она "прыгает". Наиболее полно преимущества нового алгоритма заметны на линиях, где качество сигнала меняется в небольших пределах (что соответствует 1-3 шагам по скорости приёма). "Перебирание вверх-вниз" по скоростям приёма, ненужное при отсутствии загрузки приёмного канала, тормозило работу. С появлением нового алгоритма модем быстро стабилизируется.

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

Так что если даже Вы оценили полезность этого алгоритма...
_________________
Inpro
Technical Support

[Dmitry Smirnov]

Начну с того, что по моему мнению, это одно из лучших нововведений.
При работе с интернет, субъективно, ретрейнов действительно меньше. Однако в "специальных условиях" поведение всё ещё не идеально. Мы с другом иногда играем в Starcraft по модему. Наша связь оставляет желать много лучшего, поэтому мы вынуждены ограничивать скорость соединения в пределах 14400, чтобы снизить количество ретрейнов. Во время игры, которая обычно длится около часа, траффик никогда не превышает 600 b/s. (без ограничения, модем при первой же возможности пытался подняться выше 14400, но ретрейн обычно довольно быстро заставлял модем снижать скорость.) Именно поэтому для игры у меня есть специальная строка инициализации. И если после игры я забываю вернуть старую строку, в интернет я попадаю на скорости 14400, что неприятно. Поэтому я сразу подумал, что новая функция окажется полезной в такой ситуации. И вот мы соединились для игры с новой прошивкой 2.24 и активизированной S202.3=1 (скорость не ограничивалась). На протяжении почти получаса наблюдались ретрейны (причём каждый как бы тройной, т.е. очень длинный), а скорость на приём достигала 33600, при изначальном коннекте 16800 (v34), причём МЕНЬНЕ 16800 НЕ ОПУСКАЛАСЬ. Траффик, как обычно, не превышал 600 b/s, что хорошо видно по графику ModemSpd. В такой ситуации, новый алгоритм оказался бесполезен, а значит есть что совершенствовать.
Привожу статистику соединения, характерную для одного из описанных выше соединений.

IDC-5614BXL/VR firmware by Mike Telis, V2.24-V90_2M_DLS
Copyright (c) Inpro, 1998-2003

Time Online.................. 00:24:23
Termination Reason........... RETRAIN FAILURE
Tx Rate (Last/Init/Min/Max).. 14400/14400/ 4800/14400 bps
Rx Rate (Last/Init/Min/Max).. 28800/28800/16800/28800 bps
Modulation................... V.34bis
Protocol/Compression......... LAP-M/V.42bis
Line Quality................. 127
Tx/Power Drop/Rx Level....... 4/0/NA
SNR Last/Min/Max............. 22/19/22
Highest Rx/Tx State.......... 67/87
EQM Sum...................... 0044
RBS Pattern.................. NA
Rate Drop.................... NA
Digital Loss................. None
Retrains Issued/Granted/Auto. 1/3/8
Renegs Issued/Granted........ 6/100
FForwards/FBacks/Denied...... 0/7/0
Forced FB/FB after FF/MaxREJ. 0/1/4


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 : 00:24:23
Handshake Time/Retries : 20 sec/0
TX Rate (Last/Init/Min/Max) : 14400/14400/4800/14400
RX Rate (Last/Init/Min/Max) : 28800/28800/16800/28800
Modulation/Protocol/Compression : V.34/LAPM/V.42bis
TX Symbol rate : 3200
TX/RX carrier frequency, Hz : 1829/1829
Signal Level (TX/Power Drop), -dB : 4/0
RX Signal Level (Last/Min/Max), -dB : NA/36/27
Band Edge Lower/Upper, Hz : 150/3825
Round trip delay, ms : -1.188
EQM Value (Last/Min/Max/Negative) : 127/2/127/0
EQM Samples Running Sum : 0044
EQM Last 10 Readings : 127 127 127 127 127 127 34 33 35 84
SNR Ratio (Last/Min/Max), dB : 22/19/22
TX/RX Non-linear Encoding : ON/ON
TX/RX Precoding : ON/ON
TX/RX Constellation Shaping : ON/ON
TX Trellis Encoding : 64 state
TX Pre-emphasis : 4
TX/RX state (Max TX/RX, Last TX/RX) : 87H/67H, 20H/22H
Error Correction Status : ODP:T ADP:R SABME:T UA:R XID:T,R SYNC
Energy at 3750Hz/Average Energy : 266/14
Retrains (Issued/Granted/Fast) : 1/3/0
Renegs (Issued/Granted) : 6/100
Retrans per frame/Frames rejected : 0/169
Total number of REJ sent/received : 169/61
Last Retrain/Reneg reason : Fall-back due to high EQM
Last Retrain/Reneg requested : Local Rate Renegotiation
Minutes Since Last Retrain/Reneg : 0
Disconnect reason : RETRAIN FAILURE
Remote supports symbol rate (1,2,5) : 2743:ON 2800:ON 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
CRe/CRd/CL/MS/ACK/NAK received : No/No/No/No/No/No
V.8bis success/V.8bis neg started : No/Yes
Workaround used : ABCODE check (machine-gun noise WA)

[Technical Support]