Ребят, прошу потестировать файловую систему

← →
DevilDevil © (2013-03-19 18:20) [0]

Продолжаю реализовывать оптимальный доступ к диску (для задач потокового чтения/записи)

В одной из предыдущих веток выяснилось, что я предусмотрел не самые оптимальные параметры
В связи с этим я модифицировал тест файловой системы: http://zalil.ru/34362059
Проблема в том, что теперь тестируемых комбинаций значительно больше (суммарно около 3000 итераций)

Напомню, в архиве есть тест на чтение "read_test.exe" и тест на запись "write_test.exe"
Каждый из которых пишет лог: "read_test.log" и "write_test.log" соответственно
В лог пишется операционная система, размер сектора/кластера, ход событий, а так же главное - "ТОП 20"

Да, результаты конечно скачат (это же многозадачная Windows)
Поэтому каждая из комбинаций размер буфера/опций повторяется по 4 раза
Чтобы в итоге посмотреть на ТОП и сделать выводы

По моим предположениям, тесты будут выполняться пару часов (много комбинаций)
Поэтому сейчас в архиве есть файл "RUN_AND_SHUTDOWN.exe"
Закройте перед сном все лишние программы и запустите "RUN_AND_SHUTDOWN.exe"
Она выполнит оба теста, потом выключит компьютер

Логи отсылайте мне на softforyou[ГАВ-ГАВ].inbox.ru
Или выкладывайте здесь
В любом случае интересует ОС, параметры винтчестера, ТОП 20 и конечно направление: read/write

Спасибо за участие!

← →
antonn © (2013-03-19 18:54) [1]

если запись будет с таким же кол-вом что и чтение, то запись (конкретно у меня) займет около 40-60 минут...

← →
Sapersky (2013-03-19 19:53) [2]

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

Вообще, дисковые операции - фигня. Программирование игроприставок - вот где настоящий рай для маньяка-оптимизатора!
http://ironpeter.livejournal.com/6471.html
Железо там потенциально очень мощное, но и очень капризное - вроде Пня-4, только ещё хуже. Требуется ювелирное выпиливание лобзиком - всё как ты любишь :)

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

← →
DevilDevil © (2013-03-19 20:18) [3]

> antonn © (19.03.13 18:54) [1]

эт да

> Sapersky (19.03.13 19:53) [2]

всё-таки не всё предусмотрел
на другом форуме мерились письками - там у чувака был тест, который на одних машинах работал в два раза медленней моего, а ну других - в два раза быстрее

← →
Sapersky (2013-03-19 20:47) [4]

Условия точно равные - сброс кэшей, зависимость от CPU? У тебя в последнем тесте чтение в CPU упиралось, насколько помню.
Машина на кот. тормозит - не XP? В CachedBuffers для XP какие-то махинации с NO_BUFFERING...

← →
DevilDevil © (2013-03-19 21:08) [5]

да всё вроде по честному было

← →
antonn © (2013-03-19 22:09) [6]

← →
DevilDevil © (2013-03-19 22:33) [7]

> antonn © (19.03.13 22:09) [6]

спасиб!
а какая операционка ?

ты бы запустил перед сном "RUN_AND_SHUTDOWN.exe"
комп сам выключится когда всё отработает

← →
Rouse_ © (2013-03-19 22:35) [8]

← →
antonn © (2013-03-19 22:42) [9]

> а какая операционка ?
>
> ты бы запустил перед сном "RUN_AND_SHUTDOWN.exe"
> комп сам выключится когда всё отработает

win server 2008 r2, и поэтому особо ждать не мог - для работы была нужна :)
в ночь запускать не хочется, все равно там значения больше 3000ms на запись были, уменьшил бы кол-во проходов, в чтении на ~700 остановилось, а запись за 1000 уже зашла, я обрубил ее (по завершению мог бы тоже сделать сброс текущих результатов)

← →
DevilDevil © (2013-03-19 23:45) [10]

> Rouse_ © (19.03.13 22:35) [8]
> Я так понимаю это то о чем и шла речь у нас?

угу
опять 256кб :)

> ЗЫ пока не тестировал - завтра на рабочем вечером запущу
> без шатдауна (чейто сегодня не коннектится, упал тимвьюв
> видать)

отлично!

> запись за 1000 уже зашла, я обрубил ее (по завершению мог
> бы тоже сделать сброс текущих результатов)

мне кажется там до 3х тысяч должно дойти

← →
Sapersky (2013-03-20 03:47) [11]

← →
DevilDevil © (2013-03-20 09:46) [12]

← →
DevilDevil © (2013-03-20 09:51) [13]

КСТАТИ Я ПЕРЕКОМПИЛИЛ, КАЧАЙТЕ http://zalil.ru/34363890
чтобы выдача была по 50 позиций и ещё одна маленькая вещь

← →
brother © (2013-03-20 09:59) [14]

опять час ждать? ну, нафиг! делай время тестирования приемлимое!

← →
DevilDevil © (2013-03-20 10:30) [15]

> brother © (20.03.13 09:59) [14]

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

← →
DevilDevil © (2013-03-20 16:39) [16]

← →
Rouse_ © (2013-03-20 17:07) [17]

← →
DevilDevil © (2013-03-20 17:10) [18]

← →
DevilDevil © (2013-03-20 17:13) [19]

> Rouse_ © (20.03.13 17:07) [17]

выводите пожалуйста информацию об ОС и диске

> Хм, плывет:

ну так это же операционная система Windows с многопоточностью )
поэтому и сделано сразу 4 раза
чтобы лучше видеть общую картину

> если не просадка на третьей итерации 256 Default лидировал бы.

а здесь вообще не средний показатель берётся
в "рейтинге" участвуют все позиции

← →
DevilDevil © (2013-03-20 18:03) [20]

[b]качать здесь[/b]: http://zalil.ru/34365391
должно работать быстрее раз в 6

← →
Inovet © (2013-03-20 19:23) [21]

> [17] Rouse_ © (20.03.13 17:07)
> Хм, плывет:

Да это вообще неправильная постановка эксперимента. Я уже в прошлых ветках размышлял на этут тему, но автор сказал, что ему пофиг, что я там говорю.

← →
DevilDevil © (2013-03-20 20:10) [22]

почему пофиг ?

очевидно размер буфера и опции влияют на производительность взаимодействия с диском
каким ещё образом выявить закономерности ?

ради бога - готов выслушать

← →
Inovet © (2013-03-20 20:43) [23]

> [22] DevilDevil © (20.03.13 20:10)

Надо постараться свести к минимуму влияющие на измерение, но не относящиеся у цели эксперимента факторы. Как то, влияние других процессов и самой ОС, заполненость диска. Второе можно легко сделать с первым сложнее, и полностью исключить вряд ли можно, но вот снизить до приемлемой погрешности, наверное, возможно, скажем в безопасном режиме или лучше в спец конфигурации. Но кто же массово станет это делать.

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

← →
brother © (2013-03-20 20:48) [24]

кстати, дефрагментированность ФС учитывается? иначе согласен с [23]!

← →
Rouse_ © (2013-03-20 20:49) [25]

Кстати верное замечание - попробуй SetThreadPriority + THREAD_PRIORITY_TIME_CRITICAL
Далее нужно не забывать что хардешники бывают разные, не зря для их тестирования пишут программы наподобие этой: http://sourceforge.jp/projects/crystaldiskmark/downloads/46482/CrystalDiskMark3_0_2dSrc.zip/

Попробуй сначала замерить реальную производительность диска, таким образом получив некий коэффициэнт, который можно уже будет применить к выдаваемым тобой результатам.

← →
Rouse_ © (2013-03-20 20:49) [26]

> brother © (20.03.13 20:48) [24]
> кстати, дефрагментированность ФС учитывается? иначе согласен
> с [23]!

Если ипользуется семерка, этот момент можно не учитывать, она в фоне дефраг делает и поэтому практически 90 процентов времени диск в нормальном состоянии.

← →
Дмитрий С © (2013-03-20 20:52) [27]

Я надеюсь она SSD не дефрагментирует.

← →
Inovet © (2013-03-20 20:53) [28]

> [26] Rouse_ © (20.03.13 20:49)
> она в фоне дефраг делает

Вот как раз хотел сказать и об этом. Мы же не знаем как фаза Луны влияет на измерения, может ОС в во время измерений захотела вдруг дефрагментацию устрить.

>
> Дмитрий С © (20.03.13 20:52) [27]
> Я надеюсь она SSD не дефрагментирует.

Зависит от настроек: http://support.microsoft.com/kb/2727880

ну, например, у автора XP ... это я так...
зы. для начала тестирования и сбора информации нужны лабораторные условия, похожие у всех пациентов, либо, некий коэффициент, уравновешивающий пациентов.

имхо, замерять скорости работы винта под виндой и при этом требовать наиболее точных результатов - в корне не верно!
зы. опять же... есть своп... задумался...

> [30] brother © (20.03.13 21:01)
> нужны лабораторные условия, похожие у всех пациентов

Это называется повторяемость. Сейчас её нет. Даже в процессе одного теста разброс вон какой. А результат должен повторяться в пределах известной погрешности, о вычислении которой автор вообще не подумал. Раз не повторяется, значит методологическая ошибка сидит в самой постановке.

> brother © (20.03.13 21:01) [30]
> ну, например, у автора XP ... это я так...
> зы. для начала тестирования и сбора информации нужны лабораторные
> условия, похожие у всех пациентов, либо, некий коэффициент,
> уравновешивающий пациентов.

Ну так я об чем и говорю.
Впрочем опять же повторюсь на моих тестах (расчет CRC32 папки с файлами) 256 Кб дал наиболее производительный результат. Использовался обычный TFileStream

> [31] brother © (20.03.13 21:03)
> имхо, замерять скорости работы винта под виндой и при этом
> требовать наиболее точных результатов - в корне не верно!

Вот и я в прошлой ветке шутил, что надо без Винды мерять. Кстати, может, теоретически и возможно кусок ядра выдрать и на нём запускать этот тест.

> кусок ядра

да даже дело не в этом, а в занятости самого винта! нужно наиболее гарантировать что головки работают над нашей областью тестовых данных и не занимаются другими делами)

> 256 Кб дал наиболее производительный результат

мы говорим о среднем значении для всех пациентов (с небольшими отклонениями) и не выжимаем последние капли производительности!

автору: не обижайся, но мое имхо - ты страдаешь фигней, ибо ... ну понятно?

либо гарантируй реализацию условий в [30]

Ещё вот что интересно. Будет ли Виндоус писать физически в одно и то же место диска НТФС новый экземпляр файла на н+1 прогоне, после удаления предыдущего файла н-ного прогона, при условии, естественно, что туда никто не написал уже. Это должно быть документировано по идее.

> Будет ли Виндоус писать физически в одно и то же место диска
> НТФС

вопрос не к винде, а именно к ФС! и далеко не факт, что будет.

Ребят, прошу потестировать файловую систему Найти похожие ветки