Re: Background COM port task very slow

Rick,

Thank you for your insight. In spite of running a background TASK that
won't keep up with 9600 baud, my CPU usage is still around 5% after
ACTIVATEing the COM port monitor TASK. If my CPU can't keep up with the
COM port stream due to multitasking issues, then why hasn't my CPU
utilization climbed to 100%? Why is my "Systen Idle Process" still using
so much time?

I don't know enough to question your advice, but I would like understand
that point before I venture into unfamiliar territory and FORK up my
code into threads. ;-)

I presume I can still communicate with the FORKed code via shared
variables? I'd like to avoid learning how to send messages back and
"forth" between threads.

Pedro
P.S. Sorry about the puns; I couldn't resist...

-----Original Message-----
From: sftalk-bounce_at_forth.com [mailto:sftalk-bounce_at_forth.com] On Behalf
Of Rick VanNorman
Sent: Thursday, June 26, 2003 5:07 PM
To: sftalk_at_forth.com; sftalk_at_forth.com
Subject: [sftalk] Re: Background COM port task very slow

Pedro,

Bob, although he declines to admit it, was dead on. The problem is that
you are running a task instead of a thread. Windows OS is designed for
pre-emptive multitasking; FORTH historically was not. The original goal
in SwiftForth was to maintain that historical compatability, and it was
a difficult fit. As a result, using a TASK is a poor way to share
the cpu resource in a single application. This is why I implemented the
FORKS> concept.

A thread, especially one that waits for a serial character to arrive by
using a blocking read operation, will be extremely efficient in both cpu
usage and response time.

Rick

On Thu, 26 Jun 2003 13:44:41 -0700, Bob Nash <BNash_at_smud.org> wrote:

> Tasks vs. Threads -- no, not suggesting that is the problem, but a =
> better way to go. FYI, TASK allocates a minimum of 16,384. I don't =

> think priority is the problem.
>
> -----Original Message-----
> From: Pedro Monteiro [mailto:pm_at_entropylock.com]
> Sent: Thursday, June 26, 2003 1:32 PM
> To: sftalk_at_forth.com
> Subject: [sftalk] Re: Background COM port task very slow
>
>
> The background task had a Sleep in it, but I removed it when things
> were running slowly, and relied instead upon the PAUSE inside
> (COM-KEY). It seems to have not made a difference.
>
> Yes, I am running this from the console, and I do plan to port it to a

> turnkey app. On your suggestion, I am looking into using threads
> instead of tasks.=20
>
> Are you suggesting that a Thread will run faster than a TASK? Why is
> the task so slow? Did I overlook something, or are TASKs this slow by
> default, and I must use some mystery words to speed my TASK up (e.g.
> change the thread priority)?
>
> Thanks for your help,
> Pedro
>
> -----Original Message-----
> From: sftalk-bounce_at_forth.com [mailto:sftalk-bounce_at_forth.com] On
> Behalf Of Bob Nash
> Sent: Thursday, June 26, 2003 3:48 PM
> To: sftalk_at_forth.com
> Subject: [sftalk] Re: Background COM port task very slow
>
>
> I assume GET-1GPS-REC in the background task has a sleep (or a timed
> =3D character wait with a sleep) in it. You are running this from the

> =3D console, right? Suggest using forks> and TerminateThread for
> turnkeyed =3D app.
>
> -----Original Message-----
> From: Pedro Monteiro [mailto:pm_at_entropylock.com]
> Sent: Thursday, June 26, 2003 11:56 AM
> To: sftalk_at_forth.com
> Subject: [sftalk] Background COM port task very slow
>
>
> Problem:
> TASK runs too slowly in background, but runs fine in foreground. I
> will be grateful for any advice.
>
> I have a background task that monitors the COM port for GPS data, and
> parses it into variables. When I run the parser in the foreground, the

> variables are updated as they become available on the COM port.
> However, when I run the same parser code in the background, the
> variables are updated once every two or three seconds. The serial
> buffer then grows in size, filling up with a backlog of COM port data
> that the GPS sent once per second.
>
> If I instead run the parser in the foreground, it quickly reads the
> backlogged COM port data, catching up to the real-time GPS records.
>
> - The GPS data is less than 400 bytes, sent at 9,600 baud, once each
> second.
> - SwiftForth 2.2.2.9 07May2001
> - Windows 2000
> - Reading COM port with COM-KEY from SIO.F
> - Processor usage is around 5% with background parser running.
> - A foreground task that prints the parsed variables to the SwiftForth

> console raises to 100%, when the parser is running in the FOREGROUND.
> - A foreground task that prints the parsed variables to the SwiftForth

> console varies between 70-100%, when the parser is running in the
> BACKGROUND.
> - While the foreground process is not running, the background process
> should catch up to the data with no display semaphores to possibly
> slow it down. In any case, commenting out the semaphores did not
> change the update rate.=3D20
>
> The code below shows that both the foreground word (GFR)=3D20 and the
> background word (START-GPS-MONITOR)=3D20 call the same GPS parser code

> (GET1GPS-REC).
>
> Could the Windows process priority be set too low? How do I change
> it?=3D20 How do I get GPS-MONITOR to be listed in Windows Task
> Manager?
>
> Any advice will be greatly appreciated. Thanks,
> - Pedro
>
> ----------------------------------------------------------
> : GFR ( -- ) \ get GPS record then print until key pressed
> ZERO-COUNTERS BEGIN
> GET1GPS-REC
> .GPS-RECS
> EKEY? UNTIL
> ; \ GPS-FIND-REC
>
> 8192 TASK GPS-MONITOR \ set up a background task
>
> : START-GPS-MONITOR ( -- ) \ parse each record from GPS into vars
> until killed ZERO-COUNTERS
> GPS-MONITOR ACTIVATE=3D20
> BEGIN
> GET1GPS-REC
> AGAIN
> ; \ START-GPS-MONITOR=3D20
>
> : .GPS ( -- ) \ getting GPS record in background. Now print until key
> pressed 0 GPSUPDATE# !
> BEGIN
> .GPS-RECS
> GPSUPDATE# @ 1+ DUP CR . GPSUPDATE# !
> 200 Sleep DROP
> EKEY? UNTIL
> ;

----------------------------------------------------------------------
sftalk_at_forth.com The SwiftForth programming discussion email list
To unsubscribe, send subject "unsubscribe" to sftalk-request_at_forth.com
For list command help, send subject "help" to sftalk-request_at_forth.com
Message archives are located at http://www.forth.com/archive/sftalk
----------------------------------------------------------------------
This list is a forum for SwiftForth users. For product support and bug
reports, please send email to support_at_forth.com
----------------------------------------------------------------------
Received on Thu Jun 26 2003 - 14:43:55 PDT