У меня вроде бы всё в порядке, но когда поставил W7 в Авто обновлениях увидел обновления для своей сетевой карты. Ставить не стал. Так как у меня всего 2 мбит\с падение в скорости не заметил. Страницы загружаются с той же скоростью что и на ХР, файлы также качаются. Вывод вспомните, обновляли ли вы драйвера или нет.
Ура.Сегодня ещё раз использовал метод Drinko Code netsh interface tcp set global autotuninglevel=disabled netsh interface tcp set global rss=disabled netsh interface tcp set global ecncapability=disable и о чудо,скорость восстановилась до уровня перед устоновкой 7,даже кажется шустрее стали загружатся страницы :).Спасибо
Так как при размерах окна autotuninglevel - одно из следующих значений: disabled: фиксация значения окна приема по умолчанию. highlyrestricted: разрешение на увеличение окна приема относительно значения по умолчанию, но очень незначительное. restricted: разрешение на увеличение окна приема относительно значения по умолчанию, с ограничением увеличения при некоторых сценариях. normal: разрешение на увеличение окна приема в соответствии с требованиями большинства сценариев. experimental: разрешение на увеличение окна приема в соответствии с требованиями экстремальных сценариев. и rss - одно из следующих значений: disabled: отключение масштабирования на стороне приема. enabled : включение масштабирования на стороне приема. default : восстановление заданного по умолчанию состояния масштабирования на стороне приема.
[cut noguest]будут ограничения по скорости работы сети, так как при размере окна приема
Цитата
RWIN is a multiple of MSS Other RWIN values that might work well with your current MTU/MSS: 63360 (up to 2 Mbit lines, depending on latency. MSS * 44) 126720 (1-5 Mbit lines, depending on latency. MSS * 44 * 2) 253440 (2-14 Mbit lines, depending on latency. MSS * 44 * 2^2) 506880 (8-30 Mbit lines, depending on latency. MSS * 44 * 2^3) 1013760 (25-60 Mbit lines depending on latency. MSS * 44 * 2^4)
В XP и при параметре disable значения окна приема будет равно 65535 байт, и временем отклика ~200ms. Начиная с Vista данный параметр изменен и может быть плавающим, т.е. система может сама определять его размер, в зависимости от скоростных возможностей, между сервером и клиентом, так как в данном случае подтверждается весь приемный буфер. Но данный параметр autotuninglevel (RWIN) он работает в паре с параметром Microsoft Compound TCP (CTCP), который призван увеличить количество передаваемых за TCP-сессию данных. CTCP увеличивает темп передачи с одновременным контролем размера окна и пропускной способности. Сервер быстрее достигает максимального темпа передачи и также быстрее восстанавливается при потере пакетов.
Цитата
Поставщик надстройки контроля перегрузки : ctcp congestionprovider - одно из следующих значений: none: использование встроенного стандартного алгоритма контроля перегрузки. ctcp: использование дополнительного алгоритма контроля перегрузки CTCP. default: восстановление выбранного поставщика по умолчанию.
Так же есть еще один параметр Поддержка Chimney-based разгрузки TCP/IP и поддержка netDMA. Chimney позволяет операционной системе переключать IP-стек на карты TOE (TCP Off-load Engine), которые аппаратным путем обрабатывают TCP/IP. Подобный подход позволяет значительно снизить нагрузку на процессор. Тоже самое касается случая масштабирования принимающей стороны, что позволит входящим пакетам распределяться по различным процессорам. NetDMA позволяет механизму DMA (Direct Memory Access), используемого в адаптере, выполнять операции копирования, снова освобождая от этой рутины центральный процессор.
Цитата
Состояние NetDMA : enabled Прямой доступ к кэшу (DCA) : enabled
netdma - одно из следующих значений: disabled: отключение использования NetDMA протоколом TCP/IP. enabled : включение использования NetDMA протоколом TCP/IP. default : восстановление состояния системы по умолчанию .
dca - одно из следующих значений: disabled: отключение прямого доступа к кэшу при использовании NetDMA. enabled : включение прямого доступа к кэшу при использовании NetDMA. default : восстановление состояния системы по умолчанию.
Так что тут не все так просто, нужно найти компромисс в этих настройках.
И еще при использовании VPN вы дальше сервера VPN не попадете, т.е. это канал точка точка при котором после регистрации на сервере VPN клиент работает с интернетом только через VPN (т.е. все запросы/ответы идут через него).[/cut]
Здравствуйте,нашел наконец то в инете тему на свою проблему Установил W7 32бит Максимальная сборка 6.1.7600 , и начились проблемы. Все способы описываемые тут не помогли=( да и случай у меня немного отличается. Закачка с инета идет без проблем как на ХР также и сайты открываются как должны, проблема заключается толька в онлайн играх и завышенным пингом с серваками , когда заходишь на какой нибудь сервак,допустим CS 1.6 с которым пинг на ХР был 15-20 , шас он 40-50 и скачет под 200причем вместе с ФПС , без потери пакетов и график в КС ведет себя странно , скрин предоставил ниже на нем вроди как пакеты передаются с задержкой? Как уже сказал , все способы что тут указаны не помагли , сам пробывал копаца в Брендмаузере , не помогло и отрубил его , с вирусами проблем тоже нету , стоит KIS2010 который тоже не причем Если кто знает причину проблемы , подскажите пожалуйста как ее исправить.
Drinko, Chesi писал в правильную тему. У меня аналогичная проблема инет у меня ADSL-1м/б. На XP играю без проблем, а на 7 немогу из-за "нестабильного" пинга. Страницы, видео и потоковое Mp3 идет без проблем а вот в играх это проявляется. В тех поддержке сказали проблема с виндой.
PS: Слышал что у Win7 ограничено число пакетов или портов.
skiper_nvp, Для вас, чтоб ping был нормальный в интернете куча информации как раз от геймеров, поиск видите TcpAckFrequency, TCPNoDelay
Цитата
Как это работает? Значение TcpAckFrequency определяет частоту отправки TCP/IP подтверждающего сообщения. Если значение равно 2, TCP/IP будет отправлять подтверждение после 2 принятых сегментов или после принятия 1 сегмента и отсутствия второго сегмента на протяжении 200 миллисекунд. Если значение равно 3, TCP/IP отправляет подтверждение после приема 3 сегментов, или после приема 1 или 2 сегментов и отсутствии последующих сегментов на протяжении 200 миллисекунд. И так далее. Если вам требуется сократить время ответа за счет удаления задержек отправки подтверждений TCP/IP, задайте это значение равным 1. В таком случае TCP/IP будет немедленно отправлять подтверждение для каждого сегмента. Если ваши соединения используются в основном для передачи крупных объемов данных и задержка в 200 миллисекунд несущественна, имеет смысл увеличить это значение для снижения дополнительной нагрузки отправки подтверждений. Ну а если мелкие, такие как наши пакетики ВоВ =)) то лучше поставить немедленное. Параметр TCPNoDelay отключает алгоритм Nagl'e. Из алгоритма следует, что в TCP соединении может присутствовать только один исходящий маленький сегмент, который еще не был подтвержден. Следующие маленькие сегменты могут быть посланы только после того, как было получено подтверждение. Вместо того чтобы отправляться последовательно, маленькие порции данных накапливаются и отправляются одним TCP сегментом, когда прибывает подтверждение на первый пакет. Красота этого алгоритма заключается в том, что он сам настраивает временные характеристики: чем быстрее придет подтверждение, тем быстрее будут отправлены данные. В медленных глобальных сетях, где необходимо уменьшить количество маленьких пакетов, отправляется меньше сегментов. Собственно отрубая данный алгоритм мы выигрываем в том что не тратим лишнее время на подтверждение целостности данных... но и целостность наших данных, степень ошибок сразу встает вопросом.... глюки могут случаться чаще... Так что используя данные настройки, мы уменьшаем реально нагрузку... увеличивая проходимость канала и следовательно "уменьшаем" задержку.... Однако при этом страдают такие вещи как скачивание фаилов, службы торрента, ДовнЛоадер вова тоже будет дольше качать патчи.... Потом мы можем терять данные (протокло TCP теряет свое основное преимущество над UDP)
В связи с введением в действие Постановления Правительства Российской Федерации от 14.11.2023 № 1905 т.н. "о запрете популяризации VPN" с 1 марта 2024 года - любое обсуждение способов обхода блокировок и VPN на портале запрещено!
