Date
1 - 4 of 4
WD 3.0.3.4 is latest build fixes 100% CPU bug at KK6PR
Rob Robinett
Thanks to support from Rick KK6PR, he confirmed that some minor enhancements I made to wav file validation fixed the 100% CPU problem his Thinkcentre was experiencing when there were no ssh sessions to the TC. This is the same problem Holgar OE9GHV was suffering on both his TC i5 and TC i9, and after installing 3.0.3.4 on both those machines I see no evidence of the bug. I am also running 3.0.3.4 at KPH, KFS and AI6VN/KH6, but those sites never experienced this bug.
So if you are suffering from this problem, 'git pull' the latest code and restart WD. Please report positive and negative results to me. I'm sure this isn't the last bug lurking in such a complex piece of code.
So if you are suffering from this problem, 'git pull' the latest code and restart WD. Please report positive and negative results to me. I'm sure this isn't the last bug lurking in such a complex piece of code.
wayne roth
Rob,
I did a git pull to update my APi's to 3.0.3.4. On the third APi that controls the third Kiwi I can cause the error looping to happen in a reproducible manner. With the APi/Kiwi in the "error state", where it's cycling through kiwi channels and logging to the journal about wav_recording_daemon.log not being found etc, I ssh-in with putty from a PC and kill the process with ./wsprdaemon -Z followed by ./wsprdaemon -z. If I restart WD with ./wsprdaemon -a and then exit putty, I don't see the error condition happen (by watching the channels on the Kiwi status page). However, if I ssh-in, kill the process (that I started with -a) with a wd -z, then restart with ./wsprdaemon -A and exit the ssh session, then I observe the error state happen again by watching the Kiwi channels cycle. So it appears that in this particular case, initiating wd with the -A option that sets it up to run as a service, then exit the ssh session, the absence of the ssh-session (user@1000 I assume) then the error state begins. I've attached a jpg snippet from the journalctl log which shows the cpu in the process of shutting down the user session, and at 14:54:11 the log shows immediately that the wav_recording_daemon.log does not exist and the cycling of kiwi channels begins.
I have not powered down this APi in case you want to log in and take a look. I'll need a new channel ID to give you access.
Wayne
Wayne
I did a git pull to update my APi's to 3.0.3.4. On the third APi that controls the third Kiwi I can cause the error looping to happen in a reproducible manner. With the APi/Kiwi in the "error state", where it's cycling through kiwi channels and logging to the journal about wav_recording_daemon.log not being found etc, I ssh-in with putty from a PC and kill the process with ./wsprdaemon -Z followed by ./wsprdaemon -z. If I restart WD with ./wsprdaemon -a and then exit putty, I don't see the error condition happen (by watching the channels on the Kiwi status page). However, if I ssh-in, kill the process (that I started with -a) with a wd -z, then restart with ./wsprdaemon -A and exit the ssh session, then I observe the error state happen again by watching the Kiwi channels cycle. So it appears that in this particular case, initiating wd with the -A option that sets it up to run as a service, then exit the ssh session, the absence of the ssh-session (user@1000 I assume) then the error state begins. I've attached a jpg snippet from the journalctl log which shows the cpu in the process of shutting down the user session, and at 14:54:11 the log shows immediately that the wav_recording_daemon.log does not exist and the cycling of kiwi channels begins.
I have not powered down this APi in case you want to log in and take a look. I'll need a new channel ID to give you access.
Wayne
Wayne
Andrew Cowan
Rob, thanks for the work on the software.
I still get 100 percent cpu usage here during wav, sits about 45 percent running
Unfortunately I let ubuntu upgrade itself and got the QT5 issue so reinstalled 22.04.
Just running the standard settings 500 04 etc.
conf below if needed
Andrew GM0UDL
I still get 100 percent cpu usage here during wav, sits about 45 percent running
Unfortunately I let ubuntu upgrade itself and got the QT5 issue so reinstalled 22.04.
Just running the standard settings 500 04 etc.
conf below if needed
declare RECEIVER_LIST=(
### RASP 630m and multi vert KIWIA 40m KIWIB 30-17-12 KIWIC 20-15-10
"RASP 192.168.1.199:8073 GM0UDL IO77vo NULL"
"FLYDOG 192.168.1.200:8073 GM0UDL IO77vo NULL"
"KIWIA 192.168.1.197:8073 GM0UDL IO77vo NULL"
"KIWIB 192.168.1.196:8073 GM0UDL IO77vo NULL"
"KIWIC 192.168.1.194:8073 GM0UDL IO77vo NULL"
"MERGE_KARASP RASP,KIWIA GM0UDL IO77vo NULL"
"MERGE_FR RASP,FLYDOG GM0UDL IO77vo NULL"
"MERGE_KBRASP RASP,KIWIB GM0UDL IO77vo NULL"
"MERGE_KCRASP RASP,KIWIC GM0UDL IO77vo NULL"
"MERGE_KBFLY KIWIB,FLYDOG GM0UDL IO77vo NULL"
)
declare WSPR_SCHEDULE=(
"00:00 KIWIA,60 KIWIA,60eu MERGE_KARASP,40 MERGE_KBRASP,30 MERGE_KCRASP,20 MERGE_KBRASP,17 MERGE_KCRASP,15 MERGE_KBRASP,12 MERGE_KCRASP,10 "
SIGNAL_LEVEL_STATS=no
SIGNAL_LEVEL_UPLOAD_GRAPHS="no"
SIGNAL_LEVEL_UPLOAD_ID="Callsign"
SIGNAL_LEVEL_UPLOAD="no"
SIGNAL_LEVEL_LOCAL_GRAPHS="no"
Andrew GM0UDL
Rob Robinett
Hi Andrew
I would be interested in logging on to your server to to debug your problem. To give me access add this line at the top of your wsprdaemon.conf file:
REMOTE_ACCESS_CHANNEL=48
Then run any WD command like ./wsprdaemon -s and you should see a printout of it loading a new 'frpc' library file and successfully connection to the WD server.
I then will need a login and password on your WD server which you can PM me.
Rob
I would be interested in logging on to your server to to debug your problem. To give me access add this line at the top of your wsprdaemon.conf file:
REMOTE_ACCESS_CHANNEL=48
Then run any WD command like ./wsprdaemon -s and you should see a printout of it loading a new 'frpc' library file and successfully connection to the WD server.
I then will need a login and password on your WD server which you can PM me.
Rob