Hello everybody,
I encounter problems when I log several QSOs. After every 3 or 4 QSOs cqrlog stucks for up to 3 minutes with increased cpu usage before letting me continue to do the log. After restart of cqrlog everything starts all over again.
A few days ago I discussed that with Petr and it looked like QRZ.com would be the problem. So I switched to hamQTH and it worked for a while. But today I encouter that problem no matter which service I use.
Does anyone else have that issue with version 2.5.2 on a raspberry pi 4?
I'm now thinking of reverting back to version 2.4 because it worked just fine. Does anyone know how to do that the easy way?
73,
Rico DG5BQ
PS: I installed cqrlog again manually according the discription in https://www.cqrlog.com/node/3124. Now it seems to work fine. Will report if it crashes again.
Cqrlog does not retrive the name from qrz.com. (98%) of the time Nor from Hamqth
https://t.me/pump_upp
I thought I had solved the problem. But I was wrong.
Everything seems to work fine in normal mode. But the problem described above accurs once I switch to „offline“ for logging QSOs made in the past.
Anyone any idea?
Hi Rico!
Few things come into my mind.
Have you pinpointed that the stop is actually caused by qrz/hamqth? Do you have any other windows open? (Dxcluster rbn etc...)
if you open console and give command:
sudo tcpdump -X host Hamqth.com
or use qrz.com instead if you have configured that you can see responses from HamQTH.com when you enter a new call to NewQSO and jump to next field.
See how response is related to your view in Newqso. If something happens on console after a while of waiting and then you NewQSO releases it is a network problem. You should get several packets from HamQTH right after moving away from call column of new qso.
If it hapens so, then no more traffic in console and after a while Newqso releases (without anything happening in console) then it is a problem inside RPi, or cqrlog.
In my PC I see "freezing" sometimes when closing a window (mainly preferences). Then everything stops and if moving a window then it leaves traces that after few seconds clears away and everything works normally. I could imagine this happen also with RPi if it is very busy when writing to SD card.
--
Saku
OH1KH
Hi Saku,
thx for your reply.
I just tested out what you recommended.
I did several logs. Everything worked fine until I started to change my locator on each QSO. (I have to do so because I work as aeronautical mobile)
Again after about 3 logs cqrlog freezed for about 3-4 minutes. Here is what happened in the terminal window: After I hit the TAB key to come from the callsign field to the next one nothing happened in the terminal window. After 3-4 minutes of freeze the data came up in the terminal and cqrlog was released again.
Anything I should try next?
73 de Rico
DG5BQ
HI Rico!
To confirm that I understood ok you first set locator with ctrl+L then enter callsign and move to next field with Tab key. After few calls you do not see this kind of line in tcpdump when you have pressed tab to move away from callsign column ?
15:56:13.188322 IP hamtpad.36992 > hamqth.com.http: Flags [P.], seq 1:206, ack 1, win 502, options [nop,nop,TS val 1792262234 ecr 3366765730], length 205: HTTP: GET /xml.php?id=77d06c4354847571963ba4571249a2b4828bac83&callsign=OH1KH&prg=CQRLOG HTTP/1.0
Here I have logged my own call and this tcp dump is the equest that cqrlog sends to hamqth. In your similar line(s) you will see "callsign=" and the call you have entered.
This tcp packet have some other packets (in my case three) before it as Rpi must find HamQTH.com and open the connection for request.
This happen immediately you move away from callsign field. If no output at all at that point (not a single line) it is some kind of trouble within cqrlog, or Rpi.
I did many tests with random my_locators (different for every qso) but did not get this kind of error with my Fedora 33 PC. I have to prepare my RPi for more testing as it seems to be RPi specific problem.
--
Saku
OH1KH
Sorry Rico!
No luck with my RPi 4. It works flawlessly with the procedure you described.
Do you have a metal case for your RPi? And do you use RPi's internal WiFi?
In that case it may completely loose WiFi connection easily. Metal case drops internal WiFi adapters range to less than half compared with no case at all.
I have weak WiFi at my hamshack and I have to use external USB WiFi adapter (Edup) to get Wifi working. When plugging in that it will produce two wifis both connected to my router. How ever this makes unusable situation as internal Wifi can connect but does not carry traffic properly. That is why it must be disabled (wlan0) to get only USB dongle carried connect that then starts to work very good.
If you do not see any tcpdump packets at all when jumping away from callsign with TAB key it can be possible that your RPi can not reach your WiFi router at that point. Reconnect may then take some time.
So please check your Wifi if you are using it. If you are using wired ethernet then this can not happen.
--
Saku
OH1KH
Hi Saku,
today I entered another 15 QSOs into the log. Everything worked fine. The difference to the procedure I used the last times was that I didn't change my location via CTRL-L. So I assume that the problem lies there.
Does that help you finding an issue?
Rico
DG5BQ
One more thing:
While waiting the CPU usage is increased.
Hi Rico!
When cpu usage is increased, what takes the time?
From command console you see that with command:
top
[saku@tpad ~]$ top
top - 09:01:47 up 32 min, 0 users, load average: 0,12, 0,20, 0,15
Tasks: 205 total, 1 running, 204 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0,8 us, 0,6 sy, 0,0 ni, 98,3 id, 0,0 wa, 0,2 hi, 0,1 si, 0,0 st
MiB Mem : 3723,1 total, 1562,1 free, 897,4 used, 1263,6 buff/cache
MiB Swap: 9490,0 total, 9490,0 free, 0,0 used. 2471,9 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1068 root 20 0 778412 51904 24968 S 3,0 1,4 0:18.75 Xorg
1505 saku 20 0 1019864 37956 29784 S 0,7 1,0 0:04.24 lxpanel
1661 saku 20 0 294720 23736 19872 S 0,7 0,6 0:04.70 clipit
3536 saku 20 0 560480 37676 30000 S 0,7 1,0 0:00.50 lxtermi+
3571 saku 20 0 116492 4156 3508 R 0,7 0,1 0:00.14 top
--
Saku
OH1KH
Ok, now I was able to reproduce this issue running "top" in the background.
The first line of the listing showed:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1518 pi 20 0 149020 107572 31588 R 100,0 1,3 3:30.93 cqrlog
As mentioned before: It seems to come up once I change my loc for every QSO via CTRL-L. Another 13 or so entries without changing my loc worked just fine.
73,
Rico
OK Rico !
Yes, it really seems to eat 10% of cpu. I'm not specialist with ARM but in my quad core lenovo laptop 100% cpu load means just 1/4 load for cpu. I.E. on core at full load 3 others free.
But several cores do not help if you have too small ram. Then RPi must do swapping between SD card and RAM all the time and that makes everything slower.
My test RPI 4b has 4Gb ram (the largest model). Actually same amount as I have in this laptop I am now writing.
What "top" says about your swap usage (one of the fist lines: "Swap: 9490,0 total, 9490,0 free, 0,0 used.") during normal operation and at the time it is slowing down and how big is RAM in your Rpi?
--
Saku
OH1KH
Hi Saku,
I’m using the 8 GB model (this one is the biggest at the moment) with SSD hard drive. So no SD card.
73,
Rico
OK Rico!
Just trying to find a hook to be able to reproduce the action. Seems to be hard ;-( No luck so far.
--
Saku
OH1KH
What I do is the following:
I switch to "offline"
Then I type in the callsign,
hit the TAB key,
enter the report (where I type just one number in the SEND field),
tap TAB again,
hit CTRL-L to enter a different locator,
close this window with ENTER,
select the start time with the mouse,
enter the correct time,
hit TAB to get to the end time and enter it there.
Thereafter I save it with the ENTER key.
After doing this a couple of times the described issue comes up.
I try that again when time permits. Thanks!
--
Saku
OH1KH