sergo88, если по-порядку то:
- какой модем (1) ?
- ос (2)?
из железной возни:
- линия - своя или с блокиратором, наличие скруток (лучше обходится все же нормальной розеткой под разъем RJ-11 и обжатым шнурком). сборка подключения желательна по схеме розетка->модем->телефон, а не розетка<->модем<->телефон. наличие параллельных аппаратов нежелательно но и не смертельно.
теперь из софтовой возни:
прописать dns провайдера в сетевых подключениях модема в свойствах ip-протокола. узнать его очень просто:
- пуск-выполнить->cmd
- в консоли ввести: nslookup (выход - exit)
теперь непосредственно об оптимизации самого реестра для диалапа. смотрим вот эту статью:
http://www.inethelp.ru/optima/acceleration_dialup.aspx
а вот если ручаками (с) Александр Сергеев,
[email protected]
MTU
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\Class\NetTrans
Как известно, по протоколу TCP/IP данные передаются небольшими порциями – пакетами. Перемещаясь от сервера к серверу, они порой теряются или приходят поврежденными. Если вдруг такое происходит, то принимающая сторона запрашивает пропавший пакет заново, и отправляющая тут же его пересылает. Максимальный размер такого пакета задается параметром MTU (Maximum Transmission Unit).
Обычно при модемной связи с Интернетом (протокол PPP) MTU равен 576 байт. А в Windows 95/98 его значение равно 1500 байт – в расчете на связь по локальной сети. При модемной связи «битых» пакетов оказывается больше, и загрузка линии «повторными» данными существенно возрастает. Таким образом, определяется общая зависимость: чем больше происходит ошибок (читайте: чем хуже качество связи), тем меньше должен быть MTU. Принято считать, что для модемной линии оптимум – те самые
576 байт. Однако при хорошем коннекте можно и поэкспериментировать, выставив его размер побольше.
PMTUDiscovery
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\VXD\MSTCP
Вообще, Windows может сама определять оптимальный MTU для соединения с каждым сервером. За это отвечает параметр PMTUDiscovery, который может принимать всего два значения: 1 – разрешить определение, 0 – не разрешать. Естественно, что на эту операцию затрачивается некоторое время, так что, если ваше основное занятие в Сети – просмотр страничек, эту функцию лучше выключить, а если вы занимаетесь в основном скачиванием файлов – то наоборот.
DefaultRcvWindow
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\VXD\MSTCP
Еще один заслуживающий внимания параметр – размер окна приема (Receive Window). Дело в том, что данные из принятых пакетов (кроме заголовков) накапливаются в буфере, откуда затем попадают, скажем, в браузер. Если машина сильно загружена и браузер не успевает вовремя обрабатывать данные, буфер переполняется и поступающие пакеты просто игнорируются. Это приводит к повторному запросу данных и, соответственно, к потере времени. Казалось бы, надо задавать как можно больший размер буфера. Но дело в том, что если теряется один из пакетов, повторно затребованы будут все находившиеся в буфере пакеты. Само собой, что на их доставку уйдет некоторое время. Поэтому ни слишком большой, ни слишком маленький размер буфера не является оптимальным. Размер Receive Window обязательно должен быть кратен максимальному размеру данных в пакете (MSS), который на 40 байт (размер заголовка TCP-пакета) меньше значения MTU. Так что, если MTU вы установили равным 576 байт, а MSS, следовательно, 576 – 40 = 536 байт, то Receive Window можно присвоить значение 1072, 1608, 2144, 2680 байт и т. д.. Выбор опять-таки зависит от качества связи. Совсем низкое – ставьте что-нибудь около 2144 байт. Более или менее приемлемое – раза в два больше.