locked occasional FT8 no decode, new computer? #Windows10 #raspberryPi #decode


Jim Pennino
 

On very busy bands WSJTX will sometimes fall behind and not decode the next cycle.

The current computer is Windows 10 laptop with a 4 core 1.95 GHz CPU and I am thinking about a new computer.

A new laptop with a 4 to 6 GHz 8 core CPU. These seem to run from $2K to $4k.

A new desktop with a 5 to 6 GHz 12 to 16 core CPU. These seem to run from $1.5k to $3k.

A Raspberry Pi4 dedicated to WSJTX running Ubuntu. This would cost ~$125.

So the question is, is the performance of WSJTX significantly different on Ubuntu such that I would gain much of anything by going to Raspberry Pi?

I have also thought about a 4 Pi cluster, however I doubt that WSJTX is coded such that a cluster would actually provide much, if anything, in the way of increased performance. If that is an incorrect assumption, I would be glad to be corrected.


Bill Somerville
 

On 25/08/2021 17:02, Jim Pennino via groups.io wrote:
On very busy bands WSJTX will sometimes fall behind and not decode the next cycle.

The current computer is Windows 10 laptop with a 4 core 1.95 GHz CPU and I am thinking about a new computer.

A new laptop with a 4 to 6 GHz 8 core CPU. These seem to run from $2K to $4k.

A new desktop with a 5 to 6 GHz 12 to 16 core CPU. These seem to run from $1.5k to $3k.

A Raspberry Pi4 dedicated to WSJTX running Ubuntu. This would cost ~$125.

So the question is, is the performance of WSJTX significantly different on Ubuntu such that I would gain much of anything by going to Raspberry Pi?

I have also thought about a 4 Pi cluster, however I doubt that WSJTX is coded such that a cluster would actually provide much, if anything, in the way of increased performance. If that is an incorrect assumption, I would be glad to be corrected.
Hi Jim,

one likely cause of failures to decode a period is a time adjustment by a crude SNTP time synchronization application like Dimension4. SNTP on a machine with a relatively stable system clock is usually fine, but on machines that have more wayward clocks the user tends to set the update interval too short and that causes regular time steps. It is because of this sort of behaviour that we no longer recommend SNTP time synchronization applications, instead preferring a full NTP implementation like the Meinberg NTP CLient on MS Windows, or similar.

TBH occasional manual time adjustment before an operating session is probably better then relying on a SNTP tool on a machine that keeps poor time.

Having many concurrent CPU threads has little benefit for WSJT-X, but it may be essential if you run other CPU intensive applications in parallel with using WSJT-X. You machine choice must be the right one for the load profile you intend to use.

The Raspberry Pi is at the low end of CPUs suitable for running WSJT-X, we have tuned the FT8 decoder such that the "Menu->Decode->Fast" option is about right for a Raspberry Pi Model 3 running a 32-bit o/s, that will miss occasional decodes but will deliver the bulk of decodes reasonably promptly.

73
Bill
G4WJS.


Bob McGraw - K4TAX
 

Running Windows 10 Pro 64 bit on a HP Laptop, Elite book 6930P, with a 2.4 GHz Duo CPU and 8GB of RAM, I don't see any issues with latency when running WSJT-X.  I must qualify that in that I don't have other applications running.   Thus the more one asked the computer to process, the slower it gets.   For that reason I don't run WSJT-X out of HRD and I don't run an integrated logging application such as N1MM and etc.   I do my logging within WSJT-X and then transfer that to my log on QRZ.COM and to LOTW after I'm finished with my operating session.

73

Bob, K4TAX


On 8/25/2021 11:02 AM, Jim Pennino via groups.io wrote:
On very busy bands WSJTX will sometimes fall behind and not decode the next cycle.

The current computer is Windows 10 laptop with a 4 core 1.95 GHz CPU and I am thinking about a new computer.

A new laptop with a 4 to 6 GHz 8 core CPU. These seem to run from $2K to $4k.

A new desktop with a 5 to 6 GHz 12 to 16 core CPU. These seem to run from $1.5k to $3k.

A Raspberry Pi4 dedicated to WSJTX running Ubuntu. This would cost ~$125.

So the question is, is the performance of WSJTX significantly different on Ubuntu such that I would gain much of anything by going to Raspberry Pi?

I have also thought about a 4 Pi cluster, however I doubt that WSJTX is coded such that a cluster would actually provide much, if anything, in the way of increased performance. If that is an incorrect assumption, I would be glad to be corrected.





Guillaume, F-20917
 

Hi Jim,
I am running digital on a raspberry pi 2B : I have the same problem as you have : slow decode, sometimes no decode.
I will change soon to an old PC with 3GHz dual core and Lubuntu. (same as Ubuntu but a little bit faster on old machines they say)
why don't you run your existing PC in dual boot with a Lubuntu or Ubuntu to give a try ?

73
Guillaume F4IQU 


Jim Pennino
 

As the maximum system clock error is less than 100 microseconds, I doubt it is a factor.

Out of curiosity, how much effort does WSJTX expend on decoding signals more than a couple of hundred milliseconds off?

Too bad WSJTX isn’t more multithreaded what with 8 core being a low end system these days.

I guess I will forget about Raspberry Pi for this unless WSJTX becomes more multithreaded.


Bill Somerville
 

On 26/08/2021 21:08, Jim Pennino via groups.io wrote:
As the maximum system clock error is less than 100 microseconds, I doubt it is a factor.

Out of curiosity, how much effort does WSJTX expend on decoding signals more than a couple of hundred milliseconds off?

Too bad WSJTX isn’t more multithreaded what with 8 core being a low end system these days.

I guess I will forget about Raspberry Pi for this unless WSJTX becomes more multithreaded.
Hi Jim,

the decoding effort on all candidate signals is equivalent, obviously some that are easy to decode are processed much more quickly than others. The time offset is only relevant for choosing candidate signals to attempt to decode.

100 us off is not an issue, but an SNTP time application may be making time corrections regularly to achieve that if the update interval is set too short, and the undisiplined system clock drifts significantly. Time steps from SNTP applications cause audio stream discontinuities that can disrupt a whole decoding period.

73
Bill
G4WJS.


Jim Pennino
 

Hi Bill,

You keep assuming I am running something like SNTP.

I am not.

The system runs NTP and has an attached USB GNSS receiver that keeps the system to within about 3 milliseconds absent any other time source, but it also uses two local stratum 1 NTP servers that keep the system to well within 100 microseconds when it is on the network, which is most of the time. The system clock does NOT drift outside the microsecond range.

Perhaps if I rephrase the question: Would it have much effect on the resources used if the documentation suggestion to run something like NTP was changed to a requirement to keep the clock within, say 100 milliseconds or so?


Bill Somerville
 

On 27/08/2021 14:39, Jim Pennino via groups.io wrote:
Hi Bill,

You keep assuming I am running something like SNTP.

I am not.

The system runs NTP and has an attached USB GNSS receiver that keeps the system to within about 3 milliseconds absent any other time source, but it also uses two local stratum 1 NTP servers that keep the system to well within 100 microseconds when it is on the network, which is most of the time. The system clock does NOT drift outside the microsecond range.

Perhaps if I rephrase the question: Would it have much effect on the resources used if the documentation suggestion to run something like NTP was changed to a requirement to keep the clock within, say 100 milliseconds or so?
Jim,

if I am assuming something then it is because you have not provided sufficient information. Note that saying your PC clock is always within 100 ms of UTC doesn't tell me you are running a full NTP implementation. What is sure is that a step adjustment to the PC clock during a receive period will cause an audio stream discontinuity, and that in turn may disrupt all decoding for that period. You asked what might be the cause of occasional failures to decode any signals, I offered one common reason. If that is not the case for you then you need to look for other causes, audio discontinuities are still likely to be the cause so perhaps some peak of CPU or interrupt loading is disrupting smooth audio streaming.

73
Bill
G4WJS.


Jim Pennino
 

Bill,

After running process explorer it is obvious what the problem is.

No system resource, i.e. CPU, memory, etc., gets anywhere near 100%.

wsjtx shows a peak CPU usage of about 15% and jt9 shows a peak of about 25%.

Individual core usage never gets above about 50%.

There are no strange I/O wait states that would indicate anything like an audio discontinuity.

The only thing left is that a 1.95 GHz CPU is too slow to process all the data when there are a large number of signals within a cycle, continues to process into the next cycle, and misses all the data from the next cycle.

One solution, which would only effect those with a slow CPU, would be to put a hard limit on how long WSJTX attempts to decode a cycle such that if it were nearing the time when it would lose the next cycle, it gives up on the current cycle. The result for those with slow CPU's would be to lose a few possible decodes in the current cycle as opposed to losing everything from the next.

The other solution is to get a faster CPU, but that isn't an option for those using the Raspberry Pi4.


Bill Somerville
 

On 27/08/2021 18:54, Jim Pennino via groups.io wrote:
Bill,

After running process explorer it is obvious what the problem is.

No system resource, i.e. CPU, memory, etc., gets anywhere near 100%.

wsjtx shows a peak CPU usage of about 15% and jt9 shows a peak of about 25%.

Individual core usage never gets above about 50%.

There are no strange I/O wait states that would indicate anything like an audio discontinuity.

The only thing left is that a 1.95 GHz CPU is too slow to process all the data when there are a large number of signals within a cycle, continues to process into the next cycle, and misses all the data from the next cycle.

One solution, which would only effect those with a slow CPU, would be to put a hard limit on how long WSJTX attempts to decode a cycle such that if it were nearing the time when it would lose the next cycle, it gives up on the current cycle. The result for those with slow CPU's would be to lose a few possible decodes in the current cycle as opposed to losing everything from the next.

The other solution is to get a faster CPU, but that isn't an option for those using the Raspberry Pi4.
Hi Jim,

are you running a 64-bit o/s on your Raspberry Pi Model 4?

Does this issue occur when you select "Menu->Decode->Normal" or "Menu->Decode->Fast"?

73
Bill
G4WJS.


Michael Black
 

What's your Decode menu show for the depth?
Reduce it.

Mike W9MDB




On Friday, August 27, 2021, 12:55:40 PM CDT, Jim Pennino via groups.io <penninojim@...> wrote:


Bill,


After running process explorer it is obvious what the problem is.

No system resource, i.e. CPU, memory, etc., gets anywhere near 100%.

wsjtx shows a peak CPU usage of about 15% and jt9 shows a peak of about 25%.

Individual core usage never gets above about 50%.

There are no strange I/O wait states that would indicate anything like an audio discontinuity.

The only thing left is that a 1.95 GHz CPU is too slow to process all the data when there are a large number of signals within a cycle, continues to process into the next cycle, and misses all the data from the next cycle.

One solution, which would only effect those with a slow CPU, would be to put a hard limit on how long WSJTX attempts to decode a cycle such that if it were nearing the time when it would lose the next cycle, it gives up on the current cycle. The result for those with slow CPU's would be to lose a few possible decodes in the current cycle as opposed to losing everything from the next.

The other solution is to get a faster CPU, but that isn't an option for those using the Raspberry Pi4.




Jim Pennino
 

Bill,

As I said in the first post, I am running Windows 10.

I was thinking about going to a Raspberry Pi, or even a Pi cluster, dedicated to WSJTX for better performance.

However it is now obvious that throwing more cores at the issue is futile as there is not enough parallelism in WSJTX that it would help for any number of cores beyond 4.

As for the decode setting, I start out at the highest setting and reduce it to a lower setting as WSJTX starts dropping cycles. If the number of signals noticeably drops, I start raising the setting. Repeat, rinse….

Yes, that is a work around, but a PITA as things change and it would be nice if WSJTX would recognize it is running out of time and just give up no matter what the setting. 


William Smith
 

One other thought would be to run MalwareBytes free scanner to make sure there's nothing stealing cycles.

And check your disk(s) with SmartMonTools to see if bad sectors are causing retries, which can cause mysterious slowdowns.

The CPU isn't overheating and throttling itself to prevent meltdown is it?  Check the exhaust air to see if it's hot rather than warm, or if the fans are running at full speed.

How much RAM do you have?  IME, increasing RAM and/or swapping out HDD for SSD can really make a perceived performance difference.

Just random thoughts based on my PC experience.  Constantly chasing decode settings feels like you are covering up or missing the real problem, though it could be, as you surmise, that 1.9 GHz just isn't enough.

73, Willie N1JBJ

On Aug 28, 2021, at 9:54 AM, Jim Pennino via groups.io <penninojim@...> wrote:

As for the decode setting, I start out at the highest setting and reduce it to a lower setting as WSJTX starts dropping cycles. If the number of signals noticeably drops, I start raising the setting. Repeat, rinse….


Jim Pennino
 

Again, Process Explorer shows no resource being anywhere near maxed out.

FYI Process Explorer is sort of like Task Manager on steroids, shows details to the thread level, is not installed by default and apparently few people even know it exists. 

As a side note, before I removed all the standard Windows crap like Xbox, weather, news, find phone, etc. I never use and changed startup from automatic to manual for those I do use occasionally, like “helper” apps looking for updates to things and providing “faster startup”, CPU usage would sometimes get to 100%, but not anymore.


William Smith
 

Yeah, but IME Process Explorer won't show things like CPU overheating because of blocked fan vents or disk errors causing retries, and some malware can hide itself from monitoring, hence my suggestions.

Not really sure what your computer's issue is, so just shotgunning it and/or brainstorming. As always, double your money back if not satisfied!

73, Willie N1JBJ

On Aug 29, 2021, at 9:38 AM, Jim Pennino via groups.io <penninojim@...> wrote:

Again, Process Explorer shows no resource being anywhere near maxed out.

FYI Process Explorer is sort of like Task Manager on steroids, shows details to the thread level, is not installed by default and apparently few people even know it exists.

As a side note, before I removed all the standard Windows crap like Xbox, weather, news, find phone, etc. I never use and changed startup from automatic to manual for those I do use occasionally, like “helper” apps looking for updates to things and providing “faster startup”, CPU usage would sometimes get to 100%, but not anymore.



Jim Pennino
 

CPU temperature and disk errors are both monitored by Windows.

Process Monitor shows CPU speed as do several other utilities.

No process can “hide” from Process Explorer. A process may obfuscate itself, but it’s resource usage can be seen.

The issue is simply that WSJTX, under some conditions, attempts to do more processing than the CPU can do in the time allowed.


Bill Somerville
 

On 30/08/2021 15:00, Jim Pennino via groups.io wrote:
CPU temperature and disk errors are both monitored by Windows.

Process Monitor shows CPU speed as do several other utilities.

No process can “hide” from Process Explorer. A process may obfuscate itself, but it’s resource usage can be seen.

The issue is simply that WSJTX, under some conditions, attempts to do more processing than the CPU can do in the time allowed.
Hi Jim and others,

I find the easiest way to determine if Windows, or the PC BIOS, is throttling the CPU speed is to start Windows Resource Monitor and on the CPU tab observer the blue curve on the top summary plot. It represents CPU utilization and should remain firmly at 100% if the CPU is not being throttled. If drops to a lower level or drops downwards regularly then you may have issues with thermal load or power saving options that are not compatible with high CPU demands.

73
Bill
G4WJS.


RichardH
 

Hi, Jim.  I had a different set of issues getting WSJT-X to work on my Optiplex 5050 (Dell) desktop, and after wrestling with it on and off for a couple of weeks, I threw in the towel and bought an inexpensive laptop to essentially dedicate to digital mode radio.  Reading between the lines in your posts, it looks like you may need more horsepower to handle tasks in addition to digi-mode radio so this may not be for you.

But just in case this provides at least a frame of reference, here's what I got from Dell's direct online store for about $400:  Dell Inspiron 5402, i3 chipset @3.0GHz, 4GB memory, 128GB SSD; O/S is Win10. The rig is an ICOM 7410.  This setup worked like a charm right out of the gate -- I've never had an issue 8 months and 3,500 FT8 contacts later.  There have been a few evenings where conditions were so good that the contacts were rolling in faster than I could log them -- classic one-armed paper hanger mode, so no decode latency as far as I can tell.  Running Dimension 4 (freeware) for time sync, also trouble free.  Also, I have a ham buddy with exactly the same laptop (rig is an ICOM 706) and he's had the same experience -- no issues.

You wouldn't want this machine for CPU pegging, processing intensive applications but for WSJT-X and basic computing tasks, it does just fine.  And the price is right.

73 and good luck getting to the promised land!

Dick
KK6LE


Jim-KM4JSI <KM4JSI@...>
 

I fix it. Some how my sound settings got changed in the laptop. I do need more horsepower and it’s being prepared for me and will be ready next week.

On Mon, Aug 30, 2021 at 8:25 PM RichardH <jrhoye@...> wrote:
Hi, Jim.  I had a different set of issues getting WSJT-X to work on my Optiplex 5050 (Dell) desktop, and after wrestling with it on and off for a couple of weeks, I threw in the towel and bought an inexpensive laptop to essentially dedicate to digital mode radio.  Reading between the lines in your posts, it looks like you may need more horsepower to handle tasks in addition to digi-mode radio so this may not be for you.

But just in case this provides at least a frame of reference, here's what I got from Dell's direct online store for about $400:  Dell Inspiron 5402, i3 chipset @3.0GHz, 4GB memory, 128GB SSD; O/S is Win10. The rig is an ICOM 7410.  This setup worked like a charm right out of the gate -- I've never had an issue 8 months and 3,500 FT8 contacts later.  There have been a few evenings where conditions were so good that the contacts were rolling in faster than I could log them -- classic one-armed paper hanger mode, so no decode latency as far as I can tell.  Running Dimension 4 (freeware) for time sync, also trouble free.  Also, I have a ham buddy with exactly the same laptop (rig is an ICOM 706) and he's had the same experience -- no issues.

You wouldn't want this machine for CPU pegging, processing intensive applications but for WSJT-X and basic computing tasks, it does just fine.  And the price is right.

73 and good luck getting to the promised land!

Dick
KK6LE