When configuring WD for the newly added FST4W modes, it is crucial to know that your WD server has enough CPU power to decode all of the configured modes before the end of a 2 minute WSPR cycle.  

Until I add some code to WD which would log ERROR lines when the WD server runs out of time during decode, you can watch WD at work and monitor the associated CPU temperature by running the Linux command line 'top'  and 'sensors' commands.

'top' is installed on all Linux distros that I have used, but the 'sensors' command'  will  probably need to be installed by running:

sudo apt install lm-sensors

On a Raspberry Pi, the 'sensors' command  doesn't show the CPU core temperature, but the command 'vcgencmd measure_temp' gives that information  

I have been watching for CPU overheating on all the WD servers which I have set up for F15:F30 to see what is the peak CPU temperature during the first seconds of each WSPR cycle.  For those WD sites configured for F30, minutes 00 and 30 are the most stressful.  

To observe the CPU stress and associated CPU heating, I run two terminal windows:  in the upper I run 'top' and in the lower 'watch sensors'.  When decoding starts at second 5, the kiwirecorder jobs drop down the 'top' window while the 'wsprd/ and 'jt9' decoders run.  

At Glenn N6GN the  WD Thinkcentre configured for 6 bands is so lightly loaded that all the wsprd and jt9 jobs finish by second 20 and during those 15 seconds your two CPU cores go from 50C to 65C, far below their critical 85C temp.

At Idle when his TC is only recording wav files and the TC cpus are 10%  busy:

When the TC is 100% recording this minute's wav files and also decoding the 2 minute wav from the previous WSPR cycle:

In contrast to Glenn's lightly loaded TC,  Ulli ON5KQ's TC  configured for 26 receive channels is about 35% busy during 'idle'  when CPU is about 65C.

It runs at 100% CPU from second 5 to second 60 during which the CPU temperature is about 75C, just below the 85C which (I think) will stimulate the CPU to throttle its clock back to keep it from overheating. 

At KFS where there are 26 receive channels and all are configured to decode all FST4W modes, I found Thinkcentre  could not finish all the decodes in 120 seconds.  So I moved WD to the Dell dual-Xeon Poweredge server which I have described in a previous posting.

Here at W3ENR I'm running a dual core sky lake i7 (Intel NUC) / 4 threads fed by two kiwis.

The attached image shows the config.  I'm also listening on 6m in default WSPR2 mode only (didn't all fit on the old little screen at once).

Sensors says the critical temp for my cores is 100c.

Idle, about 25% of the CPU is occupied and CPU temps in my non-air conditioned room are 66c, give or take a few degrees.

When decoding begins, one core is completely occupied while the other core is mostly working but doesn't seem to be completely taken up by wsprdaemon.

On most decoding runs the cores both go over 90c.  The max temp on the fully occupied one that I've observed is 97c.  (92-93c would be typical of the other.)

I think it may be throttling because I find it odd that exactly 97c again and again is the maximum reached on the more intense decoding minutes. (It's under 97c on the more 'average' times of the hour.)

I have successfully decoded 30 minute from N3AGE on 0.47mhz, but only a few times, I believe. Mostly it's 15m and 5m that I more regularly decode from him. 

It's hard to tell what's going on with FSTW4 - 2 minute, since it is reported as the same "mode" as WSPR2.  He's sending at 0.2w and 1w to differentiate, but I'm honestly not sure which is which.  I frequently have decoded both power levels on higher bands.

I don't really have the antenna for 2200m, so it is unsurprising there are no decodes.

N3AGE just wrote me to say that he's rebuilding his transmitter presently.

Is there a little less power hungry solution here than the old server that would work for my present configuation... and maybe leave room to do at least 2/5/15 on 20m-10m?

Edward

On 6/28/22 13:20, Rob Robinett wrote:

When configuring WD for the newly added FST4W modes, it is crucial to know that your WD server has enough CPU power to decode all of the configured modes before the end of a 2 minute WSPR cycle.  

Until I add some code to WD which would log ERROR lines when the WD server runs out of time during decode, you can watch WD at work and monitor the associated CPU temperature by running the Linux command line 'top'  and 'sensors' commands.

'top' is installed on all Linux distros that I have used, but the 'sensors' command'  will  probably need to be installed by running:

sudo apt install lm-sensors

On a Raspberry Pi, the 'sensors' command  doesn't show the CPU core temperature, but the command 'vcgencmd measure_temp' gives that information  

I have been watching for CPU overheating on all the WD servers which I have set up for F15:F30 to see what is the peak CPU temperature during the first seconds of each WSPR cycle.  For those WD sites configured for F30, minutes 00 and 30 are the most stressful.  

To observe the CPU stress and associated CPU heating, I run two terminal windows:  in the upper I run 'top' and in the lower 'watch sensors'.  When decoding starts at second 5, the kiwirecorder jobs drop down the 'top' window while the 'wsprd/ and 'jt9' decoders run.  

At Glenn N6GN the  WD Thinkcentre configured for 6 bands is so lightly loaded that all the wsprd and jt9 jobs finish by second 20 and during those 15 seconds your two CPU cores go from 50C to 65C, far below their critical 85C temp.

At Idle when his TC is only recording wav files and the TC cpus are 10%  busy:

When the TC is 100% recording this minute's wav files and also decoding the 2 minute wav from the previous WSPR cycle:

In contrast to Glenn's lightly loaded TC,  Ulli ON5KQ's TC  configured for 26 receive channels is about 35% busy during 'idle'  when CPU is about 65C.

It runs at 100% CPU from second 5 to second 60 during which the CPU temperature is about 75C, just below the 85C which (I think) will stimulate the CPU to throttle its clock back to keep it from overheating. 

At KFS where there are 26 receive channels and all are configured to decode all FST4W modes, I found Thinkcentre  could not finish all the decodes in 120 seconds.  So I moved WD to the Dell dual-Xeon Poweredge server which I have described in a previous posting.

On Jun 29, 2022, at 17:30, Rob Robinett <rob@...> wrote:



Hi Jim,

Your 3 AtomicPis are altogether decoding 26 channels and decoding FST4W only on 2200 and 630.  The single $100 / 30W Thinkcenter at KFS could match that, but it appears your APi cluster has unused CPU cycles.

So could you add F2:F5:.. modes to your configuration to see when it runs out of CPU?  Stu WB6YRW/6 is transmitting FST4W-120 on 20M but no one appears to be listening on the East Coast and his signal doesn't reach EA8BFK.

Rob

On Wed, Jun 29, 2022 at 2:12 PM Jim Lill <jim@...> wrote:

Edward,

There are probably a bunch of alternatives. Here, I run 3 Atomic Pi to split the CPU loading etc. There power consumed is < 40W DC

I run 2 kiwi and all 14 bands on both splitting the band/channels amongst the 3 APi

-Jim wa2zkd

On 6/29/22 16:27, Edward Hammond wrote:

Here at W3ENR I'm running a dual core sky lake i7 (Intel NUC) / 4 threads fed by two kiwis.

The attached image shows the config.  I'm also listening on 6m in default WSPR2 mode only (didn't all fit on the old little screen at once).

Sensors says the critical temp for my cores is 100c.

Idle, about 25% of the CPU is occupied and CPU temps in my non-air conditioned room are 66c, give or take a few degrees.

When decoding begins, one core is completely occupied while the other core is mostly working but doesn't seem to be completely taken up by wsprdaemon.

On most decoding runs the cores both go over 90c.  The max temp on the fully occupied one that I've observed is 97c.  (92-93c would be typical of the other.)

I think it may be throttling because I find it odd that exactly 97c again and again is the maximum reached on the more intense decoding minutes. (It's under 97c on the more 'average' times of the hour.)

I have successfully decoded 30 minute from N3AGE on 0.47mhz, but only a few times, I believe. Mostly it's 15m and 5m that I more regularly decode from him. 

It's hard to tell what's going on with FSTW4 - 2 minute, since it is reported as the same "mode" as WSPR2.  He's sending at 0.2w and 1w to differentiate, but I'm honestly not sure which is which.  I frequently have decoded both power levels on higher bands.

I don't really have the antenna for 2200m, so it is unsurprising there are no decodes.

N3AGE just wrote me to say that he's rebuilding his transmitter presently.

Is there a little less power hungry solution here than the old server that would work for my present configuation... and maybe leave room to do at least 2/5/15 on 20m-10m?

Edward

On 6/28/22 13:20, Rob Robinett wrote:

When configuring WD for the newly added FST4W modes, it is crucial to know that your WD server has enough CPU power to decode all of the configured modes before the end of a 2 minute WSPR cycle.  

Until I add some code to WD which would log ERROR lines when the WD server runs out of time during decode, you can watch WD at work and monitor the associated CPU temperature by running the Linux command line 'top'  and 'sensors' commands.

'top' is installed on all Linux distros that I have used, but the 'sensors' command'  will  probably need to be installed by running:

sudo apt install lm-sensors

On a Raspberry Pi, the 'sensors' command  doesn't show the CPU core temperature, but the command 'vcgencmd measure_temp' gives that information  

I have been watching for CPU overheating on all the WD servers which I have set up for F15:F30 to see what is the peak CPU temperature during the first seconds of each WSPR cycle.  For those WD sites configured for F30, minutes 00 and 30 are the most stressful.  

To observe the CPU stress and associated CPU heating, I run two terminal windows:  in the upper I run 'top' and in the lower 'watch sensors'.  When decoding starts at second 5, the kiwirecorder jobs drop down the 'top' window while the 'wsprd/ and 'jt9' decoders run.  

At Glenn N6GN the  WD Thinkcentre configured for 6 bands is so lightly loaded that all the wsprd and jt9 jobs finish by second 20 and during those 15 seconds your two CPU cores go from 50C to 65C, far below their critical 85C temp.

At Idle when his TC is only recording wav files and the TC cpus are 10%  busy:

When the TC is 100% recording this minute's wav files and also decoding the 2 minute wav from the previous WSPR cycle:

In contrast to Glenn's lightly loaded TC,  Ulli ON5KQ's TC  configured for 26 receive channels is about 35% busy during 'idle'  when CPU is about 65C.

It runs at 100% CPU from second 5 to second 60 during which the CPU temperature is about 75C, just below the 85C which (I think) will stimulate the CPU to throttle its clock back to keep it from overheating. 

At KFS where there are 26 receive channels and all are configured to decode all FST4W modes, I found Thinkcentre  could not finish all the decodes in 120 seconds.  So I moved WD to the Dell dual-Xeon Poweredge server which I have described in a previous posting.

--

Rob Robinett

AI6VN

rob@...

mobile: +1 650 218 8896

Hi Jim,

Your 3 AtomicPis are altogether decoding 26 channels and decoding FST4W only on 2200 and 630.  The single $100 / 30W Thinkcenter at KFS could match that, but it appears your APi cluster has unused CPU cycles.

So could you add F2:F5:.. modes to your configuration to see when it runs out of CPU?  Stu WB6YRW/6 is transmitting FST4W-120 on 20M but no one appears to be listening on the East Coast and his signal doesn't reach EA8BFK.

Rob

On Wed, Jun 29, 2022 at 2:12 PM Jim Lill <jim@...> wrote:

Edward,

There are probably a bunch of alternatives. Here, I run 3 Atomic Pi to split the CPU loading etc. There power consumed is < 40W DC

I run 2 kiwi and all 14 bands on both splitting the band/channels amongst the 3 APi

-Jim wa2zkd

On 6/29/22 16:27, Edward Hammond wrote:

Here at W3ENR I'm running a dual core sky lake i7 (Intel NUC) / 4 threads fed by two kiwis.

The attached image shows the config.  I'm also listening on 6m in default WSPR2 mode only (didn't all fit on the old little screen at once).

Sensors says the critical temp for my cores is 100c.

Idle, about 25% of the CPU is occupied and CPU temps in my non-air conditioned room are 66c, give or take a few degrees.

When decoding begins, one core is completely occupied while the other core is mostly working but doesn't seem to be completely taken up by wsprdaemon.

On most decoding runs the cores both go over 90c.  The max temp on the fully occupied one that I've observed is 97c.  (92-93c would be typical of the other.)

I think it may be throttling because I find it odd that exactly 97c again and again is the maximum reached on the more intense decoding minutes. (It's under 97c on the more 'average' times of the hour.)

I have successfully decoded 30 minute from N3AGE on 0.47mhz, but only a few times, I believe. Mostly it's 15m and 5m that I more regularly decode from him. 

It's hard to tell what's going on with FSTW4 - 2 minute, since it is reported as the same "mode" as WSPR2.  He's sending at 0.2w and 1w to differentiate, but I'm honestly not sure which is which.  I frequently have decoded both power levels on higher bands.

I don't really have the antenna for 2200m, so it is unsurprising there are no decodes.

N3AGE just wrote me to say that he's rebuilding his transmitter presently.

Is there a little less power hungry solution here than the old server that would work for my present configuation... and maybe leave room to do at least 2/5/15 on 20m-10m?

Edward

On 6/28/22 13:20, Rob Robinett wrote:

When configuring WD for the newly added FST4W modes, it is crucial to know that your WD server has enough CPU power to decode all of the configured modes before the end of a 2 minute WSPR cycle.  

Until I add some code to WD which would log ERROR lines when the WD server runs out of time during decode, you can watch WD at work and monitor the associated CPU temperature by running the Linux command line 'top'  and 'sensors' commands.

'top' is installed on all Linux distros that I have used, but the 'sensors' command'  will  probably need to be installed by running:

sudo apt install lm-sensors

On a Raspberry Pi, the 'sensors' command  doesn't show the CPU core temperature, but the command 'vcgencmd measure_temp' gives that information  

I have been watching for CPU overheating on all the WD servers which I have set up for F15:F30 to see what is the peak CPU temperature during the first seconds of each WSPR cycle.  For those WD sites configured for F30, minutes 00 and 30 are the most stressful.  

To observe the CPU stress and associated CPU heating, I run two terminal windows:  in the upper I run 'top' and in the lower 'watch sensors'.  When decoding starts at second 5, the kiwirecorder jobs drop down the 'top' window while the 'wsprd/ and 'jt9' decoders run.  

At Glenn N6GN the  WD Thinkcentre configured for 6 bands is so lightly loaded that all the wsprd and jt9 jobs finish by second 20 and during those 15 seconds your two CPU cores go from 50C to 65C, far below their critical 85C temp.

At Idle when his TC is only recording wav files and the TC cpus are 10%  busy:

When the TC is 100% recording this minute's wav files and also decoding the 2 minute wav from the previous WSPR cycle:

In contrast to Glenn's lightly loaded TC,  Ulli ON5KQ's TC  configured for 26 receive channels is about 35% busy during 'idle'  when CPU is about 65C.

It runs at 100% CPU from second 5 to second 60 during which the CPU temperature is about 75C, just below the 85C which (I think) will stimulate the CPU to throttle its clock back to keep it from overheating. 

At KFS where there are 26 receive channels and all are configured to decode all FST4W modes, I found Thinkcentre  could not finish all the decodes in 120 seconds.  So I moved WD to the Dell dual-Xeon Poweredge server which I have described in a previous posting.

--

Rob Robinett

AI6VN

rob@...

mobile: +1 650 218 8896

Thanks Steve, but I wouldn't add any more bands or modes to your i7.  It is 100% busy for 90 of the 120 seconds of the WSPR cycle.
It is very helpful to have your site receiving Stu.

Thanks Steve, but I wouldn't add any more bands or modes to your i7.  It is 100% busy for 90 of the 120 seconds of the WSPR cycle.
It is very helpful to have your site receiving Stu.