Pull to refresh
0
0
Send message
UFO landed and left these words here
UFO landed and left these words here
Всем давно известно, что кэш на запись при использовании SSD надо отключать.
Объяснение было «а, окей, так и должно работать»
На вопрос — а зачем тогда вообще нужен кэш записи, не ответили.

Оно так себя ведёт вне зависимости от количества дисков, от включение-выключения кэша на чтение, от того, есть ли второй том без кэша записи.

А вот второй том (который без кэша) работает нормально.

При чём — обратите внимание — с включённым кэшем записи и батареей — оно работает МЕДЛЕННЕЕ.
При чём заметно, чуть ли не на 30-50% (уже точно не помню цифру, но это не пара процентов)

перетыкал диски в Adaptec-овский контроллер — всё хоккей
Админское:
Я теперь тоже не люблю LSI.
Купил 9750-4i, обнаружил, что если включить кэширование записи — скорость возрастает (ожидаемо).
А вот если включить кэширование записи с батарейной защитой — скорость уменьшается.

После долгого треда с техподдержкой мне сообщили, что так и должно быть.
Зачем тогда нужно кэширование записи мне не сказали.

прошивка и последняя и не последняя, один чёрт.
Больший чанк — большее время «тупления» на конкретном блоке. Модели можно делать разные, у меня по мере роста размера чанка падала суммарная скорость.
Хм. А почему эта скорость падает? Чем то это должно объяснятся? Или она падает на мелких операциях? И на столько сильно, что приращение на последовательных уже становится не так важным?

Ну про интел — это понятно. Хотя, может кто-то сумеет из чипсета сделать съёмную плату и тогда будет 6*n. Но пока 6 — это предел, и он очень печальный. Я пока до 10 догоняю через ASMedia 1061 (1062). Но там всего 2 порта. Про Marvel у меня вообще печальный опыт: avryabov.livejournal.com/5056.html
А в планах собрать хранилище на 15 HDD, но тут похоже ничего лучше LSI нету. И это меня огорчает…
Я пробовал менять chunk, при росте chunk'а скорость падает.

Из всех HBA я не имею ни малейшего нарекания только к intel'ам. Точнее, у них есть проблема с потолком производительности, но зато никаких глюков я от них никогда не видел. К сожалению, 6 портов максимум, sata, и только в составе чипсета.

Подавал надежды adaptec'овский HBA (не путать с рейдами) — но когда я его видел (через пол-года после анонса) он был ещё сырой-сырой-сырой. В том смысле, что драйверов в апстриме не было, только сырцы на сайте самого адаптека. Надеюсь, они это поправили.
Разделы к этому не имеют никакого отношения. Надо понимать, что free space с точки зрения контроллера диска и файловой системы — две большие разницы. Для контроллера free space — это то, куда пока что никто не писал. Ни разу. Если записали и удалили — всё равно область с данными. Таким образом, чем больше свободного места с точки зрения контроллера, тем ему легче. Но с точки зрения контроллера fs, на которую хоть раз полностью записали все блоки, а потом переформатировали заново — всё равно полностью заполнена.

Единственные два исключения: операция TRIM и secure erase. TRIM делают многие файловые системы для ненужных данных, secure erase делается всегда руками и целиком для диска.

Когда говорят про практический underprovision'ing, то речь идёт о том, чтобы с самого начала ограничить используемое место на диске и никогда туда не писать. Иногда делают это через lba limits (то есть диск рапортует про меньшее место, чем есть), иногда через ограничение размера раздела, иногда — посредством правильного использования FS с поддержкой trim.

Эффект сильно разнится от контроллера к контроллеру, но из практических соображений иметь ФС, на которой меньше 10% свободного места — плохо. Так что обычная ФС (ext3, ext4) отлично справится с задачей underprovision'инга.
Задержку в реальной работе можно в разы, а то и на порядок, уменьшить зная особенность работы контроллера SSD диска. Контроллеру для максимальной производительности необходимо свободное место на диске. Оптимально оставлять 25% диска не размеченой.
По ссылке можно увидеть графики для сравнения www.anandtech.com/show/6489/playing-with-op

Таким образом производительность всего рейда в рабочих условиях увеличится значительно.
Это не HBA режим. В HBA-режиме нет никаких кешей, и не контроллера, как активного участника процесса.

Вообще, можно включать writeback на самих устройствах (и это даёт ошеломительную разницу на консьюмерских SSD — у меня на ноуте intel'овское чудо 500ой серии показывает 280 IOPS без writeback и 50к+ — с writeback'ом, и вопрос там не только в том, что «сначала насосались, потом пишем», главное — консолидация мелкого IO кратно уменьшающая количество «больших» операций).

В случае, когда пишут много, все кеши оказываются заполнены. Легко понять почему: предположим, у нас скорость втока — 400Мб/с, скорость «вытока» — от 200 до 300. Буффер — 200 Мб.

Мы начинаем писать на рейд — сначала все всасывают с микроскопической latency 200Мб и начинают её писать. За несколько секунд буффера заполняются. Все и у всех. У кого-то буфер заполняется раньше, у кого-то позже, но заполняется он у всех. И с этого момента мы сталкиваемся с тем, что запись в буфер возможна только если там освободилось место. Частично это проблему простоя снимает, но у SSD проблема отличается от 'seek time' для HDD. У hdd, если за счёт буферизации можно делать seek после ответа «хорошо» на запрос записи, то скорость растёт. У SSD если в промежутках между приёмами данных продолжать писать, то для housekeep'инга не остаётся времени, и в какой-то момент начинает страдать запись. В буфер ли, напрямую.

Буфер помогает — но не с latency. Более того, по очевидным причинам буфер, наборот, усиливает разброс latency (от «записали в буфер, вернули ок» до «стоп, буфер заполнен, пытаемся хоть что-то скинуть, а там хаускипинг, который настаивает, что он важнее, так что ждём его»). Разброс усиливается из-за того, что худший вариант у всех тот же самый, а лучший — лучше у writeback.
Будет проще объяснить, если принять, что запись будет идти блоками по 1М, каждый блок будет писаться либо 10мс (100МБ/с) либо 100мс (10МБ/с). В буффере 1000МБ, в рейде 10 винтов.

Контроллер отправляет на 10 винтов по 1МБ. Через 10мс 9 винтов записали свой 1МБ, а один винт пишет. Освободилось 9МБ. Контроллер отправил на свободные 9 винтов ещё по 1МБ — через 10мс они все записали, а десятый винт все ещё пишет предыдущий 1МБ — освободилось ещё 9МБ. Цикл повторяется — итого через 100мс десятый винт наконец записал свой 1МБ, а остальные винты записали к этому времени 10МБ — всего записано 91МБ за 100мс. Среднюю скорость записи посчитаете уже самостоятельно? ))
> Случай из жизни недельной давности.
Вы себе хотя бы примерно представляете, какое количество «случаев недельной давности» можно привести в случае других ОС? (См. их форумы поддержки.) Поэтому на доказательство высказанных bO_oblik утверждений данный конкретный «случай недельной давности» не подходит.

> То клиент глючит, то звук в Логитековские usb наушники не идет, то вообще не регистрируется и еще куча всяких проблем.
Ссылки на багрепорты?

> Буду рад если кто-то может что-то посоветовать. Обязательно нужен клиент с возможностью трансфера звонка на другого человека. Друг работет тур. агентом и SIP критичен.
Про SFLPhone, QuteCom, Jitsi и eyeBeam уже знаете?
Внимательнейшим образом ознакомьтесь с этой заметкой: computerra.ru/cio/3800
Не вяжется с наблюдаемой мною реальностью.

Где-то с 2010 компания сменила курс с опен-сорс на микрософт. Конечно, было непонятно и обидно — столько перл-скриптов с регекспами понаписано. На внедренца от MS смотрели чуть ли не как на засланного в тыл врага — пришёл тут бабло распиливать, бездельник. Тем не менее, переход осуществился по приказу сверху и через прошедшие годы видно, как процессы в компании упорядочились.

В инфраструктуре MS сильна интеграция, офисную жизнь можно бесконечно расписывать (что дал Exchange вместо Postfix), всякие планирования времени, Sharepoint-Lync интегрированный со всем, и т.п. Казалось, коммерческий буллшит, но на самом деле очень экономит время.

Но и чисто технические задачи, типа бекапа файловых систем, мы не могли нормально решить на linux и freeBSD.
Начинается бекап — файлопомойка стоит раком. А фоновый MS DPM мало того, что незаметен, он ещё и транзакционен: если начался бекап, изменения файлов, сделанные позже, в него не попадут (а не «как повезёт»). NTFS знает, что менялось и что надо бекапить.

И так везде — от Apache vs IIS, до Firebird vs MS SQL.
Я бы по привычному пути пошел:

1) Распаковываете драйверы (Intel Matrix Storage Manager), взятые с сайта Intel:

IATA89CD.exe -a -p <путь для распакованных файлов>.

2) Уточняете модель контроллера (со всеми доп. буковами).

3) Находите в диспетчере устройств свой контроллер, кликаете «обновить драйвер», следуете: «установка из указанного места» -> «Не выполнять поиск. Я выберу нужный драйвер самостоятельно.» Далее «Установить с диска» и указываете на файл iaAHCI.inf в папке с распакованными драйверами (для системы нужной разрядности), из списка выбираете СВОЙ контроллер и далее, далее… устанавливаете.
ОС будет предупреждать, что устройство может не работать и т.д., но если Вы выбрали верный контроллер, смело продолжайте установку. По просьбе установщика перезагружаете систему, но перед загрузкой включаете AHCI Mode в BIOS Setup.

4) После загрузки система будет находить новые устройства и т.д., после того, как система отшуршит с установкой новых устройства, можно запускать установку Intel Matrix Storage Manager, теперь он установится без проблем.

У Вас там Atom на Intel NM10, вряд ли проблемы будут…
Опять забыли про Flash Player, который обновился до версии 13.0.0.182:
www.adobe.com/ru/products/flashplayer/distribution3.html
helpx.adobe.com/flash-player/flash-player-releasenotes.html
Второе и третье попробую прояснить подробнее.

Профиль — это совокупность параметров закодированного потока, они могут меняться в довольно широких диапазонах. Изначально аппаратные декодировщики были заточены под параметры достаточные для стандарта blu-ray, но то что лежит на торрентах зачастую выходит за эти рамки. amd расширила возможности своего декодировщика достаточно давно и первой и добавила поддержку профиля high@L5.1 — это уже очень далеко выходит за рамки blu-ray. Это дало возможность воспроизводить почти все из того что на торрентах лежит. Что с этим у nvidia — я не знаю.

А в последнем абзаце я хотел сказать о том, что несмотря на то что железка переваривает профиль high@L5.1, препятствием к активации dxva ускорению может быть софт, который может посчитать, что данный поток не подейдет для dxva. Поделился тем, что с MS кодеком под mpc-hc с этим неплохо. Но эта ремарка уже по софту, а не железу.
Могу предложить из самого простого — например AMD HD6450. Самая дешевая карта из 6000-ой серии, много вариантов с пассивным охлаждением, hdmi почти на всех картах есть, а по декодированию — там стоит UVD3, который и на старших моделях. Сейчас разница в UVD чипах только от поколения к поколению, а так — от младшей до старшей модели с видео должно быть все примерно одинаково. Воспроизводить надо в плеерах с использованием аппаратного ускорения, загрузка на средних современных CPU будет порядка 5%.

Конечно можно и nvidia брать, единственный момент — amd первой ввела поддержку профиля High@L5.1, что дает больше шансов на то, что поток переварит аппаратный декодер. Я просто не в курсе как с этим сейчас у nvidia. nvidia может быть предпочтительней например для linux — у них там собственный api типа dxva, называется vdpau, его не поддерживает amd, amd вроде va-api поддерживает. Вобщем если linux — то там надо отталкиваться от плееров — будет ли он уметь делать акселерацию.

Бывает, что все-таки DXVA кодек отказывается принять поток, тогда два варианта — либо артефакты, либо будет осмысленный отказ и переключение на программный кодек. Я в основном сижу в mpc-hc с подключенным кодеком microsoft dtv-dvd h.264 и не замечал давно такого. А вот недавно поставил на другую машину mpc-hc и выяснил, что бывают потоки, которые отказывается принимать встроенный dxva кодек, а вот кодек microsoft прекрасно это дело обработал. Дело в том, что раньше многие просто отсекали от dxva потоки за пределами профиля L4.1 (blu-ray), ну или другая причина, просто не все фичи dxva покрыты во встроенном кодеке mpc-hc. Последний абзац — это уже не к оборудованию относится, а к выбору софта.
Ну это общая проблема, когда частота видео не кратна частоте обновления монитора.
В MPC-HC это решается с помощью ReClock и/или включением вертикальной синхронизации(и увеличение/уменьшение сдвига vsync).

Еще там, кажется, есть утилита AutoFrequency, позволяющая автоматически менять частоту обновления экрана, в зависимости от частоты видео.
Попробуйте так — smotr.im/3f8Q
1

Information

Rating
Does not participate
Registered
Activity