Topics

Recurring issue: awards recompute slows down to a crawl

Jan AE7U
 

Hi Everyone:

My DXKeeper awards recompute function used to be "instantaneous", but now it is very slow.  Here is one data point: QSO ends 13:37:00; recompute finishes 13:40:00.  While the recompute is going on, the log is inaccessible.  I had this problem before and it seemed to have self-rectified after installing the latest version of all software, but now the problem is back.  All the software is up to date and Windows 10 has the latest updates installed.  

I don't know if this problem is related to the fact that my JTAlert automatic logging to DXKeeper stopped working after I upgraded to Windows 10 a month or so ago?  

I suspect though, that Windows 10 is the culprit here, but I would not know where to start to fix these problems?

Dave AA6YQ
 

+ AA6YQ comments below

My DXKeeper awards recompute function used to be "instantaneous", but now it is very slow. Here is one data point: QSO ends 13:37:00; recompute finishes 13:40:00. While the recompute is going on, the log is inaccessible. I had this problem before and it seemed to have self-rectified after installing the latest version of all software, but now the problem is back. All the software is up to date and Windows 10 has the latest updates installed.

I don't know if this problem is related to the fact that my JTAlert automatic logging to DXKeeper stopped working after I upgraded to Windows 10 a month or so ago?

I suspect though, that Windows 10 is the culprit here, but I would not know where to start to fix these problems?

+ As a first diagnostic step, reboot Windows into "safe mode with networking", start DXKeeper, and take an action that initiates recomputation; any change in the time required?

73,

Dave, AA6YQ

Jan AE7U
 

Dave, I rebooted into safe mode and tested DXKeeper as a standalone (as I cannot get my normal configuration running as virtual serial ports are also disabled in safe mode). On logging a QSO, the recomputation is instantaneous.  On deleting a QSO, the recomputation is very fast - less than a second.   After rebooting back into the normal mode, I tested DXKeeper as a standalone - to compare apples with apples - and I got the same results as above.  However, once I hook everything up together, the speed issue is is back.

My basic setup is: TS590s -> COM3 (virtual port) -> COM1 (VSPE splitter) -> Commander (via DXLabsuite interface) -> WSJT-X <- JTAlert.

P.S. I also tried running without any ancillary programs e.g. SDRUno with additional instances of WSJT-X,  but it makes no difference to the speed issue.

73's, Jan, AE7U

Dave AA6YQ
 

+ AA6YQ comments below

Dave, I rebooted into safe mode and tested DXKeeper as a standalone (as I cannot get my normal configuration running as virtual serial ports are also disabled in safe mode). On logging a QSO, the recomputation is instantaneous. On deleting a QSO, the recomputation is very fast - less than a second. After rebooting back into the normal mode, I tested DXKeeper as a standalone - to compare apples with apples - and I got the same results as above. However, once I hook everything up together, the speed issue is is back.

+ That's hard evidence that an application automatically started when Windows is booted "normally" is responsible for the slowdown. The culprit is almost always an incompetent or incorrectly configured firewall or anti-malware application. You must configure these applications to consider your DXLab applications to be "safe". If you've already done that, then the applications in question are defective, and should be replaced with something that provides protection without preventing your DXLab applications from interoperating.

73,

Dave, AA6YQ

Jan AE7U
 

I don't use anti-malware or anti-virus programs, except for the built-in Windows 10 functionalities.  However, since I added all my ham radio app directories as well as exe's as exclusions in Windows Defender; the speed has improved to the point of practicality.

Thank you. 

Jan, AE7U