locked Re: Keyboard latency with multiple JTAlert processes running.


Bill Barrett
 

Hello Mike-
The timings reported by this routine are the same with multiple JTAs running or none.
The problem is after the keyboard interrupts are captured they get stacked up somewhere and released in batches.
Bill W2PKY

On Sat, Sep 26, 2020 at 9:18 AM Michael Black via groups.io <mdblack98=yahoo.com@groups.io> wrote:
Try this website and start flicking keys.  It will tell you the key down time it sees.
I found flicking a cursor key worked pretty well to get 1ms times frequently.

Also check these settings...in particular the bounce time.
And I found this utility which may be of use in diagnosing things
Inline image


Mike W9MDB


On Saturday, September 26, 2020, 07:10:10 AM CDT, Bill Barrett <billbarrett174@...> wrote:


Tom-
The PC CPU is only stressed during the decode period. Otherwise the
CPU is 93% idle.
WSJT-X and JTA take almost no CPU power during the sampling process.
The keyboard slow down is noticed anytime.
I'm sure Laurie will determine the cause and correct the problem now
that it's been uncovered.
Since most users do not run more than one instance of JTA and "X" they
do not notice the problem.
Bill W2PKY

On Sat, Sep 26, 2020 at 1:57 AM TomK <QSO@...> wrote:
>
> From the FWIW (For What It's Worth) depart.
> Sorry, if you know this, it have help others understand CPU loading issues.
>
> WSJT and JTA present X-Large and Large processor task loads.
> For JTA alone, think about the high message rate to display, lookup, resolve, flag, audio alert ... whoa!
>
> As processes consume PC cycles, other processes are obviously given less time.
> Moreover, a keyboard is an interrupt-driven task.
> When you click a key, interrupts are thrown, the BIOS passes it to the OS.
> It then passes control to an interrupt handler which passes control to registered s/w handlers.
> The registered interrupt handlers do their things then finish (consuming more CPU cycles).
> Only at a logically high level, are interrupts "asynchronous".
> The reality is that multiple interrupts may asynchronously trig interrupt handlers.
> However, once those handlers start to execute, the same CPU's cycles are consumed for all tasks.
> At each CPU's level, you have synchronous code streams.
> Multicore CPUs can ameliorate that but their allocations are seldom what an app would like.
> While all that is happening, the CPU is still being interrupted 6 ways from Sunday.
> So, with all that intense backdrop, you still have intense CPU tasks to execute.
>
> So, a keyboard should and will slow down when the CPU is already heavily occupied and can't process all the interrupts.
> Add 2, 3, or more JTA's and/or WSJT and it all gets that much worse.
>
> The fact that NOT running any JTA instances makes your k/b faster seems entirely logical and expected.
>
> I only suspect empirically, without seeing the code, that JTA doesn't do a lot of k/b interrupts itself.
>
> In short, it's bloody amazing that a PC can handle the intense FFT's in WSJT as well as all that JTA does.
>
> Just my 13 cents
> TomK KT1TK 73
>
>
> -----Original Message-----
> From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of Bill Barrett
> Sent: Friday, September 25, 2020 7:42 AM
> To: Support@hamapps.groups.io
> Subject: Re: [HamApps] Keyboard latency with multiple JTAlert processes running.
>
> Hello Laurie-
>
> I have noticed this for a long time. Never knew what caused it. Always assumed it was due to running multiple instances of WSJT-X.
> The reason Flex users notice it is because we have multiple slices and run multiple instances of WSJT-X.
> The keyboard delay is definitely related to using JTAlert. Without JTAlert the keyboard response if fast.
> In my case with the 6700 can run as many as 8 instances of "X" and JTAlert. Then the keyboard response seems stacked up.
> When pressing down on the left or right arrow key may take a second before there is a response on the screen and then the cursor moves several positions.
> Hard to tell where the interference is happening, however, seems like the keyboard interrupt handler is stalled.
> Hope this helps.
> Bill W2PKY
>
>
> On Thu, Sep 24, 2020 at 10:44 PM HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:
> >
> > On 23/09/2020 6:54 am, Patrick Skerrett wrote:
> >
> > Has anyone encountered this before?
> >
> > I am running version 2.16.13 of jtalert, 2.2.2 of WSJT-x and 15.8.0 of Dxkeeper.
> >
> > W9PDS
> >
> >
> > Has this always been a problem with your Flex and multi-instance JTAlert or is it a recent manifestation? If it is recent, what was the last version of JTAlert that didn't exhibit this behavior?
> >
> > de Laurie VK3AMA
> >
> >
> >
>
>
>
> --
> Bill Barrett
> 352-437-4758
>
>
>
>
>
>
>
>
>
>
>
>


--
Bill Barrett
352-437-4758







--
Bill Barrett
352-437-4758

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