| Предыдущая тема :: Следующая тема |
| Автор |
Сообщение |
Sunspire
Member
Зарегистрирован: 06.11.2002
Сообщения: 51
Откуда: NNOV.RU
|
 Добавлено: Вс Сен 19, 2004 8:46 pm Заголовок сообщения: v. 2.26 Комментарий. |
 |
|
>1. Добавлен алгоритм, позволяющий существенно снизить количество >перетренировок при работе на шумных линиях на протоколе V.90.
Time Online.................. 00:15:19
Termination Reason........... LOCAL REQUEST
Tx Rate (Last/Init/Min/Max).. 19200/19200/19200/19200 bps
Rx Rate (Last/Init/Min/Max).. 41333/38667/37333/41333 bps
Modulation................... V.90
Protocol/Compression......... LAP-M/V.42bis
Line Quality................. 15
Tx/Power Drop/Rx Level....... 15/0/19
SNR Last/Min/Max............. 37/37/43
Highest Rx/Tx State.......... 67/87
EQM Sum...................... 00D1
RBS Pattern.................. 00
Rate Drop.................... 0
Digital Loss................. 2000
Retrains Issued/Granted/Auto. 0/0/3
Renegs Issued/Granted........ 15/0
FForwards/FBacks/FEQM/Denied. 6/9/9/0
Forced FB/FB after FF/MaxREJ. 0/1/3
Last dialed number........... P199282
V90 9481834347EB
Что происходит на линии: несколько револьверно идущих ренегов, последний из которых заканчивается ретрейном. Так несколько раз. Учитывая, что раньше ничего подобного я не видел, это результат действия алгоритма, обозначенного в начале поста.
Специально подобрано время, когда канал нестабилен из-за высокой нагрузки на АТС. |
|
| Вернуться к началу |
|
 |
Technical Support
Expert
Зарегистрирован: 31.10.2002
Сообщения: 6330
|
| Добавлено: Вс Сен 19, 2004 9:07 pm Заголовок сообщения: |
|
|
Имеет смысл сравнивать работу 2.26 с предыдущей версией, либо работу 2.26 при настройках %E3 (это - настройка по умолчанию) и %E2.
То, что Вы описываете - действительно, результат работы нового алгоритма. Со старыми версиями микропрограммы (или при настройке %E2) скорее всего, перетренировка происходила бы сразу же.
Если любая серия пересогласований заканчивается перетренировкой - смысла в новом алгоритме нет, перейдите на %E2. Если же такое происходит не всякий раз (т.е. после серии из 1-2, ну максимум 3-х пересогласований модем успокаивается и продолжает приём, а затем (через некоторое время) делает фолл-форвард и возвращается к прежней скорости приёма) - новый алгоритм помогает и его нужно оставить.
Для большинства линий, на которых мы тестировали 2.26, процент успешного исхода серии пересогласований составлял примерно 3/4 (т.е. 75%).
_________________
Inpro
Technical Support |
|
| Вернуться к началу |
|
|
Sunspire
Member
Зарегистрирован: 06.11.2002
Сообщения: 51
Откуда: NNOV.RU
|
| Добавлено: Пн Сен 20, 2004 10:56 am Заголовок сообщения: |
|
|
| Technical Support писал(а): |
Для большинства линий, на которых мы тестировали 2.26, процент успешного исхода серии пересогласований составлял примерно 3/4 (т.е. 75%). |
Случается по-разному от 0% до 100%. 
Хочу обратить внимание на 2 другие проблемы. Проиллюстрирую их примером:
UserInit: s91=15 s120=9 +ms=12,,,41333,,,19200 m5
----------------------------------------------------------------------
Time Online.................. 00:14:18
Termination Reason........... LOCAL REQUEST
Tx Rate (Last/Init/Min/Max).. 19200/19200/19200/19200 bps
Rx Rate (Last/Init/Min/Max).. 33600/19200/19200/33600 bps
Modulation................... V.34bis
Protocol/Compression......... LAP-M/V.42bis
Line Quality................. 31
Tx/Power Drop/Rx Level....... 15/0/18
SNR Last/Min/Max............. 39/36/39
Highest Rx/Tx State.......... 85/87
EQM Sum...................... 0017
RBS Pattern.................. 00
Rate Drop.................... NA
Digital Loss................. None
Retrains Issued/Granted/Auto. 0/0/0
Renegs Issued/Granted........ 3/0
FForwards/FBacks/FEQM/Denied. 3/0/0/0
Forced FB/FB after FF/MaxREJ. 0/0/0
Last dialed number........... P199282
Flex fail 9481834347EB
1. Во многих случаях затруднительно установить соединение на в.90 с первой попытки. При этом, что самое главное, если удается зацепиться за высокую ступеньку, скажем, за 40000, модем сидит на ней долго и без проблем. Если же удалось согласовать одну млащших скоростей в.90, почти сразу делается фолл-форвард.
Общий сценарий трейна: в.90 (s120) -> в.90 (на пару ступенек ниже s120) -> в.34б (MaxTx).
Наиболее частая ситуация - спуск до 2 пункта.
Что приходится делать: снижать s120 до уровня, за который модем может зацепиться во время трейна.
Поскольку я лично не вижу принципиальной разницы между процедурами первоначального и повторного установления соединения, считаю что данная ситуация есть баг или недоработка.
2. Если модем слез на в.34, ничто его не заставит пойти обратно на в. 90, что иллюстрируется примером.
Ситуации повторяются достаточно часто, чтобы не считать их случайностями. |
|
| Вернуться к началу |
|
|
Technical Support
Expert
Зарегистрирован: 31.10.2002
Сообщения: 6330
|
| Добавлено: Пн Сен 20, 2004 11:35 am Заголовок сообщения: |
|
|
| Цитата: |
Случается по-разному от 0% до 100%
|
В таком случае нужно попытаться оценить, насколько новый алгоритм помогает увеличить производительность модема на Вашей линии. По той статистике, которая есть у нас, алгоритм практически всегда помогает (если хотя бы 1 раз из 6 удаётся обойтись без перетренировки). В противном случае он мешает, но не сильно (т.е. наблюдалось незначительное снижение производительности).
Справедливости ради заметим, что в этом случае модем показал существенно лучшие результаты на V.34 (после запрета V.90). Так что пока можно считать, что новый алгоритм полезен во всех случаях, когда есть смысл работать на V.90.
Теперь по порядку вопросов:
1. Вы не показали статистику целиком, и поэтому не видим причины падения на V.34 (Fallback to V.34 reason). Но в общем случае, нужно просто воспользоваться теми изменениями, которые произошли в версии 2.23 (цитируем по whatsnew.223):
| Код: |
3. Изменен алгоритм работы при соединении и перетренировках в случаях,
когда командой +MS запрещен переход на V.34 (например +MS=12,0,28000)
Раньше модем переходил на V.34 после двух неудачных попыток на V.90
или K56Flex. Теперь модем будет повторять попытки до истечения тайме-
ра S7 или времени на перетренировку (60 сек).
Если одновременно с запретом перехода на V.34 используется S202.5=1,
будут существенно ослаблены требования к SNR и другим факторам, влия-
ющим на автоматический переход DSP в режим V.34. Это фактически озна-
чает запрет на переход в режим V.34 по инициативе DSP.
|
Трогать S120 нет смысла: скорее всего, переход был обусловлен другими причинами.
2. Переход с V.34 на V.90 не предусмотрен рекомендациями ITU-T. Соответственно, он не поддерживается не только Вашим модемом, но и сервером, с которым Вы соединяетесь.
_________________
Inpro
Technical Support |
|
| Вернуться к началу |
|
|
Sunspire
Member
Зарегистрирован: 06.11.2002
Сообщения: 51
Откуда: NNOV.RU
|
| Добавлено: Ср Сен 22, 2004 4:53 pm Заголовок сообщения: |
|
|
| Technical Support писал(а): |
(цитируем по whatsnew.223):
3. Изменен алгоритм работы при соединении и перетренировках в случаях,
когда командой +MS запрещен переход на V.34 (например +MS=12,0,28000)
Раньше модем переходил на V.34 после двух неудачных попыток на V.90
или K56Flex. Теперь модем будет повторять попытки до истечения тайме-
ра S7 или времени на перетренировку (60 сек).
Если одновременно с запретом перехода на V.34 используется S202.5=1,
будут существенно ослаблены требования к SNR и другим факторам, влия-
ющим на автоматический переход DSP в режим V.34. Это фактически озна-
чает запрет на переход в режим V.34 по инициативе DSP.
Трогать S120 нет смысла: скорее всего, переход был обусловлен другими причинами.
|
У меня так не получается  Все равно он на третьей попытке переходит на в34.
DeviceName: IDC 5614BXL VR
UserInit: s91=15 s120=10 s50=21 +ms=12,0,,41333,,,19200 m5
----------------------------------------------------------------------
Connection time : 00:03:51
Handshake Time/Retries : 65 sec/2
TX Rate (Last/Init/Min/Max) : 19200/19200/19200/19200
RX Rate (Last/Init/Min/Max) : 33600/19200/19200/33600
Modulation/Protocol/Compression : V.34/LAPM/V.42bis
TX Symbol rate : 3429
TX/RX carrier frequency, Hz : 1959/1959
Signal Level (TX/Power Drop), -dB : 15/0
RX Signal Level (Last/Min/Max), -dB : 19/19/19
Band Edge Lower/Upper, Hz : 150/3825
Round trip delay, ms : 4.624
EQM Value (Last/Min/Max/Negative) : 33/1/40/0
EQM Samples Running Sum : 0019
EQM Last 10 Readings : 34 37 36 38 33 34 34 34 37 36
SNR Ratio (Last/Min/Max), dB : 41/39/41
TX/RX Non-linear Encoding : ON/ON
TX/RX Precoding : ON/ON
TX/RX Constellation Shaping : ON/ON
TX Trellis Encoding : 16 state
TX Pre-emphasis : 1
TX/RX state (Max TX/RX, Last TX/RX) : 87H/85H, 87H/85H
Error Correction Status : SABME:T UA:R XID:T,R SYNC
Dual PCM/120 Hz detection : No/Yes
Energy at 3750Hz/Average Energy : 2510/1
Retrains (Issued/Granted/Fast) : 0/0/0
Renegs (Issued/Granted) : 3/0
Retrans per frame/Frames rejected : 1/2
Total number of REJ sent/received : 2/0
Last Retrain/Reneg reason : Fall-forward due to low EQM
Last Retrain/Reneg requested : Local Rate Renegotiation
Minutes Since Last Retrain/Reneg : 3
Fallback to V34 reason : Data Pump decision to FB, EQM also bad
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.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
CRe/CRd/CL/MS/ACK/NAK received : Yes/No/Yes/No/Yes/No
V.8bis success/V.8bis neg started : Yes/Yes
ats202.5?
001
OK
И второе. S120 все же замечательно помогает:
DeviceName: IDC 5614BXL VR
UserInit: s91=15 s120=7 s50=21 +ms=12,0,,41333,,,19200 m5
----------------------------------------------------------------------------
Connection time : 00:07:30
Handshake Time/Retries : 33 sec/0
TX Rate (Last/Init/Min/Max) : 19200/19200/19200/19200
RX Rate (Last/Init/Min/Max) : 38667/36000/36000/40000
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 : 5.688
EQM Value (Last/Min/Max/Negative) : 10/4/18/0
EQM Samples Running Sum : 00ED
EQM Last 10 Readings : 10 11 9 8 10 10 11 9 8 10
SNR Ratio (Last/Min/Max), dB : 41/37/41
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) : 87H/67H, 87H/67H
Error Correction Status : SABME:T UA:R XID:T,R SYNC
Dual PCM/120 Hz detection : No/Yes
Energy at 3750Hz/Average Energy : 2509/1
RBS Pattern/Alternating RBS Pattern : 00/00
V.90 Digital Pad/A-law/HighPowerSrv : 0dB/Yes/No
Retrains (Issued/Granted/Fast) : 0/0/3
Renegs (Issued/Granted) : 3/0
Retrans per frame/Frames rejected : 1/8
Total number of REJ sent/received : 8/0
Last Retrain/Reneg reason : Fall-forward due to low EQM
Last Retrain/Reneg requested : Local Fast 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.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
Разница очевидна - в одном случае в.90 и с первого раза. В другом - в.34б с третьего. Да еще почему-то начальная скорость Tx=Rx. |
|
| Вернуться к началу |
|
|
Technical Support
Expert
Зарегистрирован: 31.10.2002
Сообщения: 6330
|
| Добавлено: Ср Сен 22, 2004 5:23 pm Заголовок сообщения: |
|
|
Ошибка в том, что Вы не ограничили скорость снизу. В цитате, которую мы приводили, синтаксис команды +MS такой:
+MS=12,0,28000
Вы же скорость снизу не ограничили:
+ms=12,0,,41333,,,19200
и поэтому произошёл fallback to V.34. Вам нужно заменить эту команду на такую:
+ms=12,0,28000,41333,,,19200
В этом случае модем будет "до упора" пытаться связаться на V.90. Если это не удастся, то последует рассоединение с Termination reason ... INCOMPATIBLE SPEEDS.
Влияние S120 по прежнему под сомнением. Скорее всего, тут речь идёт о совпадении.
Впрочем, при длительных (более 5 минут) сессиях в установке S120=7 нет ничего плохого: 1-2 "лишних" пересогласований скорости погоды не сделают.
_________________
Inpro
Technical Support |
|
| Вернуться к началу |
|
|
Sunspire
Member
Зарегистрирован: 06.11.2002
Сообщения: 51
Откуда: NNOV.RU
|
| Добавлено: Ср Сен 22, 2004 10:37 pm Заголовок сообщения: |
|
|
| Technical Support писал(а): | | Ошибка в том, что Вы не ограничили скорость снизу. |
Посыпаю голову пеплом, был невнимателен. Только тогда остается непонятным смысл параметра <automod>. Если следовать мануалу, он, будучи устатовленным в 0, как раз и должен запрещать трейн любого протокола, кроме прямо указанного...
| Technical Support писал(а): | | Влияние S120 по прежнему под сомнением. Скорее всего, тут речь идёт о совпадении. |
Если совпадение в 100% случаев, это уже факт. Я просто уже давно наблюдаю такую ситуацию: модем не может согласовать некоторую битовую скорость во время начальной процедуры установления соединения, зато потом сразу делает фолл-форвард на нее и преспокойно работает (если конечно, не успел слезть на в.34 - там на 33600). Неужели так по-разному оценивается обстановка на линии во время установления соединения и по его ходу?
Кстати! Не знаю, чего Вы намутили с Call Waiting, раньше даже и не знал о его существовании. А после перехода на 2.26 ТАКОЕ случается уже третий раз:
----------------------------------------------------------------------
Time Online.................. 00:00:04
Termination Reason........... CALL WAITING
Tx Rate (Last/Init/Min/Max).. 19200/19200/19200/19200 bps
Rx Rate (Last/Init/Min/Max).. 33600/33600/33600/33600 bps
Modulation................... V.34bis
Protocol/Compression......... LAP-M/V.42bis
Line Quality................. 30
Tx/Power Drop/Rx Level....... 15/0/15
SNR Last/Min/Max............. 43/41/43
Highest Rx/Tx State.......... 67/67
EQM Sum...................... 0019
RBS Pattern.................. 00
Rate Drop.................... NA
Digital Loss................. None
Retrains Issued/Granted/Auto. 0/0/0
Renegs Issued/Granted........ 0/0
FForwards/FBacks/FEQM/Denied. 0/0/0/0
Forced FB/FB after FF/MaxREJ. 0/0/0
Last dialed number........... P199282
Flex fail 9481834347EB
ats10?
014
OK |
|
| Вернуться к началу |
|
|
Technical Support
Expert
Зарегистрирован: 31.10.2002
Сообщения: 6330
|
| Добавлено: Ср Сен 22, 2004 11:15 pm Заголовок сообщения: |
|
|
| Цитата: |
Посыпаю голову пеплом, был невнимателен. Только тогда остается непонятным смысл параметра <automod>. Если следовать мануалу, он, будучи устатовленным в 0, как раз и должен запрещать трейн любого протокола, кроме прямо указанного...
|
Да, так должно быть, но есть тонкость: во всех Rockwell-модемах этот параметр не работает. А IDC/VR+ должны быть совместимы с Rockwell.
Вот и пришлось несколько извратиться. Если просто прописать automode=0, то параметр не сработает. А вот если совместить это с прописыванием минимальной скорости, то всё отработает так, как нужно.
| Цитата: |
Неужели так по-разному оценивается обстановка на линии во время установления соединения и по его ходу?
|
Скажем так: это - весьма нетипичное поведение. Обычно при выборе слишком большой скорости приёма (например, при слишком низком, для данной линии, значении S17) модем завершает хэндшейк (т.е. динамик модема отключается), затем следует 1-2 пересогласования (в худшем случае - перетренировка) и затем устанавливается соединение (выдаётся сообщение CONNECT, зажигается CD). О нетипичности линии говорит и Call waiting, обнаруженный через несколько секунд после установки соединения.
Кстати, о Call waiting. Скорее всего, Вам удалось обнаружить ошибку в микропрограмме. Будем исправлять.
Дополнение: уже исправлено, скачайте новую версию с ftp-сервера.
_________________
Inpro
Technical Support |
|
| Вернуться к началу |
|
|
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Поиск
Пользователи
Группы
Регистрация
Профиль
Войти и проверить личные сообщения
Вход
