информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Сетевые кракеры и правда о деле ЛевинаСтрашный баг в WindowsSpanning Tree Protocol: недокументированное применение
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Microsoft обещает радикально усилить... 
 Ядро Linux избавляется от российских... 
 20 лет Ubuntu 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / miscellaneous
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Это весьма распространенное заблуждение 09.01.05 19:22  Число просмотров: 1588
Автор: 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> Поиск 






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


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 1 s   Design: Vadim Derkach