Monitoring WD server CPU usage and associated CPU temperatures


Rob Robinett
 

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:
Screen Shot 2022-06-28 at 9.47.34 AM.png

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

Screen Shot 2022-06-28 at 9.47.44 AM.png

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. 


Screen Shot 2022-06-28 at 10.08.49 AM.png

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.






Edward (W3ENR / K3WRG)
 

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:
Screen
              Shot 2022-06-28 at 9.47.34 AM.png

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

Screen
              Shot 2022-06-28 at 9.47.44 AM.png

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. 


Screen
              Shot 2022-06-28 at 10.08.49 AM.png

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.






Jim Lill
 

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:
Screen Shot 2022-06-28 at 9.47.34 AM.png

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

Screen Shot 2022-06-28 at 9.47.44 AM.png

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. 


Screen Shot 2022-06-28 at 10.08.49 AM.png

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
 

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:
Screen Shot 2022-06-28 at 9.47.34 AM.png

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

Screen Shot 2022-06-28 at 9.47.44 AM.png

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. 


Screen Shot 2022-06-28 at 10.08.49 AM.png

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
mobile: +1 650 218 8896


KD2OM
 

Rob,
I just added W2,F2:F5 to 20 meters. I got WB6YRW on 20 this afternoon, so maybe I will get the /6 too.

Steve 

.
 

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
mobile: +1 650 218 8896


Stuart Ogawa
 

rob,

as a baseline reference...wspr zachtech 20m past 24 hours 


Screen Shot 2022-06-29 at 2.56.40 PM.png



contact ea8bfk about every 2 to 3 days  





On Wed, Jun 29, 2022 at 2:30 PM 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:
Screen Shot 2022-06-28 at 9.47.34 AM.png

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

Screen Shot 2022-06-28 at 9.47.44 AM.png

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. 


Screen Shot 2022-06-28 at 10.08.49 AM.png

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
mobile: +1 650 218 8896


Edward (W3ENR / K3WRG)
 

I can add it.  Will do later this evening.

EH


On 6/29/22 17:30, Rob Robinett 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:
Screen Shot 2022-06-28 at 9.47.34 AM.png

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

Screen Shot 2022-06-28 at 9.47.44 AM.png

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. 


Screen Shot 2022-06-28 at 10.08.49 AM.png

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
mobile: +1 650 218 8896


Rob Robinett
 

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.


Edward (W3ENR / K3WRG)
 

I'm gonna drop 2200 because that's really just wasting my cycles at W3ENR since I'm unlikely to hear anybody that's there.

EH


On 6/29/22 18:47, Rob Robinett wrote:
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.


Rob Robinett
 

Hi Edward,

I don't think there any Intel solutions which are much more power efficient than your i7, although I have asked Jim Lill WA2ZKD to configure his 3 * Atomic Pis like your and perhaps that is a possible solution.

For power efficiency the $900 Apple Mac M1 systems may equal the performance of the i9 and consume at max 30W, so the M1 may be capable of decoding all bands + all modes. I plan to buy one of those Mac Air M1 systems soon and will see how hard it is to get WD running on its freeBSD OS.


KD2OM
 


Before I turned the extra modes off.

On 6/29/22 22:47, Rob Robinett wrote:
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.


Rob Robinett
 

Thanks!
Adding F2  hardly increases the CPU load and add no wav file storage space, so I might make it the default on all bands.

On Wed, Jun 29, 2022 at 8:25 PM KD2OM <steve@...> wrote:


Before I turned the extra modes off.

On 6/29/22 22:47, Rob Robinett wrote:
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.



--
Rob Robinett
AI6VN
mobile: +1 650 218 8896


Erwin - PE3ES - F4VTQ
 

There are ways to build an optimized JT9 decoder using the available cpu functions like SSE2, SSE4
Is the current jt9 you use Rob already the most optimized version for the different cpu's available in wsprdaemon stations?

I found a topic on this on the Hermes Lite group with reference to SparkSDR
https://groups.google.com/g/hermes-lite/c/czF5-rwjSHU/m/vqFuU4ngAgAJ

Some other possible improvements can be found in another thread:
https://groups.google.com/g/hermes-lite/c/I4Q-DgdyyFs/m/hSSoTGa_CwAJ

I can not check if this would be applicable or in any way helpful for the wsprdaemon application. But never waste a good idea.