forum.opennet.ru

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Оглавление

Зависимость времени выполнения инструкций от данных на CPU ARM и Intel, opennews (??), 29-Янв-23, (0) [смотреть все]

А компания AMD в домике , Аноним (1), 11:31 , 29-Янв-23, (1) //

По-моему из за процессоры не считают,но я бы не отказался от топового амуде D, Попандопала (?), 11:33 , 29-Янв-23, (3) –30 //

На самом деле AMD топ Особенно те AMD, которые APU с графикой Я недавно купил, kawaii_girl (ok), 12:33 , 29-Янв-23, (21) +26 //

Про апу это довольно смешно Ни процессор ни видеокарта Ни рыба ни мясо Для ра, Аноним (27), 12:52 , 29-Янв-23, (27) –24

Все зависит от ваших требований Если вы хотите игры в 4k и 250 FPS, то не поигр, kawaii_girl (ok), 13:00 , 29-Янв-23, (31) +11

Кому-то и скайрим на минималках норм, с просадками Не надо разводить клоунаду, , Аноним (27), 13:18 , 29-Янв-23, (38) –9

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

Да я помню эти восторги Мне тут говорили, что в режиме игр за час батарейка выс, Аноним (27), 13:43 , 29-Янв-23, (45) –1

Говорить могли что угодно, а пруфы есть , Аноним (102), 18:52 , 29-Янв-23, (102) +2

Как только начнут апушки оснащать большим объемом распаянной или вшитой жирной, Аноним (51), 14:16 , 29-Янв-23, (51) +2
Skyrim прекрасно идёт на 4х ядерных Atomax на их встройках с 2Гб ОЗУ Конешно на, _kp (ok), 21:40 , 29-Янв-23, (130) –1

Да только даже относительно-современные амуде с интегрированной графикой вообще , Бывалый смузихлёб (?), 16:09 , 30-Янв-23, (205) +1

Поиграть на ноуте Мсье знает толк в извращениях В три в ряд разве что, ну сер, Омномним (?), 10:54 , 31-Янв-23, (249) –1

ну если экран убогий, там 1024х768 или ещё хуже - тогда да, иных причин не вижув, Бывалый смузихлёб (?), 12:02 , 31-Янв-23, (252)

Ну я больше фанат 65 и выше для погамалок DСо стационарником, ага 1920x1080 на, Омномним (?), 13:17 , 31-Янв-23, (253)
Короче ноут - это для вёбзагамалок и прочих три-в-ряд А так - контроллер, диван , Омномним (?), 13:18 , 31-Янв-23, (254)
Поддерживаю Это сильный плюс ноута против стационарного И именно поэтому и стр, pic (?), 12:59 , 05-Фев-23, (304)

Когда появятся на прилавках AMD-процессоры с RDNA3 на борту, вот тогда будет раз, Аноним (288), 11:18 , 02-Фев-23, (288)

Не поделитесь ссылкой на драйвер встроенной графики для APU Ryzen, а то я как и , anonymous (??), 15:33 , 29-Янв-23, (65) –2

Странная ситуация Для графики AMD как дискретной, так и APU используется свобо, kawaii_girl (ok), 15:48 , 29-Янв-23, (66)

Пока меня не забанили за оффтопик Как раз федора 37 и стоит, до этого убунту , anonymous (??), 16:58 , 29-Янв-23, (83) –2

Как это проявляется Гном лагает Что в настройках GNOME в пункте о системе напи, kawaii_girl (ok), 17:40 , 29-Янв-23, (87) +2
У меня кстати не смотря на то что все работает такая же ерунда выдается если вве, kawaii_girl (ok), 17:43 , 29-Янв-23, (88)
Сейчас погуглила вот это Это не баг и такой вывод не означает что GPU ускорение, kawaii_girl (ok), 17:52 , 29-Янв-23, (92)

Хорошие так-то APU, действительно Успел поиграть на копеечном 3200U в 3-их и 5-, Аноним (115), 20:06 , 29-Янв-23, (115)

Да не, ну если текстурирование отключить - даже киберкотлетить можно Полигоны к, Омномним (?), 13:55 , 31-Янв-23, (257)

В онлайн игры никогда не играла и не собираюсь Не интересно Поэтому не знаю ка, kawaii_girl (ok), 19:31 , 31-Янв-23, (263)

Скорее мучаться, а не играть На минималках, с просадками по FPS на сложных сцен, Омномним (?), 17:26 , 01-Фев-23, (279)

На консолях все еще хуже Но при этом консоли вполне себе пользуются популярност, kawaii_girl (ok), 20:26 , 01-Фев-23, (280)

На вскидку, около 99 игр от всего каталога Стима прекрасно играются на свежих в, Beta Version (ok), 19:26 , 29-Янв-23, (106) +1

У меня на AMD Ryzen 7 5700U 20-30 FPS в valheim на минимальных настройках с ужас, Аноним (142), 23:02 , 29-Янв-23, (142)

А diablo 2 resurected работает хорошо, хотя в минимальных системных требованиях , Аноним (142), 23:18 , 29-Янв-23, (143)
Этого уже достаточно Ну лично для меня На консолях кстати игры примерно так и , kawaii_girl (ok), 23:28 , 29-Янв-23, (144)

для valheim нет, он отвратительно дергается на такой производительности То есть, Аноним (142), 10:30 , 30-Янв-23, (181)
Ага, 20FPS, на минималках и удовольствие от такой игры состоит в чем Ну ладн, Аноним (-), 10:47 , 09-Фев-23, (334)

Все таки обычно ближе к 30 И это в киберпанке В более старых и менее требовате, kawaii_girl (ok), 12:30 , 09-Фев-23, (339)

Многое зависит от оптимизации конкретных игр и от самого ноутбука, какой у него , Beta Version (ok), 23:37 , 29-Янв-23, (147)

Я собрала компьютер на APU Ryzen специально чтобы играть в тяжелые игры Видеока, kawaii_girl (ok), 23:57 , 29-Янв-23, (153) +1

Если устраивают низкие настройки и иногда даже 720p, то ок Большинство геймеров, Beta Version (ok), 00:19 , 30-Янв-23, (157)

Питальник лучше с запасом взять и хороший Иначе потом будете чертыхаться и меня, Аноним (-), 11:01 , 09-Фев-23, (336) –1

Вообще-то сильно - если VRAM своя, это все же скоростная память на дополнительно, Аноним (-), 10:56 , 09-Фев-23, (335)

Огромный гроб у меня на стол не помещается К тому же большой корпус не только б, kawaii_girl (ok), 12:42 , 09-Фев-23, (340)

Есть один нюанс покомпилировать лучше будет на двухсокетной материночке, а дела, Аноним (-), 18:27 , 29-Янв-23, (94) –1

Спасибо за информацию В целом вы ответили на мой вопрос, вы и я используем драй, anonymous (??), 19:15 , 29-Янв-23, (104) –1
Зачем двухсокет для компиляции Что за бред , Аноним (102), 21:23 , 29-Янв-23, (127) +1

Для компиляции EPYC рулят проверено Торвальдсом и ко , Аноним (-), 23:30 , 29-Янв-23, (145) +1

Отличные CPU После перевода серверной фермы на AMD все безумные проблемы наприм, Омномним (?), 09:59 , 30-Янв-23, (174) +1

В компании AMD понимают, что поднимать производительность за счёт безопасности п, Лиза Су (?), 16:12 , 29-Янв-23, (70) +4 //

Просто они до таких оптимизаций еще не дошли , Аноним (210), 18:23 , 30-Янв-23, (210) –1 //

Знаете, в _этой_ спецолимпиаде не факт, что стоит быть первым отправлено с эл, Michael Shigorin (ok), 01:18 , 01-Фев-23, (265)

В одном домике со всеми https www opennet ru keywords amd html, Аноним (82), 16:54 , 29-Янв-23, (82) +1

Чего еще остается довольно быстрым в ядре линукс БСД так себе в ногу не стреляе, Попандопала (?), 11:32 , 29-Янв-23, (2) //

Поэтому БСД и не может стоять в ответственных местах , Аноним (7), 11:44 , 29-Янв-23, (7) –5 //

А Juniper-то и не в курсе, Аноним (1), 14:16 , 29-Янв-23, (52) +4 //

Juniper уже перешел на linux Бздя может и осталась где-то в неподдерживаемых ус, name (??), 14:58 , 29-Янв-23, (60) +2

И ты, Брут W Джун , Аноним (-), 07:37 , 31-Янв-23, (231)

Чего Я там работаю , name (??), 14:58 , 31-Янв-23, (259)

Я про Джунипера пославшего фрю Ее все чего-то в последнее время посылают Видим, Аноним (-), 05:01 , 06-Фев-23, (316)

Juniper перешел на Linux, нетфликс скатился в BLM, мндя Аргументы и факты заканч, Аноним (277), 12:53 , 01-Фев-23, (277)

Как сказал недавно Торвальдс есть 2 варианта взаимодействий с реальностью в ситу, Аноним (-), 05:05 , 06-Фев-23, (317)

Возможно поэтому freebsd перестали использовать на серверах, Igraine (ok), 12:24 , 29-Янв-23, (16) –7
Правильно, они гранатой в футбол играют Это веселее , Аноним (-), 23:33 , 29-Янв-23, (146) +2

Получается, на компьютеры уже впору возвращать кнопку Турбо - для переключения, InuYasha (??), 11:34 , 29-Янв-23, (4) +40 //

А ведь вы гениальный чел XD Почему возврощать Неужели такое уже было , Попандопала (?), 11:36 , 29-Янв-23, (5) –7 //

Было ппреключало проц 286 в режим работы 86-го - для нормальной работы программ, Аноним (10), 11:51 , 29-Янв-23, (10) +3 //

А вот на 486-х эти режимы отображались на 7-сегментном индикаторе в виде весёлых, Аноним (120), 20:45 , 29-Янв-23, (120) +3

Почему на 486 Лохи ещё на первых AT-корпусах под 286 были , Омномним (?), 10:01 , 30-Янв-23, (175) +1
Там джамперами что угодно выставлялось , Аноним (177), 10:10 , 30-Янв-23, (177) +1

Помню как сильно расстроился когда об этом узнал - думал, там реально частота от, InuYasha (??), 13:02 , 30-Янв-23, (189) +1

Зато сейчас можешь себе такой на микроконтроллере запилить, только если на нем ч, Аноним (-), 07:39 , 31-Янв-23, (232) +1

Не везде Бывали и с жёсткой пропайкой , Омномним (?), 10:47 , 31-Янв-23, (246)

https joyreactor cc post 2283880 вот тут рядом с надписью HI две кнопки Reset, Zenitur (ok), 11:52 , 29-Янв-23, (11) +4 //

В реальности на более современных на тот момент системах ничего не менялось , Аноним (12), 12:13 , 29-Янв-23, (12)

Менялось У нас на кафедре в 1990 году стояла Turbo XT При включении тактовая , Аноним (63), 15:03 , 29-Янв-23, (63) +4

только вот ПК в корпусах с кнопками турбо продавались до середины нулевых, кнопк, Аноним (133), 22:24 , 29-Янв-23, (133) +1

Начиная с первых пентиумов эта кнопка действительно стала чисто декоративной, ту, Аноним (63), 07:31 , 30-Янв-23, (164) +1

На PC XT, которые шли на 8086, а не 8088, была уже кнопка, работал на таком Толь, Омномним (?), 10:25 , 30-Янв-23, (179)

О чем я и толкую тому анониму Кнопка была, тактовую частоту реально переключала, Аноним (63), 10:55 , 30-Янв-23, (182) +1
На 8086 быстрых XT не было, были на 80186, NEC V Но это не важно, как добавил, _kp (ok), 21:58 , 30-Янв-23, (217)

Я честно говоря не помню точно, именно на 8086 или всё-таки наоборот, на 8088, н, Омномним (?), 10:50 , 31-Янв-23, (247)
Но это были именно PC XT в их классическом корпусе, и точно 808x Номер модели, Омномним (?), 10:51 , 31-Янв-23, (248)

Не фига, видел машинку, на которой кнопка турбо отключала кеш у первопня, Neon (??), 01:07 , 31-Янв-23, (223)
Сходите в яндекс-музей, чуток помолодеете , Michael Shigorin (ok), 01:21 , 01-Фев-23, (266)

Была машинки, на которой кнопка турбо отключала кэш и 486 или пень превращался в, Neon (??), 01:06 , 31-Янв-23, (222)

Спасибо Проектировщики были раньше с мозгами похоже , Попандопала (?), 12:17 , 29-Янв-23, (14) +3

В то время было проще решить задачу выведя дополнительную кнопку с платы, в оста, Аноним (27), 12:48 , 29-Янв-23, (25)
Типа сейчас нельзя частоты через биос увеличивать , Урри (ok), 18:37 , 29-Янв-23, (97) –1

вообще-то как раз сейчас и нельзя нормально увеличивать по сравнению с биосами н, Аноним (133), 22:25 , 29-Янв-23, (134) +1

Смешно Если искать можно найти Мне когда то тут ткнули пальцем -китайцы оказывае, maximnik0 (?), 10:04 , 30-Янв-23, (176)
Ну вообще сейчас это и не требуется, так как процы внутри себя делают турбо в , Омномним (?), 11:29 , 30-Янв-23, (185) +1

но всё равно иметь такую кнопку - прикольно, разве нет К тому же, всякие мате, InuYasha (??), 13:05 , 30-Янв-23, (191)

Ну эту кнопку сейчас приделать не просто, а очень просто Пихаем на USB в виде до, Омномним (?), 10:44 , 31-Янв-23, (245)

Иногда для однопоточных приложений требуется Беда в том что в этом случае требуе, maximnik0 (?), 15:34 , 30-Янв-23, (201)

Ну так нужно в биос заходить А тут прямо во время работы можно было кнопку нажа, Neon (??), 01:08 , 31-Янв-23, (224)

Да, я тоже так считаю Однако кое в чём я с ними не согласен Когда вышел 286 про, Zenitur (ok), 14:21 , 30-Янв-23, (194) +1

Не то что б бойкотировала, но без поддержки выхода из него в биос, через очень б, _kp (ok), 22:09 , 30-Янв-23, (218) +3

Действительно Я об этом и не подумал В 2002 году у меня был дуалбут WinME WinX, Zenitur (ok), 12:00 , 31-Янв-23, (251) +2

Ну не шмогла , Neon (??), 01:10 , 31-Янв-23, (225)

Тогда у малвари и хацкеров появится новый способ атаки Они просто будут нещадно, ВредныйАнон (?), 15:03 , 29-Янв-23, (62) //

Не актуален такой способ атаки Эффективные менеджеры и продуктивные разработч, Аноним (71), 16:16 , 29-Янв-23, (71) +8
Ну тогда уж свинцовые трусы, иначе никак, Аноним (211), 19:04 , 30-Янв-23, (211)

sudo apt install msr-toolsИ прилепи на хоткей любимого DM Режим Тормоз s, pavlinux (ok), 18:28 , 29-Янв-23, (95) +7

Интел и амд долгие годы занимались читерством, ускоряя процессоры на проценты и , Аноним (6), 11:41 , 29-Янв-23, (6) +7 //

Почему читерством , Аноним (8), 11:44 , 29-Янв-23, (8) //

Потому что вместо увеличения количества транзисторов, частоты, кеша, оптимизации, Аноним (20), 12:32 , 29-Янв-23, (20) +1 //

спекулятивное вычисление это и есть оптимизация архитектуры, ИмяХ (?), 12:57 , 29-Янв-23, (30) +10

ага, а вирусы это программы которые оптимизируют пользовательские данные, Аноним (32), 13:05 , 29-Янв-23, (32)

Любител Интел, амд и других читерских спекулятивных процессоров скоро и не таког, Аноним (142), 13:09 , 29-Янв-23, (34) –1
Угу, вирусы - это санитары данных Они нападают в основном на самые старые и бол, Аноним (93), 18:19 , 29-Янв-23, (93) +4

Ну это как посмотреть Я тоже могу сказать, что установка чита -- это оптимизаци, Аноним (20), 13:15 , 29-Янв-23, (36) +1

Причём тут ваши игровые понятия честно или нечестно Компьютер должен работа, ИмяХ (?), 14:07 , 29-Янв-23, (49) +1

К сожалению, сегодня ваши данные могут украсть даже если просто оставить открыто, Albertio (ok), 15:21 , 29-Янв-23, (64)

Радиоуправляемая стрекоза залетит с камерой, не иначе , Аноним (71), 16:23 , 29-Янв-23, (74) +1

На самом деле это не шутка - в ДАРПА уже 10 лет это из публично известного зан, InuYasha (??), 14:16 , 30-Янв-23, (192)

Зачем спорить с тем кто не понимает о чем пишет У Орелла был описан речекряк , Аноним (142), 19:25 , 29-Янв-23, (105)

Оруэлла, Аноним (142), 21:29 , 29-Янв-23, (128)
Оруэлл на Западе давно уже реальность Когда негра нельзя назвать негром, а pi2-, Neon (??), 01:12 , 31-Янв-23, (226) +1

Причём Тут выше спрашивали, почему читерство Я и ответил, почему А про вред, Аноним (20), 20:54 , 29-Янв-23, (123) +1
Действительно, не на всяком компе есть ценные данные, и причем на большинстве , _kp (ok), 22:11 , 30-Янв-23, (219)

Тем, что на соревнованиях мониторы предостаявляет организатор , Аноним (108), 19:33 , 29-Янв-23, (108)

Глупым инженерами из Интел и АМД никогда не понять того что очевидно любому опен, Аноним (142), 13:06 , 29-Янв-23, (33)

Инженерам из интел и амд известно кое-что, о чём аноним не задумывался А именно, Аноним (20), 13:10 , 29-Янв-23, (35)

Скрыто модератором, Аноним (-), 18:28 , 29-Янв-23, (96) –1

Как не станно, это не читерство, а оптимизация схем , Аноним (7), 11:51 , 29-Янв-23, (9) –1
Ты хотел сказать разработками передовой техники , Аноним (12), 12:13 , 29-Янв-23, (13) –3 //

Он хотел сказать, что так не может , Аноним (17), 12:28 , 29-Янв-23, (17)

Штеуд и нвидия занимались, молодой человек, учите историю, если опоздали родитьс, Аноним (18), 12:29 , 29-Янв-23, (18) +2 //

Да, amd действительно лучше В AMD нет таких серьезных проблем с безопасностью и, kawaii_girl (ok), 12:39 , 29-Янв-23, (22) +3 //

Нет такого лучше хуже Зависит от задач и конкретного набора железа, но, если вз, Аноним (27), 12:45 , 29-Янв-23, (23) –2

ага, intel особенно помогает думать при очередном патче калечащей производительн, Аноним (32), 13:17 , 29-Янв-23, (37) +2

Не нравится, не используй заплатки На практике вообще не заметно и никак не изм, Аноним (27), 13:23 , 29-Янв-23, (39) –1

Безопасности или производительности, вот в чём вопрос Достойно ль смиряться под , Аноним (32), 14:06 , 29-Янв-23, (48) –1

Именно так Зато внезапно вспомнили про PGO и no-semantic-interposition, которые, Аноним (27), 14:31 , 29-Янв-23, (54)

Если бы кушай что дают и не возникай - обычный подход Редко кто настройки по , Neon (??), 01:16 , 31-Янв-23, (227)

Есть такое хуже лучше Современный Интел не умеет в энергоэффективность и ноутбу, Beta Version (ok), 19:31 , 29-Янв-23, (107) –1

Современный амд не может в USB и не умеет в софт и софт в него, интел с последн, Аноним (27), 19:56 , 29-Янв-23, (112) –2

У меня работает USB А что у тебя не так И какой софт не работает , Beta Version (ok), 20:03 , 29-Янв-23, (113)

Не софт Когда подключаешь USB-звук, он не работает, как должен И на интелах та, Аноним (27), 20:05 , 29-Янв-23, (114) –1

Что за USB-звук Поподробнее И тут поподробнее У меня сейчас 5600X Как мне тво, Beta Version (ok), 20:33 , 29-Янв-23, (118) +3

А, ты про проблемы с софтом Да, постоянные проблемы из-за simd и переключения я, Аноним (27), 20:08 , 29-Янв-23, (116) –1

Сопли под крышку вместо термопасты штеуд уже не пихает Или интелоёбство прости, Аноним (131), 22:15 , 29-Янв-23, (131) +1

Сектанство у интелобоев Амуде какашкой назвал и адепты вечно красных дико возбу, Попандопала (?), 00:00 , 30-Янв-23, (154)

Не очень понятно что в интеле хорошего Бэкдоры Постоянное срезание всех мыслим, Аноним (-), 07:50 , 31-Янв-23, (233) +1

Ви таки сомлевались , Омномним (?), 10:41 , 31-Янв-23, (244)

Это что https www lenovo com ru ru laptops thinkpad t-series ThinkPad-T16-16 , Аноним (46), 13:51 , 29-Янв-23, (46) +3

О, оказывается есть Спасибо , kawaii_girl (ok), 14:43 , 29-Янв-23, (58) +1

Thinkpad делают не только на AMD,но и на ARM , Роман (??), 14:08 , 29-Янв-23, (50) +1

На qualcomm Поддержка линукса есть , kawaii_girl (ok), 14:45 , 29-Янв-23, (59)

В виде WSL есть, в виде инсталла на голое железо - не интересовался детально, ду, Роман (??), 19:07 , 29-Янв-23, (103)

Ну тогда и жену себе в сексшопе купите , Аноним (-), 07:52 , 31-Янв-23, (234) +1

Даже это уже можно, нужно людям, но Год Линукса На Десктопе всё не наступает, ни, Роман (??), 08:45 , 31-Янв-23, (237) –1

Да вот А С Пушкин как-то сказал зачем стадам дары свободы Поэтому для них и, Аноним (-), 11:56 , 05-Фев-23, (298)
На лично моем десктопе он уже лет 15 как наступил А чем вы там будете пользоват, Аноним (-), 05:10 , 06-Фев-23, (318)

А про 65532 Thinkpad ы на ARM можно подробности , Аноним (120), 20:50 , 29-Янв-23, (121) +1

https www reddit com r thinkpad comments zmog35 x13s_first_impressions ну и та, Роман (??), 06:54 , 30-Янв-23, (162)

У меня thinkpad t495 на райзене, Аноним (100), 18:41 , 29-Янв-23, (100)

А можно мне максимально читерский, но максимально быстрый ЦПУ А вот с этими всем, Урри (ok), 18:38 , 29-Янв-23, (98) +3 //

Тогда не надо напрягаться, что каждый раз после выхода в интернет на ваш комп ус, Аноним (6), 20:39 , 29-Янв-23, (119) –1 //

И, всё равно, замедлит максимально быстрый ЦПУ , Аноним (120), 20:52 , 29-Янв-23, (122)
Ну для базы данных аналитики пофиг на выход в нет, даже так, изолировать ее от н, Олег (??), 11:23 , 30-Янв-23, (183)

Ну так уж и вдвое , Аноним (206), 16:43 , 30-Янв-23, (206)

mitigations off, Igraine (ok), 12:21 , 29-Янв-23, (15) +1 //

Помогает, но недостаточно Ибо часть кода не написана в двух вариантах , Урри (ok), 18:39 , 29-Янв-23, (99) +1 //

имя файла и номера строчек в студию, Аноним (133), 22:20 , 29-Янв-23, (132)

В итоге будет как с флагом fast-math, когда если одна из библиотек включила этот, Аноним (46), 12:30 , 29-Янв-23, (19) +5 //

related https gcc gnu org bugzilla show_bug cgi id 55522, Аноним (46), 21:40 , 29-Янв-23, (129) +1

иногда кажется, что разрабы линукса искусственно подкидывают запланированное уст, Аноним (24), 12:45 , 29-Янв-23, (24) +5 //

Любому сделавшему за новостями на опеннет и читающему умные комментарии, это сра, Аноним (142), 12:53 , 29-Янв-23, (28) +1 //

Не надо предполагать, что люди где-то там обязательно умнее тебя , Аноним (43), 13:38 , 29-Янв-23, (43) +1 //

Да, ведь как они смеют быть умнее светил с Опеннета , Аноним (250), 10:56 , 31-Янв-23, (250)

Прикол в том, что большинство заплаток тормозят на уровне статистической погрешн, Аноним (27), 12:56 , 29-Янв-23, (29) –6 //

Ды щаз Всё от задач зависит В массовой виртуализации на личных сэмплах Meltdown, Омномним (?), 10:26 , 30-Янв-23, (180) +2
Вы говорите неправду ц -- проверено на i7-3517U и i5-3317U, статистика прям та, Michael Shigorin (ok), 01:33 , 01-Фев-23, (268) //

А что именно тормозит Я так и не смог обнаружить разницы Виртуализация -- это , Аноним (27), 14:31 , 01-Фев-23, (278)

Сравнил на одном и том же ноуте 2011 года скорость работы в Windows 11 и Fedora , Аноним (-), 14:43 , 29-Янв-23, (57) //

Потому что amd , . (?), 16:40 , 29-Янв-23, (79) –2 //

Да, AMD A6-3400M со встроенной в него видюхой Radeon HD 6520G Дискретки в ноуте, Аноним (63), 07:37 , 30-Янв-23, (165)

Какие тесты для измерения производительности использовались , Аноним (120), 20:55 , 29-Янв-23, (124) +1 //

Чуйка опеннет эксперта не требует доказательств, НяшМяш (ok), 01:49 , 30-Янв-23, (158) +2
Скорость загрузки и запуска программ, отзывчивость интерфейса и с какой скорость, Аноним (63), 07:42 , 30-Янв-23, (166)

В вашем уравнении слишком много переменных И вообще если ставить простой линукс, . (?), 09:51 , 30-Янв-23, (170) +1

Обе системы были из коробки, как есть Но я сильно сомневаюсь что после отключен, Аноним (63), 10:20 , 30-Янв-23, (178) –1

Сомневайтесь дальше, товарищ эксперт, . (?), 14:17 , 30-Янв-23, (193) +1

Ну когда со всякими виндами экспериментируешь с 92 года, а с линуксами с 98 - сл, Аноним (63), 14:24 , 30-Янв-23, (195) –2

Купил много лет назад маме бюджетный ноут с предустановленной Win8 Так венда, ч, Beta Version (ok), 15:13 , 30-Янв-23, (200)
Возможно в те годы именно так и было, что винда была шустрее Но начиная с вин7 , . (?), 15:51 , 30-Янв-23, (203)

EVE Online больше не играю ни во что под Win11 на средних настройках графики р, Аноним (63), 23:17 , 30-Янв-23, (221)

То-то у приятеля двадцать лет назад под winex игрушки быстрее шастали, чем на ви, Michael Shigorin (ok), 01:35 , 01-Фев-23, (269)

Целых два пасьянса и один сапер, которые под вайном вообще запустились, Аноним (63), 07:29 , 01-Фев-23, (275)

У тебя в конфигурации SSD ,а с ним есть тонкости,файловая система по умолчанию к, maximnik0 (?), 16:06 , 30-Янв-23, (204)

Выравниванием разделов вручную не заморачивался, просто в инсталляторе сказал чт, Аноним (63), 22:56 , 30-Янв-23, (220)

Рекомендуют для ssd отключать журналирование при условии что батареи на ноутбуке, maximnik0 (?), 03:15 , 31-Янв-23, (229)

Так проблема-то именно на новом железе, а на старом не проявляется , Аноним (71), 16:22 , 29-Янв-23, (73) //

я тебе открою один секрет новое железо тоже станет старым, Аноним (133), 17:44 , 29-Янв-23, (89) +4 //

Зато старое не устареет никогда , Аноним (108), 19:34 , 29-Янв-23, (109) +2

Что за бред Устареет, когда не сможешь аппаратно декодировать какой-нибудь код, деанон (?), 23:08 , 31-Янв-23, (264)

При чём _тут_ линукс , Michael Shigorin (ok), 01:32 , 01-Фев-23, (267)

а почему все зацикливаются на фиксах процессоров, когда править нужно алгоритмы , Allllex (?), 13:25 , 29-Янв-23, (40) +4 //

Сделать аппаратный блок Да ну на Лучше дырявые программы будем мучить , Аноним (43), 13:41 , 29-Янв-23, (44) +4 //

В очередной раз удивляюсь гениальности аудитории опеннет Так называемым инженера, Аноним (142), 16:52 , 29-Янв-23, (81) –3 //

Не пришла же - по факту , Аноним (43), 23:41 , 29-Янв-23, (149) +2

https www intel com content www us en developer articles technical advanced-en, Аноним (142), 17:27 , 30-Янв-23, (207) –2

То-то ребята из Нижнего приезжали знакомиться, вдоволь наконсультировавшись , Michael Shigorin (ok), 01:38 , 01-Фев-23, (270)

Ага аппаратный блок, в котором будет аппаратный баг , Neon (??), 01:26 , 31-Янв-23, (228) +1

алгоритмы шифрования это тока вершина айсберга, при наличии возможности определя, Аноним (32), 14:30 , 29-Янв-23, (53) +1 //

А при наличии возможности запускать произвольный код wait, OH SHIT, без запу, Аноним (71), 16:20 , 29-Янв-23, (72) +1
Если что-то в принципе возможно прочитать, значит возможно украсть Вы не выигра, Урри (ok), 18:41 , 29-Янв-23, (101) –2 //

здесь не в прятках проблема, всё как раз на виду, особенно в облаках, тут пробле, Аноним (32), 20:25 , 29-Янв-23, (117) +1

ждем эру процессоров работающих с гомоморфно шифрованными данными, остается воп, Sw00p aka Jerom (?), 07:05 , 30-Янв-23, (163)
Не даёт, а теоретически может дать, и то приложившему значительные усилия и сред, _kp (ok), 11:25 , 30-Янв-23, (184)

Поучи для начала самый просто тервер Потом уже можешь тут писать всякие глупост, Аноним (12), 16:24 , 29-Янв-23, (76)
Изучи криптографию получше, тогда не будешь глупых вопросов задавать , Аноним (126), 21:02 , 29-Янв-23, (126) –3
Изучи матанализ и тогда не будешь писать несуразности, Аноним (142), 08:23 , 30-Янв-23, (167) +1
тогда на асм надо писать, а так вывод компилятора смотреть и додумывать, трата , Sw00p aka Jerom (?), 12:39 , 30-Янв-23, (188)
Лично я тоже не понимаю почему нужно тормозить весь процессор и все программы на, Аноним (142), 17:35 , 30-Янв-23, (208)
Ну во первых, алгоритм не контролирует напрямую какие команды будут сгенерены, э, Аноним (-), 07:54 , 31-Янв-23, (235) //

Ни одной практической атаки до сих пор так и не зафиксировано, всё это работает , Омномним (?), 10:39 , 31-Янв-23, (242)

Потому что это проще продать В прямом смысле , Омномним (?), 10:40 , 31-Янв-23, (243)

А они таки обещали , user (??), 13:54 , 29-Янв-23, (47)
Надеюсь эти МЕГА ПОЛЕЗНЫЕ ПАТЧИ будут включаться специальными флагами на этапе к, Аноним (56), 14:39 , 29-Янв-23, (56) +2 //

Да, то же mitigations off уже стало нормой , Омномним (?), 09:53 , 30-Янв-23, (171)

Делайте с ядром что хотите, главное - чтоб хешрейт не просел , Аноним (84), 17:13 , 29-Янв-23, (84)
А где доказательство того, что это не включает дыру для ЦРУ 0x00001b01 - а тако, pavlinux (ok), 17:49 , 29-Янв-23, (91) –6
Зависимость это плохо , Аноним (110), 19:41 , 29-Янв-23, (110) +1
И это пропихивают в качестве архитектуры будущего Ололо , Аноним (141), 22:41 , 29-Янв-23, (141) +3 //

Вот именно, что пропихнули , Аноним (43), 23:40 , 29-Янв-23, (148)
Которое из это вы имеете в виду , ДаНуНафиг (?), 03:59 , 30-Янв-23, (160) //

АРМ, очевидно , Аноним (141), 11:43 , 30-Янв-23, (187) //

И Штеуд тоже , Аноним (206), 14:59 , 30-Янв-23, (197) +1

Я уже давно думаю Вот если важно, чтобы некая критическая операция, типа аутент, Аноним (168), 08:46 , 30-Янв-23, (168) +2 //

Задержка может быть отслежена по вторичным каналам типа кеша, потому что сильно , Омномним (?), 09:55 , 30-Янв-23, (172) +1 //

А Так это чтоб на Си не писать, чтоб Яваскрипты и Питоны использовать , _kp (ok), 11:36 , 30-Янв-23, (186) //

На них заманаешься крипто ждать хоть там как Не тормозят же , Аноним (-), 07:56 , 31-Янв-23, (236) +1

Мне вообще непонятны эти пляски вокруг постоянного времени выполнения Время выпо, Омномним (?), 09:51 , 30-Янв-23, (169) //

Почему это Берёшь N одинаковых сигналов вместе с шумом, суммируешь их, рандомны, Аноним (-), 15:49 , 30-Янв-23, (202) –2 //

Уже ошибка выборки в _разное_ время Шум же неидеальный , Аноним (214), 20:10 , 30-Янв-23, (214) +1 //

Т е с увеличением времени анализа ситуация на _реальных_ системах будет только , Аноним (214), 20:13 , 30-Янв-23, (215)
Верно Ну и да - речь-то у нас о timing attack, где мы дополнительно ну никак точ, Омномним (?), 10:37 , 31-Янв-23, (240) +2

как только шумовая составляющая превысит сумму определимых значений времени ста, Омномним (?), 10:38 , 31-Янв-23, (241) +2

А, да, ещё один момент дискретность компутерных чисел Если складывать большой , Аноним (214), 13:30 , 31-Янв-23, (256)

Да не, там всё проще Нам надо либо множество сэмплов одного и того же сигнала с , Омномним (?), 13:59 , 31-Янв-23, (258)

А вот это - ну не факт Мы можем и некие тесты на известных паттернах прогнать Е, Аноним (-), 04:07 , 08-Фев-23, (328)

Вот этим и отличаются математики от инженеров , Аноним (214), 20:13 , 30-Янв-23, (216) //

Угу, по ходу там BSD-теоретик N даже для фонового шума питания будет запредельн, Омномним (?), 10:33 , 31-Янв-23, (239)

Запредельным -- это каким 10 12 Гигагерцовому процессору на выполнение 10 12, Аноним (-), 18:47 , 31-Янв-23, (262)

и что может произойти за час ничего ведь не поменяется, всё будет стоять, как в, Аноним (214), 07:25 , 01-Фев-23, (274)
Точно BSD-теоретик Даже если мы имеем дело с side channel leak, а не сетевой экс, Омномним (?), 08:11 , 02-Фев-23, (281)

Нет Ты исходишь из того, что шум имеет паттерн Естественно, идеального шума не б, Омномним (?), 10:32 , 31-Янв-23, (238) //

Нет, это ты хочешь, чтобя я исходил из этого, потому что это позволит тебе счита, Аноним (-), 18:37 , 31-Янв-23, (261) –1

Сейчас ты вообще ушёл в сторону от исходной проблемы В конкретном случае мы вооб, Омномним (?), 08:13 , 02-Фев-23, (282)
То есть ты мне сейчас вещаешь, что при SNR 0 достаточно просто хорошо поусреднят, Омномним (?), 08:19 , 02-Фев-23, (286)

при SNR 0, конечно же, Омномним (?), 08:21 , 02-Фев-23, (287)
Да, я в отличие от тебя читал Клода Шеннона, который считается основоположником , Аноним (290), 17:26 , 03-Фев-23, (290)

А теперь подумай, в какой степени это применимо к обсуждаемому - и наконец просн, Омномним (?), 21:27 , 03-Фев-23, (291)
Ты не _передаёшь_ сигнал, ты его _принимаешь_ Передатчик тебе не подконтролен , Омномним (?), 21:27 , 03-Фев-23, (292)

если совсем туго - ты принимаешь _чужой_ сигнал, который зашумлён до уровня нер, Омномним (?), 21:30 , 03-Фев-23, (293)

А если ещё проще - да, можно добиться SNR 0 при практически любом уровне шума, и, Омномним (?), 21:38 , 03-Фев-23, (294)

Слышь, чудик, я не тот анон но чтоб ты знал SNR 0 dB не рассматривается Шен, Аноним (-), 02:10 , 06-Фев-23, (312)

Давай самую простую задачку У тебя есть исходный сигнал, состоящий из полок ст, Омномним (?), 21:54 , 03-Фев-23, (295)

Тьфу блин Вечер Выше уровня сигнала - удалить Слова модулирован достато, Омномним (?), 21:57 , 03-Фев-23, (296)
Это само по себе еще куда ни шло но это уже очень плохой дизайн протокола с, Аноним (-), 01:54 , 06-Фев-23, (310)

SNR 0 это вообще как Это по определению отношение положительных чисел А если, Аноним (-), 12:00 , 05-Фев-23, (299)

SNR 0 - это когда уровень шума превышает уровень полезного сигнала , Омномним (?), 13:36 , 05-Фев-23, (305)
напоминаю, исторически SNR измеряется в дБ, а это собственно степень, которая с, Омномним (?), 13:39 , 05-Фев-23, (306)

Тебе показать пачку протоколов работающих при отрицательных dBm в SNR или сам на, Аноним (-), 02:01 , 06-Фев-23, (311)

Тьфу ты, SNR в dB конечно, а не dBm, милливаты тут не при чем , Аноним (-), 07:05 , 06-Фев-23, (319)

GPS работает ниже уровня шумов - это вообще перл, поскольку в GPS используется н, Омномним (?), 13:44 , 05-Фев-23, (307)

и если SNR по всей полосе с определённого источника окажется 0 или менее - сигн, Омномним (?), 13:46 , 05-Фев-23, (308)
Вообще-то он и на 1 сигнал может лочиться Толку с этого будет мало т к для изм, Аноним (-), 01:22 , 06-Фев-23, (309)

Прям так взял и отделил шум от сигнала DТам наверно с хедерами летают данные N, pavlinux (ok), 16:49 , 31-Янв-23, (260) +1 //

Да, чел там почти совершил революцию в теории передачи данных Ну, у себя в голов, Омномним (?), 08:14 , 02-Фев-23, (283)

Вот те раз, XOR медленных битов NAV с быстрыми chip ами PRNG, оказывается, револ, Аноним (-), 03:03 , 06-Фев-23, (313)

Я и говорю - никакой революции нет и быть не может Мы опять и приходим всё к том, Омномним (?), 10:08 , 06-Фев-23, (320)

про глушилку я не ради красного словца заметил правильная глушилка - это к, Омномним (?), 10:16 , 06-Фев-23, (321)

амплитуда естественно тоже превышает, убивая амплитудную и частотную модуляции , Омномним (?), 10:17 , 06-Фев-23, (322)

Абсолютная амплитуда не важна, если оно более-менее рандомное bias от легитимног, Аноним (-), 06:58 , 07-Фев-23, (325)

Амплитуда важна Не абсолютная амплитуда конечно, да, а то, что размах шума в ра, Омномним (?), 09:33 , 07-Фев-23, (326)

В случае GPS вот именно cигнал, сам по себе, что-то типа -140-150dBm Порог шумо, Аноним (-), 04:39 , 08-Фев-23, (329) –1

Абсолютнейшее заблуждение, к тому же не дружащее с логикой Далее обсуждать смыс, Омномним (?), 08:19 , 08-Фев-23, (331)
На спутнике GPS передатчик ваттов 20, чтоли, а светит на полпланеты Плотность м, Аноним (-), 12:04 , 09-Фев-23, (337) –1
Не на любом, а только на том, в котором шумовая составляющая изменчива, и SNR на, Омномним (?), 09:27 , 08-Фев-23, (332)
Шум по определению изменчив, иначе какой же это шум Но если ты хочешь повыпендр, Аноним (-), 12:16 , 09-Фев-23, (338)
В исходной нашей задаче зашумления времени выполнения кода предполагается непрер, Омномним (?), 14:58 , 09-Фев-23, (345)
- работает сильно ниже уровня шумовЁпрст Какого уровня шума Мгновенного Усред, Омномним (?), 15:00 , 09-Фев-23, (346)
Задумайся, откуда у тебя на суббитах или интервалах возникает тот самый gain Э, Омномним (?), 15:24 , 09-Фев-23, (347)

Математический дохлый номер получается если линк хотел bitrate выше link margin , Аноним (-), 06:50 , 07-Фев-23, (324)

В ADC мы занимаемся обратной задачей - нам надо выделить шумовую составляющую, к, Омномним (?), 09:34 , 07-Фев-23, (327)

Вообще то достаточно похожие задачи А усреднением предпочитают не пользоваться , Аноним (-), 13:01 , 09-Фев-23, (341) +1

Почти не мешают друг другу - это очень тоже оптимистично Noise floor при DSSS р, Омномним (?), 14:53 , 09-Фев-23, (343) +1

Растет Но т к корреляция этих последовательностей в нормальных условиях микрос, Аноним (-), 15:05 , 10-Фев-23, (349)
Достаточно растёт, чтобы та же вафля при правильных звёздах работала так себе уж, Омномним (?), 16:43 , 10-Фев-23, (350)

Итогом будет только ответ Сигнал есть , pavlinux (ok), 14:31 , 08-Фев-23, (333) –2

И то не факт , Омномним (?), 14:54 , 09-Фев-23, (344)
Ты лол Это самый простой и дубовый способ передачи бинарной информации, использ, Аноним (-), 14:53 , 10-Фев-23, (348)

Ну и да, продолжая о революции Как ты там собрался этот маркер вычленять, если о, Омномним (?), 08:16 , 02-Фев-23, (284) +1

Ну вот GPS - XOR кой это делает Правда поскольку это все с приличной скорост, Аноним (-), 03:12 , 06-Фев-23, (314)

А все эти уязвимости фиксятся в новых процессорах, или после внесения правок в я, Аноним (190), 13:02 , 30-Янв-23, (190) //

Уточните какую именно уязвимость нужно фиксить Если мне не изменяет память к, Аноним (142), 15:00 , 30-Янв-23, (198) //

Ну там spectre, meltdown, и другие У меня сложилось впечатление что аппаратных , Аноним (190), 19:34 , 30-Янв-23, (212) +1 //

Пока не придумали как это пофиксить без отката производительности до уровня пред, Sem (??), 07:20 , 31-Янв-23, (230)

Интересно, кстати, как в этом плане себя показывают e2k lintel мне-то совмес, Michael Shigorin (ok), 01:43 , 01-Фев-23, (272) +1

Из них реально эксплуатируемых не в лабораторных условиях - пока что только Melt, Омномним (?), 13:21 , 31-Янв-23, (255)

Уязвимость Алгоритм нормальный сделай, а не пиши свои тупые патчи для ядра , Аноним (196), 14:27 , 30-Янв-23, (196) +2 //

они не тупые, они заставляют покупать новые процы , Аноним (214), 20:08 , 30-Янв-23, (213) +1 //

или старые, Аноним (196), 01:42 , 01-Фев-23, (271) +2 //

или вовсе другие , Michael Shigorin (ok), 01:43 , 01-Фев-23, (273) +1

Т е вместо того, чтобы вносить исправления в новые процессоры будем использоват, troizet (ok), 08:41 , 01-Фев-23, (276) //

Конечно Покупают же , Омномним (?), 08:17 , 02-Фев-23, (285) //

Мне вот надоело -- пишу с 16С , Michael Shigorin (ok), 16:44 , 17-Фев-23, (352)

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

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ообщить модератору

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


	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ообщить модератору