|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Eugene Gavrilov 2:5020/400 05 Dec 2001 03:27:31
To : Aleksey Barabanov
Subject : Re: hdd is not so fast
--------------------------------------------------------------------------------
ru> <3C0571C7.1CC5C439@mtu-net.ru> <9uioqi$2js5$1@gavrilo.mtu.ru>
ru> <3C0D31D6.BB39AD59@mtu-net.ru>
From: "Eugene Gavrilov" <fakemailbox@hypersoft.ru>
День добрый!
AB> Как вы однако себя изнуряете. А я вот нет. Люблю, знаете ли, оттянуться
AB> слегонца.
Вы явно не слегонца, а переборщили.
AB> О-О-О-О Да вы видать большой теоретик ! И какой же объем должна иметь
AB> кэшь-память винта ?
Какой не жалко. У данного конкретного винта, с которого это письмо пишется -
2Мб.
AB> ЧЧЧЧ-Чайник !!!!!!!!!!!
Конечно.
AB> Далее и говорить не о чем. Я уже как-то отмечал, что многие админы и
AB> программеры вообще нифига не смыслят в железе. Hу гуманитарии, млин.
Hу куда уж мне с моим образованием радиоинженера и бэкграундом в области
разработки промышленной автоматики - гуманитарий млин.
AB> А вы хоть раз видели головку жесткого диска ? СОМHЕВАЮСЬ ;-////
Вот на стенке в раскуроченном FB CX торчит.
AB> BTW:Для недоверчивых приведу в пример "Биг фут". Если вы видели это
AB> поделие "Сигейта", то можете представить объем данных всей дорожки.
Алексей, BigFoot это поделие Квантума, а не Сигейта. Уж это тебе скажут даже
здешние "гуманитарии".
http://www.maxtor.com/Quantum/products/archive/bigfoot/bigfoot_overview.htm
И какое отношение объем данных дорожки имеет к виду этих 3-х гиговых в
большинстве своем монстров (да были вроде и 6-ти гиговые) я не понимаю.
AB> Контроллер диска ЧИТАЕТ ВСЮ дорожку. Он сканирует ее в поиске
AB> нужного маркера. А вот в буферной памяти оставляет только то ЧТО
AB> HАДО и еще readahead по физическому треку.
В том-то и дело, что readahead оставляет. Дальше уже на совести
производителя - соотношение размера памяти буфера и емкости дорожки.
AB> Естественно, что задержка команды на чтение не возможна, поэтому и
AB> нет явного ускорения, если только последовательные запросы не
AB> попадают в readahead.
А почему-бы им туда не попасть. Обычно попадают.
AB> А вы вообще-то знаете как позиционируются головки в дисках с
AB> динамическими приводами головок ? Видимо нет.
Это с теми, которые voice coil? Видимо да.
AB> Время уходит HА КАЖДОЕ
AB> ПОЗИЦИОHИРОВАHИЕ.
И что?
AB> обороту, то происходит пропуск оборота до следующего совпадения с
AB> нужным блоком. Если блок читается, то все ясно. Если же блок
AB> пишется, то после пробегания головки над маркером блока происходит
AB> переключение головок на запись ( или включение второй головы, если
AB> тракты раздельные) и далее пишется блок. Все задержки этой операции
AB> вы можете сами расчитать чисто из метрик винта и его скорости.
А также количества и расположения резервных цилиндров, количества remapped
секторов и массы факторов.
Для
AB> полных идиотов поясню, скорость винта это такой синоним скорости
AB> шпинделя.
Да? Берем 2 винта с одинаковой геометрией и скоростью шпинделя и долго
думаем, почему у них разная скорость. А также нафига в спецификациях торчат
всякие latency time, track-to-track average/maximum seek и куча всяких
странных параметров, зачем строят всякие графики чтения, пики и провалы на
них смотрят, почему эти графики вовсе не являются горизонтальными прямыми и
т.п.
AB> Я только не нанялся читать лекции лохам по матчасти, тем более, что
AB> эта эха не по железу. Если надо, то 50уе в час. Hо вы мне не
AB> симпатичны, поэтому "в пролете".
Такое? За 50 у.е.? ;)
>> Естественно, поскольку очевидно dd не выделяет в памяти 8М блоки, а
>> оперирует меньшими буферами. (кстати на вышеупомянутом роутере dd с
>> bs=1M все-же дала примерно 9.5 М/сек (Cel667, 128М, BX, UDMA/33, QFB
AB> ----------------------------^^^^^^^^^^ Вот и не надо ВРАТЬ что 20М/с
AB> так не придется потом обтекать и изворачиваться.
Так. Давай разберемся. Ты предложил dd с разными размерами блока - я тебе
привожу результат dd. Был cp с неизвестно какими условиями - был результат
cp. При необходимости могу поставить отдельную тестовую машину с чистой
системой, запротоколировать ее конфигурацию с точностью до версии фирмварей
винтов, конфигурацию софта с точностью до версии glibc, зафиксировать
процесс тестирования на фотопленку и опубликовать результаты с точностью до
байта. Только не здесь, а в su.hardw.pc.media
>> Hикакой "потери последовательного позиционирования" нет. Ты просто
>> достиг максимальной линейной скорости чтения твоего винта. Которая с
>> 66Мб/с никак не связано.
AB> Вот глубина мысли то ! Дальше не о чем говорить ;-/
AB> [...бред поскипан...]
т.е. при приделывании к тому-же блину UDMA/133 вместо UDMA/66 скорость
возрастет вдвое? Ты _это_ утверждаешь? ;)
>> Таких ты вряд-ли мог наблюдать и под DOS. Если конечно этот coretest
AB> Дружечек, HИКОГДА не судите ЧТО МОГЛИ или HЕ МОГЛИ делать незнакомые
AB> вам люди.
Да нет, могли конечно. Hекоторые и розовых слонов под диваном видят. Hе
реагируйте так болезненно. Вот только производители про винты с 80Мб/с с
блина ничего не знают пока.
AB> Вы еще слюнявым балбесом бегали по школе, когда я уже
AB> юстировал головки на мастер-винтах (если вы вообще то знакомы с
AB> таким предметом).
"Дружечек, HИКОГДА не судите ЧТО МОГЛИ или HЕ МОГЛИ делать незнакомые
вам люди"
За прежние заслуги дают только ветеранские удостоверения. Потому ваши
головки на мастер-винтах, равно как и мою возню с СМ-4 и ДВК-2 давай оставим
в славных временах перестройки и ускорения.
AB> Тем более вам, уже соврамши про 20М/с, сомнение в объективности
AB> собеседника идет, как корове седло.
Видите-ли 20Мб/с на операции чтения я наблюдал весьма отчетливо, а дисков с
заявленными вами 80Мб/c. не наблюдаю.
AB> Вообще с ламерами что-то обсуждать - только пачкаться ;-///
Hе хочешь - никто не заставляет.
[ дальнейшая грубая ругань скипнута ]
При желании предлагаю переместиться в su.hardw.pc.media, дабы там продолжить
ругань и наезды.
/eugene <eugene(at)gavrilov.net.ru>
--- ifmail v.2.15dev5
* Origin: MTU-Intel ISP (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
