| Предыдущая тема :: Следующая тема |
| Автор |
Сообщение |
Oxy
Member
Зарегистрирован: 03.03.2004
Сообщения: 175
Откуда: Киев
|
 Добавлено: Сб Мар 06, 2004 5:21 am Заголовок сообщения: Влияет ли s17 на порог для лампочек AA и SVD? |
 |
|
Здравствуйте!
Подскажите, пожалуйста, при каких значениях EQM зажигаются (гаснут) упомянутые лампочки? Или это зависит от значения s17? |
|
| Вернуться к началу |
|
 |
Peter Stoliarov
Member
Зарегистрирован: 30.10.2002
Сообщения: 116
Откуда: Россия, Москва
|
| Добавлено: Сб Мар 06, 2004 6:25 am Заголовок сообщения: |
|
|
Индикаторы SVD и AA зажигаются, когда текущее состояние линии позволяет модему "с чистой совестью" поднять скорость, или же модему следует опустить. Если же EQM находится в пределах 30..50, т индикаторы светиться не будут.
От значения S17 показания индикаторов не зависят, т.к. данный регистр влияет на выбор скорости только при ретрейне. |
|
| Вернуться к началу |
|
|
Technical Support
Expert
Зарегистрирован: 31.10.2002
Сообщения: 6330
|
| Добавлено: Сб Мар 06, 2004 8:30 pm Заголовок сообщения: |
|
|
| Цитата: |
Подскажите, пожалуйста, при каких значениях EQM зажигаются (гаснут) упомянутые лампочки? Или это зависит от значения s17?
|
Значения EQM зависят от используемого протокола модуляции и скорости приёма (табличные значения для каждой скорости свои).
Если значение EQM в данную текущую секунду меньше, чем табличное значение для fall-forward, зажигается SVD. Если оно больше, чем табличное значение для fallback - зажигается АА. Если оно "посередине" - оба индикатора будут погашены.
На простом языке это означается, что:
1. Оба индикатора погашены - текущая скорость приёма как раз такая, как надо.
2. Горит АА - текущая скорость выше, чем надо. Модем в скором времени может запросить fallback.
3. Горит SVD - текущая скорость ниже, чем надо. Модем может запросить fall-forward.
Заметьте, что на решения о fall-forward/fallback влияют, кроме EQM, другие факторы (например, процент сбойных кадров данных). И ещё: момент выполнения процедур fall-forward/fallback никак не совпадает с моментом зажигания индикаторов AA/SVD. Например, fallback выполняется по исчерпанию таймера (определяемого S117) и при наличии других необходимых условий (существует меньшая скорость приёма, приём данных идёт на пониженной скорости и с ошибками) и т.д.
Значение регистра S17 никак не влияет на индикаторы.
_________________
Inpro
Technical Support |
|
| Вернуться к началу |
|
|
Oxy
Member
Зарегистрирован: 03.03.2004
Сообщения: 175
Откуда: Киев
|
| Добавлено: Вс Мар 14, 2004 2:56 am Заголовок сообщения: |
|
|
| Technical Support писал(а): | Значения EQM зависят от используемого протокола модуляции и скорости приёма (табличные значения для каждой скорости свои).
Если значение EQM в данную текущую секунду меньше, чем табличное значение для fall-forward, зажигается SVD. Если оно больше, чем табличное значение для fallback - зажигается АА. Если оно "посередине" - оба индикатора будут погашены.
..........................................
Значение регистра S17 никак не влияет на индикаторы.
|
Так выходит, что s17 агрессивностью модема не управляет  Ну хорошо, при рэтрейне выбрали чуть меньшую скорость, а затем модем все равно лезет вверх! Тут же "получает по шапке" и откатывается, и снова лезет! На статистику смотреть жутко:
| Цитата: | Time Online.................. 00:39:52
Termination Reason........... LOCAL REQUEST
Tx Rate (Last/Init/Min/Max).. 28800/28800/19200/31200 bps
Rx Rate (Last/Init/Min/Max).. 49333/49333/28000/56000 bps
Modulation................... V.90
Protocol/Compression......... LAP-M/V.42bis
Line Quality................. 125
Tx/Power Drop/Rx Level....... 15/1/16
SNR Last/Min/Max............. 43/37/43
Highest Rx/Tx State.......... 65/67
EQM Sum...................... 0098
RBS Pattern.................. 00
Rate Drop.................... 0
Digital Loss................. 2000
Retrains Issued/Granted/Auto. 19/6/2
Renegs Issued/Granted........ 28/2
FForwards/FBacks/Denied...... 11/26/0
V90 9481834246E0
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:39:52
Handshake Time/Retries : 27 sec/0
TX Rate (Last/Init/Min/Max) : 28800/28800/19200/31200
RX Rate (Last/Init/Min/Max) : 49333/49333/28000/56000
Modulation/Protocol/Compression : V.90/LAPM/V.42bis
TX Symbol rate : 3200
Signal Level (TX/Power Drop), -dB : 15/1
RX Signal Level (Last/Min/Max), -dB : 15/15/15
Band Edge Lower/Upper, Hz : 150/3825
Round trip delay, ms : 4.750
EQM Value (Last/Min/Max/Negative) : 125/3/127/0
EQM Samples Running Sum : 0098
EQM Last 10 Readings : 125 124 125 127 127 126 127 73 29 25
SNR Ratio (Last/Min/Max), dB : 48/37/60
TX Non-linear Encoding : OFF
TX Precoding : OFF
TX/RX Constellation Shaping : OFF/OFF
TX Trellis Encoding : 16 state
TX Pre-emphasis : 6
TX/RX state (Max TX/RX, Last TX/RX) : 67H/65H, 67H/65H
Error Correction Status : SABME:T UA:R XID:T,R SYNC
Dual PCM/120 Hz detection : No/Yes
Energy at 3750Hz/Average Energy : 953/743
RBS Pattern/Alternating RBS Pattern : 00/00
V.90 Digital Pad/A-law/HighPowerSrv : 0dB/No/No
Retrains (Issued/Granted/Fast) : 19/6/18
Renegs (Issued/Granted) : 10/2
Retrans per frame/Frames rejected : 1/54
Total number of REJ sent/received : 54/13
Last Retrain/Reneg reason : Remote initiated a retrain
Last Retrain/Reneg requested : Remote Retrain
Minutes Since Last Retrain/Reneg : 0
Disconnect reason : LOCAL REQUEST
Remote Manufacturer/Licensee Code : Conexant/Conexant
Remote Manufacturer's Product Caps : K56Flex, V.90
Remote V.8bis caps (type) : Digital (Server)
Remote V.8bis caps (K56Flex mode) : K56Flex prototype mode not supported
Remote V.8bis caps (K56Flex version): 1.1
Remote K56Flex RAM version supported: 70
Remote Coding used/forced by server : A-law/Yes
Remote controller version number : 0
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 : External
Remote is ITU/K56Flex neg/High IMD : Yes/Yes/No
V.8 bis CRe detected/early : Yes/No
CRe/CRd/CL/MS/ACK/NAK received : Yes/No/Yes/No/Yes/No
V.8bis success/V.8bis neg started : Yes/Yes
Workaround used : RateRenegFailure
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 : 16/16
Estimated noise level, -dBm : 59
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/28800
RX data rate (Last/Init) : 49333/49333
Temporary carrier loss count : 0
Carrier Rate Re-neg count : 30
Retrains Requested/Granted : 19/6
Protocol/Compression : V.42 LAPM/V.42bis
Error control frame size, bytes: 128
Error control timeouts in TX : 21
Error control NAKs received : 13
Compression dict. size, bytes : 2048
TX/RX flow control : V.24 ckt 106/133 / V.24 ckt 106/133
TX/RX chars sent : 249570/581171
TX/RX chars lost (data overrun): 0/0
TX/RX I-Frame count : 3661/7945
TX/RX I-Frame error count : 13/54
Termination Cause : cct108 turned Off
Modem Session Analyzer
-------------------------------------------------------------
Session time : 00:39:52
Retrains issued/granted/auto : 19/6/2
Renegs issued/granted/rrws : 10/2/18
TX Rate last/init : 28800/28800
RX Rate last/init : 49333/49333
Error control protocol/frame size : LAP-M/128
Average RX chars per frame : 73
TX frames/errors : 3661/13 (0.35 %)
RX frames/errors : 7945/54 (0.68 %)
Potential upstream cps : 2734
Potential downstream cps : 4667 |
Программе следовало бы отслежвать событие "Fall-back after fall-forward" (если между ними прошло менее Sn секунд (минут)), и делать соответствующие выводы (снижать агрессивность* и увеличивать консенвативность** (определения см. ниже), а в особо тяжелых случаях -- тупо ограничивать скорость). Иными словами, следует предпринять все возможное, чтобы прекратить необоснованную "пляску".
А можно ли как-то повлиять на эти "табличные значения" вручную Т.е. можно ли снизить *агрессивность (сместить диапазон рабочих значений EQM в сторону нуля), и увеличить **консервативность (расширить этот диапазон)?
А можно ли хотябы управлять задержкой fall-forward, а также запретить "перепрыгивать через ступеньки" при fall-forward?
| Technical Support писал(а): | | И ещё: момент выполнения процедур fall-forward/fallback никак не совпадает с моментом зажигания индикаторов AA/SVD |
Это то понятно. А очень жаль. Индикация процесса рэтрейна была бы весьма полезна (например, морганием лампочки HS). Ведь включать динамик не всегда прилично, да и не очень комфортно. |
|
| Вернуться к началу |
|
|
Technical Support
Expert
Зарегистрирован: 31.10.2002
Сообщения: 6330
|
| Добавлено: Вт Мар 16, 2004 10:14 pm Заголовок сообщения: |
|
|
Прежде всего, обновите микропрограмму (там и появится счётчик "fallback after fall-forward"). И всё остальное тоже появится 
S17 используется только при начальной установке соединения и при перетренировках. Воздействует он на EQM Sum (и соответственно, выбор скорости). Дело в том, что по отсчётам EQM нельзя точно вычислить скорость для любой линии. Пользуясь S17, Вы можете подстроить модем так, чтобы при начальном соединении он попадал как можно ближе к оптимальной скорости (иными словами, чтобы после соединения индикаторы AA и SVD не горели в течении первых 4-5 сек).
Дальнейшие действия модема определяются текущей обстановкой на линии, и в этих действиях присутствует вся необходимая логика (учёт fallback after fall-forward, ограничение скорости, как временные, так и "до конца сеанса"). Есть и регистр S120 (посмотрите его описание, а также битов 0,1 и 3 регистра S55).
Кстати, если Вы поглядите в статистику, то выяснится, что было всего 11 fall-forwards за 40 минут соединения. Примерно раз в 4 минуты... много? После обновления микропрограммы должно стать ещё лучше.
_________________
Inpro
Technical Support |
|
| Вернуться к началу |
|
|
Oxy
Member
Зарегистрирован: 03.03.2004
Сообщения: 175
Откуда: Киев
|
| Добавлено: Вс Мар 21, 2004 5:29 am Заголовок сообщения: |
|
|
| Technical Support писал(а): | | Прежде всего, обновите микропрограмму (там и появится счётчик "fallback after fall-forward"). И всё остальное тоже появится |
Интересно, а что ОСТАЛЬНОЕ-то 
| Technical Support писал(а): | | Пользуясь S17, Вы можете подстроить модем так, чтобы при начальном соединении он попадал как можно ближе к оптимальной скорости |
Это то понятно, да только какой в этом смысл? Разве что с RetrainFailure бороться.
| Technical Support писал(а): | | (иными словами, чтобы после соединения индикаторы AA и SVD не горели в течении первых 4-5 сек). |
Ну вот, отдохнем секунд 5, и снова "в разведку"!  По всему диапазону скоростей
Нет, я не спорю, что эта стратегия оправдана для выделенок и прочих длительных коннектов с высокой загрузкой, где скорость играет решающую роль. Хотя оправдана именно "здоровая разведка", но не "пляска", ибо последняя скорости отнюдь не способствует.
Зато это настоящий бич для кратковременных коннектов,  преследующих единственной целью загрузить пару страничек либо проверить почту: разведка занимает больше времени, чем предвидилось провести на линии. Результат: IDC -- не лучший выбор для "интернетчиков".
 Для решения этой дилемы стоит добавить возможность регулировать задержку между коннектом и началом "разведки" (в минутах, что ли)
| Technical Support писал(а): | | Кстати, если Вы поглядите в статистику, то выяснится, что было всего 11 fall-forwards за 40 минут соединения. Примерно раз в 4 минуты... много? |
Видать я выложил не самую ужасную статистику. Вот еще пример:
| Цитата: |
; Скачивался файл с провайдерского FTP (см. график)
at%s%s1#ud
Time Online.................. 00:09:39
Termination Reason........... LINK DISCONNECT ; это нормально.
Tx Rate (Last/Init/Min/Max).. 26400/24000/24000/26400 bps
Rx Rate (Last/Init/Min/Max).. 41333/53333/41333/56000 bps
Modulation................... V.90
Protocol/Compression......... LAP-M/V.42bis
Line Quality................. 7
Tx/Power Drop/Rx Level....... 15/1/16
SNR Last/Min/Max............. 43/43/43
Highest Rx/Tx State.......... 67/87
EQM Sum...................... 0077
RBS Pattern.................. 00
Rate Drop.................... 1
Digital Loss................. 2000
Retrains Issued/Granted/Auto. 4/0/2
Renegs Issued/Granted........ 26/0
FForwards/FBacks/Denied...... 3/23/0
V90 9481834246E0
Rockwell Diagnostics/W32, version 1.3.0.0, compiled at Jun 13 2002 22:35:24
(c) 2000 Stanislav V. Mekhanoshin (rampitec@tu.spb.ru, 2:5030/172.9@fidonet)
----------------------------------------------------------------------------
Connection time : 00:09:39
Handshake Time/Retries : 16 sec/0
TX Rate (Last/Init/Min/Max) : 26400/24000/24000/26400
RX Rate (Last/Init/Min/Max) : 41333/53333/41333/56000
Modulation/Protocol/Compression : V.90/LAPM/V.42bis
TX Symbol rate : 3200
Signal Level (TX/Power Drop), -dB : 15/1
RX Signal Level (Last/Min/Max), -dB : 15/15/15
Band Edge Lower/Upper, Hz : 150/3825
Round trip delay, ms : 6.000
EQM Value (Last/Min/Max/Negative) : 7/4/127/0
EQM Samples Running Sum : 0077
EQM Last 10 Readings : 5 6 5 5 5 5 6 7 7 5
SNR Ratio (Last/Min/Max), dB : 53/49/56
TX Non-linear Encoding : OFF
TX Precoding : OFF
TX/RX Constellation Shaping : OFF/OFF
TX Trellis Encoding : 16 state
TX Pre-emphasis : 6
TX/RX state (Max TX/RX, Last TX/RX) : 87H/67H, 87H/65H
Error Correction Status : SABME:R UA:T XID:T,R SYNC
Dual PCM/120 Hz detection : No/No
Energy at 3750Hz/Average Energy : 3961/3079
RBS Pattern/Alternating RBS Pattern : 00/00
V.90 Digital Pad/A-law/HighPowerSrv : 0dB/No/No
Retrains (Issued/Granted/Fast) : 4/0/13
Renegs (Issued/Granted) : 13/0
Retrans per frame/Frames rejected : 0/66
Total number of REJ sent/received : 255 or more/0
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 : LINK DISCONNECT
Remote Manufacturer/Licensee Code : Conexant/Conexant
Remote Manufacturer's Product Caps : K56Flex, V.90
Remote V.8bis caps (type) : Digital (Server)
Remote V.8bis caps (K56Flex mode) : K56Flex prototype mode not supported
Remote V.8bis caps (K56Flex version): 1.1
Remote K56Flex RAM version supported: 70
Remote Coding used/forced by server : A-law/Yes
Remote controller version number : 0
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 : External
Remote is ITU/K56Flex neg/High IMD : Yes/Yes/No
V.8 bis CRe detected/early : Yes/No
CRe/CRd/CL/MS/ACK/NAK received : No/Yes/No/Yes/No/No
V.8bis success/V.8bis neg started : Yes/Yes
Workaround used : RateRenegFailure
Unimodem Diagnostics/W32, version 1.1.0.1, compiled at Nov 20 2002 22:29:14
(c) 2000 Stanislav V. Mekhanoshin (rampitec@tu.spb.ru, 2:5030/172.9@fidonet)
----------------------------------------------------------------------------
Diag Command Specification rev.: 1.0
Call Setup Result code : V.8bis signal detected
Multi-media mode : Data Only
DTE-DCE interface mode : Async data
TX/RX signal power level, -dBm : 16/16
Estimated noise level, -dBm : 59
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) : 26400/24000
RX data rate (Last/Init) : 41333/53333
Temporary carrier loss count : 0
Carrier Rate Re-neg count : 26
Retrains Requested/Granted : 4/0
Protocol/Compression : V.42 LAPM/V.42bis
Error control frame size, bytes: 128
Error control timeouts in TX : 18
Error control NAKs received : 0
Compression dict. size, bytes : 2048
TX/RX flow control : V.24 ckt 106/133 / V.24 ckt 106/133
TX/RX chars sent : 76559/1684522
TX/RX chars lost (data overrun): 0/0
TX/RX I-Frame count : 3321/15887
TX/RX I-Frame error count : 0/322
Termination Cause : Disconnect Frame Received ; это нормально.
|
 |
|
| Вернуться к началу |
|
|
Technical Support
Expert
Зарегистрирован: 31.10.2002
Сообщения: 6330
|
| Добавлено: Вс Мар 21, 2004 3:30 pm Заголовок сообщения: |
|
|
| Цитата: |
Интересно, а что ОСТАЛЬНОЕ-то
|
Ограничение максимальной скорости после неудачного fall-forward, увеличение задержки последующих fall-forward и т.п. Регистр S120, в конце концов...
| Цитата: |
Это то понятно, да только какой в этом смысл?
|
Смысл в том, чтобы уменьшить количество пересогласований скорости, необходимых для выбора оптимальной скорости.
| Цитата: |
Ну вот, отдохнем секунд 5, и снова "в разведку"!
|
Модем не старается "пробежать" по всему диапазону скоростей. Тут, скорее, речь не о "разведке", а о накоплении "истории", по мере поступления событий. Причём события эти имеют "естественное происхождение" (вызываются реальными событиями на линии).
| Цитата: |
Видать я выложил не самую ужасную статистику. Вот еще пример:
|
Эта статистика мало чем отличается от предыдущей. Да, было 3 fall-forward-а за почти 10 минут. Это - чуть чаще, чем в предыдущем случае, но вполне в пределах допустимого.
Поймите, дело не в "характере модема", а в реальных событиях, которые происходят на линии и которые вызывают такое поведение. Поэтому давайте действовать таким образом:
1. Обновите микропрограмму (установите 2.24).
2. Сбросьте модем к фабричным установкам (at *nc22 w2 \v1 s95=3 &w &w1).
3. Очистите строку инициализации.
4. Соберите статистику.
А дальше будем разбираться, что к чему.
_________________
Inpro
Technical Support |
|
| Вернуться к началу |
|
|
Oxy
Member
Зарегистрирован: 03.03.2004
Сообщения: 175
Откуда: Киев
|
| Добавлено: Пн Мар 22, 2004 3:23 am Заголовок сообщения: |
|
|
| Technical Support писал(а): | | Смысл в том, чтобы уменьшить количество пересогласований скорости, необходимых для выбора оптимальной скорости. |
Да пусть она будет ниже оптимальной на ступеньку или две, только бы не "пляска". Т.е. хотелось бы иметь возможность управлять реальной агрессивностью модема, а не только при рэтрейнах.
| Technical Support писал(а): | | Модем не старается "пробежать" по всему диапазону скоростей. |
Да я не говорю, что "старается", просто констатирую факт:
| Oxy писал(а): |
Из первой статмстики:
Rx Rate (Last/Init/Min/Max).. 49333/49333/28000/56000 bps
|
Можно также заметить, что Last=Init
| Technical Support писал(а): | | Да, было 3 fall-forward-а за почти 10 минут. Это - чуть чаще, чем в предыдущем случае, но вполне в пределах допустимого. |
Но ведь было еще 26 Renegs Issued 
| Technical Support писал(а): | | Поймите, дело не в "характере модема", а в реальных событиях, которые происходят на линии и которые вызывают такое поведение. |
Не согласен. "Поведение" модема диктуется как реальными событиями, так и его "характером". И этот самый "характер" может быть более или менее агрессивным. А эта агрессивность, если я правильно понял, определяется "табличными значениями скоростей" (и другими факторами, подвластными, однако, только программе), и не подлежит управлению со стороны пользователя
| Technical Support писал(а): | Поэтому давайте действовать таким образом:
1. Обновите микропрограмму (установите 2.24). |
А как можно слить с модема старую прошивку (чтобы можно было откатиться, если станет хуже )
| Technical Support писал(а): | 2. Сбросьте модем к фабричным установкам (at *nc22 w2 \v1 s95=3 &w &w1).
|
А что эта недокументированая команда *nc22 "круче", чем &f2 ? |
|
| Вернуться к началу |
|
|
Technical Support
Expert
Зарегистрирован: 31.10.2002
Сообщения: 6330
|
| Добавлено: Пн Мар 22, 2004 12:10 pm Заголовок сообщения: |
|
|
В Ваших статистиках речь не идёт о пляске по скоростям. Скорость постоянно снижалась; после нескольких последовательных снижений происходила перетренировка (что вполне логично). Повышения скорости (fall-forward) были весьма редкими:
FForwards/FBacks/Denied...... 3/23/0
(из 26 изменений скорости только 3 - fall-forward-ы).
И дело тут не в агрессивности модема. Какая уж тут агрессивность, если приходилось понижать скорость? Регулировка есть (S117), да только толку от неё мало будет в Вашем случае... ну подождёт модем дольше, а затем всё равно придётся делать fallback.
Суть в том, чтобы постараться выяснить и устранить причину этих fallbacks, или хотя бы сделать их более редкими. Вот для этого и нужно посмотреть на статистику модема, работающего под управлением одной из последних версий микропрограммы.
| Цитата: |
А как можно слить с модема старую прошивку (чтобы можно было откатиться, если станет хуже)
|
Хуже не станет. На всякий случай, сохраните ответ модема на команду ati3. В случае чего, пришлём старую микропрограмму.
| Цитата: |
А что эта недокументированая команда *nc22 "круче", чем &f2
|
Она ещё очищает телефонные номера (&Zn).
_________________
Inpro
Technical Support |
|
| Вернуться к началу |
|
|
Oxy
Member
Зарегистрирован: 03.03.2004
Сообщения: 175
Откуда: Киев
|
| Добавлено: Пт Мар 26, 2004 12:03 am Заголовок сообщения: |
|
|
Программу обновил. Отличия есть, но отнюдь не кардинальные
Хотя очень порадовал "алгоритм, препятствующий попыткам увеличения скорости приема (fall-forwards), если приемный канал не полностью загружен." Наконец-то довелось полюбоваться длительным свечение SVD на НЕмаксимальной, но в то же время весьма достойной скорости, и отсутствием "пляски" при этом. Очень приятная фича для real-time коннектов. Вот бы еще таймер FForward сюда же (для загруженного канала, естесвенно).
А еще лучше -- все-таки полноценное ручное управление агрессивностью (в том числе и для ForcedFB). Ну что вам стоит ввести парочку недокументированых регистров
Есть и отрицательные моменты обновления программы. Появились ранее не наблюдавшиеся RetrainFailure , чаще даже на стадии HandShake (последние в статистику не попали). Возможно, связано с этим: Проблемы с кодом DSP от Conexant.
Огорчает также сброс s120 по ATZ Дело в том, что NvRam модема я использую не только для защиты вашей программы , но также и по прямому назначению (дабы строка инициализации не простиралась за горизонт) . По-этому модем инициализируется ATZ, а не AT&F.
Кстати, такое поведение s120 противоречит "руководству пользователя", ведь ATZ -- сброс отнюдь не аппаратный
| Цитата: | | Начальное значение этого регистра после включения, аппаратного сброса модема, или выполнения команд AT&F2/AT&F3 равно нулю (ограничение скорости отсутствует). |
Вот статистика (специально выбрал по-страшнее: ведь для цифровой связи это действительно страшно ) На последних минутах скачивался файл (канал был полностью загружен; см. график), и уверенно горел SVD, но FF не последовало.
Кроме того, наблюдалось странное значение s120.
| Цитата: | Connection : UkrTelecom
Time online : 00:12:32
Client IP address : 195.5.8.92
Server IP address : 192.168.18.6
Connection speed : 49333 bps
Bytes received : 1024781 (at 1361 B/sec)
Bytes transmitted : 91841 (at 122 B/sec)
Inactive time : 00:07:10 (efficiency 42.8 %)
Active receive speed : 3178 B/sec
Assumed cont-load recv speed : 2625 B/sec
Frames received : 2243
Frames transmitted : 0
CRC errors : 1
Timeout errors : 0
Alignment errors : 0
Hardware overruns : 1
Buffer overruns : 0
Framing errors : 0
DeviceName: IDC 5614BXL VR PnP
UserInit: atm3s202.7=1s17=58s91=15%e3
----------------------------------------------------------------------
236 ; Значение s120
Time Online.................. 00:12:39
Termination Reason........... LOCAL REQUEST
Tx Rate (Last/Init/Min/Max).. 28800/26400/19200/28800 bps
Rx Rate (Last/Init/Min/Max).. 31200/49333/ 7200/56000 bps
Modulation................... V.34bis
Protocol/Compression......... LAP-M/V.42bis
Line Quality................. 23
Tx/Power Drop/Rx Level....... 15/1/15
SNR Last/Min/Max............. 27/27/43
Highest Rx/Tx State.......... 85/87
EQM Sum...................... 0024
RBS Pattern.................. 00
Rate Drop.................... 0
Digital Loss................. None
Retrains Issued/Granted/Auto. 2/4/3
Renegs Issued/Granted........ 16/2
FForwards/FBacks/Denied...... 8/10/0
Forced FB/FB after FF/MaxREJ. 1/4/7
Last dialed number........... P5640000
Flex fail 9481834246E0
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:12:39
Handshake Time/Retries : 28 sec/0
TX Rate (Last/Init/Min/Max) : 28800/26400/19200/28800
RX Rate (Last/Init/Min/Max) : 31200/49333/7200/56000
Modulation/Protocol/Compression : V.34/LAPM/V.42bis
TX Symbol rate : 3200
TX/RX carrier frequency, Hz : 1920/1829
Signal Level (TX/Power Drop), -dB : 15/1
RX Signal Level (Last/Min/Max), -dB : 14/21/14
Band Edge Lower/Upper, Hz : 150/3825
Round trip delay, ms : 6.000
EQM Value (Last/Min/Max/Negative) : 23/0/127/0
EQM Samples Running Sum : 0024
EQM Last 10 Readings : 26 25 24 23 23 28 24 24 26 25
SNR Ratio (Last/Min/Max), dB : 27/27/53
TX/RX Non-linear Encoding : OFF/ON
TX/RX Precoding : OFF/ON
TX/RX Constellation Shaping : OFF/ON
TX Trellis Encoding : 16 state
TX Pre-emphasis : 6
TX/RX state (Max TX/RX, Last TX/RX) : 87H/85H, 87H/67H
Error Correction Status : SABME:T UA:R XID:T,R SYNC
Dual PCM/120 Hz detection : No/No
Energy at 3750Hz/Average Energy : 2255/1819
Retrains (Issued/Granted/Fast) : 2/4/7
Renegs (Issued/Granted) : 9/2
Retrans per frame/Frames rejected : 1/32
Total number of REJ sent/received : 32/5
Last Retrain/Reneg reason : Remote initiated a reneg
Last Retrain/Reneg requested : Remote Rate Renegotiation
Minutes Since Last Retrain/Reneg : 1
Fallback to V34 reason : Data Pump early decision to FB to V34
Disconnect reason : LOCAL REQUEST
Remote Manufacturer/Licensee Code : Conexant/Conexant
Remote Manufacturer's Product Caps : K56Flex, V.90
Remote V.8bis caps (type) : Digital (Server)
Remote V.8bis caps (K56Flex mode) : K56Flex prototype mode not supported
Remote V.8bis caps (K56Flex version): 1.1
Remote K56Flex RAM version supported: 70
Remote Coding used/forced by server : A-law/Yes
Remote controller version number : 0
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 : External
CRe/CRd/CL/MS/ACK/NAK received : Yes/No/Yes/No/Yes/No
V.8bis success/V.8bis neg started : Yes/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 : 16/15
Estimated noise level, -dBm : 42
TX/RX Negotiation : V.34/V.34
TX/RX Symbol Rate : 3200/3200
TX/RX Carrier frequency, Hz : 1920/1829
TX data rate (Last/Init) : 28800/26400
RX data rate (Last/Init) : 31200/49333
Temporary carrier loss count : 0
Carrier Rate Re-neg count : 18
Retrains Requested/Granted : 2/4
Protocol/Compression : V.42 LAPM/V.42bis
Error control frame size, bytes: 128
Error control timeouts in TX : 7
Error control NAKs received : 5
Compression dict. size, bytes : 2048
TX/RX flow control : V.24 ckt 106/133 / V.24 ckt 106/133
TX/RX chars sent : 92219/1025110
TX/RX chars lost (data overrun): 0/0
TX/RX I-Frame count : 3093/8488
TX/RX I-Frame error count : 5/32
Termination Cause : cct108 turned Off
Modem Session Analyzer
-------------------------------------------------------------
Session time : 00:12:39
Retrains issued/granted/auto : 2/4/3
Renegs issued/granted/rrws : 9/2/7
TX Rate last/init : 28800/26400
RX Rate last/init : 31200/49333
Error control protocol/frame size : LAP-M/128
Average RX chars per frame : 120
TX frames/errors : 3093/5 (0.16 %)
RX frames/errors : 8488/32 (0.38 %)
Potential upstream cps : 2675
Potential downstream cps : 3894
|
Вот еще одна. Хотя в этом случае v90 не свалился, ОЧЕНЬ не нравится график передачи файла (зеленый; передавался в конце сеанса).
| Цитата: | Connection : UkrTelecom
Time online : 00:19:32
Client IP address : 195.5.46.14
Server IP address : 192.168.15.3
Connection speed : 34667 bps
Bytes received : 574258 (at 490 B/sec)
Bytes transmitted : 1399257 (at 1193 B/sec)
Inactive time : 00:09:19 (efficiency 52.3 %)
Active receive speed : 936 B/sec
Assumed cont-load recv speed : 785 B/sec
Frames received : 3922
Frames transmitted : 0
CRC errors : 1
Timeout errors : 0
Alignment errors : 0
Hardware overruns : 1
Buffer overruns : 0
Framing errors : 0
DeviceName: IDC 5614BXL VR PnP
UserInit: atm3s202.7=1s17=58s91=15%e3
----------------------------------------------------------------------
020 ; Значение s120
Time Online.................. 00:19:39
Termination Reason........... LOCAL REQUEST
Tx Rate (Last/Init/Min/Max).. 28800/28800/26400/31200 bps
Rx Rate (Last/Init/Min/Max).. 48000/34667/34667/56000 bps
Modulation................... V.90
Protocol/Compression......... LAP-M/V.42bis
Line Quality................. 34
Tx/Power Drop/Rx Level....... 15/1/16
SNR Last/Min/Max............. 43/43/43
Highest Rx/Tx State.......... 65/87
EQM Sum...................... 0091
RBS Pattern.................. 00
Rate Drop.................... 1
Digital Loss................. 2000
Retrains Issued/Granted/Auto. 5/0/1
Renegs Issued/Granted........ 36/0
FForwards/FBacks/Denied...... 29/12/0
Forced FB/FB after FF/MaxREJ. 1/1/7
Last dialed number........... P5640000
V90 9481834246E0
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:19:39
Handshake Time/Retries : 28 sec/0
TX Rate (Last/Init/Min/Max) : 28800/28800/26400/31200
RX Rate (Last/Init/Min/Max) : 48000/34667/34667/56000
Modulation/Protocol/Compression : V.90/LAPM/V.42bis
TX Symbol rate : 3200
Signal Level (TX/Power Drop), -dB : 15/1
RX Signal Level (Last/Min/Max), -dB : 15/15/15
Band Edge Lower/Upper, Hz : 150/3825
Round trip delay, ms : 5.063
EQM Value (Last/Min/Max/Negative) : 34/1/127/0
EQM Samples Running Sum : 0091
EQM Last 10 Readings : 30 34 32 28 35 30 32 33 30 39
SNR Ratio (Last/Min/Max), dB : 49/49/53
TX Non-linear Encoding : OFF
TX Precoding : OFF
TX/RX Constellation Shaping : OFF/OFF
TX Trellis Encoding : 16 state
TX Pre-emphasis : 6
TX/RX state (Max TX/RX, Last TX/RX) : 87H/65H, 67H/65H
Error Correction Status : SABME:T UA:R XID:T,R SYNC
Dual PCM/120 Hz detection : No/No
Energy at 3750Hz/Average Energy : 2371/1846
RBS Pattern/Alternating RBS Pattern : 00/00
V.90 Digital Pad/A-law/HighPowerSrv : 0dB/Yes/No
Retrains (Issued/Granted/Fast) : 5/0/34
Renegs (Issued/Granted) : 2/0
Retrans per frame/Frames rejected : 1/73
Total number of REJ sent/received : 73/22
Last Retrain/Reneg reason : Fall-back due to high EQM
Last Retrain/Reneg requested : Local Retrain
Minutes Since Last Retrain/Reneg : 1
Disconnect reason : LOCAL REQUEST
Remote Manufacturer/Licensee Code : Conexant/Conexant
Remote Manufacturer's Product Caps : K56Flex, V.90
Remote V.8bis caps (type) : Digital (Server)
Remote V.8bis caps (K56Flex mode) : K56Flex prototype mode not supported
Remote V.8bis caps (K56Flex version): 1.1
Remote K56Flex RAM version supported: 70
Remote Coding used/forced by server : A-law/Yes
Remote controller version number : 0
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 : External
Remote is ITU/K56Flex neg/High IMD : Yes/Yes/No
V.8 bis CRe detected/early : Yes/No
CRe/CRd/CL/MS/ACK/NAK received : Yes/No/Yes/No/Yes/No
V.8bis success/V.8bis neg started : Yes/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 : 16/16
Estimated noise level, -dBm : 59
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/28800
RX data rate (Last/Init) : 48000/34666
Temporary carrier loss count : 0
Carrier Rate Re-neg count : 36
Retrains Requested/Granted : 5/0
Protocol/Compression : V.42 LAPM/V.42bis
Error control frame size, bytes: 128
Error control timeouts in TX : 13
Error control NAKs received : 22
Compression dict. size, bytes : 2048
TX/RX flow control : V.24 ckt 106/133 / V.24 ckt 106/133
TX/RX chars sent : 1399636/574573
TX/RX chars lost (data overrun): 0/0
TX/RX I-Frame count : 13304/8761
TX/RX I-Frame error count : 22/73
Termination Cause : cct108 turned Off
Modem Session Analyzer
-------------------------------------------------------------
Session time : 00:19:39
Retrains issued/granted/auto : 5/0/1
Renegs issued/granted/rrws : 2/0/34
TX Rate last/init : 28800/28800
RX Rate last/init : 48000/34666
Error control protocol/frame size : LAP-M/128
Average RX chars per frame : 65
TX frames/errors : 13304/22 (0.17 %)
RX frames/errors : 8761/73 (0.83 %)
Potential upstream cps : 2833
Potential downstream cps : 4039
|
Особенно неприятны периодично повторяющиеся 20-и секундные паузы, во время которых горит АА.
p.s. Пока писал этот пост, RetrainFailure успели ЗАДОЛБАТЬ: 5 из 7-8 коннектов (половина на стадии HandShake). По-этому, выложил в сеть базу со всеми своими статистиками в формате ModemSpd
Кроме того, появились обрывы на ровном месте со "странным" Termination Reason........... CALL WAITING Я раньше и слов-то таких не слыхивал Итого, из 10 последних Disconnect Reason только в 4 случаях Local Request, и это без учета неудачных HandShake
А пока, вот парочка RetrainFailure:
| Цитата: | Frames received : 320
Frames transmitted : 0
CRC errors : 0
Timeout errors : 0
Alignment errors : 0
Hardware overruns : 0
Buffer overruns : 0
Framing errors : 0
DeviceName: IDC 5614BXL VR PnP
UserInit: atm3s202.7=1s17=58s91=15%e3
----------------------------------------------------------------------
008
Time Online.................. 00:05:56
Termination Reason........... RETRAIN FAILURE
Tx Rate (Last/Init/Min/Max).. 28800/28800/24000/28800 bps
Rx Rate (Last/Init/Min/Max).. 38667/44000/29333/44000 bps
Modulation................... V.90
Protocol/Compression......... LAP-M/V.42bis
Line Quality................. 127
Tx/Power Drop/Rx Level....... 15/1/NA
SNR Last/Min/Max............. 43/43/43
Highest Rx/Tx State.......... 46/67
EQM Sum...................... 0098
RBS Pattern.................. 00
Rate Drop.................... 0
Digital Loss................. 2000
Retrains Issued/Granted/Auto. 3/1/2
Renegs Issued/Granted........ 9/0
FForwards/FBacks/Denied...... 2/10/1
Forced FB/FB after FF/MaxREJ. 0/0/2
Last dialed number........... P5640000
V90 9481834347EB
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:05:56
Handshake Time/Retries : 23 sec/0
TX Rate (Last/Init/Min/Max) : 28800/28800/24000/28800
RX Rate (Last/Init/Min/Max) : 38667/44000/29333/44000
Modulation/Protocol/Compression : V.90/LAPM/V.42bis
TX Symbol rate : 3200
Signal Level (TX/Power Drop), -dB : 15/1
RX Signal Level (Last/Min/Max), -dB : NA/15/15
Band Edge Lower/Upper, Hz : 150/3825
Round trip delay, ms : 5.688
EQM Value (Last/Min/Max/Negative) : 127/5/127/0
EQM Samples Running Sum : 0098
EQM Last 10 Readings : 127 127 127 127 127 127 127 127 36 47
SNR Ratio (Last/Min/Max), dB : 46/46/46
TX Non-linear Encoding : ON
TX Precoding : ON
TX/RX Constellation Shaping : ON/OFF
TX Trellis Encoding : 16 state
TX Pre-emphasis : 1
TX/RX state (Max TX/RX, Last TX/RX) : 67H/46H, 20H/21H
Error Correction Status : SABME:T UA:R XID:T,R SYNC
Dual PCM/120 Hz detection : No/No
Energy at 3750Hz/Average Energy : 2253/1994
RBS Pattern/Alternating RBS Pattern : 00/00
V.90 Digital Pad/A-law/HighPowerSrv : 0dB/Yes/No
Retrains (Issued/Granted/Fast) : 3/1/4
Renegs (Issued/Granted) : 5/0
Retrans per frame/Frames rejected : 3/4
Total number of REJ sent/received : 4/0
Last Retrain/Reneg reason : Fall-back due to high EQM
Last Retrain/Reneg requested : Local Retrain
Minutes Since Last Retrain/Reneg : 0
Disconnect reason : RETRAIN FAILURE
Remote Manufacturer/Licensee Code : Conexant/Conexant
Remote Manufacturer's Product Caps : K56Flex, V.90
Remote V.8bis caps (type) : Digital (Server)
Remote V.8bis caps (K56Flex mode) : K56Flex prototype mode not supported
Remote V.8bis caps (K56Flex version): 1.0, 1.1
Remote K56Flex RAM version supported: 71
Remote Coding used/forced by server : A-law/Yes
Remote controller version number : 11
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 : ITU-reserved
Remote is ITU/K56Flex neg/High IMD : Yes/Yes/No
V.8 bis CRe detected/early : Yes/No
CRe/CRd/CL/MS/ACK/NAK received : Yes/No/Yes/No/Yes/No
V.8bis success/V.8bis neg started : Yes/Yes
Workaround used : V90Phase2Escape
Workaround used : V34_Stuck_Phase2
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 : 16/47
Estimated noise level, -dBm : 95
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/28800
RX data rate (Last/Init) : 38666/44000
Temporary carrier loss count : 0
Carrier Rate Re-neg count : 9
Retrains Requested/Granted : 3/1
Protocol/Compression : V.42 LAPM/V.42bis
Error control frame size, bytes: 128
Error control timeouts in TX : 11
Error control NAKs received : 0
Compression dict. size, bytes : 2048
TX/RX flow control : V.24 ckt 106/133 / V.24 ckt 106/133
TX/RX chars sent : 64365/87596
TX/RX chars lost (data overrun): 0/0
TX/RX I-Frame count : 558/733
TX/RX I-Frame error count : 0/4
Termination Cause : Retrain Failed |
| Цитата: | Frames received : 69
Frames transmitted : 0
CRC errors : 0
Timeout errors : 0
Alignment errors : 0
Hardware overruns : 0
Buffer overruns : 0
Framing errors : 0
DeviceName: IDC 5614BXL VR PnP
UserInit: atm3s202.7=1s17=58s91=15%e3
----------------------------------------------------------------------
008
Time Online.................. 00:01:17
Termination Reason........... RETRAIN FAILURE
Tx Rate (Last/Init/Min/Max).. 26400/24000/24000/28800 bps
Rx Rate (Last/Init/Min/Max).. 38667/40000/37333/40000 bps
Modulation................... V.90
Protocol/Compression......... LAP-M/V.42bis
Line Quality................. 115
Tx/Power Drop/Rx Level....... 15/1/19
SNR Last/Min/Max............. 43/43/43
Highest Rx/Tx State.......... 67/67
EQM Sum...................... 0103
RBS Pattern.................. 00
Rate Drop.................... 1
Digital Loss................. 2000
Retrains Issued/Granted/Auto. 3/0/0
Renegs Issued/Granted........ 1/0
FForwards/FBacks/Denied...... 1/3/0
Forced FB/FB after FF/MaxREJ. 0/1/1
Last dialed number........... P5640000
V90 9481834246E0
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:01:17
Handshake Time/Retries : 28 sec/0
TX Rate (Last/Init/Min/Max) : 26400/24000/24000/28800
RX Rate (Last/Init/Min/Max) : 38667/40000/37333/40000
Modulation/Protocol/Compression : V.90/LAPM/V.42bis
TX Symbol rate : 3200
Signal Level (TX/Power Drop), -dB : 15/1
RX Signal Level (Last/Min/Max), -dB : 19/19/15
Band Edge Lower/Upper, Hz : 150/3825
Round trip delay, ms : 4.750
EQM Value (Last/Min/Max/Negative) : 115/4/127/0
EQM Samples Running Sum : 0103
EQM Last 10 Readings : 126 125 68 126 126 9 11 5 19 10
SNR Ratio (Last/Min/Max), dB : 49/49/51
TX Non-linear Encoding : OFF
TX Precoding : OFF
TX/RX Constellation Shaping : OFF/OFF
TX Trellis Encoding : 16 state
TX Pre-emphasis : 6
TX/RX state (Max TX/RX, Last TX/RX) : 67H/67H, 20H/67H
Error Correction Status : SABME:T UA:R XID:T,R SYNC
Dual PCM/120 Hz detection : No/No
Energy at 3750Hz/Average Energy : 2340/1825
RBS Pattern/Alternating RBS Pattern : 00/00
V.90 Digital Pad/A-law/HighPowerSrv : 0dB/Yes/No
Retrains (Issued/Granted/Fast) : 3/0/1
Renegs (Issued/Granted) : 0/0
Retrans per frame/Frames rejected : 4/2
Total number of REJ sent/received : 2/1
Last Retrain/Reneg reason : Fall-back due to high EQM
Last Retrain/Reneg requested : Local Retrain
Minutes Since Last Retrain/Reneg : 1
Disconnect reason : RETRAIN FAILURE
Remote Manufacturer/Licensee Code : Conexant/Conexant
Remote Manufacturer's Product Caps : K56Flex, V.90
Remote V.8bis caps (type) : Digital (Server)
Remote V.8bis caps (K56Flex mode) : K56Flex prototype mode not supported
Remote V.8bis caps (K56Flex version): 1.1
Remote K56Flex RAM version supported: 70
Remote Coding used/forced by server : A-law/Yes
Remote controller version number : 0
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 : External
Remote is ITU/K56Flex neg/High IMD : Yes/Yes/No
V.8 bis CRe detected/early : Yes/No
CRe/CRd/CL/MS/ACK/NAK received : Yes/No/Yes/No/Yes/No
V.8bis success/V.8bis neg started : Yes/Yes
Workaround used : V90Phase2Escape
Workaround used : V34_Stuck_Phase2
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 : 16/19
Estimated noise level, -dBm : 62
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) : 26400/24000
RX data rate (Last/Init) : 38666/40000
Temporary carrier loss count : 0
Carrier Rate Re-neg count : 1
Retrains Requested/Granted : 3/0
Protocol/Compression : V.42 LAPM/V.42bis
Error control frame size, bytes: 128
Error control timeouts in TX : 0
Error control NAKs received : 1
Compression dict. size, bytes : 2048
TX/RX flow control : V.24 ckt 106/133 / V.24 ckt 106/133
TX/RX chars sent : 6442/9217
TX/RX chars lost (data overrun): 0/0
TX/RX I-Frame count : 155/184
TX/RX I-Frame error count : 1/2
Termination Cause : Retrain Failed
|
Последний раз редактировалось: Oxy (Пт Апр 02, 2004 2:41 am), всего редактировалось 2 раз(а) |
|
| Вернуться к началу |
|
|
Technical Support
Expert
Зарегистрирован: 31.10.2002
Сообщения: 6330
|
| Добавлено: Пт Мар 26, 2004 9:06 am Заголовок сообщения: |
|
|
Сервер ftp.pisem.net лежит, не удалось скачать Вашу статистику:
| Код: |
C:\>tracert oxana3000.pisem.net
Tracing route to ftp.pisem.net [80.68.244.33]
over a maximum of 30 hops:
1 101 ms 96 ms 99 ms as5350.cea.ru [212.92.96.193]
2 99 ms 100 ms 98 ms gate-as5350.cea.ru [212.92.96.142]
3 101 ms 96 ms 99 ms host-1.217-12-240.rr.net21.ru [217.12.240.1]
4 96 ms 98 ms 94 ms m9-as5350.cea.ru [212.92.96.137]
5 100 ms 97 ms 100 ms cyprus-giga0-1.corbina.net [193.232.244.63]
6 98 ms 98 ms 99 ms crete-giga0-1-1.msk.corbina.net [195.14.50.119]
7 98 ms 103 ms 98 ms Corbina2-lgw.Moscow.gldn.net [194.186.0.81]
8 98 ms 92 ms 95 ms cisco13.Moscow.gldn.net [194.186.157.238]
9 99 ms 103 ms 98 ms MTU1-m9-gw.mtu.ru [193.232.244.30]
10 100 ms 99 ms 97 ms M9-FeX.core.mtu.ru [195.34.53.26]
11 99 ms 99 ms 97 ms Rbk-m9-MTUInform-GW.mtu.ru [195.34.36.14]
12 * * * Request timed out.
|
Ну да ладно, многое можно сказать уже сейчас.
Прежде всего, CALL WAITING. Вы поставили регистр S10 в значение, большее 15 (почитайте описание регистра в "Руководстве"). Отсюда и проблема.
Это, кстати, относится к вопросу о добавлении недокументированных регистров. Если уж не удаётся разобраться с вполне простым и документированным регистром, можно только представить себе ситуацию с недокументированными, особенно когда речь идёт о столь сложном механизме, как алгоритм fall-forward.
| Цитата: |
Огорчает также сброс s120 по ATZ
|
И опять Вы не разобрались. Регистр не сбрасывается по ATZ, как и сказано в документации. Вот простой эксперимент:
ats120=15
OK
atz
OK
ats120?
015
OK
| Цитата: |
На последних минутах скачивался файл (канал был полностью загружен; см. график), и уверенно горел SVD, но FF не последовало.
|
Ничего удивительного. Скорость приёма была 31200 бит/с, что является максимумом при символьной скорости в 3200 симв/с. Модему некуда было поднимать скорость.
В общем, предложение такое:
1. Верните модем к заводским установкам командой (выполнить один раз из терминальной программы):
at *nc22 w2 \v1 s95=3 &w &w1
2. Уберите все настройки из строки инициализации модема и замените их на команду M4. Эта команда заставит модем включать динамик во время перетренировок/пересогласований скорости.
3. Прослушивая динамик, постарайтесь понять, что приводит к перетренировкам и обрывам. Судя по статистикам, у Вас наблюдаются периодические мощные помехи. Кстати, возможно эти помехи исходят от "местного источника" (например, включённого параллельно телефона с АОН).
_________________
Inpro
Technical Support |
|
| Вернуться к началу |
|
|
Oxy
Member
Зарегистрирован: 03.03.2004
Сообщения: 175
Откуда: Киев
|
| Добавлено: Сб Мар 27, 2004 4:15 am Заголовок сообщения: |
|
|
| Technical Support писал(а): | | Сервер ftp.pisem.net лежит, не удалось скачать Вашу статистику |
Положил еще сюда (даже чуть более полную).
| Technical Support писал(а): | | Прежде всего, CALL WAITING. Вы поставили регистр S10 в значение, большее 15 (почитайте описание регистра в "Руководстве"). Отсюда и проблема. |
Большое спасибо за четкий ответ. Снова выручили. Вряд-ли бы я сам с этим разобрался (хотя на самом деле и знаю, что это за сигнал ), ибо s10 был изменен совершенно случайно! Имелось в виду s120=20, а вышло s10=20, т.е. просто опечатка.
| Technical Support писал(а): | | Это, кстати, относится к вопросу о добавлении недокументированных регистров. Если уж не удаётся разобраться с вполне простым и документированным регистром, можно только представить себе ситуацию с недокументированными, особенно когда речь идёт о столь сложном механизме, как алгоритм fall-forward. |
Ну зачем же так строго. Не помирать же ламером, в конце концов К тому же,на семь бед -- один Reset!
Ведь управление агрессивностью в выборе символьной уже сейчас полноценное: здесь просто отсутствуют "обходные пути" в виде FB/FF.
| Technical Support писал(а): | | Цитата: |
Огорчает также сброс s120 по ATZ |
И опять Вы не разобрались. Регистр не сбрасывается по ATZ, как и сказано в документации |
Действительно, уже не сбрасывается Чудеса! Выходит, таки не разобрался 
| Technical Support писал(а): | | Цитата: | | На последних минутах скачивался файл (канал был полностью загружен; см. график), и уверенно горел SVD, но FF не последовало. |
Ничего удивительного. Скорость приёма была 31200 бит/с, что является максимумом при символьной скорости в 3200 симв/с. Модему некуда было поднимать скорость. |
А почему бы не поднять символьную И вообще, откуда взялись эти 3200 Может это "дурное наследие" свалившегося v90? |
|
| Вернуться к началу |
|
|
Technical Support
Expert
Зарегистрирован: 31.10.2002
Сообщения: 6330
|
| Добавлено: Сб Мар 27, 2004 7:07 pm Заголовок сообщения: |
|
|
| Цитата: |
Ну зачем же так строго. Не помирать же ламером, в конце концов К тому же,на семь бед -- один Reset!
|
Тут дело даже не в профессиональной подготовке пользователей. Дело в том, что даже мы (при всём, без ложной скромности, профессионализме) не представляем, каким образом можно было бы настраивать предлагаемую Вами агрессивность.
Настраиваемые таблицы fall-forward и fall-back применяли в профессиональных модемах, ориентированных на работу по выделенным каналам связи. На ум приходят модемы Penril, например. Но выделенный канал - особая песня. Там примерно постоянное качество связи, и есть возможность путём множества проб и ошибок настроить пороги для 2-3 скоростей, на которых, в основном, происходит обмен данными по этому каналу. К тому же эти настройки применялись исключительно при модуляции V.34, где EQM (или SNR) вполне можно использовать в качестве критерия.
При использовании модуляции PCM полагаться только на EQM нельзя, слишком уж грубый это показатель. EQM хорош для начального выбора скорости соединения, как критерий при рассчёте "прыжка" (на сколько ступеней изменить скорость при пересогласовании), да и только. Точная подгонка скорости осуществляется по другим критериям (например, по проценту ошибочно принимаемых кадров данных).
Регулировать fall-forward тайм-аут также не представляется разумным. На этот тайм-аут "завязаны" другие критерии. Например, если сделать его слишком маленьким ("высокая агрессивность"), то не будет работать вычисление процента ошибок (слишком мало кадров будет передано за период). Если сделать слишком большим, то любая случайная помеха будет "сбивать процесс".
Всё-таки хотелось бы вернуться к разбору Вашей ситуации. Вы попробовали выполнить пп. 1-3 нашего предложения?
| Цитата: |
А почему бы не поднять символьную И вообще, откуда взялись эти 3200
|
Судя по статистике, 3200 было запрошено удалённым модемом (символьные скорости приёма и передачи должны совпадать). И с большой вероятностью можно предположить, что это - наследие V.90 (там символьная скорость передачи, т.е. запрашиваемая сервером провайдера, всегда 3200).
_________________
Inpro
Technical Support |
|
| Вернуться к началу |
|
|
Oxy
Member
Зарегистрирован: 03.03.2004
Сообщения: 175
Откуда: Киев
|
| Добавлено: Чт Апр 01, 2004 9:00 am Заголовок сообщения: |
|
|
| Technical Support писал(а): | Регулировать fall-forward тайм-аут также не представляется разумным. На этот тайм-аут "завязаны" другие критерии. Например, если сделать его слишком маленьким ("высокая агрессивность"), то не будет работать вычисление процента ошибок (слишком мало кадров будет передано за период). Если сделать слишком большим, то любая случайная помеха будет "сбивать процесс".
|
Сокращать интервал действительно не стоит. А вот возможность увеличивать его (причем значительно: до нескольких минут) была бы весьма полезна. Что касается "любой случайной помехи", то лучше пусть она собьет "процесс", а не модем в рэтрейн (после очередного FForward).
| Technical Support писал(а): | | Дело в том, что даже мы (при всём, без ложной скромности, профессионализме) не представляем, каким образом можно было бы настраивать предлагаемую Вами агрессивность. |
Самый простой способ: для табличных значений FF-FB-reason ввести множитель (где-то в пределах 0.8--1.2). Правда, это не повлияет на "консервативность" модема (ширину допустимого диапазона EQM).
На мой взгляд, в идеале следовало бы увеличивать консервативность одновременно с понижением агрессивности (придумать более сложную формулу для "множителя"). Иными словами, понижая агрессивность, следует смещать рабочий диапазон EQM в сторону 0 и несколько расширять его, что должно резко сократить число пересогласований.
Кроме того (и это, на сколько я понимаю, гараздо проще реализовать), хотелось бы управлять агрессивностью Forced FB
с несколько большей точностью, чем ВКЛ/ВЫКЛ .
Хотелось бы обратить внимание на поведение модема еще в одной ситуации. Если при загруженом канале ухудьшился EQM, модем не будет мнять скорость, если передача данных идет успешно. Но как только канал освободится, будет запрошен FallBack, после чего скорость может уже не подняться. А зачем нужен этот FallBack? На мой взгляд, правильнее было бы запомнить значение EQM, при котором передача данных еще возможна, а пересогласование при простое делать только при дальнейшем его ухудьшении, либо только в случае Retrain Reasone.
Кстати, коль уж зашел разговор о пересогласованиях при простое, хочется сказать пару слов о хваленом алгоритме запрета FF. Прежде всего, следует похвалить его за то, что он есть, и поругать за все остальное . Вещь действительно великолепная! Вот только выключается (или падает?) уже при кратковременной загрзке 20-30%, тагда как следовало бы не менее, чем на 80% непрерывной загрузки втечение нескольких секунд, или даже десятков секунд. Ну и, единажды свалившись, не может очухаться несколько минут, а иногда и до конца сеанса.
Бывает и обратный эффект (правда не знаю, связано ли это с упомянутым алгоритмом): ни чем не обоснованное ограничение скорости загруженного канала при уверенном свечении SVD на V90 (статистика от 31.03, если скачаете (обновил на pisem.net); там также содержится график загрузки).
На последок (точнее, прежде, чем плавно перейти к моей ситуации ), парочка вопросов в тему:
1. Влияет ли s17 на выбор скорости при RRWS
2. Виден ли по индикаторам ForcedFB Reason
3. (в дополнение к п.2 ) Включается ли динамик (M4) при Remote Rate Renegotiation?
Теперь о моей ситуации.
Сразу же раскаиваюсь в невыполнении п.1 Ваших указаний, а также в недостаточной педантичности касательно п.2 (ограничился установкой M4). Зато п.3 выполняется особо тчательно
Строка инициализации видна с статистиках. Кроме того, в NvRam разрешен алгоритм запрета FF при простое. Также разрешен MNP10 (соответствующей галочкой).
Итак, типичная картина: после установки соединения модем методично и весьма успешно карабкается вверх, практикуя почти исключительно RRWS, затем сваливается в retrain, auto retrain после неудачного FB (RRWS) или в тяжелый (auto) retrain с тонами ожидания, который не всегда завершается успешно. Иногда встречается "вертолет", практически гарантирующий retrain failure
Тяжесть ситуации зависит от наличия помех, но описанное поведение для модема характерно всегда.
Помехи в динамике модема не слышны, но иногда слышны при обычном разговоре, и напоминают шипение угольного микрофона, либо искрение контактов. Могут также полностью отсутствовать. Параллельных телефонов нет. Зато есть скрутки линии.
И еще об особеностях моей линии. Скорость 33600 на ней практически недостижима (соединение на 33600 -- не редкость, но откат следует незамедлительно). Типичные скорости (при отсутствии помех) для V34 это 28--31, а иногда 24--26. Для v90 характерны 52--53.
И на последок, поясню, почему я так ратую за снижение агрессивности. Дело в том, что раньше на этой линии стоял модем GVC Vector. Помех в те времена видать еще не было. Конект на v34 (c теми же удаленными) происходил в 90% случаев на 26400, в остальных -- на 24000. Это меньше, чем у IDC, и меньше, чем позволяет линия тому же GVC. Скорость успешно поднимлась вручную до 28800, после чего оставалась неизменной втечение многих часов! Т.е. на добрый десяток многочасовых коннектов приходилось 1--2 пересоглосования скорости! Это на дефолтных скоростях. От "навязанной" же 28800 GVC стремился избавиться, посему схлопотал %E0. И с этой настройкой -- ни одного retrain failure за полгода! Как тут ни уверeешь в святость своей линии?
Правда, с тех пор прошло полтора года... |
|
| Вернуться к началу |
|
|
Technical Support
Expert
Зарегистрирован: 31.10.2002
Сообщения: 6330
|
| Добавлено: Пт Апр 02, 2004 9:00 am Заголовок сообщения: |
|
|
| Цитата: |
Итак, типичная картина: после установки соединения модем методично и весьма успешно карабкается вверх, практикуя почти исключительно RRWS, затем сваливается в retrain, auto retrain после неудачного FB (RRWS) или в тяжелый (auto) retrain с тонами ожидания, который не всегда завершается успешно. Иногда встречается "вертолет", практически гарантирующий retrain failure
Тяжесть ситуации зависит от наличия помех, но описанное поведение для модема характерно всегда.
Помехи в динамике модема не слышны, но иногда слышны при обычном разговоре, и напоминают шипение угольного микрофона, либо искрение контактов. Могут также полностью отсутствовать. Параллельных телефонов нет. Зато есть скрутки линии.
|
Ситуация примерно такая, как и предполагали. Время от времени на Вашей линии возникают помехи, настолько мощные, что они "пробивают" на любой из допустимых скоростей V.90 (и возможно, на большинстве диапазона скоростей V.34 тоже).
Это делает бессмысленными все попытки избавиться от перетренировок (поскольку, как не уменьшай скорость, всё равно помеха "достанет"). Идея о том, что "не будь fall-forward-ов, не будет и перетренировок) также непродуктивна. Отсутствие fall-forward-а просто заставит модем работать на меньшей (чем он мог бы) скорости.
В Вашей ситуации есть только один выход (предполагаем, что избавиться от помех не удастся): принимать на максимально возможной скорости в моменты "затишья" (паузы между помехами). Затем делаем перетренировку, и опять принимаем на максимальной скорости. Образно говоря: двигаемся короткими перебежками. Нет обстрела (помех) - вскакиваем и бежим со всех ног. Стреляют - залегли (делаем перетренировку), затем опять бежим. Продолжая аналогию: если во время затишья будем бежать медленнее, то это лишь увеличит "время в пути". На обстрел и необходимость в связи с этим "залегать" скорость не влияет...
Соответствующие установки: %E1 S55.0=1 S55.1=1. Оптимальную скорость приёма нужно подобрать экспериментально, регулируя S17 и, возможно, ограничив её сверху с помощью +MS. Все остальные премудрости вроде MNP-10 нужно убрать, они либо ни на что не влияют, либо только усугубляют ситуацию (кстати, статистику опять не удалось посмотреть: сервер, на котором Вы её разместили, "лежит")
Естественно, всё это не спасёт от "Retrain Failure". Если помехи длятся очень долго, они сбивают процесс перетренировки, и один из модемов в отчаяньи отключается (скорее всего, чаще это делает удалённый модем, Вы слышите короткие гудки на фоне писка Вашего модема). Тут уж, как говорится, ничего не поделаешь...
Ну а теперь постараемся удовлетворить Ваше любопытство
| Цитата: |
Хотелось бы обратить внимание на поведение модема еще в одной ситуации. Если при загруженом канале ухудьшился EQM, модем не будет мнять скорость, если передача данных идет успешно. Но как только канал освободится, будет запрошен FallBack, после чего скорость может уже не подняться. А зачем нужен этот FallBack?
|
Когда приём данных завершился (возник "перерыв"), мы теряем один из наиболее важных критериев оценки соответствия скорости приёма качеству линии - процент сбойных кадров данных при приёме. В такой ситуации снижение скорости представляется логичным (тем более, что это можно сделать без потерь в производительности - ведь модем всё равно простаивает, обмена данными нет). Что касается "может уже не подняться", отвечаем: не может не подняться! Если для этого есть условия, скорость обязательно поднимется. Другое дело, что при этом подъёме возникнет некоторая потеря времени (на пересогласование). Однако, практические эксперименты показали, что такой подход вполне оправдан. А что касается идеи с "запоминанием EQM", то и такая идея пробовалась. Выяснилось, что подобрать порог так, чтобы это работало надёжно, невозможно. Даже во время "нормальной" работы EQM прыгает в пределах 5-8 единиц:
EQM Last 10 Readings : 26 25 24 23 23 28 24 24 26 25
Здесь среднее - 24.8 (округлим до 25). И какой порог выставлять? Выставишь на 1-2 больше среднего - будет fallback через несколько секунд, во время маленькой флуктуации на линии. Выставишь больше на 4-5 единиц - проворонится момент, когда действительно очень нужно сделать fallback, и будет перетренировка по запросу протокола коррекции ошибок (а может, и ещё хуже, разрыв связи по инициативе удалённого, с диагнозом "retransmission limit").
| Цитата: |
Кроме того (и это, на сколько я понимаю, гараздо проще реализовать), хотелось бы управлять агрессивностью Forced FB
|
При существующих в модемах IDC/VR+ алгоритмах управления скоростью в этом нет никакой необходимости. Алгоритм сравнивает реальную производительность на текущей скорости с расчётной на скорости на ступень ниже (т.е. "есть ли смысл снижать скорость"). Полный запрет перехода по такой причине необходим при импульсных помехах, которые разрушают кадры данных при любой скорости (т.е. снижение приводит только к потере производительности). Агрессивность алгоритма - только усложнение настроек.
| Цитата: |
Кстати, коль уж зашел разговор о пересогласованиях при простое, хочется сказать пару слов о хваленом алгоритме запрета FF. Прежде всего, следует похвалить его за то, что он есть, и поругать за все остальное. Вещь действительно великолепная! Вот только выключается (или падает?) уже при кратковременной загрзке 20-30%, тагда как следовало бы не менее, чем на 80% непрерывной загрузки втечение нескольких секунд, или даже десятков секунд.
|
Кажется, Вы просто не поняли работу алгоритма. S202.3=1 никоим образом не влияет на снижение скорости (fallback). Это - запрет fall-forward в случаях, когда "приёмный тракт" не полностью загружен. Модем будет снижать скорость всякий раз, когда в этом возникнет необходимость (точно так же, как и при сброшенном бите, S202.3=0). Однако, попыток повысить скорость не будет до тех пор, пока приём не заработает в полную силу (не исчезнут паузы между принимаемыми кадрами данных).
| Цитата: |
Бывает и обратный эффект (правда не знаю, связано ли это с упомянутым алгоритмом): ни чем не обоснованное ограничение скорости загруженного канала при уверенном свечении SVD на V90
|
Если приём идёт в полную силу, то это не связано с S202.3=1. Причина может быть в ограничении скорости из-за того, что перетренировка произошла сразу же после fall-forward (если речь идёт о V.90). Запрет такого ограничения - S55.0=1. Другая причина (для V.34) - модем уже работает на максимальной скорости приёма (31200 при символьной 3200, например).
| Цитата: |
1. Влияет ли s17 на выбор скорости при RRWS
2. Виден ли по индикаторам ForcedFB Reason
3. (в дополнение к п.2) Включается ли динамик (M4) при Remote Rate Renegotiation?
|
По порядку:
1. Нет. RRWS выполняется либо на текущей скорости (если модем не удовлетворён качеством приёма, в надежде улучшить ситуацию после подстройки эхоподавителя и эквалайзера), либо в сторону повышения скорости (все fall-forward на V.90 производятся путём RRWS).
2. Нет.
3. Да. Динамик включается при любой перетренировке и пересогласовании скорости, независимо от того, какой из модемов её инициировал.
_________________
Inpro
Technical Support |
|
| Вернуться к началу |
|
|
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Поиск
Пользователи
Группы
Регистрация
Профиль
Войти и проверить личные сообщения
Вход
