Log4OM

I was using Log4om v2 for the recent ARRL Sweepstakes SSB contest. I noticed that with a relatively heavy cluster load the the program would "hang up" if you would double click on a spot. Instead of quickly changing the transceiver frequency to the spot frequency and entering the call sign in the call sign field immediately the program would sit and do nothing for a significant time ranging from a couple to upwards of 10 seconds.

Sometimes the frequency on the transceiver would change and sometimes it wouldn't and often taking many seconds. Often the frequency would change but would be wrong because new spots arrived between the double click and the action taking pace. The callsign may or may not appear in the call sign box. Again, this could take 10 seconds.

I'm very convinced that this is not due to an underpowered PC but rather is a coding or design issue. It seems like the "process" for changing transceiver frequency and populating the call sign box is getting hung up and is waiting for something else to happen.

The other issue I noticed was that when I double clicked on a recent QSO in order to edit the entry, the hourglass would appear and it would take 10 or so seconds for the entry box to appear and another 5 or so seconds to slowly populate.

If I would click on the SDRuno waterfall display, the transceiver would immediately respond with the new frequency.

I killed other programs such as SDRuno, Edge etc to reduce the CPU load but this did not have any noticeable impact.

I was running version 2.9.0.0 of Log4om2 on a Windows 10 machine with 8 gigs RAM and a SS drive.
CPU utilization ranged from 22% to 45%
RAM useage was 51%
SS activity was near 0.

I was also running SDRUno and OmniRig with an Icom 7300

I started the contest with a new data base so that the maximum number of logged QSOs in the data base was less than 130.

VOCAP was not enabled

VE7CC-1 was the one and only cluster server

Cluster filter was Phone, single band selected, Spot from NA

The bottom line is that this is almost certainly not an issue of PC horsepower but rather an issue of coding efficiency or more likely one process hanging waiting for something else unnecessarily. I know that Log4om is not geared to contesting however, I don't think that is the issue.

Ray Mikula
W9NZ

I also experience this. Will the team give a response.

Hi, it is definitely not a low resource problem on PC. Even with little activity in the cluster, at times the response almost freezes.In my case Win10, AMD 6 cores processor and 8Gb RAM, the CPU load does not exceed 20-25%
I agree with Ray: "... an issue of coding efficiency or more likely one process hanging waiting for something else unnecessarily ..."
It will surely be resolved in future versions.

73
Jorge LU1DA

The issue is probably due to the cluster refresh activity, that "locks" the grid for the time needed to update. During those "lock times" the grid may be unresponsive. The amount of spot updates affects the refresh roundtrips
I'm searching for a solution

Locking makes sense as a possible cause. This behavior seems to hit me hardest during a contest, so it also makes sense that it's related to the number of active spots. If so, it would be nice if it could lock for writes/updates only, while still allowing existing spots to be read and used freely.

Craig, KX4M

Hello, but is it correct that the process uses 600-700 MB of RAM and above ?? it seems to me really excessive !!!
It could also be why there are these big slowdowns.

73? de Marco IW2EJM

now peaks of 1.3 Gb ...
ranges from 300Mb to 1.2 / 1.3GB with approximately 10 seconds to switch to the selected frequency on the cluster and fill in the log input mask or to filter bandwidth on the cluster.
windows 10 64 bit, i5 with 4 Gb ram.
I also tried to re-install LOG4Om V2 but nothing changes.
73' de Marco IW2EJM