RPI4 can't "find time" to upload spots ?
|
Hi, "Not ready to start uploads because there are running 'wsjtx', 'jt9' and/or 'derived_calc.py' jobs". |
|
|
|
Zu
Thu 23 Feb 2023 14:19:04 UTC: upload_to_wsprnet_daemon() Not ready to start uploads because there are now 148 spot files, more than the 147 spot files we previously found
Thu 23 Feb 2023 14:19:15 UTC: upload_to_wsprnet_daemon() There are 148 spot files ready for upload and 'ps' didn't find any jobs which might create more. Here are the top 10 jobs currently running on the system:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
31132 pi 30 10 15600 13352 3184 R 57.1 0.3 0:03.50 wsprd
31159 pi 30 10 14548 12748 3276 R 21.4 0.3 0:02.41 wsprd
31179 pi 30 10 14532 10444 3084 R 21.4 0.3 0:02.22 wsprd
31102 pi 30 10 14904 12992 3212 R 17.9 0.3 0:03.51 wsprd
31148 pi 30 10 14532 10476 3116 R 17.9 0.3 0:02.22 wsprd
31545 pi 20 0 16492 3232 2612 R 17.9 0.1 0:00.05 curl
31529 pi 20 0 11356 2920 2556 R 14.3 0.1 0:00.12 top
30857 pi 20 0 11536 2172 1864 S 10.7 0.1 0:00.82 rtl_power
5840 pi 20 0 87656 81860 1704 S 7.1 2.1 1:03.53 wsprdaemon.sh
9161 pi 20 0 102172 97004 2384 S 7.1 2.5 21:33.99 wsprdaemon.sh
Thu 23 Feb 2023 14:19:15 UTC: upload_to_wsprnet_daemon() Checking for CALL/GRID directories
Thu 23 Feb 2023 14:19:16 UTC: upload_wsprnet_create_spot_file_list_file() Creating a list of spot files for CALL_GRID from the 148 spot files from 1 WSPR cycles
Thu 23 Feb 2023 14:19:16 UTC: upload_wsprnet_create_spot_file_list_file() Checking for number of spots in '230223' in the list of 148 files passed to us
Thu 23 Feb 2023 14:19:16 UTC: upload_wsprnet_create_spot_file_list_file() Adding the 1089 spots in cycle 230223 to the exisiting 1089 spots will exceed the max 999 spots for an MEPT upload, so upload list is complete
Thu 23 Feb 2023 14:19:16 UTC: upload_to_wsprnet_daemon() Uploading spots from 0 files
Thu 23 Feb 2023 14:19:17 UTC: upload_to_wsprnet_daemon() Found 148 spot files but there are no spot lines in them, so flushing those spot files
Thu 23 Feb 2023 14:19:17 UTC: upload_to_wsprnet_daemon() Waiting 53 seconds until cycle offset 10 when we will start to look for spot files and for all decodes to finish
Thu 23 Feb 2023 14:20:11 UTC: upload_to_wsprnet_daemon() Waiting for there to be some spot files, for the number of spot files to stablize, and for there to be no running 'wsprd' or 'jt9 jobs
Thu 23 Feb 2023 14:20:11 UTC: upload_to_wsprnet_daemon() Not ready to start uploads because there are now 1 spot files, more than the 0 spot files we previously found
rm: cannot remove '20230223T134400Z_10138700_usb.wav': No such file or directory
Thu 23 Feb 2023 14:20:21 UTC: upload_to_wsprnet_daemon() Not ready to start uploads because there are now 2 spot files, more than the 1 spot files we previously found |
|
|
|
Rob Robinett
Hi Zu, Thank you for your kind words about our project. It is normal for a system with a CPU of modest performance like the Pi to take a long time to upload spots. The upload daemon log you view with 'wdln' shows how that daemon tries to efficiently upload spots to wsprnet.org by waiting for all the decoding demon jobs to finish. On at Pi4b like the one at VK7JJ which is currently running 8 bands and decoding WSPR-2,FST4W-120 and -300, it the take a minute or more for those decodes to complete and during that time the upload daemon log will output various 'waiting for ...' messages and sometimes the uploaded spots lists in the log will come from 2 or more WSPR cycles. However if 'toop' or the 'btop' program shown below displays periods of time when the CPU is 'idle' (only running kiwirecorder' jobs, then your spots will be eventually delivered. Sites with more than 1 Kiwi and/or searching for the longer FST4W modes are generally running x86 CPUs. I have been buying used Lenovo Thinkcenter Tiny M900s with i5-6500 CPUs for US $110 for all new deployments. They are 10x more powerful than the ARMs in the Pi and thus can support 30+ receive channels 73 Rob  On Thu, Feb 23, 2023 at 6:04 AM Zu <zuzzurellone@...> wrote:
--
|
|
|
|
Rob Robinett
To reduce the CPU burden of decoding, you can modify the decode intensity by adding the red line below to your conf file. The default is '-o 4', the saem value used by WSJT-x, but '-o 3' will significantly reduce the CPU time consumed by the wsprd decoder and result in only a few less spots being decoded Some sites have gone to '-o 1' so the Pi can finish its decoding in 2 minutes. ### In CPU constrained installations, less CPU will be used if the 'wsprd' command is instructed to search less deeply for spots. ### That can be done by uncommenting the following line and changing '-o 4' (the value used by WSJT-x) to '-o 3', '-o 2' or even '-o 1' ### However if your site requires '-o 2' or '-o 1', then you are missing a significant number of spots and should consider upgrading your WD server to one with a more powerful CPU WSPRD_CMD_FLAGS="-C 500 -o 3 -d" On Thu, Feb 23, 2023 at 6:54 AM Zu <zuzzurellone@...> wrote:
--
|
|
|
|
After reducing the "-o" value to 3, spot files are processed when they're 10, 20, 30 sometimes, and spots regularly uploaded. This on a Raspberry Pi 4 Model B Rev 1.4 with 4GB of RAM and no slow modes decoding. Thank you very much for your replies and help, Rob! |
|
|