Topics

Slow path to logging


Radio K0HB
 

I am experiencing what I think is exceptionally long transfer of contact information from WSJT-X to Log4OM via JTAlert.

 

Here’s my setup.  Computer is a very capable I7 windows machine, 16Gig RAM, SSD drive, running Windows 10.

 

Applications are the latest versions of JTAlert, WSJT-X, and Log4om.

 

Running just WSJT-X and Log4OM, the QSO travels from WSJT-X in a second or less.

 

Inserting JTAlert into the mix (with appropriate adjustments to UDP), every contact results in an error box that the contact may not have been logged.  I have adjusted the delay for that complaint out to 30 seconds, but it still happens.

 

Eventually (at around 35 seconds) the contact always DOES show up in Log4OM, suggesting the UDP path is good, but REALLY slow.

 

Any ideas?

 

73, de Hans, K0HB

 

 


Lawrence Godek
 

I had that same problem using an older version of Log4OM.  Lucky to make and log 2 QSO's in a minute or more.  With 2.11.0.0 logging is almost instantaneous.  I use WSJT 2.2.2 and JTAlert 2.16.17.  Computer is a WIN 7Pro with 16 GB ram and a regular 1 TB HD.  Nice to have quick logging working.

Larry W0OGH


On 2/17/2021 1:36 PM, Radio K0HB wrote:

I am experiencing what I think is exceptionally long transfer of contact information from WSJT-X to Log4OM via JTAlert.

 

Here’s my setup.  Computer is a very capable I7 windows machine, 16Gig RAM, SSD drive, running Windows 10.

 

Applications are the latest versions of JTAlert, WSJT-X, and Log4om.

 

Running just WSJT-X and Log4OM, the QSO travels from WSJT-X in a second or less.

 

Inserting JTAlert into the mix (with appropriate adjustments to UDP), every contact results in an error box that the contact may not have been logged.  I have adjusted the delay for that complaint out to 30 seconds, but it still happens.

 

Eventually (at around 35 seconds) the contact always DOES show up in Log4OM, suggesting the UDP path is good, but REALLY slow.

 

Any ideas?

 

73, de Hans, K0HB

 

 


Radio K0HB
 

Interesting.

 

My app versions:

 

Log4OM 2.11.0

WSJT-X 2.3.0

JTAlert 2.16.17

 

My WSJT-X is newer than yours, but this problem pre-dates that upgrade.

 

 

 

Sent from Mail for Windows 10

 

From: Lawrence Godek
Sent: Wednesday, February 17, 2021 20:44
To: Support@hamapps.groups.io
Subject: Re: [HamApps] Slow path to logging

 

I had that same problem using an older version of Log4OM.  Lucky to make and log 2 QSO's in a minute or more.  With 2.11.0.0 logging is almost instantaneous.  I use WSJT 2.2.2 and JTAlert 2.16.17.  Computer is a WIN 7Pro with 16 GB ram and a regular 1 TB HD.  Nice to have quick logging working.

Larry W0OGH

 

On 2/17/2021 1:36 PM, Radio K0HB wrote:

I am experiencing what I think is exceptionally long transfer of contact information from WSJT-X to Log4OM via JTAlert.

 

Here’s my setup.  Computer is a very capable I7 windows machine, 16Gig RAM, SSD drive, running Windows 10.

 

Applications are the latest versions of JTAlert, WSJT-X, and Log4om.

 

Running just WSJT-X and Log4OM, the QSO travels from WSJT-X in a second or less.

 

Inserting JTAlert into the mix (with appropriate adjustments to UDP), every contact results in an error box that the contact may not have been logged.  I have adjusted the delay for that complaint out to 30 seconds, but it still happens.

 

Eventually (at around 35 seconds) the contact always DOES show up in Log4OM, suggesting the UDP path is good, but REALLY slow.

 

Any ideas?

 

73, de Hans, K0HB

 

 

 


Michael Black
 

Exclude all of your ham software folders and data locations.
The antivirus programs are interfering with all sorts of ham stuff including logging QSOs

For Windows Defender: https://support.microsoft.com/en-us/help/4028485/windows-10-add-an-exclusion-to-windows-security

For example I exclude all of these
c:\Program Files (x86)\HamApps
c:\ProgramData\HamApps
c:\WSJT
%LOCALAPPDATA%\WSJT-X (and any other WSJT-X directories)
%HOMEPATH%\flrig.files
%HOMEPATH%\fldigi.files

Exclude your logging program and it's data files too.
For Log4OM and Log4OM2 I also have
%LOCALDATA%\LogOM
%APPDATA%\LogOM2

Mike W9MDB


On Wednesday, February 17, 2021, 02:36:22 PM CST, Radio K0HB <kzerohb@...> wrote:


I am experiencing what I think is exceptionally long transfer of contact information from WSJT-X to Log4OM via JTAlert.

 

Here’s my setup.  Computer is a very capable I7 windows machine, 16Gig RAM, SSD drive, running Windows 10.

 

Applications are the latest versions of JTAlert, WSJT-X, and Log4om.

 

Running just WSJT-X and Log4OM, the QSO travels from WSJT-X in a second or less.

 

Inserting JTAlert into the mix (with appropriate adjustments to UDP), every contact results in an error box that the contact may not have been logged.  I have adjusted the delay for that complaint out to 30 seconds, but it still happens.

 

Eventually (at around 35 seconds) the contact always DOES show up in Log4OM, suggesting the UDP path is good, but REALLY slow.

 

Any ideas?

 

73, de Hans, K0HB

 

 


HamApps Support (VK3AMA)
 

On 18/02/2021 7:36 am, Radio K0HB wrote:

I am experiencing what I think is exceptionally long transfer of contact information from WSJT-X to Log4OM via JTAlert.

 

Here’s my setup.  Computer is a very capable I7 windows machine, 16Gig RAM, SSD drive, running Windows 10.

 

Applications are the latest versions of JTAlert, WSJT-X, and Log4om.

 

Running just WSJT-X and Log4OM, the QSO travels from WSJT-X in a second or less.

 

Inserting JTAlert into the mix (with appropriate adjustments to UDP), every contact results in an error box that the contact may not have been logged.  I have adjusted the delay for that complaint out to 30 seconds, but it still happens.

 

Eventually (at around 35 seconds) the contact always DOES show up in Log4OM, suggesting the UDP path is good, but REALLY slow.

 

Any ideas?

 

73, de Hans, K0HB


Log4OM V2 is very slow (compared to Log4OM V1) for many of its logbook functions.

A 30 second delay in a new QSO appearing in the log is abnormal.

PC Protection software interference would not normally introduce that sort of delay in UDP traffic, at most a few milliseconds.
That sort of delay suggests that Log4OM is busy doing other processes post-logging before it finally writes the QSO to the log file (which is where JTAlert is looking to confirm the QSO is written).

Likely Log4OM is doing online log uploads, an XML lookup and updating its many internal award tracking database tables (my guess the award tracking updates is the most likely cause).

To mitigate Log4OM V2 slow logging, you can turn off JTAlert's logging confirmation check. If you are not seeing QSOs failing to be logged, that is they always appear despite the delays, turning off the QSO logged check is my recommendation. With this setting enabled, JTAlert will treat the logging as successful.



de Laurie VK3AMA


Radio K0HB
 

I ran some experiments, Laurie, and it appears that JTAlert is involved.

 

First, as a benchmark, I took JTAlert offline and logged directly from WSJT-X to Log3OM.

 

From the time I pressed “Log it” until the QSO arrived in Log4OM took a second or two.  This result is consistent.

 

Then I put JTAlert back in the app lineup (with appropriate UDP settings).

 

Then I did 4 experiments, each one twice to check consistency.

 

  1. I turned off the check as per your message below.  Two QSO’s each took about 10 seconds to arrive.
  2. I turned the check back on, with a wait of 5.  Two QSO’s each took about 25 seconds.
  3. Increased the wait to 10.  30 seconds elapsed.
  4. Increased the wait to 20.  About 50 seconds elapsed.

 

So it seems that JTAlert, even without the check, adds some (tolerable) delay.

 

Then, increasing the “time before check” also increases the travel time to Log4OM.

 

For now, I will turn off the check as you recommend, as the delay in that condition is tolerable.

 

73, de Hans, K0HB

 

 

From: HamApps Support (VK3AMA)
Sent: Wednesday, February 17, 2021 22:15
To: Support@hamapps.groups.io
Subject: Re: [HamApps] Slow path to logging

 

On 18/02/2021 7:36 am, Radio K0HB wrote:

I am experiencing what I think is exceptionally long transfer of contact information from WSJT-X to Log4OM via JTAlert.

 

Here’s my setup.  Computer is a very capable I7 windows machine, 16Gig RAM, SSD drive, running Windows 10.

 

Applications are the latest versions of JTAlert, WSJT-X, and Log4om.

 

Running just WSJT-X and Log4OM, the QSO travels from WSJT-X in a second or less.

 

Inserting JTAlert into the mix (with appropriate adjustments to UDP), every contact results in an error box that the contact may not have been logged.  I have adjusted the delay for that complaint out to 30 seconds, but it still happens.

 

Eventually (at around 35 seconds) the contact always DOES show up in Log4OM, suggesting the UDP path is good, but REALLY slow.

 

Any ideas?

 

73, de Hans, K0HB


Log4OM V2 is very slow (compared to Log4OM V1) for many of its logbook functions.

A 30 second delay in a new QSO appearing in the log is abnormal.

PC Protection software interference would not normally introduce that sort of delay in UDP traffic, at most a few milliseconds.
That sort of delay suggests that Log4OM is busy doing other processes post-logging before it finally writes the QSO to the log file (which is where JTAlert is looking to confirm the QSO is written).

Likely Log4OM is doing online log uploads, an XML lookup and updating its many internal award tracking database tables (my guess the award tracking updates is the most likely cause).

To mitigate Log4OM V2 slow logging, you can turn off JTAlert's logging confirmation check. If you are not seeing QSOs failing to be logged, that is they always appear despite the delays, turning off the QSO logged check is my recommendation. With this setting enabled, JTAlert will treat the logging as successful.



de Laurie VK3AMA

 


HamApps Support (VK3AMA)
 

On 18/02/2021 10:28 am, Radio K0HB wrote:

I ran some experiments, Laurie, and it appears that JTAlert is involved.

 

First, as a benchmark, I took JTAlert offline and logged directly from WSJT-X to Log3OM.

 

From the time I pressed “Log it” until the QSO arrived in Log4OM took a second or two.  This result is consistent.

 

Then I put JTAlert back in the app lineup (with appropriate UDP settings).

 

Then I did 4 experiments, each one twice to check consistency.

 

  1. I turned off the check as per your message below.  Two QSO’s each took about 10 seconds to arrive.
  2. I turned the check back on, with a wait of 5.  Two QSO’s each took about 25 seconds.
  3. Increased the wait to 10.  30 seconds elapsed.
  4. Increased the wait to 20.  About 50 seconds elapsed.

 

So it seems that JTAlert, even without the check, adds some (tolerable) delay.

 

Then, increasing the “time before check” also increases the travel time to Log4OM.

 

For now, I will turn off the check as you recommend, as the delay in that condition is tolerable.

 

73, de Hans, K0HB

 


Hans,

Your comparing Apples to Oranges. WSJT-X -> Log4 direct logging compared to WSJT-X -> JTAlert -> Log4 logging via the Log4OM TCP logging interface which I assume uses a different pipe-line through the Log4 code.

What Log type are you using in Log4OM V2? SQLite or MySQL? How many records does it contain?

If you have JTAlert logging confirmation checks turned off and your getting 10 second delays before the QSO gets written to the log, those delays are coming from Log4OM. Perhaps it is delayed while it does its post logging processing for QSOs logged via its TCP interface only. I don't know, that is speculation.

I would like to see some of the timings that JTAlert records in its debug file to reassure myself that JTAlert is not introducing delays. Please do the following...
  • Enable debug recording via the JTAlert "Settings -> Enable Debug Recording" menu.
  • Restart JTAlert.
  • With the "Do not check or report logging success/failure" checkbox ticked, log a QSO.
  • After the QSO has been logged and appeared in the Log4OM log you can turn off the debug recording.
  • Then use the "Help" -> "Contact Support" menu, on the main JTAlert window, to send me your JTAlert files for analysis. Pleas include a note of the Callsign logged.

de Laurie VK3AMA



Radio K0HB
 

File enroute.


Radio K0HB
 

Forgot to include:

 

Using SQLite, and my log size is about 98,000 QSO’s.

 

 

Sent from Mail for Windows 10

 

From: HamApps Support (VK3AMA)
Sent: Thursday, February 18, 2021 00:14
To: Support@hamapps.groups.io
Subject: Re: [HamApps] Slow path to logging

 

On 18/02/2021 10:28 am, Radio K0HB wrote:

I ran some experiments, Laurie, and it appears that JTAlert is involved.

 

First, as a benchmark, I took JTAlert offline and logged directly from WSJT-X to Log3OM.

 

From the time I pressed “Log it” until the QSO arrived in Log4OM took a second or two.  This result is consistent.

 

Then I put JTAlert back in the app lineup (with appropriate UDP settings).

 

Then I did 4 experiments, each one twice to check consistency.

 

  1. I turned off the check as per your message below.  Two QSO’s each took about 10 seconds to arrive.
  2. I turned the check back on, with a wait of 5.  Two QSO’s each took about 25 seconds.
  3. Increased the wait to 10.  30 seconds elapsed.
  4. Increased the wait to 20.  About 50 seconds elapsed.

 

So it seems that JTAlert, even without the check, adds some (tolerable) delay.

 

Then, increasing the “time before check” also increases the travel time to Log4OM.

 

For now, I will turn off the check as you recommend, as the delay in that condition is tolerable.

 

73, de Hans, K0HB

 


Hans,

Your comparing Apples to Oranges. WSJT-X -> Log4 direct logging compared to WSJT-X -> JTAlert -> Log4 logging via the Log4OM TCP logging interface which I assume uses a different pipe-line through the Log4 code.

What Log type are you using in Log4OM V2? SQLite or MySQL? How many records does it contain?

If you have JTAlert logging confirmation checks turned off and your getting 10 second delays before the QSO gets written to the log, those delays are coming from Log4OM. Perhaps it is delayed while it does its post logging processing for QSOs logged via its TCP interface only. I don't know, that is speculation.

I would like to see some of the timings that JTAlert records in its debug file to reassure myself that JTAlert is not introducing delays. Please do the following...

  • Enable debug recording via the JTAlert "Settings -> Enable Debug Recording" menu.
  • Restart JTAlert.
  • With the "Do not check or report logging success/failure" checkbox ticked, log a QSO.
  • After the QSO has been logged and appeared in the Log4OM log you can turn off the debug recording.
  • Then use the "Help" -> "Contact Support" menu, on the main JTAlert window, to send me your JTAlert files for analysis. Pleas include a note of the Callsign logged.

de Laurie VK3AMA

 

 


Micky Corrow
 

Nice call Mike on the exclusions.
That worked miracles on my older slow system.

Micky K1XH


HamApps Support (VK3AMA)
 

On 18/02/2021 12:29 pm, Radio K0HB wrote:
File enroute.
Files received.

All looks perfectly normal. A total of 88 ms between when JTAlert receives the QSO logged UDP message from WSJT-X and when JTAlert has vinished sending the logging instruction to Log4OM. Note the 3 highlighted entries from the debug file.

@ 01:26:26:915 the RR73 decode from KS4OT received.
@ 01:26:31:650 the Logged QSO UDP message received from WSJT-X
@ 01:26:31:738 The Log4OM log TCP instruction had finished (662 bytes sent).

In the 88ms between when JTAlert received the logged QSO message from WSJT-X and when JTAlert has finished sending the TCP message to Log4OM JTAlert gathers the log field data (_Read_Log_Data instruction), combines that data with what came from WSJT-X (_Set_Log_Data instruction) clears & sets the B4 Cache for K4SOT and writes the single adif entry record to disk (_write_singleqso_log entry).



de Laurie VK3AMA


HamApps Support (VK3AMA)
 

On 18/02/2021 12:31 pm, Radio K0HB wrote:

Forgot to include:

 

Using SQLite, and my log size is about 98,000 QSO’s.


98K records should not be a problem. I routinely run multi-million record sqlite files for testing purposes.

I wonder if there is something unusual within your Log4OM comms setup for receiving logging instructions from JTAlert. Is it setup correctly, per the JTAlert Help file,

"Settings -> Logging -> Log4OM V2" section.

Can you provide a screen-capture of your Log4OM settings? It should look something like this...


And the correct JTAlert setup like this...


de Laurie VK3AMA


Radio K0HB
 

Thanks for “hanging with me” on this Lauri.

 

Here are those screen shots.

 

 

 

Notice on the Log4OM “Configuration screen” I have an additional inbound at port 1240, not seen on your example.  I have unchecked that, and then nothing arrives at Log4OM.  So I’ve left it checked.

 

So here is where I’m at.

 

If I check the “Do not check or logging success/failure”, then I get acceptable transfer to Log4om, with about 6-9 seconds transit time.  This condition is acceptable to me.

 

If I uncheck that box, I get increased delay, and that delay can be influenced by increasing the “Check QSO Log Record” delay time.  At the lowest setting (5 seconds) the transit time is around 20 seconds.  At the 20 second setting the transit time is nearly a minute.

 

Since the “Do not check…..” option gives me acceptable performance, I’m willing to “drop the case” as some quirk at my end,  or continue to work with you if you would like.

 

73, Hans, K0HB

 

 

From: HamApps Support (VK3AMA)
Sent: Thursday, February 18, 2021 03:45
To: Support@hamapps.groups.io
Subject: Re: [HamApps] Slow path to logging

 

On 18/02/2021 12:31 pm, Radio K0HB wrote:

Forgot to include:

 

Using SQLite, and my log size is about 98,000 QSO’s.


98K records should not be a problem. I routinely run multi-million record sqlite files for testing purposes.

I wonder if there is something unusual within your Log4OM comms setup for receiving logging instructions from JTAlert. Is it setup correctly, per the JTAlert Help file,

"Settings -> Logging -> Log4OM V2" section.

Can you provide a screen-capture of your Log4OM settings? It should look something like this...


And the correct JTAlert setup like this...


de Laurie VK3AMA

 


Laurie, VK3AMA
 



On 18/02/2021 5:16 pm, Radio K0HB wrote:

Thanks for “hanging with me” on this Lauri.

Notice on the Log4OM “Configuration screen” I have an additional inbound at port 1240, not seen on your example.  I have unchecked that, and then nothing arrives at Log4OM.  So I’ve left it checked.


If unchecking the port 1240 setting stops logging that indicates that the logging is happening via that port and not via the configured JTAlert port 2335.

You have port 1240 listening to the JTAlert UDP resend (I guess that is it, 1240 is an unusual number, the default is 2334) of the WSJT-X UDP traffic. That is how Log4OM is picking up on the logging event. It also means that any additional log data you have entered in the JTAlert Log Fields area will not be getting logged. You can quickly check that by entering some unique string for the QSO partners name in the Log Fields of JTAlert and observing if that unique string gets logged. Based on your screen-captures and my interpretation of the problem it will not get logged.

There is never any need to have Log4OM listening to the JTAlert UDP resend traffic. Turn it off.

Your problem is that your JTAlert settings do not match the Log4OM settings.
  • You have the JTAlert inbound connection set to port 2235 in Log4OM.
  • You have the ADIF_Message port set to port 2335 in JTAlert.
The ports need to match. Set Log4OM to use port 2335 and turn off the port 1240 inbound connection.

How does that work now?

de Laurie VK3AMA


Radio K0HB
 

 

From: Laurie, VK3AMA
Sent: Thursday, February 18, 2021 06:40
To: Support@hamapps.groups.io
Subject: Re: [HamApps] Slow path to logging

 



Your problem is that your JTAlert settings do not match the Log4OM settings.

  • You have the JTAlert inbound connection set to port 2235 in Log4OM.
  • You have the ADIF_Message port set to port 2335 in JTAlert.

The ports need to match. Set Log4OM to use port 2335 and turn off the port 1240 inbound connection.

How does that work now?

de Laurie VK3AMA

 

That was it Laurie!  A bloody typo!

I can’t count how many times I examined those port numbers and didn’t catch it.

I sincerely apologize for wasting hours of your time, chasing a TYPO!

Again, I apologize, but appreciate your persistence.

 

73, de Hans, K0HB