locked Re: PC changes to speed up JTAlert

HamApps Support (VK3AMA)

On 25/01/2019 1:38 am, Ed wrote:

What is the execution bottleneck in JTAlert processing? Is it I/O bound with regard to my disk drive? Would the best way to reduce overall response time be to use a solid state disk drive? Or am I off track and some other aspect of the program is holding upĀ  the response time?

Thanks & 73,


There is no real disk-access bottleneck, except for the delay at startup as config data is read into memory.

There is also disk-access delays where querying your log file for each decoded callsign. This can add a second or two when the band is very busy, BUT, JTAlert mitigates the effect of these log lookup times by caching in memory the results of a lookup. This way there is only one disk-based lookup for each unique callsign encountered during a JTAlert session. This affect can be seen when first starting JTAlert when all callsigns are new and don't have a memory-cached record.

What response time are you trying to minimize? Is it the time between when WSJT-X has produced decodes and when JTAlert displays the Callsigns? What sort of delay are you seeing? If your trying to get JTAlert to display Callsigns within the short 2 second window at the end of a FT8 period, that is unlikely especially with a band full of signals.

de Laurie VK3AMA

Join Support@HamApps.groups.io to automatically receive all group messages.