The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



"Зависимость времени выполнения инструкций от данных на CPU ARM и Intel"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Зависимость времени выполнения инструкций от данных на CPU ARM и Intel"  +/
Сообщение от opennews (??), 29-Янв-23, 11:31 
Эрик Биггерс (Eric Biggers), один из разработчиков шифра Adiantum и мэйнтейнер подсистемы ядра Linux fscrypt, предложил набор патчей для блокирования проблем с безопасностью, возникающих из-за особенности процессоров Intel, не гарантирующей постоянное время выполнения инструкций для разных обрабатываемых данных. В процессорах Intel проблема проявляется начиная с семейства Ice Lake. Аналогичная проблема наблюдается и в процессорах ARM...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=58569

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (1), 29-Янв-23, 11:31 
А компания AMD в домике?
Ответить | Правка | Наверх | Cообщить модератору

3. "Зависимость времени выполнения инструкций от данных на CPU A..."  –30 +/
Сообщение от Попандопала (?), 29-Янв-23, 11:33 
По-моему из за процессоры не считают,но я бы не отказался от топового амуде.D
Ответить | Правка | Наверх | Cообщить модератору

21. "Зависимость времени выполнения инструкций от данных на CPU A..."  +26 +/
Сообщение от kawaii_girl (ok), 29-Янв-23, 12:33 
На самом деле AMD топ. Особенно те AMD, которые APU(с графикой). Я недавно купила за копейки достаточно старый и бюджетный AMD APU Ryzen 3 и он спокойно тянет на линуксе киберпанк на минимальных настройках без всяких дискретных видеокарт. С более старыми или менее требовательными играми все еще лучше. И при этом процессор практически не греется.
Ответить | Правка | Наверх | Cообщить модератору

27. "Зависимость времени выполнения инструкций от данных на CPU A..."  –24 +/
Сообщение от Аноним (27), 29-Янв-23, 12:52 
Про апу это довольно смешно. Ни процессор ни видеокарта. Ни рыба ни мясо. Для работы не годится. В игры не поиграешь, код не скомпилируешь, видео не отрендеришь. По отдельности будет куда эффективнее.
Ответить | Правка | Наверх | Cообщить модератору

31. "Зависимость времени выполнения инструкций от данных на CPU A..."  +11 +/
Сообщение от kawaii_girl (ok), 29-Янв-23, 13:00 
Все зависит от ваших требований. Если вы хотите игры в 4k и 250 FPS, то не поиграешь. Но поиграть на уровне консолей практически во все современные игры вполне можно. Кстати в консолях стоят все те же APU от AMD только еще более старые. Что вам мешает работать на компьютере с APU я вообще не понимаю. По производительности они не хуже чем обычные процессоры. Да и видео рендерить тоже думаю без проблем можно.
Ответить | Правка | Наверх | Cообщить модератору

38. "Зависимость времени выполнения инструкций от данных на CPU A..."  –9 +/
Сообщение от Аноним (27), 29-Янв-23, 13:18 
Кому-то и скайрим на минималках норм, с просадками. Не надо разводить клоунаду, на уровне консолей играть собирается (т.е. эти самые просадки, мыло, и "динамическое разрешение"). Они физически не могут быть не хуже, поскольку большую часть чипа в плане энергопотребления и нагрева занимает недовидяшка, т.е. уже не процессор, и в то же время никогда не будет столь же эффективно, как с отдельным устройством для графики.
Ответить | Правка | Наверх | Cообщить модератору

41. "Зависимость времени выполнения инструкций от данных на CPU A..."  +5 +/
Сообщение от Бывалый смузихлёб (?), 29-Янв-23, 13:27 
Скайрим на минимальных-средних идёт на UHD 630 без просадок

А ведь относительно новая АМД-шная интегрированная графика гораздо шустрее упомянутой интелловской

По сути, это и рыба и мясо и даже немного курица, запечённая до хрустящей корочки

И поиграть можно и норм поработать, ноут с таким процом тонкий, легкий, энергоэффективный и шустрый, ещё и бюджетный

Ответить | Правка | Наверх | Cообщить модератору

45. "Зависимость времени выполнения инструкций от данных на CPU A..."  –1 +/
Сообщение от Аноним (27), 29-Янв-23, 13:43 
Да я помню эти восторги. Мне тут говорили, что в режиме игр за час батарейка высаживается и эти утюги всё ещё греются. Вот взял бы нормальный лаптоп с распаянной дискреткой от nvidia и играл во все игры на ультрах спокойно. И эта распаянная дискретка тоже считается недовидяшкой, если говорить о работе, ещё и от нагрева отвалиться может (поэтому качество СО имеет особенное значение и забивать на чистки не стоит). Насчёт производительности в качестве процессора, можно нагуглить сравнения в интернете, но в целом ждать от ультрабука производительности было бы несколько наивно, это понятно.
Ответить | Правка | Наверх | Cообщить модератору

102. "Зависимость времени выполнения инструкций от данных на CPU A..."  +2 +/
Сообщение от Аноним (102), 29-Янв-23, 18:52 
Говорить могли что угодно, а пруфы есть?
Ответить | Правка | Наверх | Cообщить модератору

51. "Зависимость времени выполнения инструкций от данных на CPU A..."  +2 +/
Сообщение от Аноним (51), 29-Янв-23, 14:16 
Как только начнут апушки оснащать большим объемом распаянной (или вшитой) жирной памяти (привет HBM) — большая часть дискреток станет ненужной .
Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

130. "Зависимость времени выполнения инструкций от данных на CPU A..."  –1 +/
Сообщение от _kp (ok), 29-Янв-23, 21:40 
Skyrim прекрасно идёт на 4х ядерных Atomax на их встройках с 2Гб ОЗУ. Конешно на минималках, но для 7ми дюймового планшета годно, и 4к там заведомо не требуется для игр. Это и старая игра и хорошо оптимизированная.
Гта5, кстати в силу оптимизации, тоже идет на Atom, но ОЗУ надо от 4 ГБ. Играбелностьитак себе, но для поезда сойдёт.
Больше всего удивляет, что игра вообще масштабируема до столь слабого железа.

Итого, поскольку Атом почил, и актуальные  бюджетнейшие процессоры уже мощнее, подобного класса игры на встройках идут даже не минималках.

Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

205. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Бывалый смузихлёб (?), 30-Янв-23, 16:09 
> Итого, поскольку Атом почил, и актуальные  бюджетнейшие процессоры уже мощнее, подобного
> класса игры на встройках идут даже не минималках.

Да только даже относительно-современные амуде с интегрированной графикой вообще нифига не атомы и даже не интелы( у которых в принципе для дешёвого-серднего сегмента предполагалась убогая встройка + отдельный чип видюхи и это для ноутов! Т.е ноуты с ними в принципе не могли быть компактными, дешёвыми и шустрыми )

Ну так вот, даже на UHD 630 я вполне годно играл во всякие бордерленды и иже с ними. Пробовал даже но-менс-скай( минималки, но работало и без лагов. Мб и выше работало бы, но тогда появился 4К моник и экспериментировать с режимами и разрешениями стало тупо лень ибо игра не зашла совсем )

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

Ответить | Правка | Наверх | Cообщить модератору

249. "Зависимость времени выполнения инструкций от данных на CPU A..."  –1 +/
Сообщение от Омномним (?), 31-Янв-23, 10:54 
Поиграть на ноуте? Мсье знает толк в извращениях.
В "три в ряд" разве что, ну серьёзно, для нормальной поигры даже 17" маловато.
Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

252. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Бывалый смузихлёб (?), 31-Янв-23, 12:02 
> Поиграть на ноуте? Мсье знает толк в извращениях.
> В "три в ряд" разве что, ну серьёзно, для нормальной поигры даже
> 17" маловато.

ну если экран убогий, там 1024х768 или ещё хуже - тогда да, иных причин не вижу
в целом же, с ноутом сильно удобней - можно перебраться куда угодной поудобней и там загамать а не как со стационарником

Ответить | Правка | Наверх | Cообщить модератору

253. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 31-Янв-23, 13:17 
Ну я больше фанат 65" и выше для погамалок :D
Со стационарником, ага.

1920x1080 на 65" - тоже так себе извращение, а выше APU не тянут, даже Full HD то с трудом.

Ответить | Правка | Наверх | Cообщить модератору

254. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 31-Янв-23, 13:18 
Короче ноут - это для вёбзагамалок и прочих три-в-ряд.
А так - контроллер, диван/кровать, вот это всё.
Ответить | Правка | К родителю #252 | Наверх | Cообщить модератору

304. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от pic (?), 05-Фев-23, 12:59 
Поддерживаю.
Это сильный плюс ноута против стационарного.
И именно поэтому и стрельнул Steam Deck.
Ответить | Правка | К родителю #252 | Наверх | Cообщить модератору

288. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (288), 02-Фев-23, 11:18 
> Скайрим на минимальных-средних идёт на UHD 630 без просадок
> А ведь относительно новая АМД-шная интегрированная графика гораздо шустрее упомянутой
> интелловской
> По сути, это и рыба и мясо и даже немного курица, запечённая
> до хрустящей корочки
> И поиграть можно и норм поработать, ноут с таким процом тонкий, легкий,
> энергоэффективный и шустрый, ещё и бюджетный

Когда появятся на прилавках AMD-процессоры с RDNA3 на борту, вот тогда будет разрыв, RDNA2 уже неплох. А всякие веги это так, баловство.

Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

65. "Зависимость времени выполнения инструкций от данных на CPU A..."  –2 +/
Сообщение от anonymous (??), 29-Янв-23, 15:33 
Не поделитесь ссылкой на драйвер встроенной графики для APU Ryzen, а то я как и многие для своего AMD Ryzen 7 5700U ничего найти не могу, 3d в линуксе работает через софтовую эмуляцию, какие уж тут игры.
Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

66. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от kawaii_girl (ok), 29-Янв-23, 15:48 
Странная ситуация. Для графики AMD(как дискретной, так и APU) используется свободный драйвер amdgpu , который входит в состав mesa. Какой у вас дистрибутив? У меня на Fedora 37 все сразу заработало. Только для GPU декодирования видео в браузере пришлось установить mesa-freeworld из rpmfusion.
Ответить | Правка | Наверх | Cообщить модератору

83. "Зависимость времени выполнения инструкций от данных на CPU A..."  –2 +/
Сообщение от anonymous (??), 29-Янв-23, 16:58 
Пока меня не забанили за оффтопик... Как раз федора 37 и стоит, до этого убунту 22.04 пробовал, результат тот же...EGL не ускоряется, GLX вроде как да, но надо проверять, а ведь хочется ещё OpenCL

amdgpu_device_initialize: amdgpu_query_info(ACCEL_WORKING) failed (-13)
amdgpu: amdgpu_device_initialize failed.
amdgpu_device_initialize: amdgpu_query_info(ACCEL_WORKING) failed (-13)
amdgpu: amdgpu_device_initialize failed.
EGL client extensions string:
    EGL_EXT_device_base EGL_EXT_device_enumeration EGL_EXT_device_query

GLX:
name of display: :1
display: :1  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
    GLX_ARB_context_flush_control, GLX_ARB_create_context,...

client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions: ...

Extended renderer info (GLX_MESA_query_renderer):
    Vendor: AMD (0x1002)
    Device: AMD Radeon Graphics (renoir, LLVM 15.0.6, DRM 3.49, 6.1.6-200.fc37.x86_64) (0x1638)
    Version: 22.3.3
    Accelerated: yes
    Video memory: 512MB
    Unified memory: no
...

Ответить | Правка | Наверх | Cообщить модератору

87. "Зависимость времени выполнения инструкций от данных на CPU A..."  +2 +/
Сообщение от kawaii_girl (ok), 29-Янв-23, 17:40 
>3d в линуксе работает через софтовую эмуляцию

Как это проявляется? Гном лагает? Что в настройках GNOME в пункте о системе написано? AMD Radeon или llvmpipe? Используете wayland или иксы?

Ответить | Правка | Наверх | Cообщить модератору

88. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от kawaii_girl (ok), 29-Янв-23, 17:43 
>amdgpu_device_initialize: amdgpu_query_info(ACCEL_WORKING) failed (-13)

У меня кстати не смотря на то что все работает такая же ерунда выдается если ввести команду eglinfo:

GBM platform:
amdgpu_device_initialize: amdgpu_query_info(ACCEL_WORKING) failed (-13)
amdgpu: amdgpu_device_initialize failed.
amdgpu_device_initialize: amdgpu_query_info(ACCEL_WORKING) failed (-13)
amdgpu: amdgpu_device_initialize failed.
EGL API version: 1.4

Но чуть ниже в пункте Wayland platform уже все нормально:

Wayland platform:
EGL API version: 1.5
EGL vendor string: Mesa Project
EGL version string: 1.5
EGL client APIs: OpenGL OpenGL_ES
EGL driver name: radeonsi
EGL extensions string:


Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

92. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от kawaii_girl (ok), 29-Янв-23, 17:52 
>amdgpu_device_initialize: amdgpu_query_info(ACCEL_WORKING) failed (-13) amdgpu: amdgpu_device_initialize failed.

Сейчас погуглила вот это. Это не баг и такой вывод не означает что GPU ускорение не работает.

eglinfo tries to first use /dev/dri/card0 which will fail if:
the user is not member of the correct group (usually video)
or another app is using it (gdm, X, wayland, etc)

Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

115. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (115), 29-Янв-23, 20:06 
Хорошие так-то APU, действительно. Успел поиграть на копеечном 3200U в 3-их и 5-ых героев, Divinity: Original Sin (первый), Pathfinder. И как правило делал это в окне со включенным видосом. Сам ноут правда хлипковатый, но когда у него внезапно сдох кулер, какое-то время сидел на пониженных частотах и low профиле графики - конечно греется, но не выше 90.
Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

257. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 31-Янв-23, 13:55 
Да не, ну если текстурирование отключить - даже киберкотлетить можно. Полигоны как полигоны, там текстуры не нужны по сути.
Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

263. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от kawaii_girl (ok), 31-Янв-23, 19:31 
В онлайн игры никогда не играла и не собираюсь. Не интересно. Поэтому не знаю как они работают на APU. Но нормальные сюжетные игры отлично работают. В киберпанке где-то 30Fps есть в 1080 на минимальных настройках. Работает лучше чем на Ps4) С более старыми или менее требовательными играми все еще лучше. Например Stray - выше 30 fps на средних настройках. Prey(2017) и Mass Effect Andromeda на минимальных стабильно 40-50 fps. Совсем старый Deus Ex Human Revolution(2011) отлично играется на самых максимальных настройках. Так что играть на APU вполне можно. Ну на десктопных точно, на счет ноутбуков ничего сказать не могу так как не пользовалась ноутбуками с AMD. Ну и не стоит забывать что у меня древний и бюджетный Ryzen 3 и самая дешевая оперативная память. На каком нибудь самом новом Ryzen 5 с нормальной памятью результат будет еще лучше. А можно еще и разогнать память и графику))
Ответить | Правка | Наверх | Cообщить модератору

279. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 01-Фев-23, 17:26 
Скорее мучаться, а не играть. На минималках, с просадками по FPS на сложных сценах, и т.п.
Ответить | Правка | Наверх | Cообщить модератору

280. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от kawaii_girl (ok), 01-Фев-23, 20:26 
На консолях все еще хуже) Но при этом консоли вполне себе пользуются популярностью) Так что не все так однозначно.
Ответить | Правка | Наверх | Cообщить модератору

106. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Beta Version (ok), 29-Янв-23, 19:26 
На вскидку, около 99% игр от всего каталога Стима прекрасно играются на свежих встройках. 5600G - вообще монстр и уничтожает весь лоу сегмент дискретных видеокарт. На минималках можно и в свежие ААА играть, но APU берутся не для ААА.
Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

142. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (142), 29-Янв-23, 23:02 
У меня на AMD Ryzen 7 5700U 20-30 FPS в valheim на минимальных настройках с ужасной картинкой уровня игр <2000 года, а Dark Souls Remastered на минимальных настройках не может целевые 60 кадров (но близко, играть можно)
Но у меня маленький ноутбук для работы в коворкинге, а не для игр.

AMD год назад, обещала выпустить новые APU для ноутбуков с производительностью geforce 1050, но получилось или нет не знаю. На таком можно было бы во многие игры играть.

Ответить | Правка | Наверх | Cообщить модератору

143. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (142), 29-Янв-23, 23:18 
А diablo 2 resurected работает хорошо, хотя в минимальных системных требованиях видеокарта гораздо больше чем в этом APU
Ответить | Правка | Наверх | Cообщить модератору

144. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от kawaii_girl (ok), 29-Янв-23, 23:28 
>20-30 FPS

Этого уже достаточно. Ну лично для меня. На консолях кстати игры примерно так и идут.

Ответить | Правка | К родителю #142 | Наверх | Cообщить модератору

181. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (142), 30-Янв-23, 10:30 
для valheim нет, он отвратительно дергается на такой производительности.
То есть мало того что картинка хуже чем в quake 3 1999 года, так еще и дергается ужасно.

А если снег пойдет, то вообще превращается слайдшоу.

Ответить | Правка | Наверх | Cообщить модератору

334. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (-), 09-Фев-23, 10:47 
> Этого уже достаточно. Ну лично для меня.

Ага, 20FPS, на минималках... и удовольствие от такой игры состоит в чем? Ну ладно в опенсорсные там игры или xonotic какой не за графон играют. Но в проприетарные титлы за бабки на минималках и мизерном фпс?!

Ответить | Правка | К родителю #144 | Наверх | Cообщить модератору

339. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от kawaii_girl (ok), 09-Фев-23, 12:30 
>20FPS, на минималках

Все таки обычно ближе к 30) И это в киберпанке. В более старых и менее требовательных играх ситуация значительно лучше.

>не за графон играют

Мне вообще все равно на "графон". Я играю ради сюжета и атмосферы.

Ответить | Правка | Наверх | Cообщить модератору

147. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Beta Version (ok), 29-Янв-23, 23:37 
> У меня на AMD Ryzen 7 5700U 20-30 FPS в valheim на
> минимальных настройках с ужасной картинкой уровня игр <2000 года, а Dark
> Souls Remastered на минимальных настройках не может целевые 60 кадров (но
> близко, играть можно)
> Но у меня маленький ноутбук для работы в коворкинге, а не для
> игр.

Многое зависит от оптимизации конкретных игр и от самого ноутбука, какой у него охлад и какие частоты в нём берёт процессор. У мелких ноутов с этим всё похуже, но вообще, 5700U способен брать 25-30 фпс в Elden Ring в 1080р. Но как я сказал, это не те игры, в которые играют на ноутбучных и даже десктопных встройках.

> AMD год назад, обещала выпустить новые APU для ноутбуков с производительностью geforce
> 1050, но получилось или нет не знаю. На таком можно было
> бы во многие игры играть.

Phoenix называться будут. Во второй половине этого года должный выйти и там обещают скачок в два раза по сравнению с нынешними встройками, а это уже в районе rx570/gtx1060.

Ответить | Правка | К родителю #142 | Наверх | Cообщить модератору

153. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от kawaii_girl (ok), 29-Янв-23, 23:57 
>и даже десктопных встройках

Я собрала компьютер на APU Ryzen специально чтобы играть в тяжелые игры) Видеокарты дорого стоят. А те что можно найти по приемлемой цене не сильно лучше APU. К тому же с APU можно собрать ПК в компактном корпусе и не заморачиваться с мощным блоком питания. Так что не все так однозначно)

Ответить | Правка | Наверх | Cообщить модератору

157. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Beta Version (ok), 30-Янв-23, 00:19 
Если устраивают низкие настройки и иногда даже 720p, то ок. Большинство геймеров такие настройки не устроят, потому встройки и не берутся под ААА.

А по поводу БП: система с RX 6600 при полной нагрузке будет кушать не более 200W. Сейчас такие БП, наверное, уже и не продают, и самые слабые идут с 400W-500W. Так что за встройками разве что компактность. Но вы видели RX 6600 Pulse? Она размером чуть больше мужской ладони. Не влезет разве что в совсем уж малёхонький корпус.

Но опять же, если встройки хватает, то и дискретка не нужна.

Ответить | Правка | Наверх | Cообщить модератору

336. "Зависимость времени выполнения инструкций от данных на CPU A..."  –1 +/
Сообщение от Аноним (-), 09-Фев-23, 11:01 
Питальник лучше с запасом взять и хороший. Иначе потом будете чертыхаться и менять погоревшее железо. При том гарантия к тому моменту, конечно, уже закончится.
Ответить | Правка | Наверх | Cообщить модератору

335. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (-), 09-Фев-23, 10:56 
> Я собрала компьютер на APU Ryzen специально чтобы играть в тяжелые игры)
> Видеокарты дорого стоят. А те что можно найти по приемлемой цене
> не сильно лучше APU.

Вообще-то сильно - если VRAM своя, это все же скоростная память на дополнительной ОТДЕЛЬНОЙ шине, и это суммируется к процу и его шине а не дерется с ним несчастным за доступ в системнуж оперативу. Из за вот этого вот APU и не способны к нормальному рендеру с культурным FPS'ом.

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

> К тому же с APU можно собрать ПК в компактном корпусе

А смысл экономить место в стационаре? Зарубить себе возможности апгрейда, установки пачки винчей для жирной хранилки и проч?

> и не заморачиваться с мощным блоком питания.
> Так что не все так однозначно)

А зачем надо десктопник который будет хуже ноута - и без возможности апгрейда? К тому же как угодно но хорошие питальники, увы, только мощные бывают.

А китайский мусор... ну он работает. До поры до времени. А вон там юзер с элегантной такой дырочкой в чипсете мамки. У питальника в дежурке кондер высох, а защита была чисто номинальная, он и выгрузил 6.5 вольт вместо 5 в дежурку. Мамка на это обиделась и в кристалле чипсета образовалась маленькая аккуратная дырка. Питальник то я за 2 минуты пофиксил сменив кондер, да еще и вечным сделал, но вот 150-баксовая мамка теперь только набор запчастей, куда ее с дырочкой в чипсете такую теперь? :). В общем китайские питальники - на любителя. Сам и по себе они содраны с остальных, но вот такие маленькие нюансы как немного не работающая защита могут очень сильно расстроить при случае.

Ответить | Правка | К родителю #153 | Наверх | Cообщить модератору

340. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от kawaii_girl (ok), 09-Фев-23, 12:42 
>А смысл экономить место в стационаре?

Огромный гроб у меня на стол не помещается. К тому же большой корпус не только большой, но и тяжелый) Такой снять со стола для обслуживания целая проблема)

>установки пачки винчей

У меня установлено 2 SSD(Nvme и sata) и HDD ноутбучного формата на 1Тб. Все помещается в компактном корпусе толщиной где-то 10-12 см.

>хорошие питальники, увы, только мощные бывают

Я купила в комиссионке корпус, который сразу был с блоком питания на 300W. Блок какой-то powerman. Это хороший или нет?

Ответить | Правка | Наверх | Cообщить модератору

94. "Зависимость времени выполнения инструкций от данных на CPU A..."  –1 +/
Сообщение от Аноним (-), 29-Янв-23, 18:27 
Есть один нюанс: покомпилировать лучше будет на двухсокетной материночке, а делают их в основном для синего.
Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

104. "Зависимость времени выполнения инструкций от данных на CPU A..."  –1 +/
Сообщение от anonymous (??), 29-Янв-23, 19:15 
Спасибо за информацию. В целом вы ответили на мой вопрос, вы и я используем драйвер mesa. Даже не знаю хорошо ли это, учитывая неоднозначную репутацию этого проекта, но выбора нет. Сейчас посмотрел вывод  на десктопе, где стоит драйвер с сайта амд (rocm) , там такая же ругань на EGL, походу надо забить на это и радоваться жизни.
Ответить | Правка | Наверх | Cообщить модератору

127. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Аноним (102), 29-Янв-23, 21:23 
Зачем двухсокет для компиляции? Что за бред?
Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

145. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Аноним (-), 29-Янв-23, 23:30 
Для компиляции EPYC рулят... проверено Торвальдсом и ко.
Ответить | Правка | Наверх | Cообщить модератору

174. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Омномним (?), 30-Янв-23, 09:59 
Отличные CPU.

После перевода серверной фермы на AMD все безумные проблемы (например с бросками производительности из-за AVX; постоянно роняющими производительность патчами для разных мылдаунов и L1TF; паттернами работы VM, не дружащими с кольцевой архитектурой шины, и т.д. и т.п.) - закончились.

Дома правда всегда были AMD, но вот сейчас стоит 5950X - тоже нарадоваться не могу.
LGA'шный вариант пробовать не буду до последнего - к LGA стойкое отвращение.

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

70. "Зависимость времени выполнения инструкций от данных на CPU A..."  +4 +/
Сообщение от Лиза Су (?), 29-Янв-23, 16:12 
В компании AMD понимают, что поднимать производительность за счёт безопасности потом боком выйдет. Поэтому AMD и на коне. Молодцы.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

210. "Зависимость времени выполнения инструкций от данных на CPU A..."  –1 +/
Сообщение от Аноним (210), 30-Янв-23, 18:23 
Просто они до таких оптимизаций еще не дошли.
Ответить | Правка | Наверх | Cообщить модератору

265. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Michael Shigorinemail (ok), 01-Фев-23, 01:18 
Знаете, в _этой_ спецолимпиаде не факт, что стоит быть первым.

// отправлено с эльбруса

Ответить | Правка | Наверх | Cообщить модератору

82. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Аноним (82), 29-Янв-23, 16:54 
>AMD в домике?

В одном домике со всеми :)
https://www.opennet.ru/keywords/amd.html

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

2. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Попандопала (?), 29-Янв-23, 11:32 
Чего еще остается довольно быстрым в ядре линукс? БСД так себе в ногу не стреляет.
Ответить | Правка | Наверх | Cообщить модератору

7. "Зависимость времени выполнения инструкций от данных на CPU A..."  –5 +/
Сообщение от Аноним (7), 29-Янв-23, 11:44 
Поэтому БСД и не может стоять в ответственных местах.
Ответить | Правка | Наверх | Cообщить модератору

52. "Зависимость времени выполнения инструкций от данных на CPU A..."  +4 +/
Сообщение от Аноним (1), 29-Янв-23, 14:16 
А Juniper-то и не в курсе
Ответить | Правка | Наверх | Cообщить модератору

60. "Зависимость времени выполнения инструкций от данных на CPU A..."  +2 +/
Сообщение от name (??), 29-Янв-23, 14:58 
Juniper уже перешел на linux. Бздя может и осталась где-то в неподдерживаемых устаревших железках. Все новое делается на линуксе, инсайд инфа.
Ответить | Правка | Наверх | Cообщить модератору

231. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (-), 31-Янв-23, 07:37 
> Juniper уже перешел на linux. Бздя может и осталась где-то в неподдерживаемых
> устаревших железках. Все новое делается на линуксе, инсайд инфа.

"И ты, Брут^W Джун?"

Ответить | Правка | Наверх | Cообщить модератору

259. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от name (??), 31-Янв-23, 14:58 
Чего? Я там работаю.
Ответить | Правка | Наверх | Cообщить модератору

316. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (-), 06-Фев-23, 05:01 
> Чего? Я там работаю.

Я про Джунипера пославшего фрю. Ее все чего-то в последнее время посылают. Видимо задолбались на концепции наяривать без должной отдачи. Как-то так?

Ответить | Правка | Наверх | Cообщить модератору

277. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (277), 01-Фев-23, 12:53 
Juniper перешел на Linux, нетфликс скатился в BLM, мндя.
Аргументы и факты заканчиваются :)
Ответить | Правка | К родителю #231 | Наверх | Cообщить модератору

317. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (-), 06-Фев-23, 05:05 
> Juniper перешел на Linux, нетфликс скатился в BLM, мндя.
> Аргументы и факты заканчиваются :)

Как сказал недавно Торвальдс есть 2 варианта взаимодействий с реальностью в ситуации когда модель которую вы себе там отстроили не стыкуется с наблюдаемыми фактами.
- Можно исправить чертову модель под соответствие наблюдаемым фактам.
- Жить в стране бла-бла-бла и розовых пони.

Ну вот модель разработки фбсд кажется идет по второму маршруту. Что не нравится инвесторам.

Ответить | Правка | Наверх | Cообщить модератору

16. "Зависимость времени выполнения инструкций от данных на CPU A..."  –7 +/
Сообщение от Igraine (ok), 29-Янв-23, 12:24 
Возможно поэтому freebsd перестали использовать на серверах
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

146. "Зависимость времени выполнения инструкций от данных на CPU A..."  +2 +/
Сообщение от Аноним (-), 29-Янв-23, 23:33 
> БСД так себе в ногу не стреляет.

Правильно, они гранатой в футбол играют. Это веселее.

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

4. "Зависимость времени выполнения инструкций от данных на CPU A..."  +40 +/
Сообщение от InuYasha (??), 29-Янв-23, 11:34 
Получается, на компьютеры уже впору возвращать кнопку "Турбо" - для переключения режимов "Безопасность" и "Производительность".
Ответить | Правка | Наверх | Cообщить модератору

5. "Зависимость времени выполнения инструкций от данных на CPU A..."  –7 +/
Сообщение от Попандопала (?), 29-Янв-23, 11:36 
А ведь вы гениальный чел.XD Почему возврощать? Неужели такое уже было...%
Ответить | Правка | Наверх | Cообщить модератору

10. "Зависимость времени выполнения инструкций от данных на CPU A..."  +3 +/
Сообщение от Анонимemail (10), 29-Янв-23, 11:51 
Было: ппреключало проц 286 в режим работы 86-го - для нормальной работы программ, которые зависели от частоты процессора. То есть эта кнопка нормально была нажата.
Ответить | Правка | Наверх | Cообщить модератору

120. "Зависимость времени выполнения инструкций от данных на CPU A..."  +3 +/
Сообщение от Аноним (120), 29-Янв-23, 20:45 
А вот на 486-х эти режимы отображались на 7-сегментном индикаторе в виде весёлых надписей "LO" и HI" ;)
Ответить | Правка | Наверх | Cообщить модератору

175. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Омномним (?), 30-Янв-23, 10:01 
Почему на 486? Лохи ещё на первых AT-корпусах под 286 были.
Ответить | Правка | Наверх | Cообщить модератору

177. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Аноним (177), 30-Янв-23, 10:10 
Там джамперами что угодно выставлялось.
Ответить | Правка | К родителю #120 | Наверх | Cообщить модератору

189. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от InuYasha (??), 30-Янв-23, 13:02 
Помню как сильно расстроился когда об этом узнал - думал, там реально частота отображается :(
Ответить | Правка | Наверх | Cообщить модератору

232. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Аноним (-), 31-Янв-23, 07:39 
> Помню как сильно расстроился когда об этом узнал - думал, там реально
> частота отображается :(

Зато сейчас можешь себе такой на микроконтроллере запилить, только если на нем честно DVFS показывать - задолбает в край.

Ответить | Правка | Наверх | Cообщить модератору

246. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 31-Янв-23, 10:47 
Не везде. Бывали и с жёсткой пропайкой )
Ответить | Правка | К родителю #177 | Наверх | Cообщить модератору

11. "Зависимость времени выполнения инструкций от данных на CPU A..."  +4 +/
Сообщение от Zenitur (ok), 29-Янв-23, 11:52 
https://joyreactor.cc/post/2283880 вот тут рядом с надписью HI две кнопки: Reset и Turbo.

https://img.icity.life//upload/2022/278/768/ed9/full/768ed9a...
https://hsto.org/webt/ic/rz/ly/icrzlyhiqgcevlqg0ghic0on3pq.jpeg

Только это не про безопасность, а про совместимость

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

12. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (12), 29-Янв-23, 12:13 
В реальности на более современных на тот момент системах ничего не менялось.
Ответить | Правка | Наверх | Cообщить модератору

63. "Зависимость времени выполнения инструкций от данных на CPU A..."  +4 +/
Сообщение от Аноним (63), 29-Янв-23, 15:03 
Менялось.  У нас на кафедре в 1990 году стояла Turbo XT. При включении тактовая частота процессора возрастала со штатных 4.77 мГц до целых восьми. Разница в том же Pacman и других игрушках была вполне заметна, да и всякое добро на фортране компилилось пошустрее.
Ответить | Правка | Наверх | Cообщить модератору

133. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Аноним (133), 29-Янв-23, 22:24 
только вот ПК в корпусах с кнопками турбо продавались до середины нулевых, кнопка турбо там ничего не делала
Ответить | Правка | Наверх | Cообщить модератору

164. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Аноним (63), 30-Янв-23, 07:31 
Начиная с первых пентиумов эта кнопка действительно стала чисто декоративной, тут ты прав. Но я писал про машину, на которой лично работал в 1990 году, 32 с половиной года назад (СФ МЭИ, электромеханический факультет). Кнопка "турбо" там реально работала. Машинка не была уникальной, подобные выпускались, к примеру, Eagle Computers. Цитирую PC Tech Journal за июль 1984 года: "Eagle Computer Inc. introduced an upgrade to the Eagle PC to be called the "Eagle PC Turbo GT" (at first I thought it was a sports car). The 8086-based machine has a "Turbo" button on the front panel. Press it and the machine switches from the PC/XT compatible clock speed of 4.77 Mhz to 8 Mhz. High-speed RAM chips are used with no wait states, so that the machine runs at full speed with performance claimed to be two to three times faster than the standard IBM PC/XT" или декабрьский номер PC Magazine за тот же 1984 год: "The new Eagle uses an 8086 CPU with an 8-MHz clock and a 16-bit data path. Compared with the IBM PC's 8-bit (data path) 8088 which clocks in at just 4.77 MHz. the PC Turbo is a very fast engine indeed, even without adding the optional 8087 coprocessor in the empty socket provided for it. In fact, it is so fast that Eagle had to include a front-panel pushbutton to slow down operations by inserting extra wait states when required for PC-compatibility. The Norton Syslnfo diagnostic program rated the speed of the Eagle PC Turbo-XL in its slow mode at 1 .4 times that of the PC, and full-bore performance measured 1.8 times the PC's speed".
Ответить | Правка | Наверх | Cообщить модератору

179. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 30-Янв-23, 10:25 
На PC/XT, которые шли на 8086, а не 8088, была уже кнопка, работал на таком.
Только индикатора с лохами не было.
Ответить | Правка | Наверх | Cообщить модератору

182. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Аноним (63), 30-Янв-23, 10:55 
О чем я и толкую тому анониму. Кнопка была, тактовую частоту реально переключала. Вместо индикатора - лампочка на корпусе. Сборка белая, если кто-нибудь помнит сленг тех времен:). Когда у нас в Смоленске через пару лет наладили выпуск своих IBM-совместимых машин, туда эту фичу тоже скопировали (https://sfrolov.livejournal.com/101365.html - я такие видел и кнопка "турбо" там тоже была и работала).
Ответить | Правка | Наверх | Cообщить модератору

217. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от _kp (ok), 30-Янв-23, 21:58 
> На PC/XT, которые шли на 8086, а не 8088, была уже кнопка,
> работал на таком.
> Только индикатора с лохами не было.

На 8086 быстрых XT не было, были на 80186, NEC V**..
Но это не важно, как добавили скоростной режим, добавили и кнопку тормоза.
Главное, что добавили рано, что б отучить привязываться к частоте процессора и тактам.

А на Пентиумах, если материнка поддерживала переключение частоты, то кнопка использовалась для понижения частоты уже для программ с ошибкой 200, которые на 16 битном делении выпадали в осадок от быстродействия.


Ответить | Правка | К родителю #179 | Наверх | Cообщить модератору

247. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 31-Янв-23, 10:50 
Я честно говоря не помню точно, именно на 8086 или всё-таки наоборот, на 8088, но они "тогглились" с 4.77 на 8 MHz.
Ответить | Правка | Наверх | Cообщить модератору

248. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 31-Янв-23, 10:51 
Но это были именно PC XT в их "классическом" корпусе, и точно 808x. Номер модели не помню.
Ответить | Правка | К родителю #217 | Наверх | Cообщить модератору

223. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Neon (??), 31-Янв-23, 01:07 
Не фига, видел машинку, на которой кнопка турбо отключала кеш у первопня
Ответить | Правка | К родителю #164 | Наверх | Cообщить модератору

266. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Michael Shigorinemail (ok), 01-Фев-23, 01:21 
> Но я писал про машину, на которой лично работал в 1990 году, 32 с половиной года назад

Сходите в яндекс-музей, чуток помолодеете :)

Ответить | Правка | К родителю #164 | Наверх | Cообщить модератору

222. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Neon (??), 31-Янв-23, 01:06 
Была машинки, на которой кнопка турбо отключала кэш и 486 или пень превращался в 386
Ответить | Правка | К родителю #133 | Наверх | Cообщить модератору

14. "Зависимость времени выполнения инструкций от данных на CPU A..."  +3 +/
Сообщение от Попандопала (?), 29-Янв-23, 12:17 
Спасибо. Проектировщики были раньше с мозгами похоже.
Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

25. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (27), 29-Янв-23, 12:48 
В то время было проще решить задачу выведя дополнительную кнопку с платы, в остальном то же самое. Было ли это удобно? Конечно, нет. Но тут уже маркетологи подсуетились.
Ответить | Правка | Наверх | Cообщить модератору

97. "Зависимость времени выполнения инструкций от данных на CPU A..."  –1 +/
Сообщение от Урри (ok), 29-Янв-23, 18:37 
Типа сейчас нельзя частоты через биос увеличивать.
Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

134. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Аноним (133), 29-Янв-23, 22:25 
вообще-то как раз сейчас и нельзя нормально увеличивать по сравнению с биосами на ASRock под amd из нулевых
Ответить | Правка | Наверх | Cообщить модератору

176. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от maximnik0 (?), 30-Янв-23, 10:04 
>вообще-то как раз сейчас и нельзя нормально

Смешно.Если искать можно найти.Мне когда то тут ткнули пальцем -китайцы оказывается что угодно выпускают.Есть 4 летней давности материнские платы с Isa шиной (1-2 слота) под предыдущего поколение пентиум.
Моя материнка к сожелению не новая
но турбиниться отлично MSI X470 GAMING PLUS MAX -можно задать в Uefi горячую кнопку на турбо режим или при загрузке выбрать профиль -для АМД сокет АМ4 .

Ответить | Правка | Наверх | Cообщить модератору

185. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Омномним (?), 30-Янв-23, 11:29 
Ну вообще сейчас это и не требуется, так как процы внутри себя делают "турбо" в реальном времени, по мере возможности.
Ответить | Правка | К родителю #134 | Наверх | Cообщить модератору

191. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от InuYasha (??), 30-Янв-23, 13:05 
но всё равно иметь такую кнопку - прикольно, разве нет? :)
К тому же, всякие материнщики любят свои "оверклокерские" утилиты делать настолько вырвиглазными, что лучше их и не запускать вовсе.
Ответить | Правка | Наверх | Cообщить модератору

245. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 31-Янв-23, 10:44 
Ну эту кнопку сейчас приделать не просто, а очень просто.
Пихаем на USB в виде доп. клавиатурной клавиши (контроллеры копейки стоят), вешаем макрос к той самой утилите :D
Ответить | Правка | Наверх | Cообщить модератору

201. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от maximnik0 (?), 30-Янв-23, 15:34 
>Ну вообще сейчас это и не требуется

Иногда для однопоточных приложений требуется.Беда в том что в этом случае требуется на остальных ядрах понизить частоту или их отключить, и редко где это можно выставить.В Линукс хитрый алгоритм ,перекидывает нагруженную однопоточку по ядрам чтобы перегрева не было. А ещё на некоторых материнках можно было принудительно снизить частоты из консоли скриптом. В оффтопике конечно тоже есть утилиты,но нет перекидывания задания планировщиком.Правда это вроде дело сейчас поправили и на новых ядрах (что Интел ,что АМД) с однопоточностью дело улучшили.

Ответить | Правка | К родителю #185 | Наверх | Cообщить модератору

224. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Neon (??), 31-Янв-23, 01:08 
Ну так нужно в биос заходить. А тут прямо во время работы можно было кнопку нажать и поехало быстрее или медленнее.))) Без всяких биосов и программ, чисто аппаратно
Ответить | Правка | К родителю #97 | Наверх | Cообщить модератору

194. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Zenitur (ok), 30-Янв-23, 14:21 
> Спасибо. Проектировщики были раньше с мозгами похоже.

Да, я тоже так считаю. Однако кое в чём я с ними не согласен.

Когда вышел 286 процессор, Microsoft бойкотировала новый защищённый режим. Сказала, что из этого защищённого режима нельзя выйти обратно в реальный режим.

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

Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

218. "Зависимость времени выполнения инструкций от данных на CPU A..."  +3 +/
Сообщение от _kp (ok), 30-Янв-23, 22:09 

> Когда вышел 286 процессор, Microsoft бойкотировала новый защищённый режим.

Не то что б бойкотировала, но без поддержки выхода из него в биос, через очень быструю перезагрузку с сохранением состояния, защищенный режим был тупо бесполезен, ибо невозможность запустить Dos приложение, делала тогда Windows не востребованным.
А как только появился биос с поддержкой, то добавили в  Windows 3.

>> Или выйти из программы, перезагрузить компьютер, и запустить другую?

Тогда и для загрузки DOS, даже с жесткого диска, требовалость время.
А Windows 3.0 уже позволял поочередно пользоваться DOS приложениями, других то ещё почти не было, и быстро переключаться между ними, что тогда было круто.
А одновременно работало, и впрлне вменяемо, уже на 386 процессорах, на Windows 3.1.

Ответить | Правка | Наверх | Cообщить модератору

251. "Зависимость времени выполнения инструкций от данных на CPU A..."  +2 +/
Сообщение от Zenitur (ok), 31-Янв-23, 12:00 
> Тогда и для загрузки DOS, даже с жесткого диска, требовалость время.

Действительно. Я об этом и не подумал. В 2002 году у меня был дуалбут WinME/WinXP, и мне как-то нормально было перезагрузиться, чтобы поиграть в игру, которая на XP не работала. Я и забыл про харды на 20 Мб от Seagate, которыми пользовались в 80-е годы, как и о том, какая у них была скорость...

> ибо невозможность запустить Dos приложение, делала тогда Windows не востребованным

Так вот зачем Microsoft ломала через колено Intel... Как-то и не задумывался раньше, что во времена Windows 2.0 и 3.0 софта конкретно для винды и не было-то толком, и винда использовалась, как возможность запустить несколько DOS-приложений... Это как использовать "иксы" без DE - тупо чтоб несколько торминалов иметь на одном экране...
https://user-images.githubusercontent.com/92415328/142074353...

Ответить | Правка | Наверх | Cообщить модератору

225. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Neon (??), 31-Янв-23, 01:10 
Ну не "шмогла"...
Ответить | Правка | К родителю #194 | Наверх | Cообщить модератору

62. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от ВредныйАнон (?), 29-Янв-23, 15:03 
Тогда у малвари и хацкеров появится новый способ атаки. Они просто будут нещадно грузить компьютер юзвера (или организации), в надежде что тому (или организации) надоест тормоза и он переведет компьютер в более быстрый, но зато и более уязвимый, режим работы.
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

71. "Зависимость времени выполнения инструкций от данных на CPU A..."  +8 +/
Сообщение от Аноним (71), 29-Янв-23, 16:16 
Не актуален такой способ "атаки". Эффективные менеджеры и продуктивные разработчики в Mozilla, Google, Canonical, Fedora, GNOME и Rust за них всю работу уже сделали.
Ответить | Правка | Наверх | Cообщить модератору

211. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (211), 30-Янв-23, 19:04 
Ну тогда уж свинцовые трусы, иначе никак
Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

95. "Зависимость времени выполнения инструкций от данных на CPU A..."  +7 +/
Сообщение от pavlinux (ok), 29-Янв-23, 18:28 
>  уже впору возвращать кнопку "Турбо"

# sudo apt install msr-tools

И прилепи на хоткей любимого DM

;; "Режим Тормоз"
# sudo wrmsr -a 0x00001b01 0x00000001;

;; "Режим Турбо"
# sudo wrmsr -a 0x00001b01 0x00000000;


Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

6. "Зависимость времени выполнения инструкций от данных на CPU A..."  +7 +/
Сообщение от Аноним (6), 29-Янв-23, 11:41 
Интел и амд долгие годы занимались читерством, ускоряя процессоры на проценты и увеличивая сложность на порядки. Сейчас пришел час расплаты.
Ответить | Правка | Наверх | Cообщить модератору

8. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (8), 29-Янв-23, 11:44 
Почему читерством?
Ответить | Правка | Наверх | Cообщить модератору

20. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Анонимemail (20), 29-Янв-23, 12:32 
Потому что вместо увеличения количества транзисторов, частоты, кеша, оптимизации архитектуры (то есть "честных" методов) придумывали всю эту катавасию со спекулятивными вычислениями и пр.
Ответить | Правка | Наверх | Cообщить модератору

30. "Зависимость времени выполнения инструкций от данных на CPU A..."  +10 +/
Сообщение от ИмяХ (?), 29-Янв-23, 12:57 
спекулятивное вычисление это и есть оптимизация архитектуры
Ответить | Правка | Наверх | Cообщить модератору

32. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (32), 29-Янв-23, 13:05 
ага, а вирусы это программы которые оптимизируют пользовательские данные
Ответить | Правка | Наверх | Cообщить модератору

34. "Зависимость времени выполнения инструкций от данных на CPU A..."  –1 +/
Сообщение от Аноним (142), 29-Янв-23, 13:09 
Любител Интел, амд и других читерских спекулятивных процессоров скоро и не такого договорятся.
Ответить | Правка | Наверх | Cообщить модератору

93. "Зависимость времени выполнения инструкций от данных на CPU A..."  +4 +/
Сообщение от Аноним (93), 29-Янв-23, 18:19 
Угу, вирусы - это санитары данных. Они нападают в основном на самые старые и больные машины.
Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

36. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Анонимemail (20), 29-Янв-23, 13:15 
> спекулятивное вычисление это и есть оптимизация архитектуры

Ну это как посмотреть. Я тоже могу сказать, что установка чита -- это оптимизация моих игровых навыков. Чем это отличается от, например, покупки монитора с большим динамическим диапазоном, что бы лучше видеть врага в темноте? Принципиально -- ничем. Но очевидно, что одно "честно", а другое -- "не честно".

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

Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

49. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от ИмяХ (?), 29-Янв-23, 14:07 
Причём тут ваши игровые понятия "честно" или "нечестно"? Компьютер должен работать и выполнять свои задачи, а не соревноваться с какой-то мифической "справедливостью." И где вы тут вред увидели? То что кто-то увидит кашу данных из кэша прецессора? Да ради Бога, пусть смотрят, тот компьютер, в котором у меня есть, что скрывать, вообще к интернету не подключён.
Ответить | Правка | Наверх | Cообщить модератору

64. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Albertio (ok), 29-Янв-23, 15:21 
К сожалению, сегодня ваши данные могут украсть даже если просто оставить открытой форточку в комнате с компьютером. Так что отключение от интернета не так много даст.
Ответить | Правка | Наверх | Cообщить модератору

74. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Аноним (71), 29-Янв-23, 16:23 
Радиоуправляемая стрекоза залетит с камерой, не иначе.
Ответить | Правка | Наверх | Cообщить модератору

192. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от InuYasha (??), 30-Янв-23, 14:16 
> Радиоуправляемая стрекоза залетит с камерой, не иначе.

На самом деле это не шутка - в ДАРПА уже 10 лет (это из публично известного) занимаются управляемыми насекомыми.

Ответить | Правка | Наверх | Cообщить модератору

105. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (142), 29-Янв-23, 19:25 
Зачем спорить с тем кто не понимает о чем пишет?
У Орелла был описан "речекряк":
"членораздельная речь будет рождаться непосредственно в гортани, без участия высших нервных центров."
Механизм похожий на то что происходит в комментариях.
Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

128. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (142), 29-Янв-23, 21:29 
*Оруэлла
Ответить | Правка | Наверх | Cообщить модератору

226. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Neon (??), 31-Янв-23, 01:12 
Оруэлл на Западе давно уже реальность. Когда негра нельзя назвать негром, а pi2-раза тем, кем он есть.)))
Ответить | Правка | К родителю #105 | Наверх | Cообщить модератору

123. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Анонимemail (20), 29-Янв-23, 20:54 
> Причём тут ваши игровые понятия "честно" или "нечестно"? Компьютер должен работать и
> выполнять свои задачи, а не соревноваться с какой-то мифической "справедливостью." И
> где вы тут вред увидели? То что кто-то увидит кашу данных
> из кэша прецессора? Да ради Бога, пусть смотрят, тот компьютер, в
> котором у меня есть, что скрывать, вообще к интернету не подключён.

Причём? Тут выше спрашивали, почему "читерство". Я и ответил, почему. А про вред -- можете поинтересоваться эксплоитами, основанными на этом спекулятивном выполнении. Они могут за определённое время, например, вытаскивать из памяти ключи шифрования и другие чуствительные данные.

Понятно, что неуловимого Джо этим не испугаешь, но вред всё таки есть.

Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

219. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от _kp (ok), 30-Янв-23, 22:11 
Действительно, не на всяком компе есть "ценные" данные, и причем на большинстве их точно нет.


Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

108. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (108), 29-Янв-23, 19:33 
>Чем это отличается от, например, покупки монитора с большим динамическим диапазоном, что бы лучше видеть врага в темноте? Принципиально -- ничем.

Тем, что на соревнованиях мониторы предостаявляет организатор.

Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

33. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (142), 29-Янв-23, 13:06 
Глупым инженерами из Интел и АМД никогда не понять того что очевидно любому опеннет эксперту.
Понапридумывают спекуляций, а потом процессоры тормозят!
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

35. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Анонимemail (20), 29-Янв-23, 13:10 
> Глупым инженерами из Интел и АМД никогда не понять того что очевидно
> любому опеннет эксперту.
> Понапридумывают спекуляций, а потом процессоры тормозят!

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

Ответить | Правка | Наверх | Cообщить модератору

96. Скрыто модератором  –1 +/
Сообщение от Аноним (-), 29-Янв-23, 18:28 
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

9. "Зависимость времени выполнения инструкций от данных на CPU A..."  –1 +/
Сообщение от Аноним (7), 29-Янв-23, 11:51 
Как не станно, это не читерство, а оптимизация схем.
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

13. "Зависимость времени выполнения инструкций от данных на CPU A..."  –3 +/
Сообщение от Аноним (12), 29-Янв-23, 12:13 
Ты хотел сказать разработками передовой техники.
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

17. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (17), 29-Янв-23, 12:28 
Он хотел сказать, что так не может )
Ответить | Правка | Наверх | Cообщить модератору

18. "Зависимость времени выполнения инструкций от данных на CPU A..."  +2 +/
Сообщение от Аноним (18), 29-Янв-23, 12:29 
Штеуд и нвидия занимались, молодой человек, учите историю, если опоздали родиться. Сколько было скандалов, включая знаменитый палец Линуса. Амуде не настолько скурвилась.
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

22. "Зависимость времени выполнения инструкций от данных на CPU A..."  +3 +/
Сообщение от kawaii_girl (ok), 29-Янв-23, 12:39 
Да, amd действительно лучше. В AMD нет таких серьезных проблем с безопасностью и встроенная графика сильно лучше. Я вот думаю и ноутбук поменять на что нибудь с AMD, а то с этими всеми патчами он скоро лагать начнет. Жалко что thinkpad с amd не делают, а у других могут быть сложности с линуксом и не будет trackpoint, к которому я уже привыкла(
Ответить | Правка | Наверх | Cообщить модератору

23. "Зависимость времени выполнения инструкций от данных на CPU A..."  –2 +/
Сообщение от Аноним (27), 29-Янв-23, 12:45 
Нет такого лучше/хуже. Зависит от задач и конкретного набора железа, но, если взять амд, можно пожалеть не один раз, и с интелом о многих вещах думать не придётся никогда.
Ответить | Правка | Наверх | Cообщить модератору

37. "Зависимость времени выполнения инструкций от данных на CPU A..."  +2 +/
Сообщение от Аноним (32), 29-Янв-23, 13:17 
ага, intel особенно помогает думать при очередном патче калечащей производительность в минус, что уже начинаешь подумывать о законе Мура но тока уже для дырок в intel.
Ответить | Правка | Наверх | Cообщить модератору

39. "Зависимость времени выполнения инструкций от данных на CPU A..."  –1 +/
Сообщение от Аноним (27), 29-Янв-23, 13:23 
Не нравится, не используй заплатки. На практике вообще не заметно и никак не измеримо. Да и большинство уязвимостей на любых процессорах обнаруживаются. И там, где ищут, раньше, только и всего
Ответить | Правка | Наверх | Cообщить модератору

48. "Зависимость времени выполнения инструкций от данных на CPU A..."  –1 +/
Сообщение от Аноним (32), 29-Янв-23, 14:06 
>с интелом о многих вещах думать не придётся никогда.
>Не нравится, не используй заплатки.

Безопасности или производительности, вот в чём вопрос.
Достойно ль смиряться под ударами судьбы,
Иль надо оказать сопротивление
И в смертной схватке с целым морем бед
Покончить с ними? Умереть. Забыться.
И знать, что этим обрываешь цепь
Сердечных мук и тысячи лишений, Присущих Intel.
Это ли не цель Желанная? Скончаться.
Сном забыться. Уснуть... и видеть сны? Вот и ответ.

>На практике вообще не заметно и никак не измеримо.

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

Ответить | Правка | Наверх | Cообщить модератору

54. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (27), 29-Янв-23, 14:31 
Именно так. Зато внезапно вспомнили про PGO и no-semantic-interposition, которые дают уже не мифическое замедление на части операций, а вполне позволяют выжать из железа больше. Те, кому это надо, большинство будет жрать тормоза с лопаты как и раньше и ничего не заметят никогда. Излишние переживания на тему "безопасности" это признак шизофрении, ты, например, не облачный провайдер, но даже так, доверять облакам?
Ответить | Правка | Наверх | Cообщить модератору

227. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Neon (??), 31-Янв-23, 01:16 
Если бы...кушай что дают и не возникай - обычный подход. Редко кто настройки по умолчанию будет перелопачивать. А в ближайшем времени и их не будет, нечего будет исправлять. За всё уплочено.)
Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

107. "Зависимость времени выполнения инструкций от данных на CPU A..."  –1 +/
Сообщение от Beta Version (ok), 29-Янв-23, 19:31 
Есть такое хуже/лучше. Современный Интел не умеет в энергоэффективность и ноутбуки с ним сильнее зависят от розетки, чем ноуты с АМД с той же производительностью. Плюс ноуты с Интелом ещё и закономерно греются сильнее.
Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

112. "Зависимость времени выполнения инструкций от данных на CPU A..."  –2 +/
Сообщение от Аноним (27), 29-Янв-23, 19:56 
Современный амд не может в USB и не умеет в софт (и софт в него, интел с последним поколением сейчас столкнулся примерно с тем же, пока не знаю как разруливают). Кому нужна энергоэффективность, возьмёт арм, но я думаю всё равно будет выжирать батарейку в режиме "некалькулятора" ничуть не меньше.
Ответить | Правка | Наверх | Cообщить модератору

113. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Beta Version (ok), 29-Янв-23, 20:03 
> Современный амд не может в USB и не умеет в софт (и
> софт в него, интел с последним поколением сейчас столкнулся примерно с
> тем же, пока не знаю как разруливают). Кому нужна энергоэффективность, возьмёт
> арм, но я думаю всё равно будет выжирать батарейку в режиме
> "некалькулятора" ничуть не меньше.

У меня работает USB. А что у тебя не так? И какой софт не работает?

Ответить | Правка | Наверх | Cообщить модератору

114. "Зависимость времени выполнения инструкций от данных на CPU A..."  –1 +/
Сообщение от Аноним (27), 29-Янв-23, 20:05 
Не софт. Когда подключаешь USB-звук, он не работает, как должен. И на интелах такой проблемы нет.
Ответить | Правка | Наверх | Cообщить модератору

118. "Зависимость времени выполнения инструкций от данных на CPU A..."  +3 +/
Сообщение от Beta Version (ok), 29-Янв-23, 20:33 
> Не софт. Когда подключаешь USB-звук, он не работает, как должен. И на
> интелах такой проблемы нет.

Что за USB-звук? Поподробнее.

>    Да, постоянные проблемы из-за simd и переключения ядер, вроде из недавнего баг в ядерном менеджере процессов. Ещё лично мне приходилось запускать ядро с какими-то стрёмными параметрами, чтобы оно не падало.

И тут поподробнее. У меня сейчас 5600X. Как мне твои баги воспроизвести?

Ответить | Правка | Наверх | Cообщить модератору

116. "Зависимость времени выполнения инструкций от данных на CPU A..."  –1 +/
Сообщение от Аноним (27), 29-Янв-23, 20:08 
А, ты про проблемы с софтом. Да, постоянные проблемы из-за simd и переключения ядер, вроде из недавнего баг в ядерном менеджере процессов. Ещё лично мне приходилось запускать ядро с какими-то стрёмными параметрами, чтобы оно не падало.
Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

131. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Аноним (131), 29-Янв-23, 22:15 
Сопли под крышку вместо термопасты штеуд уже не пихает? Или интелоёбство (простите) это таки сектантство по типу яблочного?
Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

154. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Попандопала (?), 30-Янв-23, 00:00 
Сектанство у интелобоев? Амуде какашкой назвал и адепты вечно красных дико возбудились.XD У вас это очевидно что-то религиозное.%
Ответить | Правка | Наверх | Cообщить модератору

233. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Аноним (-), 31-Янв-23, 07:50 
> Сектанство у интелобоев? Амуде какашкой назвал и адепты вечно красных дико возбудились.XD
> У вас это очевидно что-то религиозное.%

Не очень понятно что в интеле хорошего. Бэкдоры? Постоянное срезание всех мыслимых углов их инженерами? Левые оптимизации ценой вообще совсем всего? Маркетинг вместо инженерии? Дурное количество багов в железе? Куда там амд до интелских багов, у интела SATA отгорал через некоторое время, помирал юсб (насовсем, иногда вместе с остальным чипсетом). Драйвер GPU от интеля состоит из воркэраундов глюков железа чуть менее чем полностью.

Интел давно зажрался, и продает имя а не инженерные достижения. Дошло до того что они искусственно оьрубают процы с мыслью потом развести сильнее. Это вообще как, специально портить свое железо чтобы потом еще раздоить?! Вот за счет подобного страдания фигней AMD и стал интель нагревать. Они ресурсы тратили на нормальную инженерию чипов вместо такого булщита.

Ответить | Правка | Наверх | Cообщить модератору

244. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 31-Янв-23, 10:41 
Ви таки сомлевались?
Ответить | Правка | К родителю #131 | Наверх | Cообщить модератору

46. "Зависимость времени выполнения инструкций от данных на CPU A..."  +3 +/
Сообщение от Аноним (46), 29-Янв-23, 13:51 
Это что? https://www.lenovo.com/ru/ru/laptops/thinkpad/t-series/Think...
Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

58. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от kawaii_girl (ok), 29-Янв-23, 14:43 
О, оказывается есть. Спасибо.
Ответить | Правка | Наверх | Cообщить модератору

50. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Роман (??), 29-Янв-23, 14:08 
Thinkpad делают не только на AMD,но и на ARM.
Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

59. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от kawaii_girl (ok), 29-Янв-23, 14:45 
> Thinkpad делают не только на AMD,но и на ARM.

На qualcomm? Поддержка линукса есть?

Ответить | Правка | Наверх | Cообщить модератору

103. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Роман (??), 29-Янв-23, 19:07 
>> Thinkpad делают не только на AMD,но и на ARM.
> На qualcomm? Поддержка линукса есть?

В виде WSL есть, в виде инсталла на голое железо - не интересовался детально, думаю где-то после наступления Года Линукса На Десктопе.

Ответить | Правка | Наверх | Cообщить модератору

234. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Аноним (-), 31-Янв-23, 07:52 
> В виде WSL есть,

Ну тогда и жену себе в сексшопе купите.

Ответить | Правка | Наверх | Cообщить модератору

237. "Зависимость времени выполнения инструкций от данных на CPU A..."  –1 +/
Сообщение от Роман (??), 31-Янв-23, 08:45 
>> В виде WSL есть,
> Ну тогда и жену себе в сексшопе купите.

Даже это уже можно, нужно людям, но Год Линукса На Десктопе всё не наступает, никак не хотят люди в такое светлое будущее

Ответить | Правка | Наверх | Cообщить модератору

298. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (-), 05-Фев-23, 11:56 
Да вот А.С. Пушкин как-то сказал: "зачем стадам дары свободы". Поэтому для них и линукс специальный, в виде андроида, чтобы с привычным поводком и намордником, все на месте. И GPS-трекер на ошейнике, как же иначе?!
Ответить | Правка | Наверх | Cообщить модератору

318. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (-), 06-Фев-23, 05:10 
> Даже это уже можно, нужно людям, но Год Линукса На Десктопе всё
> не наступает, никак не хотят люди в такое светлое будущее

На лично моем десктопе он уже лет 15 как наступил. А чем вы там будете пользоваться - не мои проблемы в общем то. Мои задачи решает и делает меня сильно эффективнее проприетарных систем, в чем прелесть и состоит. Остальное лирика.

Ответить | Правка | К родителю #237 | Наверх | Cообщить модератору

121. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Аноним (120), 29-Янв-23, 20:50 
А про Thinkpad'ы на ARM можно подробности?
Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

162. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Роман (??), 30-Янв-23, 06:54 
> А про Thinkpad'ы на ARM можно подробности?

https://www.reddit.com/r/thinkpad/comments/zmog35/x13s_first.../

ну и там далее по общему поиску https://www.reddit.com/r/thinkpad/search?q=x13s&restrict_sr=on

Среди лично знакомых у меня нет владельцев таких машин, но есть Surface Pro X - Win11, WSL/WSA, работает норм уже почти 3 месяца у человека.

Ответить | Правка | Наверх | Cообщить модератору

100. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (100), 29-Янв-23, 18:41 
У меня thinkpad t495 на райзене
Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

98. "Зависимость времени выполнения инструкций от данных на CPU A..."  +3 +/
Сообщение от Урри (ok), 29-Янв-23, 18:38 
А можно мне максимально читерский, но максимально быстрый ЦПУ?
А вот с этими всеми тормозами е..тесь сами.
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

119. "Зависимость времени выполнения инструкций от данных на CPU A..."  –1 +/
Сообщение от Аноним (6), 29-Янв-23, 20:39 
Тогда не надо напрягаться, что каждый раз после выхода в интернет на ваш комп устанавливается куча малвари.
Ответить | Правка | Наверх | Cообщить модератору

122. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (120), 29-Янв-23, 20:52 
И, всё равно, замедлит максимально быстрый ЦПУ :)
Ответить | Правка | Наверх | Cообщить модератору

183. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Олег (??), 30-Янв-23, 11:23 
Ну для базы данных аналитики пофиг на выход в нет, даже так, изолировать ее от нета здравая задача, а ускорить в двое очень желаемое действие
Ответить | Правка | К родителю #119 | Наверх | Cообщить модератору

206. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (206), 30-Янв-23, 16:43 
Ну так уж и вдвое?
Ответить | Правка | Наверх | Cообщить модератору

15. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Igraine (ok), 29-Янв-23, 12:21 
mitigations=off
Ответить | Правка | Наверх | Cообщить модератору

99. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Урри (ok), 29-Янв-23, 18:39 
Помогает, но недостаточно. Ибо часть кода не написана в двух вариантах.
Ответить | Правка | Наверх | Cообщить модератору

132. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (133), 29-Янв-23, 22:20 
имя файла и номера строчек в студию
Ответить | Правка | Наверх | Cообщить модератору

19. "Зависимость времени выполнения инструкций от данных на CPU A..."  +5 +/
Сообщение от Аноним (46), 29-Янв-23, 12:30 
> Для отключения рассматриваемого поведения компании Intel и ARM предложили новые флаги: PSTATE-бит DIT (Data Independent Timing) для CPU ARM и MSR-бит DOITM (Data Operand Independent Timing Mode) для CPU Intel, возвращающие старое поведение с постоянным временем выполнения. Компании Intel и ARM рекомендуют включать защиту по мере необходимости для особо важного кода, но на деле важные вычисления могут встречаться в любых частях ядра и пространства пользователя, поэтому рассматривается возможность постоянной активации режимов DOITM и DIT для всего ядра.

В итоге будет как с флагом fast-math, когда если одна из библиотек включила этот флаг(привет кодекам), он включается для всего бинаря.

С этим флагом, подключил ты допустим libcurl, да даже просто securerandom использовал, и весь бинарь поражен.

Ответить | Правка | Наверх | Cообщить модератору

129. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Аноним (46), 29-Янв-23, 21:40 
related: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
Ответить | Правка | Наверх | Cообщить модератору

24. "Зависимость времени выполнения инструкций от данных на CPU A..."  +5 +/
Сообщение от Аноним (24), 29-Янв-23, 12:45 
иногда кажется, что разрабы линукса искусственно подкидывают запланированное устаревание, ведь без этих mitigations на старом железе можно по 10+ лет сидеть, в отличие от винды с маком
Ответить | Правка | Наверх | Cообщить модератору

28. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Аноним (142), 29-Янв-23, 12:53 
Любому сделавшему за новостями на опеннет и читающему умные комментарии, это сразу становится очевидно
Ответить | Правка | Наверх | Cообщить модератору

43. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Аноним (43), 29-Янв-23, 13:38 
Не надо предполагать, что люди где-то там обязательно умнее тебя.
Ответить | Правка | Наверх | Cообщить модератору

250. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (250), 31-Янв-23, 10:56 
Да, ведь как они смеют быть умнее светил с Опеннета!
Ответить | Правка | Наверх | Cообщить модератору

29. "Зависимость времени выполнения инструкций от данных на CPU A..."  –6 +/
Сообщение от Аноним (27), 29-Янв-23, 12:56 
Прикол в том, что большинство заплаток тормозят на уровне статистической погрешности даже на этом сам 10+ летнем железе и вообще не тормозят на современном. Там, где используется линукс, некрожелезо никто брать не будет, так что все в выигрыше.
Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

180. "Зависимость времени выполнения инструкций от данных на CPU A..."  +2 +/
Сообщение от Омномним (?), 30-Янв-23, 10:26 
Ды щаз. Всё от задач зависит.
В массовой виртуализации на личных сэмплах:
Meltdown = -15-25%
SpectreV2 = -3-7%
L1TF = -10-15%
В итоге выкинуто и заменено на AMD.
Ответить | Правка | Наверх | Cообщить модератору

268. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Michael Shigorinemail (ok), 01-Фев-23, 01:33 
> Прикол в том, что большинство заплаток тормозят на уровне статистической погрешности
> даже на этом сам 10+ летнем железе и вообще не тормозят на современном.

Вы говорите неправду (ц) -- проверено на i7-3517U и i5-3317U, статистика прям так себе.

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

278. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (27), 01-Фев-23, 14:31 
А что именно тормозит? Я так и не смог обнаружить разницы. Виртуализация -- это не то, что нормальные люди используют на древнем железе. Если есть просадки в софтрейде, то измерить реалистично возможно только приблизительно и высока зависимость от современных SIMD. И где ещё эти заплатки проявляются? У меня с заплаткой от спектры, помню, так вообще вышло 100% воспроизводимое ускорение обработки шрифтов (версии ПО не менялись).
Ответить | Правка | Наверх | Cообщить модератору

57. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (-), 29-Янв-23, 14:43 
Сравнил на одном и том же ноуте 2011 года скорость работы в Windows 11 и Fedora 37. Винда быстрее даже без твиков вроде отключения дефендера, индексации и тому подобного. Asus K53T, 4ядерный AMD, 6 гигов оперативки, SSD
Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

79. "Зависимость времени выполнения инструкций от данных на CPU A..."  –2 +/
Сообщение от . (?), 29-Янв-23, 16:40 
Потому что amd.
Ответить | Правка | Наверх | Cообщить модератору

165. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (63), 30-Янв-23, 07:37 
Да, AMD A6-3400M со встроенной в него видюхой Radeon HD 6520G. Дискретки в ноуте нет.
Ответить | Правка | Наверх | Cообщить модератору

124. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Аноним (120), 29-Янв-23, 20:55 
Какие тесты для измерения производительности использовались?
Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

158. "Зависимость времени выполнения инструкций от данных на CPU A..."  +2 +/
Сообщение от НяшМяш (ok), 30-Янв-23, 01:49 
Чуйка опеннет эксперта не требует доказательств
Ответить | Правка | Наверх | Cообщить модератору

166. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (63), 30-Янв-23, 07:42 
Скорость загрузки и запуска программ, отзывчивость интерфейса и с какой скоростью одна и та же версия либрофиса выполняет одни и те же операции вроде поиска и замены над одним и тем же документом. Понятно что бенчмарком это можно считать сильно условно, но тормознутость федоры очень сложно не заметить. Убунту и прочее не ставил и не сравниваю.
Ответить | Правка | К родителю #124 | Наверх | Cообщить модератору

170. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от . (?), 30-Янв-23, 09:51 
В вашем уравнении слишком много переменных. И вообще если ставить простой линукс так сказать для домохозяйки, то никто не обещал в нем производительность. Но по своему опыту скажу что линукс намного шустрее винды и экономичнее, если убрать все лишнее. Но у меня 15 летний ноут на интел.
Ответить | Правка | Наверх | Cообщить модератору

178. "Зависимость времени выполнения инструкций от данных на CPU A..."  –1 +/
Сообщение от Аноним (63), 30-Янв-23, 10:20 
Обе системы были из коробки, как есть. Но я сильно сомневаюсь что после отключения всего ненужного в Win11 (а там его реально дофига) ее смог бы догнать хоть какой-нибудь линукс, использующий графическую систему, а не голую текстовую консоль.
Ответить | Правка | Наверх | Cообщить модератору

193. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от . (?), 30-Янв-23, 14:17 
> сильно сомневаюсь

Сомневайтесь дальше, товарищ эксперт

Ответить | Правка | Наверх | Cообщить модератору

195. "Зависимость времени выполнения инструкций от данных на CPU A..."  –2 +/
Сообщение от Аноним (63), 30-Янв-23, 14:24 
Ну когда со всякими виндами экспериментируешь с 92 года, а с линуксами с 98 - сложно не стать экспертом. Никогда линукс в графическом режиме не был таким же быстрым как винда того же года выпуска как минимум потому что иксы и быстродействие - вещи между собой никак не связанные. Плюс милая юниксовая привычка городить костыли поверх абстракций с целью подпереть очередную прослойку.
Ответить | Правка | Наверх | Cообщить модератору

200. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Beta Version (ok), 30-Янв-23, 15:13 
Купил много лет назад маме бюджетный ноут с предустановленной Win8. Так венда, чистая и свежая, полторы минуты грузилась. Снёс её, поставил Linux Mint - ноут начал загружаться менее чем за 30 сек. Соответственно, и в самой системе всё стало быстрее.
Ответить | Правка | Наверх | Cообщить модератору

203. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от . (?), 30-Янв-23, 15:51 
>  с 92 года, а с линуксами с 98

Возможно в те годы именно так и было, что винда была шустрее. Но начиная с вин7 ощущается просадка фпс в играх на opengl или d3d. В винХР такого не было. В вин10 также поддтормаживает, вин11 уже не стал пробовать. И что удивительно, в современном линуксе те же игры запущенные через wine идут нормально, без подтормаживания, как было в винХР.
Ну в иксах кстати много лишнего допотопного кода. Никто не мешает собрать иксы, выкинув хлам и оставив нужные компоненты. И будет еще заметнее прибавка в скорости. Например после сборки ядра под свое железо, ощущение что запустил Вин98 на современном железе. А как вернуть такую отзывчивость на современной винде? А никак, только купив железо помощнее.

Ответить | Правка | К родителю #195 | Наверх | Cообщить модератору

221. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (63), 30-Янв-23, 23:17 
> И что удивительно, в современном линуксе те же игры запущенные через wine идут нормально, без подтормаживания, как было в винХР.

EVE Online (больше не играю ни во что) под Win11 на средних настройках графики работает быстрее чем на минималках под Wine. Неважно Wine, который у федоры в репе лежит, или протоновский. Неважно, ставил вручную или через Lutris.  Разгадка простая: видюха поддерживает OpenCL 1.2, DirectX 11.2 и OpenGL 4.4, но не поддерживает Vulkan. Совсем, никакую версию.

> Ну в иксах кстати много лишнего допотопного кода. Никто не мешает собрать иксы, выкинув хлам и оставив нужные компоненты. И будет еще заметнее прибавка в скорости.

Если бы проблема решалась таким способом, то скорее всего не стали бы изобретать Wayland.

> Например после сборки ядра под свое железо, ощущение что запустил Вин98 на современном железе.

Ну конечно же я никогда не собирал ядро вручную:). И никогда не слышал про всякие флаги вроде -march=native

Ответить | Правка | Наверх | Cообщить модератору

269. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Michael Shigorinemail (ok), 01-Фев-23, 01:35 
> Плюс милая виндовая привычка городить костыли поверх
> абстракций с целью подпереть очередную прослойку.

То-то у приятеля двадцать лет назад под winex игрушки быстрее шастали, чем на винде.

Ответить | Правка | К родителю #195 | Наверх | Cообщить модератору

275. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (63), 01-Фев-23, 07:29 
Целых два пасьянса и один сапер, которые под вайном вообще запустились
Ответить | Правка | Наверх | Cообщить модератору

204. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от maximnik0 (?), 30-Янв-23, 16:06 
>но тормознутость федоры очень >сложно не заметить

У тебя в конфигурации SSD ,а с ним есть тонкости,файловая система по умолчанию какая ? BTRFS ? Хоть у нее́ есть вкусности  и некоторые оптимизации для SSD включаются автоматом, есть тонкости настройки.Допустим отключенный по умолчанию trim.Невыравненный раздел, включенные по умолчанию atime и т.д
Хоть и пишут что SSD быстрые, это до исчерпания кэша ребята .....80% ссд Sata такие,начнёшь много писать сразу тормоза обнаружишь.

Ответить | Правка | К родителю #166 | Наверх | Cообщить модератору

220. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (63), 30-Янв-23, 22:56 
> файловая система по умолчанию какая ? BTRFS ?

Выравниванием разделов вручную не заморачивался, просто в инсталляторе сказал что мне нужен 64меговый раздел для загрузки с UEFI, 8 гигов для свопа, 48 гигов для корня (форматировался в ext4), ну а все остальное место форматнуть в xfs и отвести под /home.

Ответить | Правка | Наверх | Cообщить модератору

229. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от maximnik0 (?), 31-Янв-23, 03:15 
> гигов для корня (форматировался в ext4), ну а все остальное место
> форматнуть в xfs и отвести под /home.

Рекомендуют для ssd отключать журналирование при условии что батареи на ноутбуке нормальные.И XFS -я не знаю, портировали ли в этом выпуске Федоров - журнал свободного места + падчи для trim + оптимизации для ssd.
Хфс конечно охренелло ускорили с работой с мелкими файлами но только последние 4 летние выпуски.


Ответить | Правка | Наверх | Cообщить модератору

73. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (71), 29-Янв-23, 16:22 
Так проблема-то именно на новом железе, а на старом не проявляется.
Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

89. "Зависимость времени выполнения инструкций от данных на CPU A..."  +4 +/
Сообщение от Аноним (133), 29-Янв-23, 17:44 
я тебе открою один секрет: новое железо тоже станет старым
Ответить | Правка | Наверх | Cообщить модератору

109. "Зависимость времени выполнения инструкций от данных на CPU A..."  +2 +/
Сообщение от Аноним (108), 29-Янв-23, 19:34 
Зато старое не устареет никогда.
Ответить | Правка | Наверх | Cообщить модератору

264. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от деанон (?), 31-Янв-23, 23:08 
Что за бред?! Устареет, когда не сможешь аппаратно декодировать какой-нибудь кодек или нужна будет поддержка отсутствующего аппаратного протокола или не окажется нужных процессорных инструкций и придется сидеть на неподдерживаемых версиях. Также, будет устаревать относительно старого железа, но более позднего года выпуска, не говоря уже об устаревании относительно современного железа.
Ответить | Правка | Наверх | Cообщить модератору

267. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Michael Shigorinemail (ok), 01-Фев-23, 01:32 
> иногда кажется, что разрабы линукса искусственно подкидывают запланированное устаревание

При чём _тут_ линукс?

Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

40. "Зависимость времени выполнения инструкций от данных на CPU A..."  +4 +/
Сообщение от Allllex (?), 29-Янв-23, 13:25 
а почему все зацикливаются на фиксах процессоров, когда править нужно алгоритмы шифрования, дабы они предусматривали и нивелировали эти зависимости таймингов обработки данных процессорами?
Ответить | Правка | Наверх | Cообщить модератору

44. "Зависимость времени выполнения инструкций от данных на CPU A..."  +4 +/
Сообщение от Аноним (43), 29-Янв-23, 13:41 
Сделать аппаратный блок? Да ну на! Лучше дырявые программы будем мучить!
Ответить | Правка | Наверх | Cообщить модератору

81. "Зависимость времени выполнения инструкций от данных на CPU A..."  –3 +/
Сообщение от Аноним (142), 29-Янв-23, 16:52 
В очередной раз удивляюсь гениальности аудитории опеннет.
Так называемым инженерам из Интел и АМД эта простая мысль никогда в голову не придет
Ответить | Правка | Наверх | Cообщить модератору

149. "Зависимость времени выполнения инструкций от данных на CPU A..."  +2 +/
Сообщение от Аноним (43), 29-Янв-23, 23:41 
> инженерам из Интел и АМД эта простая мысль никогда в голову не придет

Не пришла же - по факту.

Ответить | Правка | Наверх | Cообщить модератору

207. "Зависимость времени выполнения инструкций от данных на CPU A..."  –2 +/
Сообщение от Аноним (142), 30-Янв-23, 17:27 
https://www.intel.com/content/www/us/en/developer/articles/t...

Вам нужно в Интел работать консультантом, не думали об этом? Зря что-ли такой гений пропадает.

Ответить | Правка | Наверх | Cообщить модератору

270. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Michael Shigorinemail (ok), 01-Фев-23, 01:38 
> Вам нужно в Интел работать консультантом, не думали об этом?

То-то ребята из Нижнего приезжали знакомиться, вдоволь наконсультировавшись.

Ответить | Правка | Наверх | Cообщить модератору

228. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Neon (??), 31-Янв-23, 01:26 
Ага... аппаратный блок, в котором будет аппаратный баг.)))
Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

53. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Аноним (32), 29-Янв-23, 14:30 
алгоритмы шифрования это тока вершина айсберга, при наличии возможности определять время выполнения инструкций от обрабатываемых в этих инструкциях данных даёт простор для поистине колоссальных утечек данных на разных уровнях, а фикс на уровне отдельно всязтого софта сравни герметизации каюты в Титанике.
Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

72. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Аноним (71), 29-Янв-23, 16:20 
А при наличии возможности запускать произвольный код ... wait, OH SHIT, без запуска произвольного кода даже OpenNet в тыкву превращается.
Ответить | Правка | Наверх | Cообщить модератору

101. "Зависимость времени выполнения инструкций от данных на CPU A..."  –2 +/
Сообщение от Урри (ok), 29-Янв-23, 18:41 
Если что-то в принципе возможно прочитать, значит возможно украсть. Вы не выиграете эту войну путем "давайте лучше прятать".
Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

117. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Аноним (32), 29-Янв-23, 20:25 
здесь не в прятках проблема, всё как раз на виду, особенно в облаках, тут проблема в прямой корреляции времени выполнения инструкций от данных, вот к примеру, близких людей часто можно узнать по походке даже из далека не видя лица, у каждого есть свой ритм, так и здесь, вместо - "Кто шагает дружно в ряд? Пионерский наш отряд!", теперь можно по идее выделить определённые "отпечатки"(ритмы) нужных данных основываясь только на специфических задержка их обработки.
Ответить | Правка | Наверх | Cообщить модератору

163. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Sw00p aka Jerom (?), 30-Янв-23, 07:05 
>даёт простор для поистине колоссальных утечек данных

ждем эру процессоров работающих  с гомоморфно шифрованными данными, остается вопрос, на каком процессоре эти данные заранее подготовить?

Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

184. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от _kp (ok), 30-Янв-23, 11:25 
>>время выполнения инструкций..
>>данных даёт простор для поистине колоссальных утечек данных

Не даёт, а теоретически может дать, и то приложившему значительные усилия и средства, без 100% шанса достижения цели.

А вот "защита" 100% навредит производительности. Значит это плохая реализация, и нечего в ней копаться.

А личные и коммерческие данные утекают совсем по другим каналам. И подобные "защиты" - мертвому припарка.

Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

76. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (12), 29-Янв-23, 16:24 
Поучи для начала самый просто тервер. Потом уже можешь тут писать всякие глупости.
Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

126. "Зависимость времени выполнения инструкций от данных на CPU A..."  –3 +/
Сообщение от Аноним (126), 29-Янв-23, 21:02 
Изучи криптографию получше, тогда не будешь глупых вопросов задавать.
Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

167. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Аноним (142), 30-Янв-23, 08:23 
Изучи матанализ и тогда не будешь писать несуразности
Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

188. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Sw00p aka Jerom (?), 30-Янв-23, 12:39 
>дабы они предусматривали и нивелировали эти зависимости

тогда на асм надо писать, а так  вывод компилятора смотреть и додумывать, трата времени. А на асм писать не хотят, вот и переваливают на процессор.

Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

208. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (142), 30-Янв-23, 17:35 
Лично я тоже не понимаю почему нужно тормозить весь процессор и все программы на нем выполняющиеся, если можно затормозить только код выполняющий шифрование, на стороне библиотеки это шифрование обеспечивающей.

Теорию вероятности я учила, но не помню уже и очень сомневаюсь что она имеет отношение к описанной в новости проблеме

Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

235. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (-), 31-Янв-23, 07:54 
> дабы они предусматривали и нивелировали эти зависимости
> таймингов обработки данных процессорами?

Ну во первых, алгоритм не контролирует напрямую какие команды будут сгенерены, это дело компилера. И если он не те команды сгенерит - то чего?

Во вторых - а вот сейчас нам что делать? Наслаждаться как 31337-е господа выносят с хостингов ключи шифрования оптом? Ну спасибо.

Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

242. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 31-Янв-23, 10:39 
Ни одной практической атаки до сих пор так и не зафиксировано, всё это работает в основном в стерильных условиях.
Ответить | Правка | Наверх | Cообщить модератору

243. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 31-Янв-23, 10:40 
Потому что это проще продать. В прямом смысле.
Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

47. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от user (??), 29-Янв-23, 13:54 
А они таки обещали?
Ответить | Правка | Наверх | Cообщить модератору

56. "Зависимость времени выполнения инструкций от данных на CPU A..."  +2 +/
Сообщение от Аноним (56), 29-Янв-23, 14:39 
Надеюсь эти МЕГА ПОЛЕЗНЫЕ ПАТЧИ будут включаться специальными флагами на этапе компиляции ядра и по умолчанию будут выключены.
Ответить | Правка | Наверх | Cообщить модератору

171. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 30-Янв-23, 09:53 
Да, то же mitigations=off уже стало нормой.
Ответить | Правка | Наверх | Cообщить модератору

84. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (84), 29-Янв-23, 17:13 
Делайте с ядром что хотите, главное - чтоб хешрейт не просел.
Ответить | Правка | Наверх | Cообщить модератору

91. "Зависимость времени выполнения инструкций от данных на CPU A..."  –6 +/
Сообщение от pavlinux (ok), 29-Янв-23, 17:49 
>+ rdmsrl(MSR_IA32_UARCH_MISC_CTL, msr);
>+ wrmsrl(MSR_IA32_UARCH_MISC_CTL, msr | UARCH_MISC_DOITM);

А где доказательство того, что это не включает дыру для ЦРУ?


>+#define MSR_IA32_UARCH_MISC_CTL        0x00001b01

0x00001b01 - а такой hex, после "секретных парсеров" не подставится как двоичный 00001b ?

Ответить | Правка | Наверх | Cообщить модератору

110. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Аноним (110), 29-Янв-23, 19:41 
Зависимость это плохо!
Ответить | Правка | Наверх | Cообщить модератору

141. "Зависимость времени выполнения инструкций от данных на CPU A..."  +3 +/
Сообщение от Аноним (141), 29-Янв-23, 22:41 
И это пропихивают в качестве архитектуры будущего? Ололо...
Ответить | Правка | Наверх | Cообщить модератору

148. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (43), 29-Янв-23, 23:40 
Вот именно, что пропихнули.
Ответить | Правка | Наверх | Cообщить модератору

160. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от ДаНуНафиг (?), 30-Янв-23, 03:59 
Которое из это вы имеете в виду?
Ответить | Правка | К родителю #141 | Наверх | Cообщить модератору

187. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (141), 30-Янв-23, 11:43 
АРМ, очевидно...
Ответить | Правка | Наверх | Cообщить модератору

197. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Аноним (206), 30-Янв-23, 14:59 
И Штеуд тоже.
Ответить | Правка | Наверх | Cообщить модератору

168. "Зависимость времени выполнения инструкций от данных на CPU A..."  +2 +/
Сообщение от Аноним (168), 30-Янв-23, 08:46 
Я уже давно думаю. Вот если важно, чтобы некая критическая операция, типа аутентификации, всегда выполнялась за одно и то же время, в не зависимости от того, успешно она прошла или нет - то не проще ли просто добавить в нее задержку по таймеру?
Ответить | Правка | Наверх | Cообщить модератору

172. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Омномним (?), 30-Янв-23, 09:55 
Задержка может быть отслежена по вторичным каналам типа кеша, потому что сильно отличается от исходной операции.
Т.е. у задержки, даже если там в цикле что-то крутить, неизбежно будет паттерн.
Ответить | Правка | Наверх | Cообщить модератору

186. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от _kp (ok), 30-Янв-23, 11:36 
А... Так это чтоб на Си не писать, чтоб Яваскрипты и Питоны использовать ;)
Ответить | Правка | Наверх | Cообщить модератору

236. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Аноним (-), 31-Янв-23, 07:56 
> А... Так это чтоб на Си не писать, чтоб Яваскрипты и Питоны
> использовать ;)

На них заманаешься крипто ждать хоть там как. Не тормозят же.

Ответить | Правка | Наверх | Cообщить модератору

169. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 30-Янв-23, 09:51 
Мне вообще непонятны эти пляски вокруг постоянного времени выполнения.
Время выполнения операций в критичных блоках надо рандомизировать так, чтобы вариация была кратной. Потому что в случае превышения уровнем шума уровня полезного сигнала - сигнал не восстановить.
Ответить | Правка | Наверх | Cообщить модератору

202. "Зависимость времени выполнения инструкций от данных на CPU A..."  –2 +/
Сообщение от Аноним (-), 30-Янв-23, 15:49 
> в случае превышения уровнем шума уровня полезного сигнала - сигнал не восстановить.

Почему это? Берёшь N одинаковых сигналов вместе с шумом, суммируешь их, рандомные значения суммируются по random walk и увеличиваются пропорционально корню из N, а вот сигнал в сумме будет увеличен в N раз. Тебе надо лишь подобрать N достаточно большим, чтобы N/sqrt(N) (т.е. sqrt(N)) был бы больше, чем отношение уровня шума к уровню сигнала.

Всё что ты можешь получить своим шумом -- увеличить сложность атаки. Сделать атаку принципиально невозможной принципиально невозможно таким образом.

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

Ответить | Правка | Наверх | Cообщить модератору

214. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Аноним (214), 30-Янв-23, 20:10 
> Берёшь N одинаковых сигналов вместе с шумом

Уже ошибка: выборки в _разное_ время. Шум же неидеальный.

Ответить | Правка | Наверх | Cообщить модератору

215. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (214), 30-Янв-23, 20:13 
Т.е. с увеличением времени анализа ситуация на _реальных_ системах будет только ухудшаться для хакера.
Ответить | Правка | Наверх | Cообщить модератору

240. "Зависимость времени выполнения инструкций от данных на CPU A..."  +2 +/
Сообщение от Омномним (?), 31-Янв-23, 10:37 
Верно.

Ну и да - речь-то у нас о timing attack, где мы дополнительно ну никак точно время начала передачи сигнала определить не можем. А значит - складывай, не складывай, на выходе получишь только шум.

Ответить | Правка | К родителю #214 | Наверх | Cообщить модератору

241. "Зависимость времени выполнения инструкций от данных на CPU A..."  +2 +/
Сообщение от Омномним (?), 31-Янв-23, 10:38 
(как только шумовая составляющая превысит сумму определимых значений времени старта и длительности)
Ответить | Правка | Наверх | Cообщить модератору

256. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (214), 31-Янв-23, 13:30 
А, да, ещё один момент: дискретность компутерных чисел. Если складывать большой шум и маленький сигнал - точность сигнала будет подавлена, возможно, даже полностью.
Ответить | Правка | Наверх | Cообщить модератору

258. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 31-Янв-23, 13:59 
Да не, там всё проще.

Нам надо либо множество сэмплов одного и того же сигнала с разным шумом - но в timing атаке мы не знаем, "что есть сигнал", поэтому нет исходного критерия для сравнения = нет сигнала вообще, timing атаки как раз и основаны на сравнении конечного времени, позволяющие понять, что есть "0", что есть "1", а если домешать шума - тут у нас даже базы не оказывается.

Либо надо множество сигналов с одинаковым шумом, что опять же априори исключено.

Т.е. рандомизация конкретно от этого типа атак - идеальный вариант.

Ответить | Правка | Наверх | Cообщить модератору

328. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (-), 08-Фев-23, 04:07 
> шумом - но в timing атаке мы не знаем, "что есть сигнал",

А вот это - ну не факт. Мы можем и некие тесты на известных паттернах прогнать.

> Т.е. рандомизация конкретно от этого типа атак - идеальный вариант.

Есть шансы что удастся ее аннулировать.

Ответить | Правка | Наверх | Cообщить модератору

216. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (214), 30-Янв-23, 20:13 
> надо лишь подобрать N достаточно большим, чтобы N/sqrt(N) (т.е. sqrt(N)) был бы больше, чем ...

Вот этим и отличаются математики от инженеров.

Ответить | Правка | К родителю #202 | Наверх | Cообщить модератору

239. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 31-Янв-23, 10:33 
Угу, по ходу там BSD-теоретик. N даже для фонового шума питания будет запредельным.
Я уж молчу, если для генерации ещё с внешней среды что-нибудь ловить дополнительно.
Ответить | Правка | Наверх | Cообщить модератору

262. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (-), 31-Янв-23, 18:47 
"Запредельным" -- это каким? 10^12? Гигагерцовому процессору на выполнение 10^12 инструкций потребуется порядка часа.
Ответить | Правка | Наверх | Cообщить модератору

274. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (214), 01-Фев-23, 07:25 
> порядка часа

и что может произойти за час? ничего ведь не поменяется, всё будет стоять, как вкопанное...

Ответить | Правка | Наверх | Cообщить модератору

281. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 02-Фев-23, 08:11 
Точно BSD-теоретик.
Даже если мы имеем дело с side channel leak, а не сетевой эксплуатацией, в лабораторных условиях - посчитай число инструкций, которое тебе потребуется, удивись.
Ответить | Правка | К родителю #262 | Наверх | Cообщить модератору

238. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 31-Янв-23, 10:32 
Нет.
Ты исходишь из того, что шум имеет паттерн.
Естественно, идеального шума не будет, но ликать пару байт столетие - так себе затея.
Ответить | Правка | К родителю #202 | Наверх | Cообщить модератору

261. "Зависимость времени выполнения инструкций от данных на CPU A..."  –1 +/
Сообщение от Аноним (-), 31-Янв-23, 18:37 
> Ты исходишь из того, что шум имеет паттерн.

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

В случае с замерами времени, достаточно простой статистики: у тебя каждый замер времени будет числом вида t+r_i, где t -- реальное время выполнения, а r_i -- случайное число. Мы прогоняем код N раз, и считаем по i=1..N сумму t+r_i, после чего делим это на N и получаем (\sum t)/N + (\sum r_i)/N, первое слагаемое равно t*N/N==t -- времени выполнения инструкции, второе слагаемое будет равно среднему значению r_i делённому на N. При N стремящемся к бесконечности второе слагаемое стремится к нулю, и таким образом сумма замерянных значений делённая на количество этих значений стремится к искомому числу. Самый фокус в том, чтобы подобрать N, чтобы лишнего не мерять, но в то же время шум снимать. Но если познаний в математике не хватает для этого, то это можно сделать методом тыка.

Это элементарная математика 8 класса. Я не понимаю, что тебя сбивает с толку? Может ты думаешь, что можно создать такой генератор случайных чисел r_i, чтобы это не работало? Поделись с нами своей гениальностью, расскажи как можно победить этот метод из восьмого класса.

Ответить | Правка | Наверх | Cообщить модератору

282. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 02-Фев-23, 08:13 
Сейчас ты вообще ушёл в сторону от исходной проблемы.

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

Если к сигналу о сигнале добавить рандомный шум, ничего ты оттуда уже не выдавишь. Никак, от слова "совсем".

Ответить | Правка | Наверх | Cообщить модератору

286. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 02-Фев-23, 08:19 
То есть ты мне сейчас вещаешь, что при SNR<0 достаточно просто хорошо поусреднять.
Ну, удачки.
Ответить | Правка | К родителю #261 | Наверх | Cообщить модератору

287. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 02-Фев-23, 08:21 
// при SNR>0, конечно же
Ответить | Правка | Наверх | Cообщить модератору

290. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (290), 03-Фев-23, 17:26 
> То есть ты мне сейчас вещаешь, что при SNR<0 достаточно просто хорошо поусреднять.

Да, я в отличие от тебя читал Клода Шеннона, который считается основоположником всей дисциплины и изобретателем информации. Вне зависимости от уровня шума, ты можешь передавать полезный сигнал, выменивая вероятность отсутствия ошибок передачи за счёт скорости передачи. "Просто поусреднять" -- это не всегда наилучший подход, но да, если очень надо, то можно обойтись им.

Ответить | Правка | К родителю #286 | Наверх | Cообщить модератору

291. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 03-Фев-23, 21:27 
А теперь подумай, в какой степени это применимо к обсуждаемому - и наконец проснись.
Ответить | Правка | Наверх | Cообщить модератору

292. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 03-Фев-23, 21:27 
Ты не _передаёшь_ сигнал, ты его _принимаешь_. Передатчик тебе не подконтролен.
Ответить | Правка | К родителю #290 | Наверх | Cообщить модератору

293. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 03-Фев-23, 21:30 
(если совсем туго - ты принимаешь _чужой_ сигнал, который зашумлён до уровня неразборчивости, SNR<=0. всё. на этом месте все твои потуги рушатся. Шэннон - это про то, что уровень шума, да, не является непреодолимым для устойчивой передачи и приёма сигнала, который ты формируешь сам. но чужой сигнал, который ты не можешь адаптировать "по форме" к актуальному уровню шума - ты принять уже не сможешь)
Ответить | Правка | Наверх | Cообщить модератору

294. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 03-Фев-23, 21:38 
А если ещё проще - да, можно добиться SNR>0 при практически любом уровне шума, и попытаться это как-то принять даже при запредельно низком соотношении. На самом деле не совсем так, и надо добавлять "в физически допустимых пределах", потому что мы можем подойти к физическому пределу допустимого уровня в рамках носителя, шумов и сигналов в реальности выше которого существовать уже не может (в случае ЭМВ - к уровню пробоя среды бггг или просто элементов приёмника/передатчика).

Но если у тебя исходно по имеющемуся сигналу, которым ты не управляешь, SNR уже <= 0 - всё. Туши свет.

Ответить | Правка | Наверх | Cообщить модератору

312. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (-), 06-Фев-23, 02:10 
> А если ещё проще - да, можно добиться SNR>0

Слышь, чудик, я не тот анон но чтоб ты знал: SNR = 0 (dB) не рассматривается Шеноном как что-то специальное или какой-то частный случай после которого случается что-то особенное. Ну вот нет там никаких жестких порогов.

Ответить | Правка | Наверх | Cообщить модератору

295. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 03-Фев-23, 21:54 
Давай самую простую задачку.

У тебя есть исходный сигнал, состоящий из "полок" строго в -1 и +1. Длительность сих "полок" не известна.
Ты можешь проиграть исходный сигнал сколько угодно раз, при этом паттерн шума будет иным.

Сигнал модулирован идеальным белым шумом выше уровня сигнала - это значит, что уровней ниже -1 и +1 у нас в результате не появляется.

Как будем в реальном мире восстанавливать?

Ответить | Правка | К родителю #290 | Наверх | Cообщить модератору

296. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 03-Фев-23, 21:57 
Тьфу блин. Вечер.

// "Выше уровня сигнала" - удалить. Слова "модулирован" достаточно.

Это как раз наш случай с таймингами, кстати.

Ответить | Правка | Наверх | Cообщить модератору

310. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (-), 06-Фев-23, 01:54 
> У тебя есть исходный сигнал, состоящий из "полок" строго в -1 и +1.

Это само по себе еще куда ни шло...

> Длительность сих "полок" не известна.

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

Более того - скоростные линки передают клок не для красоты: сэмплирование в конкретные и правильные моменты времени тоже сильно улучшает дело. Совсем асинхронный сигнал проблематично разогнать до хорошего битрейта. Ошибки клока ведут к тому что весь хвост пакета где врезался или выпал лишний бит - ошибка. С таким числом ошибок даже мощный FEC не справится, не говоря про простой и быстрый типа ECC.

> Ты можешь проиграть исходный сигнал сколько угодно раз, при этом паттерн шума будет иным.

Если допустить что биты все же постоянны по скорости (вполне достижимое требование) тогда есть такое соображение: сумма сигналов битов отлична от ноля. А шум так то взаимно аннулируется, его среднее около ноля. И processing gain ценой потери битрейта возникает именно оттуда :D. Коррелятор GPS занимается именно этим.

> Сигнал модулирован идеальным белым шумом выше уровня сигнала - это значит, что
> уровней ниже -1 и +1 у нас в результате не появляется.

Это не так уж важно, если на самом деле каждый "cупер-бит" был кодирован пачкой "мини-битов". Прикинь, коррелятор GPS всего лишь залоченый на те же параметры PRNG и ксорка. Если корреляция сильная, это наш сигнал, и мы можем видеть его вероятное состояние. А если слабая - ну, упс, это не наш сигнал - или лок не удался, ессно этот фокус требует знание точных времянок чтобы "маленькие" биты попадали в свои интервалы, без этого магия с реинфорсом правильных значений не сработает.

Смотри: sum(1+0.6, 1-0.6, 1+0.6, 1-0.6) / 4 дает ровно 1. А случайное телепание +/- 0.6 представленное немного утрировано и упрощенно - аннулировано. Ну как, при захвате битов как 1 и 0 из шума ты будешь часто видеть сие как 0x55 или 0xAA, я отмасштабировал до 0.6, но можешь и в бинарном виде так же. Если не нравится дробная математика, на большой пачке мини-битов валидно целыми числами оперировать, GPS коррелятор лишь XORит вход с лоченым на chip rate PRNG да смотрит на уровень корреляции. И тут можно уже иначе решать что это. "Скорее всего 1", "Скорее всего 0", "вообще не наш сигнал". Ну вот так вот.

> Как будем в реальном мире восстанавливать?

Посмотри на GPS/CDMA/прочие подвиды идей в духе DSSS. Вот так и будем. А кто тебе сказал что вон то не работает? Шенона оно конечно не обойдет, битрейт на избыточное кодирование битиков придется потерять, извините.

А, да, я говорил что основы (line) coding и проч в рфских вузах не дают? Ну вот оно и заметно. Эксперты блин, вообще не способные CDMA осознать.

Ответить | Правка | К родителю #295 | Наверх | Cообщить модератору

299. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (-), 05-Фев-23, 12:00 
> То есть ты мне сейчас вещаешь, что при SNR<0 достаточно просто хорошо поусреднять.

SNR < 0 это вообще как? Это по определению отношение положительных чисел. А если это про dBm какие было, внезапно, GPS работает сильно ниже уровня шумов. И не только он. "Processing gain" they call it.


Ответить | Правка | К родителю #286 | Наверх | Cообщить модератору

305. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 05-Фев-23, 13:36 
SNR <0 - это когда уровень шума превышает уровень полезного сигнала.
Ответить | Правка | Наверх | Cообщить модератору

306. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 05-Фев-23, 13:39 
(напоминаю, исторически SNR измеряется в дБ, а это собственно степень, которая собственно отрицательна, когда N>S)
Ответить | Правка | К родителю #299 | Наверх | Cообщить модератору

311. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (-), 06-Фев-23, 02:01 
> (напоминаю, исторически SNR измеряется в дБ

Тебе показать пачку протоколов работающих при отрицательных dBm в SNR или сам найдешь?

GPS один из них и что интереснее, сделал это вот именно "цифровым" методом. То-есть если тебе нравятся только 2 значения сигнала, фокус с XOR чип-рейта vs медленные биты - вполне вариант. Ну и да, при этом не надо работать с дробными числами, корреляция может быть измерена и в (целом) числе совпавших с ожиданиями мини-битов, например.

И да, при этом - только подумай - становится возможно "не бинарное" декодирование (soft decoding). Когда можно говорить о вероятности что это 1 или 0 или "дистанции" от идеальных точек 1 и 0. Если дистанция небольшая, это наш сигнал. Если большая - это вообще скорее всего что-то не то. Так что вот, можно нарисовать на сигнале маркер отличающий его от шума. Просто XOR'ом с PRNG даже вот. Лишь бы PRNG на обоих сторонах линка одинаково работал. В этом месте мы начинаем догадываться почему GPS так заморачивается с точным временем... без лока с точностью до чипа он вообще декодирован не будет на самом базовом уровне, лол.

Ответить | Правка | Наверх | Cообщить модератору

319. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (-), 06-Фев-23, 07:05 
> Тебе показать пачку протоколов работающих при отрицательных dBm в SNR или сам найдешь?

Тьфу ты, SNR в dB конечно, а не dBm, милливаты тут не при чем.

Ответить | Правка | Наверх | Cообщить модератору

307. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 05-Фев-23, 13:44 
GPS работает ниже уровня шумов - это вообще перл, поскольку в GPS используется не прямой приём сигнала, а корреляция нескольких сигналов, плюс сигнал GPS использует широкую полосу, SNR по которой варьируется.
Ответить | Правка | К родителю #299 | Наверх | Cообщить модератору

308. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 05-Фев-23, 13:46 
(и если SNR по всей полосе с определённого источника окажется 0 или менее - сигнал GPS от данного источника резонно принят быть не может)
Ответить | Правка | Наверх | Cообщить модератору

309. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (-), 06-Фев-23, 01:22 
> GPS работает ниже уровня шумов - это вообще перл, поскольку в GPS
> используется не прямой приём сигнала, а корреляция нескольких сигналов,

Вообще-то он и на 1 сигнал может лочиться.

Толку с этого будет мало т.к. для измерения координат надо не менее 3 спутников в 2D а для 3D и всех 4. Без этого в лучшем случае удастся собрать навигационные сообщения и текущее время, но с учетом битрейта и сколько времени занимает полный цикл сообщения - шанс что все это время не будет ошибок приема достаточно скромный и работать это все будет "не очень".

А корреляция там делается на расширенную по бандвизу версию сигнала, когда 1 битик NAV растянут на эвон сколько битиков PRNG (chips). И вот этот вот PRNG, на который корреляция и лочится, так то и является вот именно маркером своего сигнала. И относительно шума, и относительно даже других сигналов спутников. Если последовательности "ортогональные" -  они друг другу не мешают даже при вещании на той же частоте: в среднем их эффект аннулируется. Представляешь, кроме деления эфира по времени и по частоте, есть еще, вот Code-division. Третья опция. Маркирование своего сигнала. И конструирование его так чтобы можно было сразу N сигналов на 1 частоте пускать. Не мешая друг другу. А заодно и от шума помогает - какая корреляция у шума с выходом PRNG? Правильно - мизерная. И как раз по уровню корреляции и понятно - тот ли это сигнал который мы хотели найти или нет.

> плюс сигнал GPS использует широкую полосу, SNR по которой варьируется.

Не отменяет того факта что сигнал спутника светящего жалким 20W передатчиком на половину планеты хилее уровня шумов. Однако есть такая штука - "processing gain". И в этом частном случае он как раз именно о целенаправленной "маркировке" сигнала :). Так что как видим при желании на сигнал можно и свой маркер отличающий его от шума воткнуть. Правда не тегами а последоваьельностью PRNG но это уже детали.

Ответить | Правка | К родителю #307 | Наверх | Cообщить модератору

260. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от pavlinux (ok), 31-Янв-23, 16:49 
> чем отношение уровня шума к уровню сигнала.

Прям так взял и отделил шум от сигнала :D

Там наверно с хедерами летают данные <NOISE>1110001110001110001111</NOISE><SIGNAL>110101010101</SIGNAL><NOISE>111000</NOISE> ...

>  Время выполнения операций в критичных блоках надо рандомизировать

А вот это хороший маркер, как только увидим тормоз в ожидании рандомов - начало критичного блока.

Ща предложит предварительную генерацию рандомов для шифровки 40GbE трафика :D

Ответить | Правка | К родителю #202 | Наверх | Cообщить модератору

283. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 02-Фев-23, 08:14 
Да, чел там почти совершил революцию в теории передачи данных.
Ну, у себя в голове. Реальность так не работает :)
Ответить | Правка | Наверх | Cообщить модератору

313. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (-), 06-Фев-23, 03:03 
> Да, чел там почти совершил революцию в теории передачи данных.
> Ну, у себя в голове. Реальность так не работает :)

Вот те раз, XOR медленных битов NAV с быстрыми chip'ами PRNG, оказывается, революция!

Хочешь глупый и неэффективный) пример? Пусть у нас мастер-бит создается как повтор 256 раз более быстрых битов (чипов). Мы захватываем на приеме только 1 или 0. И черт с PRNG и XOR для простоты.

Как кодируем мастер-1: 256 x 1, мастер-0: 256 x 0. Допустим шум портит биты одинаково, так что без сигнала в среднем при случайном шуме сумма около половины этого, т.е. 128. Идеальный прием 0 разумеется сумма мини-битов = 0, а идеальный прием 1 это сумма мини-битов = 256.

А что если приняли нечто с суммой 50? Это сильно ниже 128, значит "скорее всего 0". А если 150? Это выше 128, "скорее всего 1".

В чем прикол? Если будет только шум, с равномерным 1 и 0, их сумма будет стремиться к половине диапазона. А мастер-сигнал сдвигает центр распределения относительно середины. Чем длиннее последовательность тем меньший сдвиг относительно центра можно уловить и тем выше "processing gain".

Замена суммы на XOR, желательно с PRNG, придает более желательные свойства тому что получится. В том числе и возможность слать >1 потока так чтобы они не мешали друг другу, при низкой корреляции "чужой" поток аннулируется в нечто (почти) не создающее bias в решении 1 это или 0. Ну а по величине корреляции можно судить насколько это вообще похоже на ожидаемый сигнал. Если дистанция от идеальных 0 и 1 слишком большая, это, вероятно, вообще что-то левое.

Ответить | Правка | Наверх | Cообщить модератору

320. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 06-Фев-23, 10:08 
Я и говорю - никакой революции нет и быть не может.

Мы опять и приходим всё к тому же SNR по диапазону - т.е. пытаемся исходить из того, что из-за изменчивости
шумовых характеристик _реального мира_ на длине в те самые 256 слотов SNR в итоге окажется выше 0, и нам удастся за счёт усреднения по диапазону понять, что там реально пришло.

Может быть. Как-нибудь. Что не поняли, забить ECC. Но если всё-таки SNR непрерывно слишком низкий - то "это, вероятно, вообще что-то левое".

В реальном мире так: ставишь "глушилку", дающую SNR<0, и ничего эта схема уже не примет в районе действия таковой.

-

Но вернёмся к исходной задаче: в исходной задаче мало того что передатчик не контролируется, так ещё и есть возможность SNR<0 (задержками, превышающими полное время обработки как одиночно 0 так и одиночной 1) желающему попробовать поусреднять выдать.

Ответить | Правка | Наверх | Cообщить модератору

321. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 06-Фев-23, 10:16 
(про "глушилку" я не ради красного словца заметил: правильная "глушилка" - это как раз таки математический "дохлый номер" для подобных схем с усреднением, можно даже "белый шум" не рассматривать - слишком дорого, хватит дискретного шума: если частота модуляции дискретной помехой (при совпадении полосы носителя, естественно) совпадает или превышает кратно частоту собственно слотов - SNR по всему диапазону станет непрерывно ниже 0, и ничего усреднить хоть и 256, хоть из 2560000000000000000000000000... слотов уже не получится)
Ответить | Правка | Наверх | Cообщить модератору

322. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 06-Фев-23, 10:17 
(амплитуда естественно тоже превышает, убивая амплитудную и частотную модуляции. кратность убьёт фазовую модуляцию)
Ответить | Правка | Наверх | Cообщить модератору

325. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (-), 07-Фев-23, 06:58 
> (амплитуда естественно тоже превышает, убивая амплитудную и частотную модуляции.

Абсолютная амплитуда не важна, если оно более-менее рандомное bias от легитимного источника все равно пролезет в sub-bit'овое разрешение и приемник сможет различать состояния. Главное чтобы большие биты были достаточно медленными для накопления достаточного количества отличий. Нас так то Eb/No нормальный интересовал, а не SNR :)

Ответить | Правка | Наверх | Cообщить модератору

326. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 07-Фев-23, 09:33 
Амплитуда важна. Не абсолютная амплитуда конечно, да, а то, что размах шума в рамках времени суббита или даже меньшего превышает сам суббит по амплитуде.
Ответить | Правка | Наверх | Cообщить модератору

329. "Зависимость времени выполнения инструкций от данных на CPU A..."  –1 +/
Сообщение от Аноним (-), 08-Фев-23, 04:39 
> Амплитуда важна. Не абсолютная амплитуда конечно, да, а то, что размах шума
> в рамках времени суббита или даже меньшего превышает сам суббит по амплитуде.

В случае GPS вот именно cигнал, сам по себе, что-то типа -140-150dBm. Порог шумов выше. И что хочешь с этим то и делай. Он совершенно штатно работает именно в таком режиме, поэтому и устроен вот так вот. На память об этом - даже если у ресивера много каналов и он NAV параллельно с эн спутников ухватывает, необходимый минимум инфо для нормального FIX со всеми наворотами не может быть менее примерно 31 секунды. Это минимальное time to firt fix достижимое в системе бех всяких особо хитрых хаков и читов. Реально может и хуже быть - с учетом времени фрейма NAV гарантий что его спутник будет все это время в видимости, особенно если двигаться - никакой. А FEC там нет и если сколько-то "больших" битов выпало - ну ой, не повезло, начинай сначала.

The C/A PRN codes are Gold codes with a period of 1023 chips transmitted at 1.023 Mchip/s, causing the code to repeat every 1 millisecond. They are exclusive-ored with a 50 bit/s navigation message
У GPS нет монополии на этот фокус, эти трюки можно делать на любом линке, ценой потери битрейта. Шум никак не отменяет измеримый bias, в данном случае проявляющий себя как тот или иной уровень корреляции vs известный шаблон.
Ответить | Правка | Наверх | Cообщить модератору

331. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 08-Фев-23, 08:19 
> В случае GPS вот именно cигнал, сам по себе, что-то типа -140-150dBm.
> Порог шумов выше.

Абсолютнейшее заблуждение, к тому же не дружащее с логикой. Далее обсуждать смысла не вижу.

Ответить | Правка | Наверх | Cообщить модератору

337. "Зависимость времени выполнения инструкций от данных на CPU A..."  –1 +/
Сообщение от Аноним (-), 09-Фев-23, 12:04 
> Абсолютнейшее заблуждение,

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

> к тому же не дружащее с логикой.

Вон тебе вся логика, додик.

> Далее обсуждать смысла не вижу.

Еще бы, сперва азы обработки сигналов изучи. Хотя-бы Шенона. А так чисто посмеяться, я таки запиливал и расширение битности ADC, и простенькое, но все же улучшение линка когда битов стало вместо одного эн, и решение принимается уже не по 1 сэмплу а нескольким, и если совсем непонятно, тому ридсоломону erasure маркируется, он так вдвое больше чинит чота. Пустячок, а апгрейдом фирмвары линк чего-то заметно дальнобойней стал. Хотя формт сигнала, железо и канал те же самые, просто пересмотрено как битики используются и как это декодируется. Ценой потери битрейта разумеется, но там много и не надо было. Ты же не думал что я эти идеи с потолка взял?

Ответить | Правка | Наверх | Cообщить модератору

332. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 08-Фев-23, 09:27 
> эти трюки можно делать на любом линке, ценой потери битрейта

Не на любом, а только на том, в котором шумовая составляющая изменчива, и SNR на суббитах выходит в приемлемый диапазон. Если нет понимания даже этого - ну, повторюсь, обсуждать собственно далее нечего.

Ответить | Правка | К родителю #329 | Наверх | Cообщить модератору

338. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (-), 09-Фев-23, 12:16 
> Не на любом, а только на том, в котором шумовая составляющая изменчива,

Шум по определению изменчив, иначе какой же это шум? Но если ты хочешь повыпендриваться, для GPS один из самых эффективных трюков это локальный синтез протокола: эта версия сигнала просто мощнее, валидна, успешно декодируется и поэтому перекрывает собой спутниковый, так что теперь в Зимбабве. Но это уже не уровень тупого глушения, это осмысленный синтез протокола.

> и SNR на суббитах выходит в приемлемый диапазон.

Вообще-то весь пойнт заморочки с суб-битами это processing gain. А заодно и расширение полосы, так что глушакам становится более тяжко.

Впрочем можно и без суббитов. Ну вон у WISPR, WSJT и проч - просто бит немеряного размера, у особо клинических форм - длина бита до секунды, чтоли, доходит, тоже работает сильно ниже уровня шумов. Просто заходит с чуть другого бока. А в целом читайте Шенона, там про SNR и скорость сказано все что можно сказать.

> Если нет понимания даже этого - ну, повторюсь, обсуждать собственно далее нечего.

Это ты как раз испытываешь проблему с пониманием "processing gain". Который как раз вытягивает в случае когда с точки зрения SNR тухло смотрелось.

Ответить | Правка | Наверх | Cообщить модератору

345. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 09-Фев-23, 14:58 
В исходной нашей задаче зашумления времени выполнения кода предполагается непрерывное зашумление с неизменно превышающей амплитуду полезного сигнала (время 0 и 1) амплитудой. Здесь хоть сколько измерений делай - на выходе будет каша.
Ответить | Правка | К родителю #338 | Наверх | Cообщить модератору

346. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 09-Фев-23, 15:00 
- работает сильно ниже уровня шумов
Ёпрст. Какого уровня шума? Мгновенного? Усреднённого?
Возможно, потому что на этом интервале наверняка найдётся достаточного участков
А вот на минимальном уровне шума выше сигнала - можно забывать.
Ответить | Правка | К родителю #338 | Наверх | Cообщить модератору

347. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 09-Фев-23, 15:24 
Задумайся, откуда у тебя на суббитах или интервалах возникает тот самый "gain".
Это попытка высокой частотной характеристикой получить пристойную амплитудную, которой нет на внешнем интервале целиком. В реальном мире это работает, потому что шум создаётся множеством источников с непостоянными характеристиками. На генераторе белого шума выше уровня сигнала - работать не будет вообще.
Но если у нас на всём интервале амплитудная характеристика шума равномерная - всё, никакому "gain" взяться будет неоткуда.
Ответить | Правка | К родителю #338 | Наверх | Cообщить модератору

324. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (-), 07-Фев-23, 06:50 
> (про "глушилку" я не ради красного словца заметил: правильная "глушилка" - это
> как раз таки математический "дохлый номер" для подобных схем с усреднением,

Математический дохлый номер получается если линк хотел bitrate выше link margin. Чем эти условия вызваны, целенаправленным глушаком или внешними факторами - какая разница? И вопрос сводится к link margin. Если есть цель, можно делать под любой SNR. Просто если сильно увлечься, битрейт получится специфичный.

> совпадает или превышает кратно частоту собственно слотов - SNR по всему
> диапазону станет непрерывно ниже 0, и ничего усреднить хоть и 256,
> хоть из 2560000000000000000000000000... слотов уже не получится)

Вообще-то получается. Более того - на в чем-то похожем эффекте основано расширение разрядности ADC. Когда мы захватываем больше битов чем у железа есть. Более того, при этом еще и абсолютно принципиально чтобы шум - был. Если мы 256 раз захватим условное 0x100 - мы не получили никаких новых данных, облом. А если оно болталось между 0x98 и 0x103 - вот тут уже мелкие sub-bit'овые вещи как раз и влияли на итоговую сумму. И мы извлекли именно эти мелкие суб-битовые телепания. Представляешь, умея различать только 1 и 0 можно однако захватывать промежуточные состояния с произвольной в общем то разрядностью. Главное чтобы 1 и 0 телепались между собой, чтобы тот эффект вообще работал.

Ответить | Правка | К родителю #321 | Наверх | Cообщить модератору

327. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 07-Фев-23, 09:34 
В ADC мы занимаемся обратной задачей - нам надо выделить шумовую составляющую, которая ниже сигнала, здесь как раз усреднение прекрасно работает.
Ответить | Правка | Наверх | Cообщить модератору

341. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Аноним (-), 09-Фев-23, 13:01 
> В ADC мы занимаемся обратной задачей - нам надо выделить шумовую составляющую,
> которая ниже сигнала, здесь как раз усреднение прекрасно работает.

Вообще то достаточно похожие задачи. А усреднением предпочитают не пользоваться в основном потому что...
1) В RF системах долговременный DC-bias обычно не велкам по ряду причин, длинная пачка одинаковых битов - это оно. Усреднение processing gain так то дает, если длинная пачка битов проблем не вызвала. Но это не лучшее решение из известных, хоть и работает.
2) Придумали способ лучше, когда вместо усреднения XOR с специфичными последовательностями. Это позволяет засунуть в 1 полосу сразу N передатчиков которые (почти) не мешают друг другу несмотря на одновременную работу. CDMA интересен тем что processing gain может сочетаться попутно с новым способом дележки эфира на эн передатчиков. И раз пошла такая пьянка то почему-бы не поделить эфир на эн передатчиков заодно, раз уж они (почти) не мешают друг другу из-за специфичного кодирования сигнала?

Ответить | Правка | Наверх | Cообщить модератору

343. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Омномним (?), 09-Фев-23, 14:53 
Почти не мешают друг другу - это очень тоже оптимистично. Noise floor при DSSS растёт с каждым передатчиком. Тут вопрос, насколько быстро оно упрётся в достаточном числе суббитов в конкретной среде.

А в обсуждаемой задаче с атакой у нас нет никаких суббитов, и нет никакой возможности их воспроизвести с заданной точностью в time plane (которая нам как раз и не известна).

Ответить | Правка | Наверх | Cообщить модератору

349. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (-), 10-Фев-23, 15:05 
> Почти не мешают друг другу - это очень тоже оптимистично. Noise floor
> при DSSS растёт с каждым передатчиком.

Растет. Но т.к. корреляция этих последовательностей в нормальных условиях микроскопическая - то растет слабо. Вот GPS и вещает всей толпой на 1575.42 - и ничего, нормально. Хотя с шумами там душно.

> Тут вопрос, насколько быстро оно упрётся в достаточном числе суббитов в конкретной среде.

Вопрос числа суббитов и желаемого processing gain. А так к чему оно стремится Шенон сказал. Одни стремятся к этому с такой стороны, другие с другой. Можно wideband и корреляцией/суббитами, можно narrowband и длинными как черти что битами. Суть примерно та же - накопление инфо о медленном бите. Просто заход с разных сторон.

> А в обсуждаемой задаче с атакой у нас нет никаких суббитов, и
> нет никакой возможности их воспроизвести с заданной точностью в time plane
> (которая нам как раз и не известна).

Вот это - ну совсем не факт. Люди имеют свойство недооценивать объем доступной на самом деле информации в цифровых системах. И потом немало удивляются разным "волшебствам". Вот так мы гимпом вашу замазку на фоточке с документом стираем и все буковки проступают. А вот так видео где нифига не видно - хоть на ютуб лей становится. Откуда такая железная уверенность что вон там все фокусы не сработают кто б его знает. Учитывая что есть несколько атак на практически существуюшие системы которые угадывают состояние системы (в том числе PRNG и ключи) такой оптимизм потом дорого обходится.

Ответить | Правка | Наверх | Cообщить модератору

350. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 10-Фев-23, 16:43 
Достаточно растёт, чтобы та же вафля при правильных звёздах работала так себе уже на втором передатчике :D

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

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

Ответить | Правка | Наверх | Cообщить модератору

333. "Зависимость времени выполнения инструкций от данных на CPU A..."  –2 +/
Сообщение от pavlinux (ok), 08-Фев-23, 14:31 
> А мастер-сигнал сдвигает центр распределения относительно середины.

Итогом будет только ответ: Сигнал есть! :)

Ответить | Правка | К родителю #313 | Наверх | Cообщить модератору

344. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 09-Фев-23, 14:54 
И то не факт.
Ответить | Правка | Наверх | Cообщить модератору

348. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (-), 10-Фев-23, 14:53 
> Итогом будет только ответ: Сигнал есть! :)

Ты лол. Это самый простой и дубовый способ передачи бинарной информации, используемый миллионами устройств, всякие пульты открытия ворот и включения люстр так работают: есть сигнал 1 нет сигнала 0. On-off keying (OOK) это наызвается.

Предлагается сделать продвинутую версию, с коррелятором и CDMA? Вообще, это даже работать будет, почему нет.

Ответить | Правка | К родителю #333 | Наверх | Cообщить модератору

284. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Омномним (?), 02-Фев-23, 08:16 
Ну и да, продолжая о революции.
Как ты там собрался этот маркер вычленять, если оно у нас ничем от исполнения остального кода отличается?
Я уж молчу про попытку время выполнения по сети померить.

Такое ощущение, что вижу какие-то безумные попытки за уши притянуть 1 курс матстата, слабо вспоминаемый.

Ответить | Правка | К родителю #260 | Наверх | Cообщить модератору

314. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (-), 06-Фев-23, 03:12 
> Как ты там собрался этот маркер вычленять, если оно у нас ничем
> от исполнения остального кода отличается?

Ну вот GPS - XOR'кой это делает :). Правда поскольку это все с приличной скоростью (chip rate), а поток битов от PRNG надо еще и двигать относительно сигнала, чтобы нащупать правильную корреляцию, а вариантов сигнала еще и по числу спутников, там это специальными железками подперто, чтобы перебор версий "чей сигнал * сдвиг последовательности по времени" при холодном старте делать за какие-то разумные времена.

Ответить | Правка | Наверх | Cообщить модератору

190. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (190), 30-Янв-23, 13:02 
А все эти уязвимости фиксятся в новых процессорах, или после внесения правок в ядро на это забивают?
Ответить | Правка | Наверх | Cообщить модератору

198. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Аноним (142), 30-Янв-23, 15:00 
Уточните какую именно "уязвимость" нужно "фиксить"?
Если мне не изменяет память количество тактов которые выполнялась инструкция зависело от данных начиная с процессора 8086. Так что наверное ответ на ваш вопрос: нет
Ответить | Правка | Наверх | Cообщить модератору

212. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Аноним (190), 30-Янв-23, 19:34 
Ну там spectre, meltdown, и другие. У меня сложилось впечатление что аппаратных уязвимостей уже десятки.
Ответить | Правка | Наверх | Cообщить модератору

230. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Sem (??), 31-Янв-23, 07:20 
Пока не придумали как это пофиксить без отката производительности до уровня пред core2dio и ещё совместимость не сломать. Поэтому, пока оставили на откуп ОС.
Ответить | Правка | Наверх | Cообщить модератору

272. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Michael Shigorinemail (ok), 01-Фев-23, 01:43 
> Пока не придумали как это пофиксить без отката производительности до уровня пред
> core2dio и ещё совместимость не сломать. Поэтому, пока оставили на откуп ОС.

Интересно, кстати, как в этом плане себя показывают e2k+lintel... (мне-то совместимость не упала, нативного кода достаточно)

Ответить | Правка | Наверх | Cообщить модератору

255. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 31-Янв-23, 13:21 
Из них реально эксплуатируемых не в лабораторных условиях - пока что только Meltdown, L1TF и MDS.
Ответить | Правка | К родителю #212 | Наверх | Cообщить модератору

196. "Зависимость времени выполнения инструкций от данных на CPU A..."  +2 +/
Сообщение от Аноним (196), 30-Янв-23, 14:27 
Уязвимость... Алгоритм нормальный сделай, а не пиши свои тупые патчи для ядра.
Ответить | Правка | Наверх | Cообщить модератору

213. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Аноним (214), 30-Янв-23, 20:08 
> тупые патчи

они не тупые, они заставляют покупать новые процы.

Ответить | Правка | Наверх | Cообщить модератору

271. "Зависимость времени выполнения инструкций от данных на CPU A..."  +2 +/
Сообщение от Аноним (196), 01-Фев-23, 01:42 
или старые
Ответить | Правка | Наверх | Cообщить модератору

273. "Зависимость времени выполнения инструкций от данных на CPU A..."  +1 +/
Сообщение от Michael Shigorinemail (ok), 01-Фев-23, 01:43 
...или вовсе другие :)
Ответить | Правка | Наверх | Cообщить модератору

276. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от troizet (ok), 01-Фев-23, 08:41 
> в будущих моделях процессоров снижение производительности может усилиться.

Т.е. вместо того, чтобы вносить исправления в новые процессоры будем использовать костыли?

Ответить | Правка | Наверх | Cообщить модератору

285. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Омномним (?), 02-Фев-23, 08:17 
Конечно. Покупают же.
Ответить | Правка | Наверх | Cообщить модератору

352. "Зависимость времени выполнения инструкций от данных на CPU A..."  +/
Сообщение от Michael Shigorinemail (ok), 17-Фев-23, 16:44 
Мне вот надоело -- пишу с 16С. :)
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру