Полигон-2

нормально виктория 4,47 работает на всех виндах от ХР до 10, 32 или 64 не важно
только на винде 7 и выше надо запускать файл в режиме администратора и будет все ок

CodeMaster написал:

[q]

тест поверхности показывает, что в определённых местах есть провалы. С чем они могут быть связаны?

[/q]

Могут быть места с ухудшенной читаемостью, где она вытягивается за счёт ECC. Может компьютер не справляться - при прямом доступе к портам тестирование идёт в режиме PIO, это сильно грузит процессор. Могут параллельно запущенные процессы сбивать таймер.

CodeMaster написал:

[q]

Почему данные тестирования могут так плавать день ото дня?

[/q]

Ну, вообще говоря, плотность записи современных HDD такова, что они даже на громкие звуки реагируют, не говоря уже о положении в пространстве, вибрации, атмосферном давлении, температуре и др. А может, причина чисто софтовая, в самом стенде.

KALDYH написал:

[q]

Могут быть места с ухудшенной читаемостью, где она вытягивается за счёт ECC.

[/q]

Это очень интересная информация. А не встречалась кому блок-схема как firmware винта проводит отбор кантидатов на ремап, их тестирование и собственно ремап (он по возможности происходит с сохранением информации или всегда с потерей)?


KALDYH написал:

[q]

Может компьютер не справляться - при прямом доступе к портам тестирование идёт в режиме PIO, это сильно грузит процессор.

[/q]

Не, там мощные системы, загрузка проца 1%. Я вот как-то тестил винты на буке PIII-500 через переходник в USB 1.1, так вот там видно, что скорость режется на уровне 30 Мбит/с (у HDDScan и того меньше) и загрузка проца 50-90%


KALDYH написал:

[q]

Могут параллельно запущенные процессы сбивать таймер.

[/q]

Тут, кстати, интересный вопрос (вкупе с предыдущим про проц). По идее, тест Verify в HDDScan и Victoria for Win и Линейное чтение (которое раньше и в DOS назвалось верификацией) в Victoria 3.5 проводится firmware винта без участия интерфейса и компа и комп здесь выступает как терминал который выводит собираемую контролером диска информации о скорости доступа. Всё бы вроде так и видно что тесты Read и PIO - чтение идут значительно медленнее, но... тот самый бук PIII-500. Неужели его не хватает для минимальных требований прог тестирования и он не справляется даже с функцией терминала?


KALDYH написал:

[q]

Ну, вообще говоря, плотность записи современных HDD такова, что они даже на громкие звуки реагируют

[/q]

Это да, но это выглядит как чуть более медленный единичный блок секторов (я же не на вибростенде их проверяю ;-) и на график никак не влияет.


KALDYH написал:

[q]

не говоря уже о положении в пространстве, вибрации,

[/q]

Оно статично.


KALDYH написал:

[q]

атмосферном давлении, температуре и др.

[/q]

Это влияло бы на всё тестирование поверхности.


KALDYH написал:

[q]

А может, причина чисто софтовая, в самом стенде.

[/q]

Может, но вряд ли этот "софтовый" затык может занять 5-10% объёма диска. К данному моменту у меня есть графики тестирования около 20-ти разных дисков и на некоторых я перепроверял подозрительные "впадины" и "пики" и они либо повторяются, либо несколько сглаживаются (в основном провалы) если по этому месту пройтись записью. В данном случае этого не было, да и опять же объём совсем другой это не единичный провал.


i8088 написал:

[q]

В дополнение, еще может быть влияние температуры, чтение может улучшаться/ухудшться при прогреве/охлаждении.
PS. Это явление очень сильно заметно с MFM, у моделей с разомкнутой петлей позиционирования.

[/q]

Температура у них примерно стабильна, да и тестируются диски более 80 гигов, т.ч. MFM тут не причём.

CodeMaster написал:

[q]

тот самый бук PIII-500. Неужели его не хватает для минимальных требований прог тестирования и он не справляется даже с функцией терминала?

[/q]

Судя по графику загрузки процессора - не хватает. Возможно, просто проги так наговнокодили, возможно, это объективно недостижимо. Скорее всего, там для измерения коротких промежутков времени используются программные задержки вместо системных таймеров. В качестве эксперимента, попробуйте во время верификации параллельно позапускать другие ресурсоёмкие процессы (браузер отлично подойдёт). Как вариант, задать тестовой программе приоритет Realtime - мне очень помогало при поиске медленных секторов с помощью WDMarvel.

CodeMaster написал:

[q]

Это влияло бы на всё тестирование поверхности.

[/q]

Диск имеет зонное распределение. В начале каждой зоны продольная плотность чуть ниже, в конце - чуть выше. В конце зоны канал чтения может и не вытягивать - будет видно как не просто ступенька, а ступенька с "трещинкой". К тому же адаптивное зонное распределение обычно задаёт границы зон, но не число секторов на них, и при не идеальном качестве канала чтения остальные зоны можно сдвинуть вперёд, чтобы уменьшить продольную плотность и уложиться в требования по качеству чтения, а первая зона всегда начинается от начала диска, и её не сдвинешь. Если качество пары головка/пластина чуть ниже проектного, все зоны сдвинутся ближе к началу (краю), а на нулевой появятся провалы чтения. Наблюдал такое не раз на многих винтах, как с заводской разметкой, так и после селфскана.

CodeMaster написал:

[q]

А не встречалась кому блок-схема как firmware винта проводит отбор кантидатов на ремап, их тестирование и собственно ремап (он по возможности происходит с сохранением информации или всегда с потерей)?

[/q]

У меня - только собственные логические измышления по результатам экспериментов и наблюдений за логами терминала. Излагать?
По возможности происходит всегда с сохранением информации.

i8088 написал:

[q]

У той же Seagate есть баг, встречается у некоторых семейств

[/q]

Встречается, похоже, у многих семейств.

Так вот, по алгоритму ремапа. Во-первых, при обращении к сектору проверяется количество попыток повторного чтения и уровней ECC коррекции, и если они выше определённого лимита (пользователю он не виден, но он весьма и весьма высок - будет пытаться не трогать до последнего) - сектор заносится в список кандидатов. При следующей записи в него будет произведён ремап.
Во-вторых, винт имеет онлайн-самотестирование SMART (то самое пощёлкивание и жужжание в простое). При этом сканируются отдельные участки поверхности, если найдены бэды - также заносятся в relo-list (терминология WD) "Онлайн" одначает, что BUSY не ставится, и при любом обращении по интерфейсу тест прерывается.
В-третьих, в ходе того же тестирования SMART винт пробует снова считать проблемный сектор, и если он наконец считался - ремап будет произведён автономно, незаметно для пользователя.
Во всех случаях данные не теряются. Если же битый сектор не читается никак, он так и будет оставаться битым до тех пор, пока пользователь не перезапишет его явно.

i8088 написал:

[q]

Те в результате в основном уменьшится количество цилиндров в первой
зоне, а остальные будут сдвинуты вперед?

[/q]

Ага. Не, ну вроде у каких-то более новых появляется адаптивное число секторов в зонах, но это произошло не сразу. Надо на примере сигейтов в таблицах глянуть.