Свежие комментарии
| Title | Comment |
|---|---|
| и ? попытка провокационный |
и ? попытка провокационный вброса : в конечном итоге важно не то что FRV/RD покажет на тему клиппинга (это важно при осваивании камеры), а как искомый конвертер у вас отработает в конечный результат |
| Ну вот, например, снимали с |
Ну вот, например, снимали с брекетингом (как многие делают, флешки дешевые). |
| а я в последнее время просто |
а я в последнее время просто перешел, о ужас, на просто bridge... экспозиция благо больше и давно не проблема вообще и с dSLM фокус просто не промахивается /нет, уровня графиков дедушки Кассона не предлагать/ (если знаешь что ожидать)... зато preview ну почти как в конвертере, включая профили камеры итд... вот сменю камеру обратно стряхну пыль с FRV & RD. |
| А когда может понадобиться |
А когда может понадобиться эта информация? При съемке - в большинстве случаев нет возможности посмотреть RAW. Про обработке - ну разве что есть огромная куча практически идентичных по сюжету, но разных по экспозиции снимков и из них надо быстро выбрать 1-2 на обработку. |
| Ну вот да, я буду тестировать |
Ну вот да, я буду тестировать именно что "чтение с windows клиента", но там же еще Это не на полчаса развлечение, а значит ближе к сентябрю. На гигабите то у меня проблем не было (последние пару лет что я был на гигабите т.е. 2010-12), насытить его даже с тройки "архивных" медленных дисков получалось. |
| dd для создания файла |
dd для создания файла локально. По сети только чтение с windows клиента. |
| dd по сети или локально? |
dd по сети или локально? Локально на другой машине (10.3, 6 дисков, raidz1) - чем больше блок (при БОЛЬШОМ блоке у dd) тем толще партизаны. |
| Всё-таки попробуй, что я |
Всё-таки попробуй, что я написал выше и ты удивишься результату. Я не про паттерны, а про согласование размеров блоков (recordsize) при передачи из одной "среды" в другую. А когда станут понятны механизмы взаимодействия "сред" и что на что влияет, тогда подобрать параметры под нужные паттерны станет делом техники. PS. Заинтригую. Решил ещё раз проверить, что написал. У меня правда на тестовой машинке FreeBSD 10.1, поэтому сравнивал recordsize 64k и 128к(максимальный размер). primarycache=metadata. Дальше dd ... Выиграл 64k. Если сравнить 64k с 1M, то разрыв будет ещё больше (боюсь даже предположить :-)). Конечно primarycache=all всё нивелирует, но заставляет задуматься :-). |
| >> Чтение без L2Arc - |
>> Чтение без L2Arc - примерно на 100Mb/s медленнее в среднем и близко не такое ровное. В одном случае 500MB в другом 200-280MB. Что-то здесь не пляшет :-). Решил проверить сам. Правда у меня нет 10 гигабитной сети :-). Нашел подходящий файл на шаре (в моём случае 9,2GB, можно взять поменьше, нужно только чтобы он полностью влез в ARC). Начал читать его локально dd. У меня первое чтение 162MB/s. Четвертое чтение 8409MB/s. Проверил чтение идёт только из памяти. На стороне windows клиента прочитал этот файл. Проверил чтение было только из RAM, то есть претензий к источнику нет. Скорость 112MB/s :-). Если есть 10 гигабит и быстрый ssd на стороне windows, то можно попробовать оценить и 10 гигабит. |
| К этому прилагается еще ж |
К этому прилагается еще ж паттерн доступа. В интересном мне случае Веса непонятны, оверхед L2ARC понятен (то ли 200, то ли 400 байт на record), тестовых наборов с разным recordsize сделать нетрудно, остается "достать линейку", потратить три дня (вряд-ли меньше) и померять. |
| >> Ну я понимаю какой паттерн |
>> Ну я понимаю какой паттерн мне интересен и что мерять, дальше можно уже тестовый стенд делать Я немного не об этом. Файловая система читает допустим блоками в 1MB. Самба запрашивает блоки по 64K. Допустим в ARC кэшируется всё ... и понеслась :-). Для примера: разреши в ARC кэшировать только метаданные. Затем прочитай по самбе большой файл с recordsize 1MB. Затем такой же по размеру файл с recordsize 64kB. Сравни :-). iostat это немного не то :-). Но если оттолкнуться от 400MB/s записи в кэш и 500-600MB/s чтения из пула hdd, то фраза "как оно постепенно (довольно медленно, что обидно," становится как бы понятной, даже без учёта всех остальных настроек :-). |
| В два процесса - 990 и те же |
В два процесса - 990 и те же 200-280. |
| Нет сомнений в самбе. md5deep |
Нет сомнений в самбе. md5deep (первое что попалось под руку что много читает) в один процесс читает с ssd-шки 500+ (и упирается в CPU), а с сети - 200-280. |
| Ну я понимаю какой паттерн |
Ну я понимаю какой паттерн мне интересен и что мерять, дальше можно уже тестовый стенд делать На страйп пишется - ну вот 400Mb/s видел по zpool iostat. Разрешено 900. |
| Ну тогда можно разочек и на |
Ну тогда можно разочек и на ssd, что бы снять сомнения с самбы :-). |
| >> Планка записи у меня |
>> Планка записи у меня поднята до небес Я имел ввиду скорость записи на заполненные ssd, входящие в кэш. >> буду еще играться с recordsize Recordsize - это наверено вообще для любой поставленной задачи "главная" тема. И наверно довольно сложная :-). |
| Ну вот я и проверил (файл был |
Ну вот я и проверил (файл был на 80, но читал я оттуда 10), см ниже. Планка записи у меня поднята до небес, буду еще играться с recordsize (похоже что 1M именно для L2ARC не сильно оптимально), но наверное уже ближе к сентябрю, дела все забросил с этим NAS. |
| >> И попадаем еще на |
>> И попадаем еще на дополнительный emulation layer. Ну так легко же проверить :-). Загнать небольшой файл (6-8GB) в ARC и проверить самбу и слой эмуляции. >> еще я вижу, как оно постепенно (довольно медленно, что обидно, надо пожалуй поменьше recordsize попробовать) ложится на ssd-кэш Нижнюю планку скорости записи проверял? Ещё бы до конца понять что делают .l2arc_norw и .l2arc_noprefetch :-). Какое у тебя сложилось мнение/понимание? |
| Вдогонку: это, естественно, |
Вдогонку: это, естественно, не первая попытка. А сначала 3 по сети, потом локальная (зачетная), потом по сети зачетная. dd не торт, но вообще вот варез который просто читает файлы большими блоками через Win32 - надо освежить. |
| Но тем не менее - попробовал, |
Но тем не менее - попробовал, один и тот же файл, пришлось его уложить в L2ARC чтобы не отключать, ну значит 10G ресурса кэша запилили. Локально, на сервере (из ARC, понятно): [lexa@iscsi ~]$ cd /zdata/test/ Через cygwin/mingw (который пришел мне вместе с git-msys, может не очень кошерный): lexa@ganzer970 MINGW64 /t |
| И попадаем еще на |
И попадаем еще на дополнительный emulation layer. У меня где-то в закромах был варез, который писал большие (и маленькие и всякие) файлы, я его в прошлый заход, когда iSCSI vs SRP мерял написал, вот помню что написал. Но на самом деле интерес довольно условный уже, в интересном мне паттерне (просмотр/редактирование большого набора raw-файлов) я вижу скорости на интерфейсе "под 400" (раньше было скорее "под 250" и то не каждый раз) и еще я вижу, как оно постепенно (довольно медленно, что обидно, надо пожалуй поменьше recordsize попробовать) ложится на ssd-кэш и мне хорошо - вся эта йэбля была не зря. (а еще я бэкапный раздел унес на отдельный пул - и у меня основной не встает колом когда оно бэкапится) |
| Я думаю самба в данном случае |
Я думаю самба в данном случае не является ограничением. Чтоб не пилить ssd в Windows в Cygwin64Terminal (ставиться на раз) набираем dd if=/cygdrive/t/test of/dev/zero ... ну в общем всё как во FreeBSD. |
| извращенцы, угу. |
извращенцы, угу. |
| Получается, да: https://www |
Получается, да: https://www.corning.com/microsites/coc/ocbc/Documents/CNT-076-AEN.pdf С ума сойти! |
| вроде на 100 метров. |
вроде на 100 метров. Но я вот прочитал это вот: http://appleinsider.com/articles/14/02/16/review-cornings-thunderbolt-op... В разъеме макбука - медь. Получается, этот кабель - это там внутри, в разъеме, медиаконвертор? |
| Между тем диском и этим |
Между тем диском и этим диском - еще samba (довольно загадочная) ну и клиент, который этой самбе что-то транслирует. Вот при записи видно, что сетевая часть - не (сильно) ограничивает. По тому самому горбу в 1+gb/s в начале. При чтении - чтобы диск не запиливать надо свой софт какой-то понятный-вменяемый делать (или осваивать всякие готовые), а лень. |
| А ведь скорость чтения и |
А ведь скорость чтения и записи у hhd дисков условно равны :-). |
| Чтение без L2Arc - примерно |
Чтение без L2Arc - примерно на 100Mb/s медленнее в среднем и близко не такое ровное. Но тестировать чтение неприятно "SSD запиливается" |
| Интересно посмотреть на |
Интересно посмотреть на картинку чтения. Особенно в сравнении с записью. А ведь наверняка картинка есть :-). |
| по идее хоть на километр - |
по идее хоть на километр - если найти мифический оптический кабель тандерболта. |
Pages
