Объяснение было «а, окей, так и должно работать»
На вопрос — а зачем тогда вообще нужен кэш записи, не ответили.
Оно так себя ведёт вне зависимости от количества дисков, от включение-выключения кэша на чтение, от того, есть ли второй том без кэша записи.
А вот второй том (который без кэша) работает нормально.
При чём — обратите внимание — с включённым кэшем записи и батареей — оно работает МЕДЛЕННЕЕ.
При чём заметно, чуть ли не на 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.
IATA89CD.exe -a -p <путь для распакованных файлов>.
2) Уточняете модель контроллера (со всеми доп. буковами).
3) Находите в диспетчере устройств свой контроллер, кликаете «обновить драйвер», следуете: «установка из указанного места» -> «Не выполнять поиск. Я выберу нужный драйвер самостоятельно.» Далее «Установить с диска» и указываете на файл iaAHCI.inf в папке с распакованными драйверами (для системы нужной разрядности), из списка выбираете СВОЙ контроллер и далее, далее… устанавливаете.
ОС будет предупреждать, что устройство может не работать и т.д., но если Вы выбрали верный контроллер, смело продолжайте установку. По просьбе установщика перезагружаете систему, но перед загрузкой включаете AHCI Mode в BIOS Setup.
4) После загрузки система будет находить новые устройства и т.д., после того, как система отшуршит с установкой новых устройства, можно запускать установку Intel Matrix Storage Manager, теперь он установится без проблем.
У Вас там Atom на Intel NM10, вряд ли проблемы будут…
Профиль — это совокупность параметров закодированного потока, они могут меняться в довольно широких диапазонах. Изначально аппаратные декодировщики были заточены под параметры достаточные для стандарта 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, позволяющая автоматически менять частоту обновления экрана, в зависимости от частоты видео.
На вопрос — а зачем тогда вообще нужен кэш записи, не ответили.
Оно так себя ведёт вне зависимости от количества дисков, от включение-выключения кэша на чтение, от того, есть ли второй том без кэша записи.
А вот второй том (который без кэша) работает нормально.
При чём — обратите внимание — с включённым кэшем записи и батареей — оно работает МЕДЛЕННЕЕ.
При чём заметно, чуть ли не на 30-50% (уже точно не помню цифру, но это не пара процентов)
перетыкал диски в Adaptec-овский контроллер — всё хоккей
Я теперь тоже не люблю LSI.
Купил 9750-4i, обнаружил, что если включить кэширование записи — скорость возрастает (ожидаемо).
А вот если включить кэширование записи с батарейной защитой — скорость уменьшается.
После долгого треда с техподдержкой мне сообщили, что так и должно быть.
Зачем тогда нужно кэширование записи мне не сказали.
прошивка и последняя и не последняя, один чёрт.
Ну про интел — это понятно. Хотя, может кто-то сумеет из чипсета сделать съёмную плату и тогда будет 6*n. Но пока 6 — это предел, и он очень печальный. Я пока до 10 догоняю через ASMedia 1061 (1062). Но там всего 2 порта. Про Marvel у меня вообще печальный опыт: avryabov.livejournal.com/5056.html
А в планах собрать хранилище на 15 HDD, но тут похоже ничего лучше LSI нету. И это меня огорчает…
Из всех HBA я не имею ни малейшего нарекания только к intel'ам. Точнее, у них есть проблема с потолком производительности, но зато никаких глюков я от них никогда не видел. К сожалению, 6 портов максимум, sata, и только в составе чипсета.
Подавал надежды adaptec'овский HBA (не путать с рейдами) — но когда я его видел (через пол-года после анонса) он был ещё сырой-сырой-сырой. В том смысле, что драйверов в апстриме не было, только сырцы на сайте самого адаптека. Надеюсь, они это поправили.
Единственные два исключения: операция TRIM и secure erase. TRIM делают многие файловые системы для ненужных данных, secure erase делается всегда руками и целиком для диска.
Когда говорят про практический underprovision'ing, то речь идёт о том, чтобы с самого начала ограничить используемое место на диске и никогда туда не писать. Иногда делают это через lba limits (то есть диск рапортует про меньшее место, чем есть), иногда через ограничение размера раздела, иногда — посредством правильного использования FS с поддержкой trim.
Эффект сильно разнится от контроллера к контроллеру, но из практических соображений иметь ФС, на которой меньше 10% свободного места — плохо. Так что обычная ФС (ext3, ext4) отлично справится с задачей underprovision'инга.
По ссылке можно увидеть графики для сравнения www.anandtech.com/show/6489/playing-with-op
Таким образом производительность всего рейда в рабочих условиях увеличится значительно.
Вообще, можно включать 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.
Контроллер отправляет на 10 винтов по 1МБ. Через 10мс 9 винтов записали свой 1МБ, а один винт пишет. Освободилось 9МБ. Контроллер отправил на свободные 9 винтов ещё по 1МБ — через 10мс они все записали, а десятый винт все ещё пишет предыдущий 1МБ — освободилось ещё 9МБ. Цикл повторяется — итого через 100мс десятый винт наконец записал свой 1МБ, а остальные винты записали к этому времени 10МБ — всего записано 91МБ за 100мс. Среднюю скорость записи посчитаете уже самостоятельно? ))
Вы себе хотя бы примерно представляете, какое количество «случаев недельной давности» можно привести в случае других ОС? (См. их форумы поддержки.) Поэтому на доказательство высказанных bO_oblik утверждений данный конкретный «случай недельной давности» не подходит.
> То клиент глючит, то звук в Логитековские usb наушники не идет, то вообще не регистрируется и еще куча всяких проблем.
Ссылки на багрепорты?
> Буду рад если кто-то может что-то посоветовать. Обязательно нужен клиент с возможностью трансфера звонка на другого человека. Друг работет тур. агентом и SIP критичен.
Про SFLPhone, QuteCom, Jitsi и eyeBeam уже знаете?
Где-то с 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:
2) Уточняете модель контроллера (со всеми доп. буковами).
3) Находите в диспетчере устройств свой контроллер, кликаете «обновить драйвер», следуете: «установка из указанного места» -> «Не выполнять поиск. Я выберу нужный драйвер самостоятельно.» Далее «Установить с диска» и указываете на файл iaAHCI.inf в папке с распакованными драйверами (для системы нужной разрядности), из списка выбираете СВОЙ контроллер и далее, далее… устанавливаете.
ОС будет предупреждать, что устройство может не работать и т.д., но если Вы выбрали верный контроллер, смело продолжайте установку. По просьбе установщика перезагружаете систему, но перед загрузкой включаете AHCI Mode в BIOS Setup.
4) После загрузки система будет находить новые устройства и т.д., после того, как система отшуршит с установкой новых устройства, можно запускать установку Intel Matrix Storage Manager, теперь он установится без проблем.
У Вас там Atom на Intel NM10, вряд ли проблемы будут…
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 с этим неплохо. Но эта ремарка уже по софту, а не железу.
Конечно можно и 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, позволяющая автоматически менять частоту обновления экрана, в зависимости от частоты видео.