Ну, если есть SLC-кэш, то будет падать. Если нет, то может не падать. Но во внешнем SSD (не флешке) он в общем-то всегда будет, SLC/MLC-память ушла в прошлое, а SSD с TLC/QLC без SLC-кэша - штука корпоративная.
"Рутокен ЭЦП 2.0 Flash. Защищенный раздел выглядит как ридер карт памяти, но без вставленной в него карты, доступа к данным нет. Однако, запустив приложение и введя простой PIN-код..."
Это всё же не то - скрытый раздел вместо защиты от записи, есть мотив требовать приложение, чтобы не вбивать код на корпусе флешки. Защита от людей (надо знать код) вместо защиты от вредоносов (надо блокировать запись).
слёзно просить мастдай не стирать файлы
Ещё подумалось - на блочном уровне и в том рутокене защита работает, наверное, честно. Но так как производителям хочется удобно прошивать контроллеры флешек на производстве, то везде можно ожидать наличие доступа по USB, позволяющего хотя бы отформатировать флешку.
Но в 99% случаев там просто нужно установить фирменную утилиту, которая будет читать положение переключателя и слёзно просить мастдай не стирать файлы
Это странно звучит, такие флешки / внешние SSD / USB-боксы бывают ли вообще?
Производители контроллеров могут давать доступ к уже реализованной защите от записи, тут не видно больших сложностей. Если уж волноваться, то о том, точно ли нет этого доступа через USB (или достаточно ли он через USB затруднён). А то пишут об утилите PhisonWP, которая может включать/отключать блокировку на флешках* без их разбора или форматирования...
или оно определяется как файлопомойка
Представляться не совсем обычным накопителем, а... оптическим приводом должны уметь рутованные андроидофоны. Ну и известные коробки от Zalman это делают с ~2011 года.
Из некоторых одноплатников ещё флешка/привод с защитой от записи делается (modprobe g_mass_storage), но, видимо, не очень практично.
Вот как? А я наоборот, читал статью, где указывалось, что такое поведение - как раз способ вычислить smr диски.
Способ не годится: пост про SMR (TL;DR: последовательная запись всего диска никак не сигнализировала об SMR в ходе записи и, потом, чтения: картинка с чтением).
Но это было в духе волны паники лет 5 назад, тогда многих интересовало как при помощи палки и камня выявить наличие SMR, тогда все диски с большим кэшем на всякий случай записывали в SMR.
Вроде все адекватные способы в посте по ссылке и тут перечислены. Обычно достаточно запроса типа ... filetype:pdf site:seagate.com и знания, что DM-SMR нет среди дисков выше 8 ТБ у Seagate и выше 6 ТБ у WD.
Собственно, будь заголовок менее кликбейтным и будь пояснение о том, что тут не ставится целью срывать покровы с мирового заговора производителей дисков, но показать, как важно правильно проектировать хранилище - и реакция была бы другой.
Тщательное описание задержек полезно, если нам нужно быстрое случайное мелкоблочное IO. Но если оно нужно, то берут SSD.
HDD для такой нагрузки перестали производить, 20-терабайтные диски не будут выбирать по этой характеристике. И, наверное, там разницу лучше не искать в характеристиках, а создавать самому с помощью выноса метаданных ZFS на SSD и других подобных приёмов. btrfs тоже хотел такую функцию добавить, но это было давно и неправда это бесконечный долгострой.
После продольной записи (LMR) все диски - с перпендикулярной (PMR), эти тоже.
PMR пытались использовать в значении "без SMR", но это только путаницу создаёт, для "точно без SMR" придумали название conventional magnetic recording (CMR).
Из-за представления, будто все эти технологии исключают друг-друга, ещё одна ошибка встречается: что HAMR-диски не могут быть с SMR.
Можно как 3 оси представить:
LMR / PMR - ориентация магнитных доменов
CMR / SMR - расстояние между дорожками
∅ / ePMR / HAMR / MAMR - наличие доп. источника энергии
⁴ Based on internal testing ... location of the max min rate is at approximately 10% 100% into the capacity of the HDD.
От юридических солоночных хакеров отбиваться с помощью уже имеющегося "performance may vary depending on host environment, drive capacity, logical block address (LBA), and other factors" или добавить "sequential" в название величины.
Они указывают, что скорость - максимальная. Они рассказывают про уменьшение скорости на внутреннем радиусе. Упоминают на своих сайтах short-stroking*. Картинки из Victoria, HD Tune или AIDA64 в обзорах в интернете можно заметить. Эти же картинки из AIDA64 показывают, что там у SSD после исчерпания SLC-кэша, можно по аналогии задуматься про HDD. Также вопросов не будет, если знать про ухудшение звука у пластинок на внутреннем радиусе. Или про деление дисков любых видов на CLV и CAV (constant linear velocity и constant angular velocity). Или про дефрагментаторы на винде**.
* То есть уменьшение ёмкости HDD, чтобы уменьшить ход блока головок. Это в первую очередь про случайное IO, но линейное тоже растёт (внутренняя часть пластин не используется). В бытовом варианте можно место за первым разделом не выкидывать, а класть туда менее горячие данные.
** Прикольная оптимизация, продвинутую дефрагментацию объявляли ненужной скорее по принципу "нет на Linux - значит не нужно (а если появится, то станет нужно)".
Я, повторюсь, совсем не в теме, но что-то здесь не так. Если бы этот "single GPU pipeline parallelism" хорошо работал, то не надо было бы гнаться за объёмом VRAM для инференса. В multi-GPU pipeline parallelism не съедается пропускная способность PCIe загрузкой частей модели, их не надо постоянно загружать. А если надо, то, видимо, это становится явным узким местом и смысл теряется.
Если это настолько велосипед, то я бы о нём услышал. Услышал бы "возьмите платформу AM5, два Gen5 SSD на 14 ГБ/с линейного чтения и поделите модель вот этой утилитой".
upd: если каждая часть видеокартой используется достаточно долго, то нам и скорость SSD не очень нужна. Лишь бы успевать загрузить данные из SSD в RAM, прежде чем видеокарте потребуется следующая часть. Потом отдавать из RAM, полностью насыщая шину видеокарты.
GPU offloading
Гугл мне отвечает про распределение нагрузки между CPU и GPU, а не про то, как избежать нужды в профессиональных объёмах VRAM.
Если (бы?) модель можно было разделить на части так, чтобы они использовались однократно и последовательно (первые 10 ГБ, вторые 10 ГБ...), то идея бы сработала. Только на видеокарту SSD ставить не надо, используем PCIe 5.0 x16 (63 ГБ/c) видеокарты и несколько SSD, чтобы получить ~30 ГБ/с (упираемся в PCIe-линии не-HEDT процессоров).
В общем, как если бы мы эти части грузили из RAM, но вместо RAM - дешёвая флеш-память (всё равно основное бутылочное горлышко - это PCIe-шина видеокарты).
С моделью на 300 ГБ и массивом SSD на 30 ГБ/с на перекладывание частей во VRAM тратилось бы 10 секунд. Гуглу известен некий llm pipeline parallelism, но я не в теме.
Если идею применить не к модели-на-видеокарте, а к модели-на-CPU, то массив SSD можно ускорить до ~100 ГБ/с (отдаём ещё 16 линий под SSD).
Это может плохо кончиться. Создаст барьер для маленьких производителей (требовать 10 лет софтовой поддержки - отличный способ для Apple и Samsung разобраться с конкурентами), поможет экономике стран-конкурентов, которые таким регулированием заниматься не станут.
Если окажется, что покупатели всё равно хотят новый айфон и дольше пользоваться телефонами не начинают, придётся ударять по ним "утильсбором на телефоны", чтобы передумали.
Даже при хорошо работающей гарантии, думаю, покупателям с сильно выгоревшим за 9 лет OLED'ом будут отказывать. Покупатели прикинут остаточную стоимость устройства, величину судебных расходов и сделают выводы.
О процессе соединения там не говорят, зато есть обычное "solder joint".
Но и в этом случае, это не распаивание и не припаивание, а спаивание
Разваривать микросхемы можно, а распаивать нельзя? Wire bonding в русском стал разваркой, а для пайки microbump'ов устоявшаяся терминология вряд ли есть.
Вот, не интеграция, а "solder reflow", пайка оплавлением. Сухие документы говорят, что микросхема может быть распаянной таким способом почти так же надёжно, как вилка лежит, тарелка стоит, а птичка сидит. Или вот: "said Doug Scott, senior vice president of wafer level packaging at Amkor Technology ... copper pillar bumps ... assembly reflow".
задело меня не это, а то что microbumps дело не ограничивается
Ну, внутреннее устройство HBM (соединение стеков) в рамках статьи не важно, про это не говорилось.
Хм, bonded joint - хороший термин. Соединённое соединение. По смыслу - что-то вроде неразъёмного соединения, но переводов в микроэлектронике не видно.
Конечно, с чего бы ей не падать-то (анекдот)
Ну, если есть SLC-кэш, то будет падать. Если нет, то может не падать. Но во внешнем SSD (не флешке) он в общем-то всегда будет, SLC/MLC-память ушла в прошлое, а SSD с TLC/QLC без SLC-кэша - штука корпоративная.
Вот другое, но похожее: https://habr.com/ru/companies/aktiv-company/articles/331862/
"Рутокен ЭЦП 2.0 Flash. Защищенный раздел выглядит как ридер карт памяти, но без вставленной в него карты, доступа к данным нет. Однако, запустив приложение и введя простой PIN-код..."
Это всё же не то - скрытый раздел вместо защиты от записи, есть мотив требовать приложение, чтобы не вбивать код на корпусе флешки. Защита от людей (надо знать код) вместо защиты от вредоносов (надо блокировать запись).
Ещё подумалось - на блочном уровне и в том рутокене защита работает, наверное, честно. Но так как производителям хочется удобно прошивать контроллеры флешек на производстве, то везде можно ожидать наличие доступа по USB, позволяющего хотя бы отформатировать флешку.
Это странно звучит, такие флешки / внешние SSD / USB-боксы бывают ли вообще?
Производители контроллеров могут давать доступ к уже реализованной защите от записи, тут не видно больших сложностей. Если уж волноваться, то о том, точно ли нет этого доступа через USB (или достаточно ли он через USB затруднён). А то пишут об утилите PhisonWP, которая может включать/отключать блокировку на флешках* без их разбора или форматирования...
Представляться не совсем обычным накопителем, а... оптическим приводом должны уметь рутованные андроидофоны. Ну и известные коробки от Zalman это делают с ~2011 года.
Из некоторых одноплатников ещё флешка/привод с защитой от записи делается (modprobe g_mass_storage), но, видимо, не очень практично.
* с какими-то контроллерами от Phison, конечно.
Способ не годится: пост про SMR (TL;DR: последовательная запись всего диска никак не сигнализировала об SMR в ходе записи и, потом, чтения: картинка с чтением).
Но это было в духе волны паники лет 5 назад, тогда многих интересовало как при помощи палки и камня выявить наличие SMR, тогда все диски с большим кэшем на всякий случай записывали в SMR.
Вроде все адекватные способы в посте по ссылке и тут перечислены. Обычно достаточно запроса типа
... filetype:pdf site:seagate.comи знания, что DM-SMR нет среди дисков выше 8 ТБ у Seagate и выше 6 ТБ у WD.Так уже писали:
Тщательное описание задержек полезно, если нам нужно быстрое случайное мелкоблочное IO. Но если оно нужно, то берут SSD.
HDD для такой нагрузки перестали производить, 20-терабайтные диски не будут выбирать по этой характеристике. И, наверное, там разницу лучше не искать в характеристиках, а создавать самому с помощью выноса метаданных ZFS на SSD и других подобных приёмов. btrfs тоже хотел такую функцию добавить, но
это было давно и неправдаэто бесконечный долгострой.Если там есть какая-то ошибка, то сверху может быть побитовый xor. Так под прошлым постом два раза в джаваскрипте делали.
После продольной записи (LMR) все диски - с перпендикулярной (PMR), эти тоже.
PMR пытались использовать в значении "без SMR", но это только путаницу создаёт, для "точно без SMR" придумали название conventional magnetic recording (CMR).
Из-за представления, будто все эти технологии исключают друг-друга, ещё одна ошибка встречается: что HAMR-диски не могут быть с SMR.
Можно как 3 оси представить:
LMR / PMR - ориентация магнитных доменов
CMR / SMR - расстояние между дорожками
∅ / ePMR / HAMR / MAMR - наличие доп. источника энергии
Идея устарела/устаревает вместе с дисками на 15K и 10K RPM, вместе с 2.5". "Random Read/Write: быстрее, чем у магнитной ленты", ну и ладно.
Почитал про FlexGen.
___
Пишут, что моя ошибка тут:
Необходимо повторять процесс для каждого токена, они же зависят от предыдущих.
"For a 500 token reply you’d basically be loading the whole model, layer by layer, 500 times".
Только сейчас заметил, что оговорился: "успевать загрузить
данныеследующий кусок модели".Так же.
Sustained transfer rate⁴ (MB/s,
maxmin)⁴ Based on internal testing ... location of the
maxmin rate is at approximately10%100% into the capacity of the HDD.От юридических солоночных хакеров отбиваться с помощью уже имеющегося "performance may vary depending on host environment, drive capacity, logical block address (LBA), and other factors" или добавить "sequential" в название величины.
Он про то, чтобы добавить в характеристики ещё эту величину:
Что диски нельзя сушить в микроволновке...
___
Они указывают, что скорость - максимальная. Они рассказывают про уменьшение скорости на внутреннем радиусе. Упоминают на своих сайтах short-stroking*. Картинки из Victoria, HD Tune или AIDA64 в обзорах в интернете можно заметить. Эти же картинки из AIDA64 показывают, что там у SSD после исчерпания SLC-кэша, можно по аналогии задуматься про HDD. Также вопросов не будет, если знать про ухудшение звука у пластинок на внутреннем радиусе. Или про деление дисков любых видов на CLV и CAV (constant linear velocity и constant angular velocity). Или про дефрагментаторы на винде**.
* То есть уменьшение ёмкости HDD, чтобы уменьшить ход блока головок. Это в первую очередь про случайное IO, но линейное тоже растёт (внутренняя часть пластин не используется). В бытовом варианте можно место за первым разделом не выкидывать, а класть туда менее горячие данные.
** Прикольная оптимизация, продвинутую дефрагментацию объявляли ненужной скорее по принципу "нет на Linux - значит не нужно (а если появится, то станет нужно)".
Я, повторюсь, совсем не в теме, но что-то здесь не так. Если бы этот "single GPU pipeline parallelism" хорошо работал, то не надо было бы гнаться за объёмом VRAM для инференса. В multi-GPU pipeline parallelism не съедается пропускная способность PCIe загрузкой частей модели, их не надо постоянно загружать. А если надо, то, видимо, это становится явным узким местом и смысл теряется.
Если это настолько велосипед, то я бы о нём услышал. Услышал бы "возьмите платформу AM5, два Gen5 SSD на 14 ГБ/с линейного чтения и поделите модель вот этой утилитой".
upd: если каждая часть видеокартой используется достаточно долго, то нам и скорость SSD не очень нужна. Лишь бы успевать загрузить данные из SSD в RAM, прежде чем видеокарте потребуется следующая часть. Потом отдавать из RAM, полностью насыщая шину видеокарты.
Гугл мне отвечает про распределение нагрузки между CPU и GPU, а не про то, как избежать нужды в профессиональных объёмах VRAM.
Если (бы?) модель можно было разделить на части так, чтобы они использовались однократно и последовательно (первые 10 ГБ, вторые 10 ГБ...), то идея бы сработала. Только на видеокарту SSD ставить не надо, используем PCIe 5.0 x16 (63 ГБ/c) видеокарты и несколько SSD, чтобы получить ~30 ГБ/с (упираемся в PCIe-линии не-HEDT процессоров).
В общем, как если бы мы эти части грузили из RAM, но вместо RAM - дешёвая флеш-память (всё равно основное бутылочное горлышко - это PCIe-шина видеокарты).
С моделью на 300 ГБ и массивом SSD на 30 ГБ/с на перекладывание частей во VRAM тратилось бы 10 секунд. Гуглу известен некий llm pipeline parallelism, но я не в теме.
Если идею применить не к модели-на-видеокарте, а к модели-на-CPU, то массив SSD можно ускорить до ~100 ГБ/с (отдаём ещё 16 линий под SSD).
Ранняя смерть (69 лет) указывала не только на недостатки отдельных людей наверху, но и на общую нестабильность системы. А в мире современности есть стабильная страна, перехватившая знамя. Ей уже 77-й год, на хабре о ней были "инсайды".
https://habr.com/ru/companies/ruvds/articles/646925/
https://habr.com/ru/companies/ruvds/articles/648399/
Хотя нас там, наверное, считают познавшими запретный плод "крысиного мира современности" и врата не откроют.
Это может плохо кончиться. Создаст барьер для маленьких производителей (требовать 10 лет софтовой поддержки - отличный способ для Apple и Samsung разобраться с конкурентами), поможет экономике стран-конкурентов, которые таким регулированием заниматься не станут.
Если окажется, что покупатели всё равно хотят новый айфон и дольше пользоваться телефонами не начинают, придётся ударять по ним "утильсбором на телефоны", чтобы передумали.
Даже при хорошо работающей гарантии, думаю, покупателям с сильно выгоревшим за 9 лет OLED'ом будут отказывать. Покупатели прикинут остаточную стоимость устройства, величину судебных расходов и сделают выводы.
Это всё не важно, но...
Это очень общий термин. Что-то с чем-то объединили - интеграция.
О процессе соединения там не говорят, зато есть обычное "solder joint".
Разваривать микросхемы можно, а распаивать нельзя? Wire bonding в русском стал разваркой, а для пайки microbump'ов устоявшаяся терминология вряд ли есть.
Вот, не интеграция, а "solder reflow", пайка оплавлением. Сухие документы говорят, что микросхема может быть распаянной таким способом
почти так же надёжно, как вилка лежит, тарелка стоит, а птичка сидит. Или вот: "said Doug Scott, senior vice president of wafer level packaging at Amkor Technology ... copper pillar bumps ... assembly reflow".Ну, внутреннее устройство HBM (соединение стеков) в рамках статьи не важно, про это не говорилось.
Хм, bonded joint - хороший термин. Соединённое соединение. По смыслу - что-то вроде неразъёмного соединения, но переводов в микроэлектронике не видно.