проект WSJT-X: моды JT65,JT9,WSPR,JT4,JTMS,MSHV - работа с тестовым софтом

[US4IRT]

Может я не совсем понимаю суть дискуссии, но какие могут быть 50 декодов, если включен фильтр на Европу? DX-ов столько просто нет. Декодировать нужно несколько (обычно 1-2) слабых сигналов, что на 160м, что на 6м. Железо, о котором писал ниже, прекрасно с этим справляется.

Пользуюсь точно так же, Виктор. Выбирать сейчас некого в эфире. Поэтому провожу эксперименты, изучаю более глубже.

[RM6LA]

Может я не совсем понимаю суть дискуссии, но какие могут быть 50 декодов, если включен фильтр на Европу? DX-ов столько просто нет.

Виктор, декодируется всегда весь спектр, а фильтруется только вывод на экран. Вы сами подумайте, КАК фильтр без декода будет работать вообще? Никак.

Уже несколько раз наблюдал такое явление:
включен фильтр на Европу и после декодирования интервала вообще нет ни одной станции, хотя информация о декодировании более чем 30 станций отображается.
В следующий интервал отключаю фильтр, появляются станции и среди них несколько амеров, которых при включенном фильтре не было.
Включаю фильтр и опять история повторяется.
Складывается впечатление, что включенный фильтр иногда режет все подряд.
Специально смотрел по два интервала, чтобы декодировать всех, кто в эфире.

Попробуйте оффлайн декодировать период с фильтром и без него. Программа может записывать звуковые файлы с которыми можно экспериментировать.

[UR4UM]

Привет народ, вопрос может будет и не по теме, кто смог запустить работу маламута с программой tdx-2.1.0-RUS-rc151-win32.exe не видет устройство, в 150 версии все работает!
п.с. Привожу фото настроек которые работают в 150 версии]

Да, столкнулся с проблемой неделю назад, Маламут отдыхал пару месяцев, а работал на ІС-746, а когда подключил - "xxxx"!
Вернул на 150ю - не видит, а 149я работает. Подскажите кто поборол проблему - PSE! Думаю многие поблагодарят...

[UA5AA]

…..
Надо , только памяти побольше, ну и графику. .
...

...память и графика - вторично. Первичное - это мощность ( скорость) процессора. Сколько бы не было памяти и какая бы не была крутая видеокарта, все равно все " просеивается" через процессор

[UT5NM]

Не согласен. У меня AMD, 2 ядра, разогнанный до 3,3 ГГц (можно до 4-х, но страшновато), память DDR3-1600 без радиаторов, на данный момент 1200 МГц. SSD.
Когда работаю трансивером - даже при 40-50-ти декодах всё в норме. Когда SDR-ом - уже нет. И DT 0,2-0,3, и декодирует с запаздыванием.
Т. е. работа программы Power SDR грузит всё довольно сильно. Особенно когда не сворачиваешь её (по видео).

Василий, я говорил о 775-м чипсете от Интел. На ДДР-3 он не работает от слова совсем - слоты памяти разные, даже молотком не забьешь. А стандартная ДДР2-800 и по частоте и по таймингам сливает более чем в два раза. И это при том, что все сложнейшие математические алгоритмы обрабатываются именно в оперативке...
АМД не пользовал ни разу за более чем 20 лет работы в IT сфере. Было бы интересно посмотреть на лаги при современном недорогом Райзене с быстрой оперативкой.
Владислав(QDP), у нас сейчас грозы, дома я не часто, поэтому все радио отключены. Но дело даже не в этом. Лаги очень сильно зависят от загруженности диапазона и эксперимент на каком-то случайном сетапе лишен смысла. И самое главное - эта ветка организована тимлидером команды программистов JTDX, у которых в распоряжении стенды с генерацией эталонных последовательностей, шумов и пр, на которых они составляли точные таблицы декодов при различных настройках программы, расхождении времени и пр. Так неужели они не знают, "понимает" ли ИХ программа гипертрейдинг?! Игорь постоянно в ветке и думаю даст однозначный ответ, а если и сомневается, то добавит в таблицы на сайте программы столбик "HyperThreading on/off". Для наглядности
ЧуднО слышать, как на "стареньком два ядра" все супер ОК и нет проблем. Для понимания сложнейшей математической обработки синхронных последовательностей(это далеко не простенькая прикладнушка) надо во-первых, обязательно установить 150 или 151 версии JTDX, где введен индикатор лагов. И четко усвоить, еще раз пересмотрев эталонные таблицы, что задержка вашей передачи даже на 0.5-0.8 секунды на 30% лишает ЕГО возможности декодировать ВАШ сигнал и ответить на вызов! Даже с быстрым мощным компом.
Отсюда и вопросы у владельцев "два ядра" - а чего он другим отвечает, а мне нет?! Гримаса судьбы - будь этот лаг даже на половину периода передачи, на ВАШ прием это совершенно не влияет. При условии точной синхронизации времени у обоих. Но надеяться на ответ от НЕГО при таком запаздывании не стоит даже с киловаттом. Разве что соседям "за пределами 5-6-го". Которым и обрывка передачи хватит, если "сигнальчик ровный 150%"...

- - - Добавлено - - -

...память и графика - вторично. Первичное - это мощность ( скорость) процессора. Сколько бы не было памяти и какая бы не была крутая видеокарта, все равно все " просеивается" через процессор

Евгенй, ну Вы явно не читатель. Я ведь написАл, как лагала JTDX с процомi7-4790к на частоте 5.2 ГГц при загрузке всего в 20%. При брендовой, но сравнительно медленной ДДР3-1600. Потому как "мы всё делаем в оперативке" (С). Ее, к стати, не должно быть много(если СДР в добавок не крутится). 4 ГГб с головой, но только быстрой! Сейчас это ДДР4-2300.
И проц конечно нужен хороший, думаю 3.2-3.7 ГГц i3 более чем достаточно. Почти уверен, что ГП "пристегивать" к процу WSJT и JTDX не умеют. Иначе в настройках был бы выбор что "пристегнуть" - встроенную или внешнюю. У многих геймерские карточки(зачастую пара в тандеме) работаю в разы быстрее чем самый топовый i9. Поэтому и относительно недорогие Ксеоны и АМД более чем.
О, вспомнил!!! Специально для Владислава QDT - Игорь совсем недавно разъяснял здесь же, в этой ветке, о влиянии количества потоков на скорость и глубину декодов. Пояснял еще, что больше 12-ти программа не может. В мире еще не изобрели монстеров с 12-ю физическими головами в одном слоте. Значит однозначно гипертрейдинг РАБОТАЕТ. Автору программы не верить в этом вопросе по меньшей мере глупо...

[Voevoda]

Да, столкнулся с проблемой неделю назад, Маламут отдыхал пару месяцев, а работал на ІС-746, а когда подключил - "xxxx"!
Вернул на 150ю - не видит, а 149я работает. Подскажите кто поборол проблему - PSE! Думаю многие поблагодарят...

А в настройках Езу или Кенвуд? Ставьте Кенвуд.

[RX4HX]

Зачем столько ресурсов для, по сути, терминальных программ?

Я тоже этого не понимаю. И моего 10-летнего Core i5 за глаза хватает.

как лагала JTDX с процомi7-4790к на частоте 5.2 ГГц при загрузке всего в 20%. При брендовой, но сравнительно медленной ДДР3-1600.

Я этого честно не понимаю. И причем тут скорость памяти - тоже. На скорость вычислений (а именно на это все нагрузка) скорость памяти явно не влияет.

думаю 3.2-3.7 ГГц i3 более чем достаточно

Поддерживаю.

Итог: если у Вас Core i3 или выше и у вас проблема со скоростью декодирования JTDX - ищите причину в установленных программах. Может антивирус тормозит, может что еще.

- - - Добавлено - - -

мире еще не изобрели монстеров с 12-ю физическими головами в одном слоте

Как Вам это:



Кстати для всех - по процам очень хорошая ссылка:

https://www.chaynikam.info/cpu_table.html

[UA5AA]

Евгенй, ну Вы явно не читатель....

..этт точно - я писатель. Процессоры i1,1,2,3,4...и далее по списку только в ноутах и применять..не рассматриваю. У меня надежный Процессор AMD FX-4100 Zambezi и нет проблем..

[UT5NM]

Я этого честно не понимаю. И причем тут скорость памяти - тоже. На скорость вычислений (а именно на это все нагрузка) скорость памяти явно не влияет.

Алексей, ну от Вас такое слышать, мягко говоря, удивительно. Конечно математические вычисления проводит процессор, но все данные для них он получает, обрабатывает и отдает, а потом еще дважды получает и отдает именно из/в оперативную память по системной шине. Ну, вот в моем конкретном примере, на моем оборудовании, матернка неплохая с шиной в 5ГГц, и проц был разогнан до 5 ГГц, а память сравнительно медленная ДДР3-1600 мГц с соответсвующими этой невысокой частоте таймингами. Причем скорость записи еще и меньше скорости считывания...
Проц в пиках декода был загружен всего на 20%, так как фактически простаивает, потому, что оперативка просто не успевает отдавать ему данные и получать обратно. Медленная оператива не может вовремя загрузить его данными. В результате куча математических алгоритмов за три прохода не укладывается в жестко ограниченное и синхронизированное до миллисекунд время. Отсюда и лаги. Что же тут непонятного?!
Говорите, что 10-ти летнего i5 хватает? Раз 10 лет, то значит чипсет под ДДР-3. ОК, тогда и Вы сделайте нам всем одолжение. Надеюсь, установлена версия JTDX с выведенным лагом. Если нет, то обязательно обновите! Все настройки декодирования на максимум согласно рекомендациям авторов: Количество потоков можно на "Авто", Широкополосное декодирование - "Глубокое", Количестово циклов декодирования - "3", QSO RX уровень чувствительности - "Высокое", чувствительность декодера - "Использовать субпасс". Включите любой загруженный бендезон, где не менее 30-40 декодов(все равно какого уровня, откуда) и отскриньте какой получился Lag. А мы посмотрим как "справляется".
Да, отстал я от "аэмдей", каюсь. Смотри ка - супер Райзен всего за 4 штуки баксов оценочно "там". Сколько стоит под него мать, сколько слотов и какой памяти смогут его обеспечить загрузкой, даже представить сложно. Наверное именно про такой и говорил Игорь Черников. Получается его жалкая поделка максимум с 12-ю потоками ровно в 10 раз(на порядок) до лидера не достает. Надо срочно замутить версию с такими "алгоритмами", чтоб при ее включении не только разогнанные i7 висли, но и свет в квартире тух
Но о потоках мы вспомнили только с точки зрения понимает ли гипертрейдинг JTDX. В теме про выпадения пакетов Игорь говорил о том, что в режиме "авто" при i7 задействовано только 7 потоков, но можно принудительно установить и все 8 для увеличения быстродействия. Но есть типа опасность некоторых глюков. Поскольку в i7 только 4 физ. головы, то значит гипертрейдинг JTDX точно поддерживает. Как-то так.

[UA3AIF]

...память и графика - вторично. Первичное - это мощность ( скорость) процессора. Сколько бы не было памяти и какая бы не была крутая видеокарта, все равно все " просеивается" через процессор

Для Ryzen нужно памяти побольше, чем для интела. Во вся ком случае так многие утверждают. А потом, в цене, что 8, что 16 - не так ощутимо. Ну , а графика, - так у них нет встроенной, хоть что то, но нужно, что бы два-три монитора работали.

- - - Добавлено - - -

......Говорите, что 10-ти летнего i5 хватает? Раз 10 лет, то значит чипсет под ДДР-3. ОК, тогда и Вы сделайте нам всем одолжение. Надеюсь, установлена версия JTDX с выведенным лагом. Если нет, то обязательно обновите! Все настройки декодирования на максимум согласно рекомендациям авторов: Количество потоков можно на "Авто", Широкополосное декодирование - "Глубокое", Количестово циклов декодирования - "3", QSO RX уровень чувствительности - "Высокое", чувствительность декодера - "Использовать субпасс". Включите любой загруженный бендезон, где не менее 30-40 декодов(все равно какого уровня, откуда) и отскриньте какой получился Lag. А мы посмотрим как "справляется".......

А еще потом дополнительно включить JTAlert с окном декодов. Это очень удобная функция для отслеживания нужных штатов USA, да и вообще для подбора нужных стран по диапазонам.
Конечно, можно обойтись и без всего этого, но если есть возможность, то почему не использовать.

[RX4HX]

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

Ну во первых у процессора есть свой кэш, и во внешнюю память он может ничего и не отдавать. Тут нужно знать как в таких случаях сам комп работает. Может Ваши доводы и верны, а может и нет. Не знаю.
Во вторых - на счет объема данных - так ли он велик? Тут наверное Игорь может подсказать.
Да память у моего компа DDR3 - самому интересно стало, завтра проверю по Вашей методике на предмет Lag'ов.

[RA3QDP]

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

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

[RM6LA]

Но о потоках мы вспомнили только с точки зрения понимает ли гипертрейдинг JTDX. В теме про выпадения пакетов Игорь говорил о том, что в режиме "авто" при i7 задействовано только 7 потоков, но можно принудительно установить и все 8 для увеличения быстродействия. Но есть типа опасность некоторых глюков. Поскольку в i7 только 4 физ. головы, то значит гипертрейдинг JTDX точно поддерживает. Как-то так.

Андрей, вы как айтишник со стажем, вообще-то должны знать, что ПО делится на уровни.

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

Самой JTDX, которая является прикладной программой (верхний уровень) абсолютно безразлично физическое устройство потоков, реальные ли это процы или потоки гипертрейдинга. За это отвечают программы самой операционки, то есть драйвера (базовый уровень).
То есть, если заявлено автором, что обрабатывается 12 вычислительных потоков, то они и обрабатываются, независимо от их физического происхождения.
Ну и что касается памяти - при чистой математике память, при современных обьёмах кэшей, практически не работает, работает скоростной кэш, которого хватает с головой для хранения промежуточных результатов.
Вообще, увеличение лагов зависит, скорее всего, от операций ввода-вывода и скорости чтения-записи, которые физически (по прерываниям) заставляют ждать процессор окончания их выполнения. Ну и от вычислительной мощности процессора и обьёма кэша конечно.

[RA3QDP]

Самой JTDX, которая является прикладной программой (верхний уровень) абсолютно безразлично физическое устройство потоков, реальные ли это процы или потоки гипертрейдинга. За это отвечают программы самой операционки, то есть драйвера (базовый уровень).

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

[UA3DJY]

Мой эксперимент показывает, что только частотой и "потоковостью" проца вопрос не решить. Независимо от платформы, для полного использования всего заявленного потенциала JTDX на максимальных настройках, необходимы прежде всего материнки с шириной шины в 5 ГГц(это все чипсеты 1150 и выше) и под самую быструю оперативную память DDR-4 с частотой 2300 мГц. Отсюда и требования к сокетам процессоров.
Когда "процессор 2 ядра", то это 775-й сокет(на самых продвинутых материнках шина 1300 мГц) и память DDR-2(самая дорогая, с радиаторами 1066 мГц, обычно 800 мГц). В этом случае на загруженных НЧ диапазонах даже при самых "быстрых и мелких" настройках JTDX реально влететь в период передачи больше секунды и потерять до 30% самых слабых(и как правило самых нужных) декодов.

В JTDX чувствительность FT8 декодера на частоте QSO определяется отдельно от широкополосного декодирования, даже на средних по производительности процессорах можно мониторить диапазон в режиме SWL, при проведении QSO отключать кнопку SWL и использовать настройки широкополосного декодирования позволяющие во время QSO вписаться в необходимую задержку декодирования.

- - - Добавлено - - -

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

И JTDX и WSJT-X используют stdout для передачи декодированных сообщений из декодера (процесс jtdxjt9) в процесс работающий с GUI jtdx (в WSJT-X jt9/wsjtx). Под Windows этот stdout + вывод на экран при большом количестве декодированных сообщений занимают ощутимое время.

Интересно какую часть из этого занимает вывод на экран, необходим эксперимент с текстовыми фильтрами повторов, ненужных континентов, стран и т.п.. Возможно с текстовыми фильтрами под Windows удастся немного уменьшить задержку декодирования.

- - - Добавлено - - -

Все настройки декодирования на максимум согласно рекомендациям авторов: Количество потоков можно на "Авто", Широкополосное декодирование - "Глубокое", Количестово циклов декодирования - "3", QSO RX уровень чувствительности - "Высокое", чувствительность декодера - "Использовать субпасс". Включите любой загруженный бендезон, где не менее 30-40 декодов(все равно какого уровня, откуда) и отскриньте какой получился Lag.

Режим количества потоков "Авто" сделан для тех кто не разбирается в компьютерах, это компромисс при котором декодер использует количество потоков на единицу меньше количества логических ядер. Например на процессоре 4/8 ядер минимальный лаг можно получить на 4-х потоках. У каждого пользователя параллельно с JTDX бегут свои приложения, соответственно будет своя оптимальная настройка количества потоков.

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

- - - Добавлено - - -

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

Операционная система распределяет задачи по логическим ядрам. Попробуйте найти в OpenMP метод распознавания физического ядра от логического: https://www.openmp.org/

- - - Добавлено - - -

Игорь совсем недавно разъяснял здесь же, в этой ветке, о влиянии количества потоков на скорость и глубину декодов. Пояснял еще, что больше 12-ти программа не может.

Пока не вижу смысла делать больше: спектр частот равномерно делится между потоками что увеличивает количество 'приграничных' частот между потоками приводя к небольшому снижению количества декодированных сообщений при использовании более 4-х потоков. В FT8 декодере JTDX еще есть проверка: он не может использовать больше потоков чем доступно логических ядер в операционной системе. То есть если на процессоре с 4-мя логическими ядрами пользователь выберет 12 потоков то FT8 декодер не будет использовать более 4-х.

Это связано с тем что операционная система не может выделить больше ресурсов под задачу чем у нее есть, и если попытаться использовать 12 потоков декодирования на 4-х ядерном процессоре то операционная система будет выделять ресурсы последовательно три раза по 4 потока, то есть время декодирования по сравнению с использованием 4 потоков вырастет в три раза и появятся проблемы с декодированием сигналов в 'приграничных' областях потоков из-за несвоевременного вычитания.

- - - Добавлено - - -

Отличие "i" от Ксеонов в наличии графического процессора. А при установке отельной видеокарты(не надо навороченной!) ПРАВИЛЬНЫЕ программы(последние Фотошопы, КАД-ы, видеомонтаж и пр.) умеют "пристегивать" встроенный ГП к основному процу, в разы увеличивая его скорострельность! Надеюсь, JTDX правильная прога и тоже умеет это делать.

Автоматическое использование графических ядер заманчиво, но эти ядра на современных видеокартах заточены под обработку кусочков изображений видео потока, множества небольших задач, что потребует переработки кода под декодирование каждого кандидата на отдельном логическом ядре. Пока не знаю можно ли разбить декодирование внутри потока CPU на подпотоки GPU, какой для этого необходим компилятор и сохранится ли при этом поддержка многоплатформенности в JTDX. Декодирование сигнала с большим количеством ошибок OSD (ordered-statistics decoder) декодером ресурсоемкая задача, не знаю хватит ли для нее ресурсов логического ядра GPU чтобы вписаться в требуемое время декодирования.