В моем случае я давал HR-ам мною составленную анкету с списком 20 вопросов касаемо будущей должности, был ли опыт там, сям, что умеет, не умеет. Чему готов учиться и так далее. И уже после этого по результатам просмотра анкеты этой и резюме в совокупности было понятно - подходит кандидат или нет, какой процент белых пятен есть и можно ли его потом дообучить если пробелы не критичные.
А симметричность канала соблюдена? Условно, что точка-то "доорётся" до клиента, а вот "слабоорущий" клиент доорётся до точки? Обычно для таких кейсов делают бэкхол точка-точка для точек доступа, а они уже в соответствии с максимально допустимым EIRP дают в своей зоне, где канал связи до абонента остаётся симметричным и не возрастает количество перепосылок трафика.
Ну и если говорить об антеннах - лучше покрывать территорию секторными антеннами, а не омнями.
Согласен, эмуляция сложных протоколов на SDR дело ресурсоемкое, сложное и порой лучше пользовать аппаратными транссиверами изготовлены под конкретный протокольный стек.
Но всё зависит от задачи. Например, для изучения того же 802.11 aka. Wi-Fi - есть прикольный проект от nuand под bladeRF для того, чтобы развернуть устройство Wi-Fi с помощью SDR.
Если хочется изучать что-то - то это лучший вариант, а если реализовывать изделие - то тут конечно SDR вообще не вариант
К сожалению у меня его нет, а так с удовольствием бы. Если бы дал кто на месяцок попользоваться, родил бы материал с полным обзором)
Про Bluetooth придерусь немного, BLE - это тоже Bluetooth, вы наверное имели ввиду BR/EDR. С ним да, сложновато будет, учитывая FHSS и его тягу к перестроению частоты во всем ISM-диапазоне
Эта картинка была приведена в качестве демонстрации того, что можно водрузить на плату т.е. по сути полноценное управление без ПК через эти разъемы расширения. И указанные обозначения на этой картинке никакого отношения к списку по разъемам расширения не имеет
Замечание о необходимости первичной загрузки из ОЗУ верно лишь отчасти – современные процессоры активно используют предвыборку, чтобы минимизировать задержку даже при первом проходе. И утверждение, что кэш инструкций бесполезен на линейных участках кода, категорически ошибочно.
Без I-cache линейный код работал бы чудовищно медленно. Скорость доступа к L1 I-cache (1-4 такта) — это основа для непрерывной работы конвейера процессора. Ожидание каждой новой инструкции из ОЗУ (200+ тактов) полностью парализовало бы выполнение любого кода.
Конвейер зависит от I-cache постоянно. Стадия выборки (Fetch) беспрерывно читает инструкции из кэша L1, чтобы поддерживать заполненность конвейера. Это критично для производительности на любом коде.
Польза кэша не ограничивается циклами. Любой часто исполняемый путь кода, то есть "горячий" код, будь то тело функции, обработчики, часто вызываемые процедуры, все это получает огромное преимущество от нахождения в быстром I-cache. Локальность исполнения работает и в линейном коде.
Да и кэш инструкций не просто "плюшка" для циклов. Это фундаментальный механизм, без которого современный высокопроизводительный процессор не смог бы исполнять вообще никакой код достаточно эффективно, будь он линейным или содержащим циклы. Его эффективная работа, которая включает предвыборку, в том числе обеспечивает базовую скорость подачи инструкций в конвейер.
Видимо речь идет про какую-то частную реализацию, что является краеугольным камнем любого open-source изделия.
Насколько я знаю - RISC-V позволяет и часто требует проверки указателя стека (SP) для обеспечения безопасности. Только вот механизм зависит от профиля архитектуры, например, RVA20+ или RVA22+. Всякие штуки типа Physical Memory Protection, ePMP, MMU - никуда не делись. И отсутствие одной стандартной инструкции как TST SP, #7 в ARM - не означает невозможности проверки. Проверка просто выполняется другими средствами. До кучи - привилегированные режимы (M/S/U) с четким разделением уровней исполнения, защита памяти, гипервизор в H-extension с изоляцией виртуальных машин, PAC/BTI, Scrypto обмазанное маслом открытости, а равно позволяющее глубоко провести сек-аудит - вообще не имеет ничего общего с "небезопасностью".
Насчёт прерываний - тоже не правда. В RISC-V есть гибкая система прерываний и исключений и вероятно все зависит от конкретно взятой реализации. Регистры mcause/scause точно указывают на источник прерывания. Приоритеты и маскирование в системе PLIC, система локальных прерываний типа CLINT.
В общем можно почитать в спецификациях и понять что озвученное утверждение малость "не правда".
У подавляющего большинства CPU, будь то CISC, RISC - есть кэши команд (L1/L2,I-cache) которые хранят недавно используемые инструкции и большинство инструкций берется из быстрого кэша, а не каждый раз из медленной оперативной памяти.Ещё в эпоху первых RISC-процессоров была реализована стратегия увеличения размера кэшей, чтобы компенсировать потенциально больший объём кода RISC-программ. И поэтому даже если в байтовом выражении программа получается больше, то процессор не ждет "медленной памяти", а основные циклы и часто используемый код берется прямо из кэша и исполняется на полной скорости ядра.
Следующий момент. Классическая архитектура RISC и правду без дополнительных оптимизаций использует фиксированный размер инструкций и требует раздельных команд загрузки/выгрузки. Но на практике компиляторы оптимизируют код так, чтобы сократить количество обращений в "медленную" память. К тому же RISC-процессоры имеют больше регистров, в которые можно заранее загрузить нужные операнды и повторно их использовать без обращения к ОЗУ. Например, типичный RISC-процессор предоставляет 32 регистра общего назначения (против 8 в x86), что позволяет хранить больше переменных в регистрах и реже делать загрузки/выгрузки в память. Помимо этого есть Comressed ISA, которые позволяют существенно снижать размер кода, тот же режим Thumb с сокращением длины инструкций с 32 до 16 байт в ARM.
Распространенно заблуждение что “1 CISC-инструкция лучше 5 RISC-инструкций”. И вправду, x86 позволяет в одной инструкции ADD [RBX+RAX*8], imm вычислить адрес, загрузить, сложить и сохранить. Но это не означает, что реально за один такт всё выполнится. В современных x86-процессорах сложные инструкции декодируются во внутренние микрооперации (μops) – по сути, те же простые RISC-подобные шаги внутри процессора. То есть, внешне у вас одна команда, а внутри она разбивается на несколько микрокоманд, которые процессор выполняет по конвейеру. И получается что разница между “5 инструкций RISC” и “1 инструкцией CISC” размывается – в x86 тоже происходит несколько элементарных операций, просто скрыто от глаз программиста. К тому же, декодирование сложных команд и управление ими – это задача, требующая транзисторы и энергию (блоки предсказания, буферы переупорядочивания, кеш μops и т.п.). В RISC же декодер проще, а исполнение разбивается на много коротких простых действий, которые легче масштабировать по конвейерам и ядрам. Не буду описывать про преимущества простоты ISA RISC-V, таких как значительно более простое декодирование, более длинный конвейер и более высокие потенциальные частоты, простота верификации и проектирования и т.п.
Что касается "потолка" в 2.4ГГц. Это вообще не соответствует действительности. Современные ARM-серверы уже превысили 3 ГГц. Например, Ampere Altra – 80-ядерный ARM-процессор для серверов – работает на частоте до 3.3 ГГц на все ядра. Тактовая частота его 128-ядерной версии (Altra Max) достигает 3.0 ГГц. Да и частота ограничивается не памятью, а рассеиваемой мощностью, энергопотреблением и в целом актуально вообще для всех. Другой пример - ARM чипы от Apple M1/M2, которые работают себе на частотах 3.2–3.5 ГГц. IBM Power10 (Power ISA, RISC) – топовый серверный процессор IBM – работает на частотах до ~3.9–4.0 ГГц на ядро.
В общем это тоже всё отголоски старых мифов и холиваров из CISC vs. RISC.
Какая картинка? Какая батарейка? Можете ВНЯТНО объяснить суть своих комментариев? Открываем схематик, открываем документацию и приведите по фактам что не так, и опишите как написанное мной расходится с реальностью.
Потому что софтовый процессинг данных полученных с SDR требует достаточно много ресурсов хостовой машины и виртуализация в свою очередь - это дополнительные накладные расходы, и чаще всего через множественные абстракции и без прямого доступа к железу.
Я в Москве, к сожалению (
В моем случае я давал HR-ам мною составленную анкету с списком 20 вопросов касаемо будущей должности, был ли опыт там, сям, что умеет, не умеет. Чему готов учиться и так далее. И уже после этого по результатам просмотра анкеты этой и резюме в совокупности было понятно - подходит кандидат или нет, какой процент белых пятен есть и можно ли его потом дообучить если пробелы не критичные.
А симметричность канала соблюдена? Условно, что точка-то "доорётся" до клиента, а вот "слабоорущий" клиент доорётся до точки? Обычно для таких кейсов делают бэкхол точка-точка для точек доступа, а они уже в соответствии с максимально допустимым EIRP дают в своей зоне, где канал связи до абонента остаётся симметричным и не возрастает количество перепосылок трафика.
Ну и если говорить об антеннах - лучше покрывать территорию секторными антеннами, а не омнями.
И это круто, что такие сложные штуки стали гораздо доступнее для широкого круга энтузиастов
Хм. А почему бы мне не оформить перевод этой статьи...выглядит как крутое и исчерпывающее исследование
Согласен, эмуляция сложных протоколов на SDR дело ресурсоемкое, сложное и порой лучше пользовать аппаратными транссиверами изготовлены под конкретный протокольный стек.
Но всё зависит от задачи. Например, для изучения того же 802.11 aka. Wi-Fi - есть прикольный проект от nuand под bladeRF для того, чтобы развернуть устройство Wi-Fi с помощью SDR.
Если хочется изучать что-то - то это лучший вариант, а если реализовывать изделие - то тут конечно SDR вообще не вариант
К сожалению у меня его нет, а так с удовольствием бы. Если бы дал кто на месяцок попользоваться, родил бы материал с полным обзором)
Про Bluetooth придерусь немного, BLE - это тоже Bluetooth, вы наверное имели ввиду BR/EDR. С ним да, сложновато будет, учитывая FHSS и его тягу к перестроению частоты во всем ISM-диапазоне
Учебников для начинающих не много про антенны, рекомендую присмотреться к курсу физики в подаче Павла Виктора: https://www.youtube.com/playlist?list=PL1Us50cZo25lI9BRQat7KXDMW5XWWiEXC
И курсу по антеннам от Тимура Гаранина
Плюсом Электроника шаг за шагом от Рудольфа Свореня.
А потом если мат. аппарат позволяет - рекомендую книгу Джоэля П. Дансмора Измерения параметров СВЧ-устройств
Спасибо большое!
Да, когда читал и изучал исходные материалы - ваще прям удивлялся сколько всего реализовано)
https://www.rtl-sdr.com/bouncing-lora-signals-off-the-moon-with-a-hackrf/
Задам риторический вопрос - характеризует особенность реализации конкретного изделия всю архитектуру RISC-V? На мой взгляд нет
Эта картинка была приведена в качестве демонстрации того, что можно водрузить на плату т.е. по сути полноценное управление без ПК через эти разъемы расширения. И указанные обозначения на этой картинке никакого отношения к списку по разъемам расширения не имеет
Замечание о необходимости первичной загрузки из ОЗУ верно лишь отчасти – современные процессоры активно используют предвыборку, чтобы минимизировать задержку даже при первом проходе. И утверждение, что кэш инструкций бесполезен на линейных участках кода, категорически ошибочно.
Без I-cache линейный код работал бы чудовищно медленно. Скорость доступа к L1 I-cache (1-4 такта) — это основа для непрерывной работы конвейера процессора. Ожидание каждой новой инструкции из ОЗУ (200+ тактов) полностью парализовало бы выполнение любого кода.
Конвейер зависит от I-cache постоянно. Стадия выборки (Fetch) беспрерывно читает инструкции из кэша L1, чтобы поддерживать заполненность конвейера. Это критично для производительности на любом коде.
Польза кэша не ограничивается циклами. Любой часто исполняемый путь кода, то есть "горячий" код, будь то тело функции, обработчики, часто вызываемые процедуры, все это получает огромное преимущество от нахождения в быстром I-cache. Локальность исполнения работает и в линейном коде.
Да и кэш инструкций не просто "плюшка" для циклов. Это фундаментальный механизм, без которого современный высокопроизводительный процессор не смог бы исполнять вообще никакой код достаточно эффективно, будь он линейным или содержащим циклы. Его эффективная работа, которая включает предвыборку, в том числе обеспечивает базовую скорость подачи инструкций в конвейер.
Видимо речь идет про какую-то частную реализацию, что является краеугольным камнем любого open-source изделия.
Насколько я знаю - RISC-V позволяет и часто требует проверки указателя стека (SP) для обеспечения безопасности. Только вот механизм зависит от профиля архитектуры, например, RVA20+ или RVA22+. Всякие штуки типа Physical Memory Protection, ePMP, MMU - никуда не делись. И отсутствие одной стандартной инструкции как TST SP, #7 в ARM - не означает невозможности проверки. Проверка просто выполняется другими средствами. До кучи - привилегированные режимы (M/S/U) с четким разделением уровней исполнения, защита памяти, гипервизор в H-extension с изоляцией виртуальных машин, PAC/BTI, Scrypto обмазанное маслом открытости, а равно позволяющее глубоко провести сек-аудит - вообще не имеет ничего общего с "небезопасностью".
Насчёт прерываний - тоже не правда. В RISC-V есть гибкая система прерываний и исключений и вероятно все зависит от конкретно взятой реализации. Регистры mcause/scause точно указывают на источник прерывания. Приоритеты и маскирование в системе PLIC, система локальных прерываний типа CLINT.
В общем можно почитать в спецификациях и понять что озвученное утверждение малость "не правда".
Я бы еще добавил немного техники в вопрос.
У подавляющего большинства CPU, будь то CISC, RISC - есть кэши команд (L1/L2,I-cache) которые хранят недавно используемые инструкции и большинство инструкций берется из быстрого кэша, а не каждый раз из медленной оперативной памяти.Ещё в эпоху первых RISC-процессоров была реализована стратегия увеличения размера кэшей, чтобы компенсировать потенциально больший объём кода RISC-программ. И поэтому даже если в байтовом выражении программа получается больше, то процессор не ждет "медленной памяти", а основные циклы и часто используемый код берется прямо из кэша и исполняется на полной скорости ядра.
Следующий момент. Классическая архитектура RISC и правду без дополнительных оптимизаций использует фиксированный размер инструкций и требует раздельных команд загрузки/выгрузки. Но на практике компиляторы оптимизируют код так, чтобы сократить количество обращений в "медленную" память. К тому же RISC-процессоры имеют больше регистров, в которые можно заранее загрузить нужные операнды и повторно их использовать без обращения к ОЗУ. Например, типичный RISC-процессор предоставляет 32 регистра общего назначения (против 8 в x86), что позволяет хранить больше переменных в регистрах и реже делать загрузки/выгрузки в память. Помимо этого есть Comressed ISA, которые позволяют существенно снижать размер кода, тот же режим Thumb с сокращением длины инструкций с 32 до 16 байт в ARM.
Распространенно заблуждение что “1 CISC-инструкция лучше 5 RISC-инструкций”. И вправду, x86 позволяет в одной инструкции ADD [RBX+RAX*8], imm вычислить адрес, загрузить, сложить и сохранить. Но это не означает, что реально за один такт всё выполнится. В современных x86-процессорах сложные инструкции декодируются во внутренние микрооперации (μops) – по сути, те же простые RISC-подобные шаги внутри процессора. То есть, внешне у вас одна команда, а внутри она разбивается на несколько микрокоманд, которые процессор выполняет по конвейеру. И получается что разница между “5 инструкций RISC” и “1 инструкцией CISC” размывается – в x86 тоже происходит несколько элементарных операций, просто скрыто от глаз программиста. К тому же, декодирование сложных команд и управление ими – это задача, требующая транзисторы и энергию (блоки предсказания, буферы переупорядочивания, кеш μops и т.п.). В RISC же декодер проще, а исполнение разбивается на много коротких простых действий, которые легче масштабировать по конвейерам и ядрам. Не буду описывать про преимущества простоты ISA RISC-V, таких как значительно более простое декодирование, более длинный конвейер и более высокие потенциальные частоты, простота верификации и проектирования и т.п.
Что касается "потолка" в 2.4ГГц. Это вообще не соответствует действительности. Современные ARM-серверы уже превысили 3 ГГц. Например, Ampere Altra – 80-ядерный ARM-процессор для серверов – работает на частоте до 3.3 ГГц на все ядра. Тактовая частота его 128-ядерной версии (Altra Max) достигает 3.0 ГГц. Да и частота ограничивается не памятью, а рассеиваемой мощностью, энергопотреблением и в целом актуально вообще для всех. Другой пример - ARM чипы от Apple M1/M2, которые работают себе на частотах 3.2–3.5 ГГц. IBM Power10 (Power ISA, RISC) – топовый серверный процессор IBM – работает на частотах до ~3.9–4.0 ГГц на ядро.
В общем это тоже всё отголоски старых мифов и холиваров из CISC vs. RISC.
Какая картинка? Какая батарейка? Можете ВНЯТНО объяснить суть своих комментариев? Открываем схематик, открываем документацию и приведите по фактам что не так, и опишите как написанное мной расходится с реальностью.
Взято из документации: https://hackrf.readthedocs.io/en/latest/expansion_interface.html
Расскажите как :)
Тоже вариант, да. Если будут деньги - прикуплю, потестирую с удовольствием.
Потому что софтовый процессинг данных полученных с SDR требует достаточно много ресурсов хостовой машины и виртуализация в свою очередь - это дополнительные накладные расходы, и чаще всего через множественные абстракции и без прямого доступа к железу.