Очень низкая скорость

oleg1251
Новичок
1/31/2009, 10:27:20 PM
Хочу новые серии остаться в живых скачать, а канал, 12 килабай.
Вроде слышал что существуют какие-то сервисы по увеличению скорости скачивания. Если кто сталкивалься посоветуйте.
Вроде слышал что существуют какие-то сервисы по увеличению скорости скачивания. Если кто сталкивалься посоветуйте.

Алексеев
Мастер
2/1/2009, 1:20:12 AM

Так им! Запоминайте, гады:
1 мегабайт = 1000 килобайт!
1000 мегабит - примерно от 20 до 30 мегабайт!
Параметры оконечных устройств не влияют на скорость загрузки!
Smart QoS не способна ограничивать пропусную способность линии!
Умом Россию не понять, стандартами не ограничить...

scats
Мастер
2/1/2009, 1:41:19 AM
Переношу в компьютерную "болталку"

Алексеев
Мастер
2/1/2009, 3:08:04 AM
Ндя, была где-то такая тема...
А никак. Можно конечно пошаманить с настройками, но если из-за этого скорость подрастет хотя бы до 12,5 - это будет просто праздник жизни и чудо Господне в одном флаконе.
Для сего шаманства есть куча отдельных программ, чуть менее чем все из которых - замаскированные трояны, естественно для скорости бесполезные. Ещё есть программы комплексного обслуживания типа TuneUp Utilites, они на самом деле что-то пытаются оптимизировать. Про эффект смотри выше.
Единственный вариант заметно увеличить скорость - перезаключить договор с провайдером. Или засесть в P2P сети, типа осла или торрента. Там скорость выше :)
А никак. Можно конечно пошаманить с настройками, но если из-за этого скорость подрастет хотя бы до 12,5 - это будет просто праздник жизни и чудо Господне в одном флаконе.
Для сего шаманства есть куча отдельных программ, чуть менее чем все из которых - замаскированные трояны, естественно для скорости бесполезные. Ещё есть программы комплексного обслуживания типа TuneUp Utilites, они на самом деле что-то пытаются оптимизировать. Про эффект смотри выше.
Единственный вариант заметно увеличить скорость - перезаключить договор с провайдером. Или засесть в P2P сети, типа осла или торрента. Там скорость выше :)

oleg1251
Новичок
2/1/2009, 2:19:47 PM
Вобщем сервис по увеличению скорости я нарыл -
сжимающий прокси. Сервис прикольный, страницы сжимает, на вирусы трафик проверяет. Вобщем если у кого канал тормозной или деньги за трафик платиш, то этот сервис самое то. Вот тока одно, видео сжимать не умеет, то есть если просто по инету лазить, то время загрузки страниц меньше и загружаються быстрее. Показывает степень сжатия в 4 раза.
Но вот тока пробовал киношку скачать, показал степень сжатия 0 процнтов.
Ещё немного поэкспереминтировал с настройками политик(gpedit.msc), но скорость от этого не увеличилась.
сжимающий прокси. Сервис прикольный, страницы сжимает, на вирусы трафик проверяет. Вобщем если у кого канал тормозной или деньги за трафик платиш, то этот сервис самое то. Вот тока одно, видео сжимать не умеет, то есть если просто по инету лазить, то время загрузки страниц меньше и загружаються быстрее. Показывает степень сжатия в 4 раза.
Но вот тока пробовал киношку скачать, показал степень сжатия 0 процнтов.
Ещё немного поэкспереминтировал с настройками политик(gpedit.msc), но скорость от этого не увеличилась.

Матчо
Новичок
2/3/2009, 4:45:39 AM
Сменить тарифный план, провайдера.

heep25
Специалист
2/7/2009, 12:25:24 AM
(oleg1251 @ 01.02.2009 - время: 11:19) Вобщем сервис по увеличению скорости я нарыл -
сжимающий прокси. Сервис прикольный, страницы сжимает, на вирусы трафик проверяет. Вобщем если у кого канал тормозной или деньги за трафик платиш, то этот сервис самое то. Вот тока одно, видео сжимать не умеет, то есть если просто по инету лазить, то время загрузки страниц меньше и загружаються быстрее. Показывает степень сжатия в 4 раза.
Но вот тока пробовал киношку скачать, показал степень сжатия 0 процнтов.
Ещё немного поэкспереминтировал с настройками политик(gpedit.msc), но скорость от этого не увеличилась.
Обычно видио идет уже сжатым в архивах RАR, или каких то других поэтому сжимать его дальше не куда, а вообще графика и видио сами по себе сжимаются плохо. Как уже было сказано выше смени тариф и будет все нормально.
сжимающий прокси. Сервис прикольный, страницы сжимает, на вирусы трафик проверяет. Вобщем если у кого канал тормозной или деньги за трафик платиш, то этот сервис самое то. Вот тока одно, видео сжимать не умеет, то есть если просто по инету лазить, то время загрузки страниц меньше и загружаються быстрее. Показывает степень сжатия в 4 раза.
Но вот тока пробовал киношку скачать, показал степень сжатия 0 процнтов.
Ещё немного поэкспереминтировал с настройками политик(gpedit.msc), но скорость от этого не увеличилась.
Обычно видио идет уже сжатым в архивах RАR, или каких то других поэтому сжимать его дальше не куда, а вообще графика и видио сами по себе сжимаются плохо. Как уже было сказано выше смени тариф и будет все нормально.

Kyigor
Акула пера
2/7/2009, 3:06:06 AM
да собственно никак только перезаключить оговор с твоим провайдером.
все остальное полный бред сам когда то пытался искать разные проги типа увеличивающие скорость- полная туфта.
все остальное полный бред сам когда то пытался искать разные проги типа увеличивающие скорость- полная туфта.

Moriarti
Новичок
2/20/2009, 5:17:08 AM
Очень ошибается тот, кто считает, что настройки сетевого и Интернет-соединения мало влияют на скорость передачи данных.
Вот один пример: Любому компьютерщику известно, что данные в компьютерных системах хранятся и передаются блоками (пакетами) определённого размера. Каждый передаваемый по сети пакет имеет заголовок и некоторый объём служебной информации, а его "стандартный" размер устанавливается переменной MTU. При увеличении размера пакета уменьшается их количество и соответственно соотношение передаваемой "полезной" и служебной информации улучшается, но при передаче большого количества маленьких файлов сеть будет перекачивать преимущественно "воздух". А при чрезмерном уменьшении - "мелкие" файлы передаются более эффективно, а вот большие файлы оказываются "разбавлены" большим количеством служебной информации. И в том, и в другом случае растёт трафик и теряется скорость, и то и другое стоит денег. Но и это ещё пол-беды! Вторая половина в том, у Вашего провайдера "стандартный" размер пакетов скорее всего будет иной, чем у Вас, и длинные пакеты будут безбожно порезаны на куски а короткие заполнены "воздухом". И так на каждом участке...
Далее, каждый передаваемый пакет имеет установленный предельный "срок жизни" - TTL, при маленьком значении которого многие пакеты могут "погибать" в пути, как сперматозоиды, не достигнув "заветной цели".
Увеличение TTL, правильно прописанные маршруты и метрика позволят пакетам находить оптимальный путь с меньшими потерями.
Ну и ещё один "секрет" заключается в том, что все сетевые устройства "сообщаются" между собой не одновременно, а поочерёдно (как собеседники по телефону). Как только возникает "накладка" - коллизия, оба сетевых устройства "замолкают", а через некоторое время повторяют попытку. Это время у разных сетевых устройств разное, и тот, у кого это время меньше (или тот, кто знает, как его уменьшить), будет иметь "право первого голоса", а все остальные будут вынуждены терпеливо ждать...
Хорошее средство - использовать менеджер закачки, который разбивает её на несколько потоков, находит зеркала и пр. а также отключение фаервола, веб-антивируса, или добавление сайта в доверенную зону. И ещё замена медной витой пары на более "медную" и более "витую"...
Вот один пример: Любому компьютерщику известно, что данные в компьютерных системах хранятся и передаются блоками (пакетами) определённого размера. Каждый передаваемый по сети пакет имеет заголовок и некоторый объём служебной информации, а его "стандартный" размер устанавливается переменной MTU. При увеличении размера пакета уменьшается их количество и соответственно соотношение передаваемой "полезной" и служебной информации улучшается, но при передаче большого количества маленьких файлов сеть будет перекачивать преимущественно "воздух". А при чрезмерном уменьшении - "мелкие" файлы передаются более эффективно, а вот большие файлы оказываются "разбавлены" большим количеством служебной информации. И в том, и в другом случае растёт трафик и теряется скорость, и то и другое стоит денег. Но и это ещё пол-беды! Вторая половина в том, у Вашего провайдера "стандартный" размер пакетов скорее всего будет иной, чем у Вас, и длинные пакеты будут безбожно порезаны на куски а короткие заполнены "воздухом". И так на каждом участке...
Далее, каждый передаваемый пакет имеет установленный предельный "срок жизни" - TTL, при маленьком значении которого многие пакеты могут "погибать" в пути, как сперматозоиды, не достигнув "заветной цели".
Увеличение TTL, правильно прописанные маршруты и метрика позволят пакетам находить оптимальный путь с меньшими потерями.
Ну и ещё один "секрет" заключается в том, что все сетевые устройства "сообщаются" между собой не одновременно, а поочерёдно (как собеседники по телефону). Как только возникает "накладка" - коллизия, оба сетевых устройства "замолкают", а через некоторое время повторяют попытку. Это время у разных сетевых устройств разное, и тот, у кого это время меньше (или тот, кто знает, как его уменьшить), будет иметь "право первого голоса", а все остальные будут вынуждены терпеливо ждать...
Хорошее средство - использовать менеджер закачки, который разбивает её на несколько потоков, находит зеркала и пр. а также отключение фаервола, веб-антивируса, или добавление сайта в доверенную зону. И ещё замена медной витой пары на более "медную" и более "витую"...

Алексеев
Мастер
2/20/2009, 6:40:09 AM
Более медную... более витую... от коллизий
В последней части бред всё, что после слова "секрет". По-видимому автор плохо знаком с понятием коллизии.
Остальная часть отдает мхом и урбанистическими легендами времен смены тысячелетий, наподобие искусственного притормаживания Windows разработчиками.
Походу оригинал статьи был написан году в 2001-2002, когда деревья были зеленые, сети медленные, админы ленивые, а книги дорогие

В последней части бред всё, что после слова "секрет". По-видимому автор плохо знаком с понятием коллизии.
Остальная часть отдает мхом и урбанистическими легендами времен смены тысячелетий, наподобие искусственного притормаживания Windows разработчиками.
Походу оригинал статьи был написан году в 2001-2002, когда деревья были зеленые, сети медленные, админы ленивые, а книги дорогие


heep25
Специалист
2/20/2009, 12:57:54 PM
(t-kvark @ 20.02.2009 - время: 03:40) Более медную... более витую... от коллизий
В последней части бред всё, что после слова "секрет". По-видимому автор плохо знаком с понятием коллизии.
Остальная часть отдает мхом и урбанистическими легендами времен смены тысячелетий, наподобие искусственного притормаживания Windows разработчиками.
Походу оригинал статьи был написан году в 2001-2002, когда деревья были зеленые, сети медленные, админы ленивые, а книги дорогие
Четко знаю одну вещь чем дороже заплатишь за инет тем выше скорость а остальное

В последней части бред всё, что после слова "секрет". По-видимому автор плохо знаком с понятием коллизии.
Остальная часть отдает мхом и урбанистическими легендами времен смены тысячелетий, наподобие искусственного притормаживания Windows разработчиками.
Походу оригинал статьи был написан году в 2001-2002, когда деревья были зеленые, сети медленные, админы ленивые, а книги дорогие




b00ka
Новичок
2/20/2009, 2:16:19 PM
Moriarti
какой ужас
сам сочинил или подсказал кто?
относительно MTU: а о том что параметр сравнивается и автоматически понижается до минимального значения, и фактически изменив параметр только на одном конце соединения ты его можешь только уменьшить, сказать не?
какой ужас
сам сочинил или подсказал кто?
относительно MTU: а о том что параметр сравнивается и автоматически понижается до минимального значения, и фактически изменив параметр только на одном конце соединения ты его можешь только уменьшить, сказать не?

Moriarti
Новичок
2/20/2009, 11:55:19 PM
Признаюсь - сам сочинил! Хотя кое-что слышал или читал. Высказывания супер-профессионалов вроде "А на фига это нужно!? Купи, Поменяй, Переустанови - и будет тебе счастье!" и заявления типа "Бред!", "Сникерс с лесным орехом не существует!" - не оригинальны и совсем не новость (Хотя... когда будет у меня 100-гигабитный Инет , я скорее всего и сам таким стану).
А всё-таки почему - "бред!"? Где аргументы? Мы разве не "рождены, чтоб сказку сделать былью"?
"Более медная" и "более витая" - значит, с бОльшим содержанием меди и в-общем более качественная. Хотя о коллизиях я говорил в совершенно по другому поводу, они действительно существуют, и качество (и длина) витой пары имеет к ним непосредственное отношение. Не согласны - аргументируйте.
b00ka, а Вас я попрошу остаться! Пожалуйста, уточните - с какого конца и кто под кого всё-таки подстраивается?
То, что MTU может корректироваться и только в меньшую сторону (если запретить дефрагментацию пакетов), я не отрицаю, только вот немного сомневаюсь, что подобная коррекция решает все проблемы.
А всё-таки почему - "бред!"? Где аргументы? Мы разве не "рождены, чтоб сказку сделать былью"?
"Более медная" и "более витая" - значит, с бОльшим содержанием меди и в-общем более качественная. Хотя о коллизиях я говорил в совершенно по другому поводу, они действительно существуют, и качество (и длина) витой пары имеет к ним непосредственное отношение. Не согласны - аргументируйте.
b00ka, а Вас я попрошу остаться! Пожалуйста, уточните - с какого конца и кто под кого всё-таки подстраивается?
То, что MTU может корректироваться и только в меньшую сторону (если запретить дефрагментацию пакетов), я не отрицаю, только вот немного сомневаюсь, что подобная коррекция решает все проблемы.

b00ka
Новичок
2/21/2009, 12:38:20 AM
в процессе согласования соединения между двумя устройствами они обмениваются значениями МТУ, из которых выбирается меньшее
таким образом, если есть доступ к изменению МТУ только на одном устройстве - его можно только уменьшить, т.к. для увеличения нужно увеличить самое малое из них.
(в данном случае предположено, что у клиента значение мту назначено по-умолчанию, и в 98% случаев равно или больше мту провайдера, который выставлен из расчета знаний своей сети.)
и... вообщето МТУ указывает на максимальный возможный размер нефрагментированного пакета в данной сети
когда на этом можно сыграть...
предположим:
есть цепочка Х1-(Р11-Р12)-(Р21-Р22)-Х2
где Х - хосты
Р - роутеры
Рх1 и Рх2 - интерфейсы роутеров
в сетях Х1-Р1 и Х2-Р2 МТУ одинаковое и равно А
но между Р1 и Р2 оно меньше А
тогда, пакет посланный от Х1 к Х2 при значении больше А будет фрагментирован на 2 пакета размером А и отослан Р1
в свою очередь Р1 еще раз фрагментирует кажный пакет и отправит уже, допустим, 4 пакета Р2
после конечной пересылки Х2 старается собрать из фрагментов начальный пакет
естественно, что при фрагментации пакета добавляются заголовки и часть служебного трафика возростает
если обмен ведется по ТСР, то после каждых 4-х пакетов проводится проверка и отсылается подтверждение Х1
и если между Р1-Р2 потерялся один пакет, то Х1 начнет передачу всей цепочки сначала
итого 4*2*2=16 пакетов Х2 получит еще раз, соберет и сверит
это съедает трафик и процессорное время Х2
для борьбы с такими проблемами можно, например, уменьшить МТУ на Х1 до размера МТУ связки Р1-Р2
но это рекомендуют делать только как временное решение, до устранения причины потерь Р1-Р2
могут быть неточности, но надеюсь лекцию можно заканчивать
материалов в сети на почитать достаточно, удачи
и, мориарти, это уже совсем дикий офтоп...
таким образом, если есть доступ к изменению МТУ только на одном устройстве - его можно только уменьшить, т.к. для увеличения нужно увеличить самое малое из них.
(в данном случае предположено, что у клиента значение мту назначено по-умолчанию, и в 98% случаев равно или больше мту провайдера, который выставлен из расчета знаний своей сети.)
и... вообщето МТУ указывает на максимальный возможный размер нефрагментированного пакета в данной сети
когда на этом можно сыграть...
предположим:
есть цепочка Х1-(Р11-Р12)-(Р21-Р22)-Х2
где Х - хосты
Р - роутеры
Рх1 и Рх2 - интерфейсы роутеров
в сетях Х1-Р1 и Х2-Р2 МТУ одинаковое и равно А
но между Р1 и Р2 оно меньше А
тогда, пакет посланный от Х1 к Х2 при значении больше А будет фрагментирован на 2 пакета размером А и отослан Р1
в свою очередь Р1 еще раз фрагментирует кажный пакет и отправит уже, допустим, 4 пакета Р2
после конечной пересылки Х2 старается собрать из фрагментов начальный пакет
естественно, что при фрагментации пакета добавляются заголовки и часть служебного трафика возростает
если обмен ведется по ТСР, то после каждых 4-х пакетов проводится проверка и отсылается подтверждение Х1
и если между Р1-Р2 потерялся один пакет, то Х1 начнет передачу всей цепочки сначала
итого 4*2*2=16 пакетов Х2 получит еще раз, соберет и сверит
это съедает трафик и процессорное время Х2
для борьбы с такими проблемами можно, например, уменьшить МТУ на Х1 до размера МТУ связки Р1-Р2
но это рекомендуют делать только как временное решение, до устранения причины потерь Р1-Р2
могут быть неточности, но надеюсь лекцию можно заканчивать
материалов в сети на почитать достаточно, удачи
и, мориарти, это уже совсем дикий офтоп...

Алексеев
Мастер
2/21/2009, 3:23:34 AM
(Moriarti @ 20.02.2009 - время: 20:55)Не согласны - аргументируйте.
Аргументирую.
Бредом последний абзац был назван хотя бы потому, что к глобальным сетям он не применим. Он подошел бы к лекции про организацию какого-нибудь локального FTP-сервера на тупом и медленном хабе конца 20-го века. Да и то, про антивирусы и файерволлы я бы промолчал :) То же касается и ТТЛ.
Про MTU вообще разговор особый. Как верно сказал b00ka, с клиентского компьютера MTU целесообразно только уменьшать.
Но, сети сейчас быстрые и провайдеру выгодны большие размеры пакетов. По умолчанию, что в системе, что в клиентском сетевом оборудовании, обычно также выставляются максимальные значения.
То есть, смысла играть с МТУ в 70% случаев нет вообще. Оставшиеся 30% приходятся на плохие линии или неграмотно настроенное провайдерское оборудование, но и там шустрее выделенного провайдером канала качать не будет. И смысл заморачиваться есть только в том случае, когда скорость интернета постоянно и намного меньше обещанной.
Про качество кабеля тоже вопрос спорный. Мало кто для соединения с провайдером лично прокладывает себе километровые сети с ретранслирующим оборудованием. Обычно все укладываются в стандартные 100 метров шнура, где любой кабель будет работать нормально :)
Аргументирую.
Бредом последний абзац был назван хотя бы потому, что к глобальным сетям он не применим. Он подошел бы к лекции про организацию какого-нибудь локального FTP-сервера на тупом и медленном хабе конца 20-го века. Да и то, про антивирусы и файерволлы я бы промолчал :) То же касается и ТТЛ.
Про MTU вообще разговор особый. Как верно сказал b00ka, с клиентского компьютера MTU целесообразно только уменьшать.
Но, сети сейчас быстрые и провайдеру выгодны большие размеры пакетов. По умолчанию, что в системе, что в клиентском сетевом оборудовании, обычно также выставляются максимальные значения.
То есть, смысла играть с МТУ в 70% случаев нет вообще. Оставшиеся 30% приходятся на плохие линии или неграмотно настроенное провайдерское оборудование, но и там шустрее выделенного провайдером канала качать не будет. И смысл заморачиваться есть только в том случае, когда скорость интернета постоянно и намного меньше обещанной.
Про качество кабеля тоже вопрос спорный. Мало кто для соединения с провайдером лично прокладывает себе километровые сети с ретранслирующим оборудованием. Обычно все укладываются в стандартные 100 метров шнура, где любой кабель будет работать нормально :)

BBS
Любитель
2/22/2009, 5:52:15 AM
(t-kvark @ 31.01.2009 - время: 22:20)
Эту тему читают меряканские шпиёны?
Так им! Запоминайте, гады:
1 мегабайт = 1000 килобайт!
1000 мегабит - примерно от 20 до 30 мегабайт!
Параметры оконечных устройств не влияют на скорость загрузки!
Smart QoS не способна ограничивать пропусную способность линии!
Умом Россию не понять, стандартами не ограничить...
1000Мбит = 125Мбайт

Так им! Запоминайте, гады:
1 мегабайт = 1000 килобайт!
1000 мегабит - примерно от 20 до 30 мегабайт!
Параметры оконечных устройств не влияют на скорость загрузки!
Smart QoS не способна ограничивать пропусную способность линии!
Умом Россию не понять, стандартами не ограничить...

1000Мбит = 125Мбайт

busbm
Мастер
2/23/2009, 7:11:31 AM
читал и плакал ))) Мориарти -жжОте! )))

busbm
Мастер
3/2/2009, 1:17:38 AM
а расфлудились-то )))
за мытищинскую ссылку - спасибо, буду теперь народ пугать скоростью в 1.3 ГИГАбит/с ))))
Кензо - читайте мат. часть. без обид, но такой ахинеи я давно не читал )
топикстартеру - Вы ничего не путаете со скоростями? 512 кбит/с=64кб/с. выходит, у Ваших друзей скорость закачки почти соответствует заявленной. дело ведь в том, что скорость подключения провайдеры указывают в мегабитах и килобитах, а скорость закачки в большинстве (подавляющем) програм указывается в килобайтах и мегабайтах ))
а ещё... попробуйте скачать утилитку CureIt от Dr.Web и прогоните ею систему на наличие вирусов. так, на всякий сучай.
за мытищинскую ссылку - спасибо, буду теперь народ пугать скоростью в 1.3 ГИГАбит/с ))))
Кензо - читайте мат. часть. без обид, но такой ахинеи я давно не читал )
топикстартеру - Вы ничего не путаете со скоростями? 512 кбит/с=64кб/с. выходит, у Ваших друзей скорость закачки почти соответствует заявленной. дело ведь в том, что скорость подключения провайдеры указывают в мегабитах и килобитах, а скорость закачки в большинстве (подавляющем) програм указывается в килобайтах и мегабайтах ))
а ещё... попробуйте скачать утилитку CureIt от Dr.Web и прогоните ею систему на наличие вирусов. так, на всякий сучай.

BeeLena
Любитель
3/4/2009, 11:56:20 AM
в P2P сети, типа осла или торрента. Там скорость выше :)
Выше головы все равно не прыгнуть... Если толщина канала ограничена провом, то пинать надо только его. Так же можно поковырять настройки TCP/IP на предмет half open connections (Это если про увеличение скорости с p2p). Но делу это не особо поможет, в данном случае...
Выше головы все равно не прыгнуть... Если толщина канала ограничена провом, то пинать надо только его. Так же можно поковырять настройки TCP/IP на предмет half open connections (Это если про увеличение скорости с p2p). Но делу это не особо поможет, в данном случае...

Алексеев
Мастер
3/5/2009, 12:14:42 AM
Вчитался в цитату Nick Name и аж подавился :))
Толщина чего?
Толщина чего?