Перейти к содержанию
    

Rst7

Модератор
  • Постов

    4 619
  • Зарегистрирован

  • Победитель дней

    2

Весь контент Rst7


  1. Это как раз нормальная софтина. Ну когда-то была, пока ее поддерживали в актуальном состоянии и другой не было. Потом появился LatencyMon, с возможностью куда более расширенной диагностики. В общем выяснилось, что самый кривой с точки зрения затыков в DPC драйвер - это Nvidia. Причем, на всех системах по разному: бывает хорошо, а бывают полные провалы. Кому DPC Latency действительно важно (например, обработка многоканального звука в реальном времени), тот либо по RDP без видеокарт использует комп, либо ATI туда ставит. Ну а по совсем нынешним временам куда более интересно и поучительно разглядывать вот такие скриншоты: Что за глупости? Какие еще прокладки?
  2. DPC Latency Checker покажет проблемы только если там совсем плохо. Потому что он измеряет время от инициации DPC до начала собственно выполнения отложенной процедуры. Причем делает это раз в 1мс. Куда более полное представление о происходящем можно получить при помощи LatencyMon, правда, на XP работают только версии до 5й включительно. Гарантирую, что Вы там увидите совсем другие цифры, ибо там рапортуется о максимальных временах выполнения всех DPC.
  3. Скорее всего у вас уже сам tcpdump - узкое горлышко. Пора писать собственный софт, для начала хотя бы просто recvfrom в бесконечном цикле. Оцените загрузку процессора. Потом будете пробовать запись на диск добавлять. Ну или попробуйте поиграться с параметрами типа Interrupt moderation/Interrupt coalescing/etc
  4. Да никак не уделывает, не переживайте. Проигрывает безусловно. Причины я уже перечислил, и они совсем не в количестве доступного процессу ОЗУ, хотя в некоторых применениях это ох как важно.
  5. Вы плохо думаете об обработке видео/звука ;) При нелинейном монтаже крайне желательно иметь произвольный быстрый доступ к любым данным. Как бы можно и в 32 бита, частями файлы маппить в адресное пространство, так и делали в уже доисторические времена, но очень геморойно это, а с 64тибитной архитектурой все куда веселее и удобнее.
  6. Ах простите, Xcelium - это симулятор же, да? Ну что, если уважаемым удалось распараллелить вычисления, используя всякие SSE - только честь им и хвала. Я почему-то подумал про компилятор, потому это мое возражение снимается. Значит просто перепишут, тем более, что на сайте вроде пишут, что
  7. Да всегда там пара-тройка циклов. А то и скорее всего вообще сторонняя библиотека типа fftw, которую давно портировали ;) А если больше - то это что-то такое специфическое, которое совсем не надо каждый день на другую архитектуру портировать. И скорее всего - вообще не надо. Ничего, перекомпилируют, когда время придет. Сто процентов нет там привязок к x86. Ну вот не верю я (читай - мой уже, блин, немалый инженерный опыт подсказывает), что там прям нужны какие-нибудь SSE4-инструкции. Да ладно вам. Кодерки средней руки щас по рублю пучок. А других для этого сегмента и не надо.
  8. Да этого где-то в паре-тройке inner-loop'ов может есть десяток-другой инструкций. Ничего сложного в самом ручном переписывании нет.
  9. Это неважно. Важно то, как это выглядит с точки зрения программиста. Если нет ортогональности - компиляторы сильно проигрывают. Любые *nix'ы, например. MacOS в том числе, кстати, там и так одна и та же ОС в двух таргетах работает, один из них - ПК, другой - телефоны/планшеты на AARCH64. Вот собираются и ПК перевести на унифицированную архитектуру, так сказать. Да как бы все это "серверное ПО" получается автоматически при сборке *nix'ов под новое ядро. Да кому они нужны эти жаба-приложения?
  10. Доказывали что? Наконец-то в 64й архитектуре РОНов стало не 8, а 16. И чуть более ортогональной стала система команд. В среднем компиляторы Си процентов на 20 более эффективный код генерят для x64, нежели для x86. Потому байки про "более производительную 32хбитную архитектуру" не надо нам тут рассказывать, уж чего-чего, а на своем собственном опыте много раз перемерял. Я имею в виду тестирование того софта, который я пишу под PC, например, всяческая ЦОС. Вообще, конечно, сама по себе архитектура Intel'овских процов - говнище то еще, но хоть чуть-чуть меньше содрогания испытываешь, когда смотришь в листинг для x64, а не x86. Не зря вон Apple решил таки на ARM'ы все переводить. Теперь о том, какие прелести более современных ОС с точки зрения более адекватной данному форуму, нежели использование PC в качестве печатной машинки. Например, появление с Win8.1 крайне полезного API для работы с сокетами под названием Registered IO. Кстати, аналогичные дела с USB тоже вроде с 8.1 только появились. Но это все, понятное дело, неинтересно тем, кому буковки шлепать в txt-файлах, а интересно только тем, у кого, скажем, широкие потоки информации надо принять и обработать. Ну и, кстати, лишнее, например, с Win10 отпиливается очень быстро. Реально там надо всего-то чуть более десятка запущенных служб, остальное можно выключить нафиг (вместе со всеми прекрасными обновлениями, телеметриями и прочим шлаком), правда, не под простым пользователем. Run as Trusted Installer - великая вещь для такой кастомизации, вдруг кто не в курсе.
  11. Как насчет в два этажа включить транзисторы? Хотя, конечно, там придется пободаться со скоростью верхнего транзистора, да. Можно вообще поглядеть Вашу схему выходного каскада?
  12. В смысле если пересчитать со всеми накладными расходами, то достигается почти Wire Speed. Конечно, если считать по чистым данным TCP, то меньше.
  13. А Вы смешной. Зачем мне искать кто как в лужу сел, если вот оно на столе лежит и работает.
  14. Есть люди, упорно расказывающие байки типа: Или И ничего с этим не поделать. И скажите, что делать бедным самопальщикам, у которых iIMX RT1020 через USB HS почти 480Mbps продувает с загрузкой проца порядка 30%? Имеется в виду RNDIS и TCP, конечно.
  15. Ну поглядите в документации, инициализирует ли там Cold Reset регистры, ответственные за конфигурацию TCM. Если нет - то, видимо, будет такая же жопа.
  16. Конечно-конечно. Это как раз Вы самопальщик - ничего самостоятельно написать не можете, только из готовых кубиков слепить что-то умеете. Отлично она из SPI Flash выполняется. Понятное дело, если бездумно "кубиками" засирать I-Cache и D-Cache, то толку не будет.
  17. Это просто отвод от 15% витков. Просто в spice-симуляторе так удобнее. Отсчитываете от верхнего по схеме вывода L2 15% витков и припаиваете туда вывод R1. А L3 делать не надо, это просто для имитации катушки с отводом сделано.
  18. У меня есть. Работают без проблем, без возбуждений и непонятных сдвигов уровней. Схема из даташита на TPA6120 вполне простая и рабочая. Я бы давал вольт по 9 на плечо. Токи, соответственно, будут до 300мА в импульсе. Можно. AD8397 очень даже ничего работает.
  19. Что за ЦАП? Обычно звуковые ЦАПы с однополярным питанием, и на выходе имеют половину опорного напряжения. Конечно, в такой схеме все сломается.
  20. Ну и что, что 100мкВ? Давайте-ка полную схему, чего куда Вы там насоединяли, с номиналами. А, кстати, источник питания у Вас там достаточно крепкий? Сможет сотню-другую миллиампер выдать?
  21. Никто никого не лишится. +-9..12 вольт - вполне нормальное питание для раскачки обычных студийных наушников с сопротивлением 250ом, например популярных Beyerdynamic DT 770. Для каких-нибудь низкоомных затычек это может и многовато, но, например, я для довольно чувствительных внутриканальных наушников с очень даже вменяемой звукоизоляцией, делал усилитель в In-Ear мониторинге с питанием 12вольт (+-6В), и этого было ну в притык, если на сцене громко. И еще момент - тот же самый TPA6120A2 - отнюдь не Rail-To-Rail, кстати.
  22. Как-то очень меня этот Захаровский приемник подзацепил. Когда-то в юности у меня он не поехал, терпения справиться с ним не хватило, а сейчас что-то захотелось размять мозги, а то сплошное софтописательство неспеша превращает в омерзительного "ымбеддера". Посидел, подумал и вот что надумал. Короче, работает этот приемник нифига не так, как автор описывал. На всякий случай - оригинальная схема: Из-за конденсатора C4 коэффициент усиления VT1 как смесителя по постоянному току равен 0. А следовательно - этот приемник не может работать как именно приемник с ФАПЧ. Он не сможет следить за частотой сигнала. Вообще в целом цифры, мягко говоря, не бьются - если задаться чувствительностью 1мВ (тупенький весьма), то с предлагаемыми емкостями гетеродинного контура коэффициент управления частотой будет где-то 1МГц/В, а это значит, что усиление на ПЧ нужно иметь порядка сотни: (100кГц типичная девиация) / (1МГц/В) = 100мВ типичный сигнал управления. Это еще если коэффициент преобразования - единица, а он тут никакой, прямо скажем. Коэффициент усиления транзистора - ну десять. В общем, цифры не сходятся больше чем на порядок. Но как-то же (хоть и хреново), но он работает. И происходит это вот как - гетеродин захватывает входной сигнал. Без этого захвата ничего не работает. Более того, захват происходит только из-за кучи разных нелинейностей. В том числе из-за изменения Cкб в течении периода частоты гетеродина, некий такой себе параметрический захват. А вот уже сверху прямого захвата начинает работать именно ФАПЧ - преобразование в нулевую ПЧ на второй гармонике гетеродина и изменение напряжения Cкб, а уже как следствие - изменение частоты гетеродина. По моим оценкам вклад прямого захвата чуть ли не больше, нежели ли характерные сдвиги частоты от, так сказать, режима ФАПЧ. Более того, способность гетеродина войти в прямой захват сильно зависит от добротности гетеродинного контура, что крайне трудно предсказать. Ну и да, прямое детектирование никто не отменял. Что можно сделать для того, чтобы эта штука была более повторяемая: 1. Вменяемый смеситель на встречно-параллельных диодах. 2. Полоса пропускания смесителя и усилителя - от 0. Этим сразу снимается вопрос необходимости прямого захвата сигнала. 3. Увеличить усиление и увеличить коэффициент управления частотой. Вот такая схема нарисовалась: Что тут есть занятного? а) Максимальный коэффициент управления частотой. Скб - единственный конденсатор контура (если не считать небольшой емкости диодов и емкость монтажа). Коэффициент получается чуть ли не порядка 20МГц/В б) Режим гетеродина подобран так, чтобы иметь правильный угол отсечки диодов смесителя. Причем, этот режим сохраняется в довольно широком диапазоне токов транзистора. Обратная связь (отвод с части витков) - весьма слабая для такой схемы включения, всего с 15% витков, причем, ближе к базе, нежели к общему проводу. И тогда там все автоматически получается, диоды отпираются так, как надо. При этом транзистор всегда находится в классе А (он ведь еще и усилитель постоянного тока). Диоды смесителя надо брать именно Шоттки и с небольшими собственными емкостями. Ну да нынче этого добра кругом как грязи. в) Правильно (ну насколько это удалось) посчитанный пропорционально-интегрирующий фильтр, чтобы расширить диапазон устойчивой работы при сильных сигналах. Конденсатор С3 - специально небольшой, иначе при сильных входных сигналах будет неустойчивость в петле. г) Полностью DC path. Небольшой ток базы, протекающий через нижний диод заметно меньше несинусоидальности самого напряжения гетеродина, можно забить. д) Поднял питание, чтобы увеличить усиление. Да и все равно по нынешним временам веселее от литиевого аккумулятора питать, кстати, вполне приемлемый размах на последующем УНЧ можно получить. е) Входную цепь прикинул на 50ом, соответственно, контур входной на середину диапазона 100-108МГц. ж) Добавил повторитель на выход, чтобы не добавлять емкость на землю в фильтре ФАПЧ, а то см. пункт в) По сравнению с оригинальной схемой в принципе добавляется два диода плюс транзистор или диод для стабилизации режимов. Выходной повторительно можно не считать, его и в схеме Захарова очень нестыдно ставить. В симуляторе этот вариант прекрасно захватывает входной сигнал в 100мкВ, при этом типичный размах сигнала на выходе - порядка 5-6мВ. В общем, я бы такое попробовал в живую собрать. Закончится карантин и попаду в мастерскую - обязательно попробую.
  23. Тут обнаружились интересные грабли. Если в вашем софте вы отключаете OCRAM (я, например, все доступное ОЗУ переключаю в режим ITCM/DTCM), то при любом не Power On-сбросе все повиснет. Не Power On Reset - это, например, срабатывание сторожевого таймера или софтовый сброс через регистр AIRCR, или через отладчик. Оказывается (это отражено в документации, понятное дело мелким шрифтом на одной из 3000 страниц мануала), что не POR (в терминах мануала - Cold reset) не сбрасывает в начальное состояние IOMUXC. Т.к. конфигурация ITCM/DTCM/OCRAM находится именно в регистрах IOMUXC, то при cold reset ядро стартует с измененной конфигурацией ОЗУ, а в Boot Rom'е колхозники забыли, что надо сначала инициализировать соответствующие регистры IOMUXC, а уже потом хоть что-то делать с ОЗУ (в конкретно Boot Rom'е первый же BL приводит к фатальным последствиям). На грабли эти я наступил отлаживая свой загрузчик, которому надо сделать сброс контроллера после обновления прошивки. Вроде бы ничего особо смертельного, восстановил перед насилованием AIRCR содержимое соответствующих регистров IOMUX - и все поехало, но, черт возьми, сторожевой таймер тоже не сбрасывает процессор. Только передергивание питания. Думаю, что такая история во всей линейке i.MX RT, а может и шире. Конкретно я работал с 1020. В общем, не наступите на грабли. Доклад окончен.
  24. Какой-нибудь i.MX RT1010...1020 Вам вполне подойдет. Там PHY под Hi Speed уже внутри есть. Например, каких-нибудь 60 евро - и уже можете пробовать - https://www.nxp.com/design/development-boards/i-mx-evaluation-and-development-boards/i-mx-rt1020-evaluation-kit:MIMXRT1020-EVK
  25. В общем-то сама по себе идея этого приемника очень занятная, но работать нормально он не будет никогда. Основная проблема - плохой режим работы гетеродина (он же и смеситель). Для хорошего коэффициента преобразования на второй гармонике транзистор должен работать в классе С с углом отсечки порядка 60 градусов. В генераторе такой режим достижим, если базовым/затворным/сеточным током перезаряжается входная емкость и транзистор подзапирается. Конкретно в этом приемнике напряжение частоты гетеродина слишком мало, и транзистор все время находится в классе А. И коэффициент преобразования из-за этого слишком мал. Из-за аналогичной проблемы практически не работает схема с доп. диодом, призванная улучшить ситуацию с прямым детектированием. В классическом смесителе на встречно-параллельных диодах напряжение гетеродина выбирается таким, чтобы угол отсечки тока диодов был порядка 60 градусов. В рассматриваемом приемнике вроде бы и да, диод работает на другой полуволне напряжения гетеродина, но только он все время открыт и практически не производит "ключевание" другой полуволны. Я даже думаю, что ситуация вообще ухудшается относительно начальной схемы, ибо характеристика диода почти наверняка сильно отличается от входной характеристики транзистора. В общем, я, конечно, понимаю, что один транзистор - это очень прикольно, но лучше бы вы попробовали намакетить вот такой приемник: Тоже в общем совершенно несложный, но заработает почти наверняка с хорошим результатом. Эта схема на самом деле весьма толковая, даже очень правильно сделан момент с устранением постоянного тока через диоды смесителя. В принципе сам УПТ стоит по нынешним временам заменить на малошумящий ОУ с заметно лучшим результатом.
×
×
  • Создать...