[comp.sys.atari.st] Clock priority?

buggs@cup.portal.com (William Edward JuneJr) (12/14/90)

Here's question from another net, sure would appreciate any/all replies.

\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

Conf : FoReM Sysop's Support
Msg# : 5643  Lines: Extended  Read: 1
Sent : Dec 9, 1990  at 8:38 PM
To   : ALL
From : DAVID CHIQUELIN at Node 3  Atari-OH! in Houston,
Subj : Connect rates



When the mailer started out there was no HST and no Fixed Link.  Since a
calling mailer often connects to the BBS first and the BBS runs the
mailer, there is no CONNECT message to read.  So I have the calling mailer
(which at that time always knew the baud rate of the call) pass the
information to the called node for reporting purposes.  That works fine
until you start running Fixed Link...

With fixed link the baud rate is never changed.  It always stays at 19200.
The modem-modem rate may change, but as far as the mailer is concerned the
rate doesn't change, and really doesn't matter.  It would be possible to
read the CONNECT message with the dialing out mailer, but even then it
might not be all that accurate when Fixed Link is used.  (A connect 2400
to an MNP modem, so that the transfer rate ends up being higher than 2400)
And I am not about to try to handle all the possible CONNECT type messages
that the different modems can display.  The only attempt to read those
messages is when a mailer dials in while the mailer is trying to dial out.
Then it will look at the message if it can, but the baud rate for reporting
purposes is still what the calling in mailer says it is.

The bottom line, right now, is that the baud rate reporting is not going
to be accurate when nodes are using fixed link, and is a "gee whiz" report
anyway that is not even needed.  The CPS reporting is as accurate as the
ST's system clock and TOS allows it to be.  It counts the ACTUAL bytes
received and divides by the ACTUAL time as reported by the 200 hz system
clock.  Unfortunately some versions of TOS set the system clock priority
low, so that the clock losses time during serial port usage (and probably
hard drive activity).  If someone tells me how I can modify the program so
that EVERY version of ST, including those with no hardware clock, can get
an accurate time that is of high resolution, then I'll change the program.

                David C.


Conf : FoReM SysOps' Conference (Xnet)
Msg# : 4095  Lines: 18  Read: 4
Sent : Dec 11, 1990  at 8:59 PM
Recv : Dec 13, 1990
To   : ED JUNE
From : DAVID CHIQUELIN
Subj : Re: <4076> Connect rates

 In message 3/15/4076, ED JUNE writes:

 >
 > Hey Dave,
 >
 > My I poST your question on UseNet? Maybe someone from Atari <Allan Pratt or
 >  John Townsend> will reply, eh?
 >
Sure, you can ask about how to change the priority for the clock, if you
REALLY think that added accuracy is worth the slowdown in data transfer...
I figure Atari must have decided the clock can miss a few cycles to enable
higher actual cps rates rather than having the serial port pause while the
clock was updated.

Since the cps rate is not a necessary item, I'm not sure how much we want
to slow the system down to get it accurate...  But a lot of people DO
complain about inaccurate cps reporting, so maybe it is worth it to them.

               David C.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\