| Предыдущая тема :: Следующая тема |
| Автор |
Сообщение |
Dmitry Smirnov
Member
Зарегистрирован: 12.02.2003
Сообщения: 21
|
 Добавлено: Сб Сен 13, 2003 6:03 am Заголовок сообщения: Разъяснения |
 |
|
| Technical Support писал(а): |
| Цитата: |
Начну с того, что по моему мнению, это одно из лучших нововведений.
|
Почему Вы так считаете?
|
Потому что ретрейн весьма ощутим пользователем, и неприятен даже в отсутствии траффика. Здравый смысл подсказывает, что меры по стабилизации связи важны и необходимы. Зачем гнать автомобиль во всю мочь, если не торопиться? Траффик может быть небольшим, но очень важным, например запросы к серверам имён DNS. Почему очевидные вещи нужно объяснять?
| Technical Support писал(а): |
В этой ситуации трудно говорить о полезности алгоритма.
|
Ну вот, стоит привести немного статистики, как Вы уклоняетесь от темы, увлекаясь её интерпретированием. Зря я её привёл, теперь приходится всё расписывать по пунктам:
| Technical Support писал(а): |
За каких-то 24.5 минуты соединения удалённый модем запросил 100 пересогласований скорости. В среднем, каждые 15 сек (а на самом деле, ещё чаще, посколько немало времени ушло на 12 перетренировок).
|
Во-первых, я ни о чём не спрашивал, это очевидно и вполне понятно из статистики. Пересогласования мне не мешают, они кратковременны, и не ощутимы во время игры. Мешают только ретрейны.
| Technical Support писал(а): |
Алгоритм направлен на снижение количества пересогласований скорости, инициируемых Вашим модемом. Но здесь их и так было немного, всего 6 против 100, запрошенных удалённым. Кстати, из этих 6 запрошенных пересогласований не было ни одного fallforward-а.
|
Отсутствие fallforward-а хорошо, но недостаточно.
Из-за того, что модем упорно не снижал скорости приёма меньше 16800 проскакивали ретрейны, которых в три(!) раза меньше, если скорость на приём 14400. Эти данные подтверждены многократно. А пересогласования другого модема - это его дело, я пишу про другое, про наш  модем.
| Technical Support писал(а): |
Судя по внешним признаком, у Вашего друга один из модемов US Robotics. Да, эти модемы очень склонны к бешеной (и в большинстве случаев, бесцельной) беготне по скоростям. Со своей стороны Вы пытались помочь, подняв уровень мощности своего передатчика до -4 дБм (кстати, при работе на V.34 этот уровень крайне нежелательно поднимать выше -6 дБм), но это мало помогло. Говорить об эффективности данного алгоритма при подобных обстоятельствах не приходится: каждый модем "сам себе Буратино". Захотел удалённый модем побегать по скоростям - нам остаётся только подчиниться этому желанию. Так уж устроены протоколы...
|
Да, модем именно такой, старый Courier. Напротив, увеличение уровня мощности передатчика помогло, да ещё как: при S91=9 вообще даже соединения не происходило! Я совершенно не согласен насчёт "крайне нежелательно". Удалённый модем всегда может попросить снизить уровень сигнала. А вот попросить его увеличить, насколько я знаю, нельзя. Огромная накопленная статистика подтверждает эффективную работу этих механизмов. Вот запрещать понижать уровень сигнала как раз крайне нежелательно, ввиду непостоянства условий связи. Но, мы уклонились от темы.
Чтобы было понятно, что речь именно об алгоритме темы дискуссии, добавлю, что эффект, про который я писал наблюдался при MS=11,,,,,,14400 - черезерно высокая скорость на приём - и как следствие ретрейны. Траффик не превышает 600 b/s а модем держит скорость >=16800, что приводит к нестабильной связи. При MS=11,,,14400,,,14000 устойчивая работа на приём.
Проверялось несколько раз, в разные дни сериями примерно по полчаса с ограничением 14000 на приём и без. Начинали играть без ограничения, и переключались на ограничение примерно через полчаса, когда либо связь падала из-за неудачного ретрейна, либо когда время сеанса превышало полчаса(для сравнения), либо когда из-за постоянных ретрейнов сдавали нервы, и невозможно было продолжать игру.
Единственная разница всех соединений, это скорость более 16800 на приём при MS=11,,,,,,14400 и обилие ретрейнов по сравнению с сеансами с MS=11,,,14400,,,14400 для которых характерно пренебрежимо малое количество ретрейнов. Разница ни много ни мало, это возможность играть во втором случае, и невозможность в первом. |
|
| Вернуться к началу |
|
 |
Technical Support
Expert
Зарегистрирован: 31.10.2002
Сообщения: 6330
|
| Добавлено: Сб Сен 13, 2003 2:22 pm Заголовок сообщения: |
|
|
Начнём с простых вопросов, не имеющих прямого отношения к теме. В соответствии с рекомендацией V.34 сигналы тестирования линии (Line probing) должны передаваться при уровне +6 дБм относительно номинальной (т.е. заданной регистром S91) мощности (см. ITU-T V.34 параграф "10.1.2.4 Line Probing Signals"). Если Вы выставляете S91=4 то, по идее, сигналы L1/L2 должны передаваться с уровнем в +2 дБм. Однако, максимальная мощность передатчика модема - 0 дБм, и именно при такой мощности будут переданы L1/L2. Удалённый модем ничего не знает о возникших у нас трудностях, и базирует свои расчёты на том, что дальнейшая передача будет идти с уровнем, на шесть (а не на четыре) дБ меньше, чем тот, на котором он принял L1/L2. Иными словами, Вы искусственно создаёте проблемы удалённому модему.
Конечно, иногда повышение уровня мощности передатчика - единственный способ преодолеть "глухоту" линии и удалённого модема, и тут уж из двух зол приходится выбирать меньшее. Но такой выбор должен быть, во-первых, осознанным (вполне возможно, что и -6 дБм вполне хватило бы) и во-вторых, в подобных ситуациях лучше перейти на V.32bis (всё равно скорость передачи в подобных ситуациях редко превышает 14400 бит/с), ведь на этом протоколе нет необходимости передавать с уровнем большим, чем заданное S91 значение.
| Цитата: |
Почему очевидные вещи нужно объяснять?
|
Приведённая Вами статистика не показывает "явных преимуществ" нового алгоритма. Поэтому и возникло (вполне естественное) желание узнать, чем именно этот алгоритм Вам приглянулся (а вдруг чего-то не заметили в этой статистике)?
| Цитата: |
Из-за того, что модем упорно не снижал скорости приёма меньше 16800 проскакивали ретрейны, которых в три(!) раза меньше, если скорость на приём 14400. Эти данные подтверждены многократно. А пересогласования другого модема - это его дело, я пишу про другое, про наш модем.
|
Давайте посмотрим ещё раз на статистику. Всего перетренировок было 12, из них только одна - на совести нашего модема. Три - на совести удалённого. Оставшиеся восемь - автоматические (т.е. инициированные по причине того, что модемы не смогли завершить пересогласование скорости):
Retrains Issued/Granted/Auto. 1/3/8
Renegs Issued/Granted........ 6/100
FForwards/FBacks/Denied...... 0/7/0
Из этих восьми случаев как минимум две перетренировки возникли во время пересогласований скорости, запрошенных удалённым модемом (всего наш модем просил 6 пересогласований, а автоматических перетренировок было восемь). Что касается оставшихся шести авто-перетренировок, то с большой долей вероятности они возникли из-за пересогласований, запрошенных именно удалённым модемом (хотя бы по теории вероятностей: наш модем является "автором" всего лишь 5.6% общего числа пересогласований.
Хотелось бы взглянуть на типичную статистику работы со строкой инициализации +MS=11,,,14400. Есть подозрение, что при использовании этой строки существенно снижается количество пересогласований скорости, запрашиваемых Курьером, и как следствие, связанных с этим "прямых" и авто-перетренировок.
Есть и предположение о том, почему это происходит. Дело в том, как модем отрабатывает параметры MinRxRate, MaxRxRate и MaxTxRate команды +MS, и в том, как на это реагирует Курьер.
MinRxRate и MaxRxRate задают маску скоростей модема (Data signalling rate capability mask, биты 35-49 MP-последовательности, см. Table 20/V.34). Когда Вы задаёте +MS=11,,,14400, модем обнуляет биты маски, соответствующие скоростям 16800-33600. Маска - священная корова для любых V.34 модемов: если в маске не указана возможность работы на той или иной скорости, то ни Ваш, ни удалённый модем не будут пытаться её использовать. Параметр MaxTxRate задаёт значение поля Maximum call modem to answer modem data signalling rate (биты 20-23 MP) или Maximum answer modem to call modem data signalling rate (биты 20-27 MP), в зависимости от того, Ваш модем является вызывающим или отвечающим. Большинство модемов правильно понимают такое ограничение. Однако, в случае с Курьером это не так: модем пытается "пробить потолок" и тупо запрашивает пересогласования скорости. Мы такое явление наблюдали и поэтому не рекомендуем пользоваться параметром MaxTxRate при работе с Курьерами.
Поэтому давайте посмотрим типичную статистику при +MS=11,,,14400. Если предположение верно, то бороться с Курьером придётся с помощью "ручного" ограничения скорости. В противном случае будем думать, как можно было бы автоматизировать процесс.
_________________
Inpro
Technical Support |
|
| Вернуться к началу |
|
|
Dmitry Smirnov
Member
Зарегистрирован: 12.02.2003
Сообщения: 21
|
| Добавлено: Сб Сен 13, 2003 6:51 pm Заголовок сообщения: new data |
|
|
Спасибо, то, что Вы пишите про уровень сигнала, очень интересно. Действительно, S91=6 оказалось вполне достаточно (по данным одного соединения), однако разница по сравнению с S91=4 невелика. Мы пробовали соединяться на v32, но быстро отказались от этого, так как часто связь прерывалась по RETRAIN FAILURE. v34 оказался гораздо устойчивее, и хотя ретрейнов иногда бывало несколько подряд, разрывы были очень и очень редки. Как Вы спрашивали, высылаю статистику для +MS=11,,,14400 но я не заметил никакой разницы по сравнению с +MS=11,,,14400,,,14400. Думаю, что проблему, о которой я писал можно компенсировать увеличением значения S17, так, чтобы при ретрейне скорость выбиралась около 14400, тогда наверно станет возможно обойтись без ограничения скорости. Буду пробовать. Спасибо!
UserInit: s91=6+ms=11,,,14400
----------------------------------------------------------------------
IDC-5614BXL/VR firmware by Mike Telis, V2.24-V90_2M_DLS
Copyright (c) Inpro, 1998-2003
Time Online.................. 01:14:28
Termination Reason........... LOCAL REQUEST
Tx Rate (Last/Init/Min/Max).. 14400/14400/ 4800/14400 bps
Rx Rate (Last/Init/Min/Max).. 14400/14400/ 4800/14400 bps
Modulation................... V.34bis
Protocol/Compression......... LAP-M/V.42bis
Line Quality................. 4
Tx/Power Drop/Rx Level....... 6/0/22
SNR Last/Min/Max............. 27/27/32
Highest Rx/Tx State.......... 85/87
EQM Sum...................... 001B
RBS Pattern.................. NA
Rate Drop.................... NA
Digital Loss................. None
Retrains Issued/Granted/Auto. 0/2/2
Renegs Issued/Granted........ 4/72
FForwards/FBacks/Denied...... 2/2/0
Forced FB/FB after FF/MaxREJ. 0/0/3
----------------------------------------------------------------------------
Connection time : 01:14:28
Handshake Time/Retries : 19 sec/0
TX Rate (Last/Init/Min/Max) : 14400/14400/4800/14400
RX Rate (Last/Init/Min/Max) : 14400/14400/4800/14400
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 : 6/0
RX Signal Level (Last/Min/Max), -dB : 22/35/21
Band Edge Lower/Upper, Hz : 150/3825
Round trip delay, ms : -1.188
EQM Value (Last/Min/Max/Negative) : 4/0/127/0
EQM Samples Running Sum : 001B
EQM Last 10 Readings : 4 3 3 4 4 4 4 4 4 4
SNR Ratio (Last/Min/Max), dB : 27/27/32
TX/RX Non-linear Encoding : ON/OFF
TX/RX Precoding : ON/ON
TX/RX Constellation Shaping : ON/ON
TX Trellis Encoding : 64 state
TX Pre-emphasis : 8
TX/RX state (Max TX/RX, Last TX/RX) : 87H/85H, 87H/67H
Error Correction Status : ODP:T ADP:R SABME:T UA:R XID:T,R SYNC
Energy at 3750Hz/Average Energy : 1341/271
Retrains (Issued/Granted/Fast) : 0/2/0
Renegs (Issued/Granted) : 4/72
Retrans per frame/Frames rejected : 1/179
Total number of REJ sent/received : 179/159
Last Retrain/Reneg reason : Remote initiated a reneg
Last Retrain/Reneg requested : Remote Rate Renegotiation
Minutes Since Last Retrain/Reneg : 2
Disconnect reason : LOCAL REQUEST
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 |
|
| Вернуться к началу |
|
|
Technical Support
Expert
Зарегистрирован: 31.10.2002
Сообщения: 6330
|
| Добавлено: Вс Сен 14, 2003 12:33 pm Заголовок сообщения: |
|
|
| Цитата: |
Действительно, S91=6 оказалось вполне достаточно (по данным одного соединения), однако разница по сравнению с S91=4 невелика.
|
Чем больше различие между ожидаемым и действительным уровнем сигнала (т.е. чем больше Вы "скручиваете" модем, мешая ему сделать уровень L1/L2 на 6 дБм выше номинального), тем больше разница в поведении модемов. Кроме того, выставленное Вами ограничение в 14400 бит/с облегчает жизнь удалённому модему, ещё больше нивелируя различия.
В любом случае, делать уровень выше -6 дБм при отсутствии реальной необходимости неразумно.
| Цитата: |
Как Вы спрашивали, высылаю статистику для +MS=11,,,14400 но я не заметил никакой разницы по сравнению с +MS=11,,,14400,,,14400.
|
Этой разницы быть не может. При работе на V.34 параметр MaxRxRate команды +MS ограничивает не только скорость приёма, но и скорость передачи (об этом вполне конкретно написано в "Руководстве пользователя"). Т.е. при +MS=11,,,14400 скорость передачи и так ограничивается до 14400. Задание MaxTxRate=14400 ничего не меняет.
Теперь обратимся к предоставленной Вами статистике. Для простоты будем считать, что продолжительность этого сеанса (примерно 75 минут) была втрое больше, чем длительность первого сеанса (примерно 25 минут). Тогда приведённое значение запрошенных Курьером пересогласований скорости будет 72/3=24, что примерно в четыре раза меньше, чем в первом сеансе. Иначе говоря, подозрения в неадекватной реакции Курьера на ограничение скорости MaxTxRate подтверждаются.
| Цитата: |
Думаю, что проблему, о которой я писал можно компенсировать увеличением значения S17, так, чтобы при ретрейне скорость выбиралась около 14400, тогда наверно станет возможно обойтись без ограничения скорости.
|
Попробуйте... хотя у нас есть сомнения в эффективности выбранного Вами пути. Выбор скорости приёма идёт через биты 20-23 (или 24-27) MP-последовательности. Если предположение о необходимости ограничения через маску скоростей (и только через неё) верно, то Вас ждёт разочарование...
_________________
Inpro
Technical Support |
|
| Вернуться к началу |
|
|
Dmitry Smirnov
Member
Зарегистрирован: 12.02.2003
Сообщения: 21
|
| Добавлено: Пн Сен 15, 2003 1:13 am Заголовок сообщения: 2.24 feature |
|
|
| Technical Support писал(а): |
Иначе говоря, подозрения в неадекватной реакции Курьера на ограничение скорости MaxTxRate подтверждаются.
|
Вот на этот счёт у меня имеются сомнения: вполне возможно, что Вы правы, но возможно также и то, что уровень сигнала оказался более подходящим, или связь в этот раз была лучше, чем в прошлый. Похожие результаты бывали и раньше, поэтому я не уверен в таком выводе по результатам одного сравнения. Впрочем, это не так уж важно, так как пресогласования во время игры не заметны.
Интереснее другое: как модему подбирать оптимальную скорость соединения соответственно загрузке канала? Вы научили модем не поднимать скорость без необходимости - и это хорошо. Но если минимальная скорость выбырается слишком высокой, и много ретрейнов при ничтожном траффике? Что же тогда? Манипуляции регистром S17 не помогут? Как помочь модему установить оптимальную начальную скорость во время ретрейна?
P.S. Спасибо за помощь в оптимизации настроек. |
|
| Вернуться к началу |
|
|
Technical Support
Expert
Зарегистрирован: 31.10.2002
Сообщения: 6330
|
| Добавлено: Пн Сен 15, 2003 2:07 pm Заголовок сообщения: |
|
|
| Цитата: |
Интереснее другое: как модему подбирать оптимальную скорость соединения соответственно загрузке канала? Вы научили модем не поднимать скорость без необходимости - и это хорошо. Но если минимальная скорость выбырается слишком высокой, и много ретрейнов при ничтожном траффике? Что же тогда? Манипуляции регистром S17 не помогут? Как помочь модему установить оптимальную начальную скорость во время ретрейна?
|
Вариант с принудительным снижением скорости при низкой загрузке канала малопригоден для реальной жизни. Большинство пользователей работают по схеме: загрузка странички, просмотр, затем загрузка следующей. Если во время просмотра (когда загрузки нет) снижать скорость, то потом её можно и не успеть увеличить во время загрузки следующей страницы. Кроме того, сама загрузка обычно занимает 10-15 сек и потеря 2-3 сек на пересогласование скорости - весьма существенна (да и появление загрузки канала нужно определить, а это - тоже время). Поэтому более предпочтителен вариант, при котором скорость приёма снижается в силу естественных причин (помехи), а потом её просто не увеличиваем, пока в этом не возникнет необходимость.
Естественно, S17 может быть использован для занижения скорости во время перетренировок. Беда Вашего конкретного случая в том, что перетренировки происходят по инициативе удалённого модема (и Вы на это не можете повлиять), что удалённый модем, по всей вероятности, хочет видеть "зажатую по маске" скорость и наконец, что оптимальная скорость на линии на 6 ступеней (да-да!) ниже той, которая выбирается при соединении и при перетренировках. Работа "ограничительных алгоритмов" может быть эффективной только в том случае, когда речь идёт о снижении скорости на 2-3 ступеньки (ступенька, в случае V.34, равна 2400 бит/с). Когда нужно снижать с 28800 до 14400, придумать эффективный алгоритм (да ещё такой, чтоб не мешал работе на нормальных линиях), невозможно.
_________________
Inpro
Technical Support |
|
| Вернуться к началу |
|
|
Dmitry Smirnov
Member
Зарегистрирован: 12.02.2003
Сообщения: 21
|
| Добавлено: Ср Сен 17, 2003 12:37 am Заголовок сообщения: 2.24 feature OK |
|
|
Что верно, то верно :)
Но далеко не всегда перетренировки запрашивает удалённый модем - нередки случаи, когда как раз он запрашивает всего одну, тогда как мы - около 7, и ни одной автоматической. Но это было давно.
| Technical Support писал(а): |
Иначе говоря, подозрения в неадекватной реакции Курьера на ограничение скорости MaxTxRate подтверждаются.
|
Я покопался в логах, и обнаружил, статистику, как две капли воды с той, что при +MS=11,,,,,,14400 и без. (одинаково соотношение длительности сеанса к числу renegs, запрошенных курьером). Наверно это не мой случай. Возможно дело в том, что у "курьера" прошивка AVC. Хотя быть может его неадекватность проявляется не всегда, а только тогда, когда он считает что надо поднять скорость больше, чем ему ограничено? Кажется курьер всегда просит много пересогласований, независимо от MaxTxRate.
А эксперимент с S17 оказался удачным - одна строка инициализации для обоих случаев. "Фича" работает замечательно, и скорость на приём не была слишком велика. Вот и статистика последнего соединения:
UserInit: s17=77s91=6+ms=11,,,,,,24000
----------------------------------------------------------------------
IDC-5614BXL/VR firmware by Mike Telis, V2.24-V90_2M_DLS
Copyright (c) Inpro, 1998-2003
Time Online.................. 01:46:14
Termination Reason........... LINK DISCONNECT
Tx Rate (Last/Init/Min/Max).. 19200/16800/ 9600/21600 bps
Rx Rate (Last/Init/Min/Max).. 9600/12000/ 4800/12000 bps
Modulation................... V.34bis
Protocol/Compression......... LAP-M/V.42bis
Line Quality................. 25
Tx/Power Drop/Rx Level....... 6/3/28
SNR Last/Min/Max............. 26/26/27
Highest Rx/Tx State.......... 84/87
EQM Sum...................... 0990
RBS Pattern.................. NA
Rate Drop.................... NA
Digital Loss................. None
Retrains Issued/Granted/Auto. 0/2/3
Renegs Issued/Granted........ 7/140
FForwards/FBacks/Denied...... 1/6/0
Forced FB/FB after FF/MaxREJ. 4/0/7
----------------------------------------------------------------------------
Connection time : 01:46:14
Handshake Time/Retries : 19 sec/0
TX Rate (Last/Init/Min/Max) : 19200/16800/9600/21600
RX Rate (Last/Init/Min/Max) : 9600/12000/4800/12000
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 : 6/3
RX Signal Level (Last/Min/Max), -dB : 27/28/24
Band Edge Lower/Upper, Hz : 150/3825
Round trip delay, ms : -0.563
EQM Value (Last/Min/Max/Negative) : 25/4/127/0
EQM Samples Running Sum : 0990
EQM Last 10 Readings : 26 26 28 27 26 26 26 27 25 26
SNR Ratio (Last/Min/Max), dB : 26/26/27
TX/RX Non-linear Encoding : ON/OFF
TX/RX Precoding : OFF/ON
TX/RX Constellation Shaping : OFF/ON
TX Trellis Encoding : 64 state
TX Pre-emphasis : 8
TX/RX state (Max TX/RX, Last TX/RX) : 87H/84H, 87H/67H
Error Correction Status : ODP:T ADP:R SABME:T UA:T,R XID:T,R SYNC
Energy at 3750Hz/Average Energy : 745/170
Retrains (Issued/Granted/Fast) : 0/2/0
Renegs (Issued/Granted) : 7/140
Retrans per frame/Frames rejected : 1/46
Total number of REJ sent/received : NA
Last Retrain/Reneg reason : Remote initiated a reneg
Last Retrain/Reneg requested : Remote Rate Renegotiation
Minutes Since Last Retrain/Reneg : 5
Disconnect reason : LINK DISCONNECT
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 |
|
| Вернуться к началу |
|
|
Technical Support
Expert
Зарегистрирован: 31.10.2002
Сообщения: 6330
|
| Добавлено: Ср Сен 17, 2003 7:28 am Заголовок сообщения: |
|
|
Каким было значение S17 до того, как Вы его изменили на 77 ?
_________________
Inpro
Technical Support |
|
| Вернуться к началу |
|
|
Dmitry Smirnov
Member
Зарегистрирован: 12.02.2003
Сообщения: 21
|
| Добавлено: Ср Сен 17, 2003 6:14 pm Заголовок сообщения: |
|
|
| Technical Support писал(а): |
Каким было значение S17 до того, как Вы его изменили на 77 ?
|
Конечно же по умолчанию - 72!! Будь оно другим - я написал бы!! |
|
| Вернуться к началу |
|
|
Technical Support
Expert
Зарегистрирован: 31.10.2002
Сообщения: 6330
|
| Добавлено: Ср Сен 17, 2003 6:29 pm Заголовок сообщения: |
|
|
В этом случае Вы случайно попали на очень плохое (в сравнении с предыдущими статистиками) соединение. Достаточно взглянуть на EQM Sum этого и предыдущих соединений.
Да, S17 влияет на EQM Sum, но различия между получаемыми значениями при S17=72 и S17=77 несущественны. Тут же разница в порядке величин EQM Sum.
Так что можно смело отбрасывать эту статистику, как случайную.
_________________
Inpro
Technical Support |
|
| Вернуться к началу |
|
|
Dmitry Smirnov
Member
Зарегистрирован: 12.02.2003
Сообщения: 21
|
| Добавлено: Пт Сен 19, 2003 12:51 am Заголовок сообщения: please more info |
|
|
Будьте добры, подробнее насчёт S17 и EQM Sum!
Как подбирать значения S17 ?
На сколько нужно изменить значение S17 чтобы скорость соединения изменилась на 1 шаг?
Как и в какой степени S17 влияет на EQM Sum?
Как использовать EQM Sum при интерпретациях?
Спасибо. |
|
| Вернуться к началу |
|
|
Technical Support
Expert
Зарегистрирован: 31.10.2002
Сообщения: 6330
|
| Добавлено: Пт Сен 19, 2003 9:02 am Заголовок сообщения: |
|
|
Пересчёт EQM Sum выполняется по следующей формуле:
Sum_77 = Sum_72 * 77 / 72
Напоминаем: в статистике EQM Sum приводится в виде 16-ричного числа, которое для начала нужно преобразовать в десятичное. Таким образом, для статистики:
EQM Sum...................... 0044
Соответствующая величина при S17=77 была бы 0048, а в Вашей последней статистике стоит:
EQM Sum...................... 0990
Величины отличаются в 34 раза!
Что касается подстройки S17 под "одну-две ступеньки", то таковых не существует. Линейной зависимости между значениями S17 и выбираемой скоростью нет. Если возникла необходимость подстройки S17, то делать это нужно по индикаторам SVD и AA при установленном S13.7=1. Если вскоре после соединения зажигается АА, то значение S17 нужно увеличить. Если зажигается SVD, то S17 нужно уменьшать. Если же после соединения ни один из этих индикаторов не зажигается (в течении 5-10 сек), то всё настроено правильно.
_________________
Inpro
Technical Support |
|
| Вернуться к началу |
|
|
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Поиск
Пользователи
Группы
Регистрация
Профиль
Войти и проверить личные сообщения
Вход
