информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Атака на InternetГде водятся OGRыСетевые кракеры и правда о деле Левина
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Утекший код XP и Windows Server... 
 Дела виртуальные 
 Простое пробивание рабочего/провайдерского... 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / miscellaneous
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Это весьма распространенное заблуждение 09.01.05 19:22  Число просмотров: 1307
Автор: J'JF <Dmytro Volhushyn> Статус: Elderman
<"чистая" ссылка>
Мог бы я, конечно, отослать к KB316666, KB318602 и остальным сопутствующим материалам (касающимся QoS, RSVP и GQoS API). Но не буду. Попробую объяснить, как я это все понял.
Суть технологии резервирования каналов заключается в том, что приложение, которое использует канал, должно зарезервировать за собой полосу для передачи по ней служебной информации QoS. Какие приложения это делают? Да немногие по умолчанию. Например, это NetMeeting.
Цитата из KB316666:
"By default, programs can reserve up to an aggregate bandwidth of 20 percent of the underlying link speed on each interface..."
Это означает, что по умолчанию программа не может отхватить кусок канала больше 20%. Для того, чтобы дать ей больше или меньше и нужно лезть в групповые политики. Вот именно оттуда и вылазят пресловутые 20% ;-)
На самом деле, приложение не сможет зарезервировать ни одного процента канала, если отключена служба QoS.

Ну и самое примечательное в этой статье:
"Correction of some incorrect claims about Windows XP QoS support
There have been claims in various published technical articles and newsgroup postings that Windows XP always reserves 20 percent of the available bandwidth for QoS. These claims are incorrect. The information in the "Clarification about QoS in end computers that are Running Windows XP" section correctly describes the behavior of Windows XP systems."
Грубо говоря, здесь написано то, что весь этот треп (в частности тот, который ты процитировал) - всего лишь треп и не имеет ничего общего с действительностью.

Вернемся к KB:
"... If the program that reserved the bandwidth is not sending sufficient data to use it, the unused part of the reserved bandwidth is available for other data flows on the same host."
Что означает, что даже если мы оставим службу QoS включенной в свойствах интерфейса, и если даже какое-то приложение запросит резервирование канала, то этот канал будет ему отдан только в том случае, если эта программа будет реально что-то по нему слать. В противном случае, незанятый кусок полосы будет отдаваться под другие нужды, в частности под поток "обычных" данных.
А вот на вопрос, в каком случае программа будет что-то слать по зарезервированному каналу, попытайся ответить сам. ;-)

Прежде чем продолжать спорить - проверь. Сделать это просто - протестируй скорость передачи данных через сетевой интерфейс со включенной службой, с "отключенной через групповые политики" (гы-гы-гы!) и с отключенной тем способом, на котором настаиваю я - убедись, что падения пропускной способности ниже погрешности измерений ты не увидишь.
В общем, не читай глупых статей в FAQ по WinXP. По крайней мере по этому вопросу они ошибаются ;-)))))

Вот трезвый взгляд на вещи: http://timhome.hut.ru/xp/xp_03.htm#24
<miscellaneous>
напомните укуренному 09.01.05 04:37  
Автор: hex.sex <Computer-Hitler> Статус: Elderman
<"чистая" ссылка>
как убить QoS в ХР
В свойствах соединения удали эту службу. 09.01.05 10:05  
Автор: J'JF <Dmytro Volhushyn> Статус: Elderman
<"чистая" ссылка>
Ну и сервис можешь остановить, если QoS вообще не нужен.
Этого будет достаточно.
Цитата :"Причём, даже если удалить службу QoS Packet Scheduler из Properties соединения, этот канал не освобождается." 09.01.05 17:42  
Автор: hex.sex <Computer-Hitler> Статус: Elderman
<"чистая" ссылка>
> Ну и сервис можешь остановить, если QoS вообще не нужен.
> Этого будет достаточно.
Освободить канал, или просто настроить QoS, можно здесь. Запускаем апплет Group Policy (gpedit.msc). В Group Policy находим Localcomputer policy и нажимаем на Administrative templates. Выбираем пункт Network -- QoS Packet Sheduler. Включаем Limit reservable bandwidth. Теперь cнижаем Bandwidth limit 20% до 0, или просто отключаем его. При желании здесь же можно настроить и другие параметры QoS. Для активации произведённых изменений остаётся только перезагрузиться.
Это весьма распространенное заблуждение 09.01.05 19:22  
Автор: J'JF <Dmytro Volhushyn> Статус: Elderman
<"чистая" ссылка>
Мог бы я, конечно, отослать к KB316666, KB318602 и остальным сопутствующим материалам (касающимся QoS, RSVP и GQoS API). Но не буду. Попробую объяснить, как я это все понял.
Суть технологии резервирования каналов заключается в том, что приложение, которое использует канал, должно зарезервировать за собой полосу для передачи по ней служебной информации QoS. Какие приложения это делают? Да немногие по умолчанию. Например, это NetMeeting.
Цитата из KB316666:
"By default, programs can reserve up to an aggregate bandwidth of 20 percent of the underlying link speed on each interface..."
Это означает, что по умолчанию программа не может отхватить кусок канала больше 20%. Для того, чтобы дать ей больше или меньше и нужно лезть в групповые политики. Вот именно оттуда и вылазят пресловутые 20% ;-)
На самом деле, приложение не сможет зарезервировать ни одного процента канала, если отключена служба QoS.

Ну и самое примечательное в этой статье:
"Correction of some incorrect claims about Windows XP QoS support
There have been claims in various published technical articles and newsgroup postings that Windows XP always reserves 20 percent of the available bandwidth for QoS. These claims are incorrect. The information in the "Clarification about QoS in end computers that are Running Windows XP" section correctly describes the behavior of Windows XP systems."
Грубо говоря, здесь написано то, что весь этот треп (в частности тот, который ты процитировал) - всего лишь треп и не имеет ничего общего с действительностью.

Вернемся к KB:
"... If the program that reserved the bandwidth is not sending sufficient data to use it, the unused part of the reserved bandwidth is available for other data flows on the same host."
Что означает, что даже если мы оставим службу QoS включенной в свойствах интерфейса, и если даже какое-то приложение запросит резервирование канала, то этот канал будет ему отдан только в том случае, если эта программа будет реально что-то по нему слать. В противном случае, незанятый кусок полосы будет отдаваться под другие нужды, в частности под поток "обычных" данных.
А вот на вопрос, в каком случае программа будет что-то слать по зарезервированному каналу, попытайся ответить сам. ;-)

Прежде чем продолжать спорить - проверь. Сделать это просто - протестируй скорость передачи данных через сетевой интерфейс со включенной службой, с "отключенной через групповые политики" (гы-гы-гы!) и с отключенной тем способом, на котором настаиваю я - убедись, что падения пропускной способности ниже погрешности измерений ты не увидишь.
В общем, не читай глупых статей в FAQ по WinXP. По крайней мере по этому вопросу они ошибаются ;-)))))

Вот трезвый взгляд на вещи: http://timhome.hut.ru/xp/xp_03.htm#24
100% в точку. Я тоже всегда хохотал над QoS-бредом ;-) 10.01.05 08:34  
Автор: HandleX <Александр Майборода> Статус: The Elderman
<"чистая" ссылка>
1






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2020 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach