Rick,

I converted my TASK to a FORKS()> implementation, and it solved the
problem. Now my COM monitor can keep up with the input data. Many
thanks! :-D

The conversion to FORKS()> was quick and non-problematic. I also put the
100 Sleep back in. Surprisingly, a 500 Sleep could not allow my code to
keep up with the 9,600 baud input rate.

I hope that SwiftForth adds this to chapter 7 of their Windows Manual,
since the difference between FORKs and TASKs is so significant.

Now I must silence the "H." screen IO for the turn-key application.

Thanks again,
Pedro

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

Pedro,

The problem with how long it takes in a TASK is related to the
implementation
of PAUSE in the system. PAUSE incorporates a sleep, which is why the
delay
is so long. Other applications using PAUSE might be more prone to high
cpu utilization, but response time is directly related to this.

Rick

On Thu, 26 Jun 2003 17:41:05 -0400, Pedro Monteiro <pm_at_entropylock.com>
wrote:

> 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 Fri Jun 27 2003 - 13:39:50 PDT