RTC precision?

[DoN Nichols]

In article <1991Feb28.160950.7042 at sci.ccny.cuny.edu> jeffrey at sci.ccny.cuny.edu (Jeffrey L Bromberger) writes:

	[ ... ]

>Another thing that seems fishy regarding the WIN/TCP software.   Timed
>uses ethernet ICMP TIMESTAMP packets to tell how far apart the system
>clocks are.  Well, when you do that for any machine on our local
>network, you get:
>% repeat 10 timedc clockdiff cel

	[ ... ]

>Now, when you do the same for a 3b1 with version 1.4 of LOSE/TCP (it
>sure ain't WIN :-), here's what comes out:
>
>% repeat 10 timedc clockdiff notvax

	[ ... ]

>Now, the time difference is OK, the daemon isn't up and running yet.
>But!  Look at the variability!  Our Celerity (and Vaxen) differ by at
>most 1 millisecond.  The *range* for the 3b1 is 832 millisecs.  And
>that's when the machine is IDLE!  What gives here?  Is the whole
>ethernet driver just a kludge?!?  One day, when I get done writing my
>thesis, I'll get around to rewriting it.

	The resolution of the clock is 1 second, and the timestamps are
derived from the system clock.  If you ran it long enough, you'd get a 999mS
range.  Till we get some extra hardware, a counter run from the 10MHZ system
clock, divided down, and readable by the system, we aren't going to get much
more resolution unless we dedicate LOTS of cpu cycles to it.

	As to the hardware, this might be another thing to include in the
super combo card. (Of course, we'd need to modify the kernel to
access it. :-) Is there a statute of limitations on the prohibition from
disassembling the kernel ? :-)

	Perhaps the counter could be put on a new ethernet board, since that
is where we need the calls.  Can we add system calls that are serviced by a
loadable device driver?

	We can but hope!
		DoN.
-- 
Donald Nichols (DoN.)		| Voice (Days):	(703) 664-1585
D&D Data			| Voice (Eves):	(703) 938-4564
Disclaimer: from here - None	| Email:     <dnichols at ceilidh.beartrack.com>
	--- Black Holes are where God is dividing by zero ---