Я заметил что многие обсуждают NCQ. Обращаю внимание на это.

NCQ это хорошо когда оно есть и можно его обсудить. Но стартовое сообщение не об этом.

Когда оптимизировано на всех уровнях это хорошо. Хочется чтобы так оно и было.

Поэтому предложения:
1. создать про NCQ отдельную ветку, если нужно
2. в это ветке говорить только об операционной системе: почему она так тормозит, кто виноват, как это исправить, сколько это стоит, и когда это будет исправлено.

Т.е. философствовать т.к. врятли это когда либо исправят. А хочется чтобы исправили, поэтому и философствуем

19.09.2010 23:52, Здравствуйте, Feonyf:
> Т.е. философствовать т.к. врятли это когда либо исправят. А хочется
> чтобы исправили, поэтому и философствуем

Блин, ну неисправимо это... Это физическое свойство жесткого диска — для
перевода головок требуется время, причем довольно длительное. NCQ не
спасает совершенно, он даст прирост начиная с 5-6 потоков. Именно из-за
этой особенности сейчас идет вторая волна его внедрения на SATA винтах,
в сказевых винтах TCQ давно и успешно трудится. Но покупать на десктоп
их один черт не имеет смысла — прирост будет ощутим только на серверах.

Здравствуйте, Ромашка, Вы писали:

Р>Блин, ну неисправимо это... Это физическое свойство жесткого диска — для
Р>перевода головок требуется время, (...)

Неверю. Вот рассуждение:

Пошлём читать один файл. Допустим скорость в результате этого опыта 10 МБ/с. Характеристика HDD: скорость переключения на другой файл 20 мс (произвольный доступ головкой).
Теперь, пошлём читать два файла сразу.
В худшем случае будет: 4 килобайта считали переключились на второй файл, 4 килобайта считали переключились на первый и.т.д.
В лучшем случае будет: тоже самое только считываем по 10 мегабайт.

Понятно что во втором случае скорость произвольного доступа влияет на скорость гораздо меньше и ей (если она 20 мс) можно пренебречь.

Рассуждение верно ?

Еще случай:
Есть два приложения которые копируют файлы, и которые хотят сообщить операционной системе что для них важна скорость чтения а не отзывчивость.
Риторический вопрос: что будет если они пойдут одновременно читать разные большые файлы с CD-ROM ? (наверно тоже самое что в рассуждении выше, только ситуация ввиду долгого произвольного доступа будет в 10 раз хуже).

Здравствуйте, andrey82, Вы писали:

A>Здравствуйте, Feonyf, Вы писали:

F>>вопросы:
F>>1. это мне кажется или оно таки есть ?

A>Да, так и есть. Время позиционирования головки на нужную дорожку ~единиц миллисекунд на современных винтах. Ели переключаться с одной дисковой задачи на другую несколько раз в секунду, то записать мало чего можно успеть.

F>>2. если оно так и есть, то почему программисты до сих пор не сделали грамотное разделение ресурсов диска ?

A>Кое-что сделали...например
A>NCQ

F>>Это применимо не только к виндусным системам.

Непонятно какие на диске дорожки и головки. Там же контроллер стоит. Он показывает что диск имеет 256 головок. А на самом деле их две, может больше. И как он интерпретирует команду записи непонятно. Может в буфер пишет, а потом вываливает на диск большим куском.

Здравствуйте, shks57, Вы писали:

S>Непонятно какие на диске дорожки и головки. Там же контроллер стоит. Он показывает что диск имеет 256 головок. А на самом деле их две, может больше. И как он интерпретирует команду записи непонятно. Может в буфер пишет, а потом вываливает на диск большим куском.

Что значит "какие головки" обычные, физические, для чтения и записи... обычно от 2 до 8 штук. Независимо от алгоритма интерпретации данные на диск все равно в итоге потребуется сбрасывать, т.к. буфер невелик (16, 32, изредка 64Мб, при этом скорость линейной записи на современных винтах что-то около 50Мб/c)

Здравствуйте, SE, Вы писали:

T>>Теоретически, в таких случаях ось могла бы вести себя поумнее, но M$ не до того

SE>Откуда же оси знать, какой из файлов важнее. Что ни сделай пользователи останутся недовольны.

Как это откуда? Ей об этом должны сообщить прикладные программы через соответствующие API. В висте, кстати, появилась кое-какая поддержка для этого.