Category: компьютеры

Category was added automatically. Read all entries about "компьютеры".

404

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

У моего ноута (SCHENKER WORK 15) почти всё работает. Не работает только подсветка клавиатуры (работает после включения, выключается после suspend). Я потыкался-потыкался в железо, и ничего не нашёл. Зато есть gpio чип. У которого 360 (!) пинов. Почитал-почитал доку по gpio в линуксе и начал эти пины тыкать.

Уже нашёл: пин, который в '0' выключает машину. Мгновенно. Пин, который управляет питанием экрана (просто вкл/выкл). Пин, который соответствует кнопке "выключить экран" на клавиатуре, так, что он включается по нажатию любой кнопки. (оказалось, это разные пины!). Пин, который выключает питание на nvme устройстве (это было весьма трудно отлаживать, потому что ... ну вы поняли, где у меня ОС).

И это я пока пины с 152 по 166 посмотрел (пины с 152 начинаются, и до 512 продолжаются). О сколько мне открытий чудных... или сдам в гарантию.
404

О задаче остановке и энтропии

Во-первых, давайте переформулируем, что такое "остановка". У нас нет остановки (машина не может остановиться), у нас есть бесконечный цикл, в котором состояние не меняется. Грубо говоря, loop {}. Легко показать, что если состояние машины (включая ленту) не поменялось в результате выполнения инструкции, то оно не поменяется никогда.

Дальше, если у нас нет понятия "остановка", то мы начинаем оперировать циклами. Цикл размера 0 (ноль инструкций, помимо инструкции повтора) - это аналог "остановки", но произойти он может не только в результате достижения конца алгоритма, но и в любой другой момент времени. Мы теряем при этом возможность знать, что на ленте тот результат, который был задуман но, в целом, мы не можем этого знать и в контексте halt инструкции, потому что из-за ошибки в коде мы можем перейти на halt до выводе результата целиком. Другими словами, если мы договоримся, что loop{} - это аналог halt, то будет результат или нет в этот момент на выводе - это добрая воля программы.

Далее: у нас не может быть циклов состояний машины размером 1 (заметим, не инструкций, а состояний). Любая циклическая операция требует как минимум два состояния между которыми будут переходы, потому что переход из состояния в само себя - это цикл размера 0, а переход в другое состояние оставляет машину в новом состоянии, и для "зацикливания" ей нужно перейти в состояние до первого изменения, т.е. размеры циклов 0, 2. Циклы размером 3, впрочем, быть могут (loop{ a=1; a=2; a=3;}). Заметим, loop{a=1} имеет размер 0, т.к. состояние a=1 не меняется между циклами.

Некоторые состояния программы не могут быть повторены, и являются уникальными. Программа начинает свою работу из уникального состояния, и продолжает перемещаться, пока не достигнет бесконечного цикла. бесконечный цикл (состояния) может быть только один, потому что для перехода во второй, нам надо досчитать до бесконечности.

Некоторые программы имеют нулевой начальный путь, т.е. они начинают с состояния, которое достигают снова и снова.

Вне зависимости от размера цикла, как только программа достигла повторяемого состояния (цикла), она может считаться "завершённой" (в том смысле, что достигла бесконечно повторяющегося цикла). Даже если этот цикл - поиск ответа на вопрос 42, занимающий квинтилионы лет. Заметим, в этом месте у нас отсутствуют side effects и side causes, потому что при их наличии у нас может и не быть (в общем случае) повторяющегося цикла.

Таким образом, программа начинает с неповторяющейся последовательности состояний (возможно, нулевой длинны), и переходит в повторяющийся цикл состояний.

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

Конечная тьюринг-машина всегда стремится перейти из состояние низкой энтропии в состояние высокой энтропии, либо уже находится в состоянии бесконечной энтропии. Бесконечная машина Тьюринга может оттягивать этот процесс бесконечно долго.

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

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

Для конечного компьютера без учёта side effects/causes, максимальный размер неповторяющейся программы - это время пересчёта всех состояний машины (например, от максимального до нулевого с зацикливанием на нуле - если зацикливание произойдёт не на нуле, то размер цикла больше, уникальных состояний меньше). Пренебрегая регистрами, для идеализированного компьютера, это примерно 28*mem_in_bytes-1 состояний.

Задача остановки компьютера в такой терминологии сводится к поиску циклов. Поскольку цикл состояний один, достаточно найти любой цикл, и этого достаточно для определения остановки. При конечных компьютерах эта задача имеет теоретическое простое решение: через 28*mem_in_bytes состояний компьютер гарантировано находится в зацикленном состоянии, достаточно просто подождать/смоделировать это количество инструкций и быть уверенным, что программа зациклилась. Для бесконечного компьютера это не работает - простейшее loop {a+=1} не завершится никогда, но и цикла не создаст никогда. В этой ситуации машина находится в состоянии нулевой энтропии (по любому из определений), и переходит в состояние нулевой энтропии, ненулевых значений у такой машины нет.

Я не знаю, зачем я всё это писал, но мне понравилась идея про "энтропию" машины. Есть время или его подобие - есть энтропия.
404

О конечном автомате, который себя вообразил компьютером

Внезапно, я сейчас осознал интересный plot twist для self-reference systems. Допустим, у нас есть тьюринг-машина (обычный компьютер, для удобства обсуждения, без дисков и сети, только память). Допустим, этот компьютер задумался "о себе", и решил пересчитать все возможные свои состояния. Его память N бит, т.е. у него может быть не более чем 2^N состояний. Так вот, для хранения числа 2^N, нам надо N бит, и ничего, кроме числа возможных состояний компьютер хранить в себе не сможет.

Другими словами, self-referencing система не может проанализировать все свои действия. Более того, если код занимает ненулевое число бит, то даже пересчитать не может.
404

(no subject)

Я тут, внезапно, обзавёлся ноутбуком. Я хотел было взять всякое разное свободное (purism/system76 и т.д.), но оказалось, что у них ничего нет (физически). out of stock, с ожидаемым delivery date куда-то во вторую половину лета.

Так что пришлось шоппить коммодити. Меня не впечатлил dell, и я купил странное - b-brand. Немецкий. Называется

Manufacturer: SchenkerTechnologiesGmbH
Product Name: SCHENKER WORK 15 (Early 2021)

Quadratisch Praktisch Gut. Невыразительный дизайн "a laptop", нормальная клавиатура без выкрутасов. Кнопка питания утопленная и сбоку. Ужасная веб-камера, средней паршивости звук (не за это покупал). Матовый FHD. Внутрях i5-1135G7 @ 2.40GHz (4 ядра), 32Гб одной планкой (с рассчётом на вторую в будущем), терабайт nvme.

Хотели 30 евро за отсутствие своего логотипа на крышке. Сделали в срок, довезли.

Главное, что меня удивляет, что остались производители ноутбуков в Европе. Linux'ы (Debian) поднялись с небольшими ударами в firmware-non-free бубен, всё работает, кроме подсветки клавиатуры (которая умирает после первого suspend'а). После загрузки обещают 10 часов работы; с перерывами с часу до 11, съел батарейки, достаточно, чтобы обещать, что осталось 3.5 часа. Т.е. реальных часов 8-9 будет держать.

Но пост не совсем об этом. Почему он ... медленее? Он по скорости напоминает мой ноутбук на работе и всё остальное с чем я работал.

А медленее он по сравнению с моим домашним компьютером, который на базе Ryzen 5 5600X (3700Mhz).

И знаете, где это заметно? На коде удаления виртуалок (когда их нет). У меня на домашней машине ансибл летает подозрительно быстро - 2.5с на всю плейбуку. На ноуте тот же код отрабатывает за обычные 9с.

Вы знаете, 2.5с vs 9с - это же очень, очень, много. Этого даже нельзя объяснить разницей 3.7ГГц и 2.4Ггц.

Что-то тут не так. Весь код - чистый localhost, и почему-то на райзене анисбл весьма и весьма быстрее шуршит.

userbenchmark говорит - 26% быстрее, 31% меньше latency памяти (Ryzen vs intel). Но у меня в Ryzen ECC'шная память, вовсе не top speed. Эти никак трёхкратное ускорение не объяснить. NVME? У меня и там и там. Я не думаю, что io критично для помойки от ansible (всё в файловый кеш).

Может быть, это расплата за одну планку (вместо двух)?
404

Что б такое продать, чтобы вызвать ненависть технарей?

О, придумал. soft airgap. Это как airgap, но реализованный в ПО. Очень удобно - airgap-машину можно подключить к сети в любой момент, а можно использовать специальный sdag протокол, имитирующий передачу сообщений последством вывода на экран и ввода с клавиатуры. Идеально походит для хранения особо важных серкетов компании, денег в криптокошельках, корневых сертификатов и т.д.

Помимо того, что оно airgapped, оно ещё и умеет отдавать метрики в прометеус, у него есть приятный веб-интерфейс для управлением статуса airgapped, поддержка групповых политик, авторизация через kerberos и пользовательские сертификаты TLS.

А ещё её можно запускать даже на компьютерах без аппаратной виртуализации.

Супер-технология! От создателей активной poll-based имитации пассивной защиты для реакторов!
404

Абсолютный, грандиозный успех!

Итог:
render fps: 2400 fps
draw fps: 60 fps
cpu use: 120%

или

render fps: 2100 fps
draw fps: 310 fps
cpu use: 200%

lockless rendering. Один тред считает в цикле (тупо fill новым цветом, 100% CPU в треде), второй это читает и выводит, либо asap (310 fps, 100% CPU в треде), либо по vsync (60 fps, 20% CPU в треде).

Сам код - я на питоне бы не смог написать короче. 55 строк вся библиотека (и то, я не уверен, что нужно руками clone делать). ... Уверен, вся библиотека 47 строк.

https://github.com/amarao/equart/tree/switching_to_sdl/src

Это просто счастье какое-то! Наконец-таки, у моего нового быстрого компьютера появился новый быстрый код!

Ближайший роадмп: сделать инверсию (вынести SDL в тред, в main сделать только рисование), чтобы остался только init_graphics()...

Заметим, этот же алгоритм идеально режется на параллельны треды. Каждому свой диапазон значений считать, а вывод - в общий буффер, и всё. Сравните это со старой версией (piston) - 1200+ строк, в которых ад и погибель с message'ами и копированиями буферов.

AtomicU32 вместе с Arc и Ordering::Relaxed звучит как читерство. Слишком просто, слишком волшебно, слишком легко.
404

Игрища с рандомом

Я поправил функцию рандома до 1ns (для u8). Удивительно, но ключевым решением была не борьба с ковейером процессора, а #[inline(always)], с u128 в качестве базового типа. (Как всегда, спасибо Олегу).

Проблема в том, что этого не достаточно. 2560*1440*60*4 - это 884 миллиона в секунду (1.1 ns), и это не считая всего остального (например, процесса копирования в текстуру и отправки текстуры в GPU). В целом, чтобы получить желаемые 200 fps (fade in/out примерно столько показывает) нужно делать 339 ps на один байт (плюс запас на вывод), что опасно близко к одному тику процессора (270ps/тик).

Я сейчас подошёл к интереснейшей микрозадачке rust'а (как из [u8] сделать [u128] бесплатно, т.е. с помощью typecast'а), и если мы перейдём на u128, то требования сильно упростятся. u128 - это аж 4 полных пиксела, т.е. можно иметь аж 5.4 ns на каждый рандом. Вероятнее всего, это и будет решение.

На всякий случай, вот формулы:

1/(2560*1440*200*4)*1000*1000*1000 (время на одну u8 компоненту пиксела для вывода 200 fps на 2560x1440)
1/(2560*1440*200/4)*1000*1000*1000 (время на 4 u32 пиксела для вывода 200 fps на 2560x1440)
404

wipe/secure erase

Я уже неделю занимаюсь, казалось бы, простой задачей "как вайпать диски". Я очень рад, что начал с чтения этой работы [1], потому что это задало правильные ожидания. Я начал с того, что написал wipe_canary, и что бы вы думали? На втором диске из набора в лаборатории, она триггернулась. Делаешь blkdiscard - и все данные на месте. До ужасов статьи (--secure-erase делает то же самое) я не дошёл, но...

... Но привнесение в список sas-устройств привело к тому, что из 10 (в настоящий момент) найденных firmware-assisted вайпов, между sas и sata ssd есть ровно 0 (ноль) поддерживаемых и работающих методов. Зато я нашёл как минимум две команды, которые ставят устройство в неудобную позу c сообщениями, которых я никогда в жизни раньше не видел, например:
Write same(16): Unit attention
sg_write_same failed: Unit attention

Если что, вот кандидаты на wipe'ы:


--security-erase
--security-erase-enhanced
blkdiscard
blkdiscard -s
sg_format --format
sg_unmap -f --all=0,65536
sg_sanitize --overwrite --zero # SANITIZE OVERWRITE ERASE
sg_sanitize --block # SANITIZE BLOCK ERASE
sg_sanitize --crypto # SANITIZE CRYPTO SCRAMBLE
sg_write_same --unmap --lba=0 --num 0

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

[1] https://www.usenix.org/legacy/events/fast11/tech/full_papers/Wei.pdf
404

апгрейд

(последний кусочек на сегодня)

Перевёз с помощью pvmove шифрованный раздел с одного диска на другой. Попутно нашёл мелкий wtf с переименованием самого шифрованного раздела: https://medium.com/opsops/how-to-rename-encrypted-root-volume-c6333cb72094

Починил, всё хорошо.

Говорю чуть меньшее «хорошо» асусу за отсутствие апдейтов к биосу через fwupdate. На Dell'е это было проще — зашёл, скачалось, поставилось. А тут придётся руками. Видимо, уже завтра.

Ща проверю, что без старой ssd грузится, и следующим на очереди будет home. Будет чуть сложнее, потому что у меня есть кастомный код для pam'а для расшифровки home хитрейшим образом (я про него уже писал).


404

Ну, с апгрейдом меня

Был — Core 2 Quad (4 ядра 2.5GHz), стал — AMD Ryzen 5 5600X  (6 ядер, 3.4GHz) вместе с X570-P. И, главное, я не ошибся с памятью — я сумел засунуть в Ryzen ECC'шную память. Буквально в последний момент я осознал, что буфферизованную/регистровую нельзя, и нашёл единственную опцию небуфферизованной ECC памяти (2x Kingston 16GB 3200MHz DDR4 ECC CL22)

Переезд с древней SSD Intel 320 (40Gb) на умеренно модную NVME ещё в переди (я не хочу переустанавливать систему из-за такой ерунды, как смена платформы), так что полную скорость и отзывчивость системы ещё не видно. А в принципе, переткнул устройства, настроил с какого грузиться — работает. Хотя есть несколько беспокоящих меня сообщений в dmesg, но это всё потом.

А для ощущения прироста я взял свой растовый код, взял baseline от предыдущего бенчмарка и запустил его снова.

Запись в QuadTree с использованием f64 — улучшение в 2 раза. Поиск по дереву стал быстрее в 4.6 раза.

Нового корпуса ещё нет, видеокарту/монитор я не грейдил (и рад, т.к. новые мониторы с CES'а обещаются быть особо хорошими), но look-n-feel системы стал сильно приятнее.

... Не удержался, вот бенчмарк nvme'шки. Злой бенчмарк, как и полагается от привычного к серверам человека, с fsync'ами, write through и т.д.

Надо сказать, консьюмерская nvme за сто с копейками в коротком забеге удивительно хороша. 260k+ иопсов (в сравнении с 500k у интеловского DC за килобакс). Я подозреваю, что мухлюют зверски, но для обычной десктопной нагрузки более чем.

IOPS=262k lat (usec): min=64, max=7204, avg=121.59, stdev=103.45

тест:

[job]
iodepth=32
filename=/dev/nvme0n1
readwrite=randwrite
blocksize=4k
ioengine=libaio
direct=1
time_based=1
ramp_time=2
runtime=120
buffered=0
fsync=1

... мухлёж с внутренним write-back'ом становится виден на чтении, где это чудо выжало всего 82k IOPS (RA=0). Феномен мне пока не понятен.

... Зато я знаю про форматирование. Пробую. Увы, интелы в 4k умеют форматироваться, наш герой (KINGSTON SA2000M81000G) — нет.

... пока я это писал nvme пришла в себя (видимо, флашила что-то в бэкграунде) и даёт уже более приличные 361k IOPS на чтение.

Видимо, в этом и состоит разница между 100 баксами и 1000 в контексте nvme.

Ещё, интеерсно, если write back включить, iops'ы падают с 200k+ до 4k. У меня ощущение, что этот флаг в линуксах перепутан. Нет?

Точнее, комбинация такая: write through + fsync = 260k, write back без fsync — те же 260k,  write back + fsync = 4.2k. Упс.

Ещё, код equart'а выдал

thread 1 rate: 84.36 Mpps
thread 5 rate: 85.13 Mpps
thread 3 rate: 84.96 Mpps
thread 2 rate: 84.29 Mpps
thread 4 rate: 72.06 Mpps
thread 0 rate: 72.22 Mpps

... чего явно достаточно для отрисовки 2560х1440 даже на 60Hz.

Щастье!