From: tas@concert.net (Tim Seaver)
Subject: SunOS zs serial port delays
Date: 24 Sep 93 16:25:03 GMT [-/+]
Organization: CONCERT Network
X-Keywords: PPS WWVB [-/+]
This may be old news to most of you running STREAMS kernel
drivers for radio clocks on Sun workstations, but I don't recall
it being mentioned before. In the course of tracking down a
30 millisecond variation in timestamps on our WWVB radio
clock PPS signal, I discovered that, by default, SunOS only
services the zs serial port receive buffers every 3 clock ticks.
There's an internal flag used with the mouse port that allows
immediate interrupts, but I could find no way to set it from
user mode (other than by patching the kernel with adb once the
port is open). What this seems to imply is that every radio clock
kernel module running under SunOS on the zs serial ports should
do a
putctl1(WR(q)->q_next, M_CTL, MC_SERVICEIMM)
in the module open routine to pass the MC_SERVICEIMM (service
immediately) flag to the zs serial driver. In the xntp3
distribution, the dcf77 driver does set this, but the other
kernel modules don't. Setting this flag dropped a 30 millisecond
variation in our PPS timestamps to under 100 microseconds and
quite often under 10 microseconds over 5-10 second intervals.
Tim
============================================================================
From: pb@swan.cl.cam.ac.uk (Piete Brooks)
Subject: Re: XNTP3 on a Sun-3
Date: 27 Sep 93 21:44:55 GMT [-/+]
Organization: U of Cambridge Computer Lab, UK
X-Keywords: multicast [-/+] precision [-/+] syslog [-/+] timezone [-/+]
In article <28739v$ous@spatula.csv.warwick.ac.uk> cudep@csv.warwick.ac.uk (Ian Dickinson) writes:
>Could anyone provide correct values for Sun4m SunOS4 and Sun4d SunOS5 please?
* -20 for the former (well, that's what I use).
>I don't know how to calculate these values so far.
* The code I use (in my clock driver) just finds the time to read the clock.
* Old Sun4s increment the usec each time the clock is read, then suddenly
* jumps up 20ms. So this is a plausible kind of guess as to what it might
* approximate to ...
* Try it a few times, or better still, just keep reading the clock and printing
* the deltas. If you have multicast, look at the code to check the idle time
* of an MBone mrouted -- it's tweaked to do go fast -- microtime makes quite a
* change :-)
/* Find the precision of the system clock by reading it */
#define USECS 1000000
#define MINSTEP 5 /* some systems increment uS on each call */
#define MAXLOOPS (USECS/9)
static int ees_get_precision()
{
struct timeval tp;
struct timezone tzp;
long last;
int i;
long diff;
long val;
gettimeofday(&tp, &tzp);
last = tp.tv_usec;
for (i=0; i< 100000; i++) {
gettimeofday(&tp, &tzp);
diff = tp.tv_usec - last;
if (diff < 0) diff += USECS;
if (diff > MINSTEP) break;
last = tp.tv_usec;
}
syslog(LOG_INFO,
"I: ees: precision calculation given %duS after %d loop%s",
diff, i, (i==1) ? "" : "s");
if (i == 0) return -20 /* assume 1uS */;
if (i >= MAXLOOPS) return EESPRECISION /* Lies ! */;
for (i=0, val=USECS; val > 0; i--, val /= 2) if (diff > val) return i;
return EESPRECISION /* Lies ! */;
}
============================================================================
From: armand@bcvms.bc.edu
Subject: Re: network time server recommendations?
Date: 27 Sep 93 18:35:02 GMT [-/+]
Organization: Boston College
X-Keywords: Bancomm [-/+]
In article <1993Sep27.121527.1@bcvms.bc.edu>, armand@bcvms.bc.edu writes:
>
> I'm interested in dedicated Network Time Servers, specifically their relative
> price/performance/reliability information. I've seen an ad for Bancomm's
> Tymserve(tm) box in a recent trade journal, but have nothing to which to
> compare it. Any help would be appreciated. Since this question is likely to
> have been asked many times in the past, a reference to when it was last
> discussed would give me a place to start.
>
I guess I spoke/wrote too quickly. I just found a list of timecode receivers
currently available on the market in CLOCK.TXT Any experiences and/or
recommendations would still be welcomed.
Armand
---
Boston College Computer Center Internet: armand@bc.edu
140 Commonwealth Ave. Bitnet: armand@bcvms
Chestnut Hill, MA 02167
============================================================================
============================================================================
Subject: none (auto-inserted) [-/+]
From: Mills@UDEL.EDU [-/+]
Date: 1 Oct 93 18:33:07 GMT [-/+]
Dave,
See the file clock.txt in the pub/ntp/doc directory on louie.udel.edu for
a comprehensive list of public primary and secondary servers, along with
advice on how to set up a local NTP subnet. Advice can also be found in
the doc directory of the xntp3.3.tar.Z distribution in the pub/ntp
directory on louie.
Dave
============================================================================
From: denny@eng.sun.com (Denton Gentry)
Subject: Re: tickadj -A on Solaris
Date: 4 Oct 93 17:55:02 GMT [-/+]
Organization: Sun Microsystems Computer Corp
X-Keywords: dosynctodr [-/+]
In article k7s@spatula.csv.warwick.ac.uk, cudep@csv.warwick.ac.uk (Ian Dickinson) writes:
>That's the 'problem' - Solaris 2.2 has been fixed to work correctly.
>You only need to call tickadj with the -s flag to turn off dosynctodr,
>tickadj doesn't exist anymore and tick is correct.
You can also turn off dosynctodr in the /etc/system file, by putting in a line as follows:
set dosynctodr=0
(Just on general principles, to avoid mucking around in a running kernel with tickadj -s).
Denny
============================================================================
From: WhiskerP@logica.co.uk (Peter Whisker)
Subject: Re: NTP for DOS? (We've done everything else...)
Date: 12 Oct 93 11:02:03 GMT [-/+]
Organization: Logica DCG Ltd.
X-Keywords: daylight delay [-/+] FAQ [-/+] Novell [-/+] timezone [-/+]
In article <CEEMpI.LFr@wang.com> fitz@wang.com (Tom Fitzgerald) writes:
>From: fitz@wang.com (Tom Fitzgerald)
>Subject: NTP for DOS? (We've done everything else...)
>Date: Tue, 5 Oct 1993 03:22:29 GMT
>Macs and Novell servers are covered - but how about DOS clients? Anyone
>have NTP client code for them? Even a simple boot-time ntpdate equivalent
>would be welcome.
>This should probably be in the FAQ too, if someone has an answer to it.
Perhaps this might help ...
;*************************************************************************
;** USING PDCLKSET TO SET THE PC SOFTWARE CLOCK **
;*************************************************************************
;** **
;** PDCLKSET sets the time and date of the PC clock using a TIME server.**
;** To do so, the following information is required: **
;** **
;** - This clients unique IP number. **
;** - The IP number of an UDP/IP time server (most Unix systems). **
;** - The time zone offset from UTC (GMT) at this place. **
;** - If daylight saving (summer) time is used, which algorithm to use. **
;** **
;** All the above info can be supplied as arguments to PDCLKSET. If any **
;** of the first three are missing, it will send a BOOTP request to try **
;** to find the missing info. If you are not using BOOTP you probably **
;** must use gateway and mask arguments too. Except for client IP number**
;** and network mask, arguments to PDCLKSET override BOOTP info. **
;** Using a BOOTP server is highly recommended, freeware code exists **
;** for Unix systems and MSDOS PCs. **
;** **
;** BOOTP can not supply which dst algorithm to use; also, zone offset **
;** can't always be trusted. So, in practice, zone offset and dst algo- **
;** rithm (if applicable) are required arguments. On the other hand, **
;** these parameters will stay the same all around the year, no need to **
;** change the setup. **
;** **
;** If PDCLKSET finds more than one time server (sum of arguments and **
;** BOOTP fields) and the first one does not answer, it will try the **
;** other servers. The same applies for gateways. **
;** **
;** It is very hard to get accurate info on all the dst algorithms used **
;** all over the world, so the one you choose, you should test out. Use **
;** the alter argument to add or subtract time and days, and check that **
;** the dst switch occurs correctly. When using the alter argument, the **
;** date and time is displayed as usual, but the PC clock is not set. **
;** If you find any errors, mail me the correct info to my mail address **
;** below. If you want to, you can customize your own dst algorithm, **
;** see detailed info below. **
;** **
;** PDCLKSET talks to the network card via a packet driver. If you have **
;** more than one packet driver, it will use the first one (lowest **
;** packet interrupt number) unless you use the pktintno argument. **
;** I have only tested PDCLKSET with Ethernet or Ethernet simulating **
;** packet drivers. I have one report that it works with S&K FDDI **
;** interfaces, if so it should work for token ring too, but I've got **
;** no confirmation on that. **
;** **
;** Running through remote bridges or slip links may require longer **
;** than default timeouts. Add the number of extra seconds you need **
;** with the argument LongerTimeout= time. **
;** **
;** If you want to omit the "End of pdclkset..." msg, add Flag=128 **
;** **
;** In AUTOEXEC.BAT you should first load the packet driver, then call **
;** PDCLKSET. It is very small (13 kbyte) and executes fast, so you will**
;** not notice any delay. PDCLKSET is not memory resident and does not **
;** use any CONFIG.SYS devices, so no memory is wasted. Use TERMIN.COM **
;** if you want to unload the packet driver. See call syntax below. **
;** Note: If you always log into a Novell server after a boot, you **
;** don't need this program, the PC clock will be set from the server. **
;** However, if you are the supervisor, use PDCLKSET+SRVTIME to set it **
;** (available at msdos.ftp.sunet.se:pub/network/novelutl/srvtime). **
;** **
;*************************************************************************
;** USING PDCLKSET TO SET A TIMEZONE VARIABLE **
;*************************************************************************
;** **
;** PDCLKSET can also assign the proper normal or dls timezone name to **
;** an environment variable (TZ is used by most systems). Argument **
;** "Zone= #" will assign numeric zones to TZ (like TZ=+0100). If you **
;** want anything else, use the alternative syntax, e.g. **
;** "Zone= tzone=MET,METDST" will set TZONE=MET or METDST. **
;** **
;*************************************************************************
;** SYNTAX AND EXAMPLES FOR TIMESETTING **
;*************************************************************************
;** **
;** (time is [- | +] [<hours>h] [<minutes>m] [<seconds>[s]] ) **
;** **
;** pdclkset (displays a usage message) or **
;** **
;** pdclkset b[ootp] (only if dst not used) or **
;** **
;** pdclkset [o[ffset]=time] **
;** **
;** [d[aylightsave]=PAC | USA | CUB | CHIL | BRZ | GBR | **
;** W_EU | M_EU | E_EU | LIBY | EGY | TURK | **
;** ISR | IRAN | PRC | ROK | AUS | TASM | **
;** NSW | LHI | NZE | **
;** FrTime,FrWeekDay,FrDayOfYear, **
;** ToTime,ToWday,ToDayOfYr,AddTime] **
;** **
;** [z[onename]= # | varible=normalname,dlsname **
;** **
;** [i[pnr]=n.n.n.n] [t[imservers]=n.n.n.n[,n.n.n.n[,...]]] **
;** **
;** [m[ask]=n.n.n.n g[ateways]=n.n.n.n[,n.n.n.n[,...]]] **
;** **
;** [p[ktintno]=hexnr] [a[lter]=days,time] [f[lags]=flagnr] **
;** **
;** [l[ongertimeout]=time] **
;** **
;** **
;** All arguments to pdclkset must be on the same line, no continuation.**
;** For arguments to BAT files, use ":" instead of "=" and ";" instead **
;** of "," . **
;** **
;** Valid flags for this mode: **
;** 128 = half quiet (skip the End of pdclkset line if no errors) **
;** **
;** Examples: **
;** **
;** pdclkset o= -1h d=M_EU z=# (my IP nr and timeserver(s) from BOOTP)**
;** **
;** pdclkset offs=6h dst=USA zonename= tz=CST,CDT (sets TZ=CST or CDT) **
;** **
;** pdclkset o=8h d=PAC ip=123.45.6.7 ts=123.45.6.8 (BOOTP not used)**
;** **
;** pdclkset o=-9h30m t=1.2.3.4 i=2.3.4.5 g=2.3.4.1 m=255.255.255.0 **
;** **
;** **
;** Part of an AUTOEXEC.BAT file may look like this: **
;** **
;** \net\wd8003e -w 0x7d 3 0x280 0xd000 (install packet driver) **
;** \net\winpkt 0x7c 0x7d (install winpkt driver) **
;** \net\pdclkset o=-1h d=M_EU z=# (set PC clock and TZ) **
;** **
;** If you don't want to keep the paket drivers in memory, add the **
;** following line: **
;** **
;** \net\termin 0x7c (remove packet drivers) **
;** **
;** If you just need timesetting, use pdclksml instead of pdclkset. **
;** **
;*************************************************************************
;** WHERE TO GET IT FROM **
;*************************************************************************
;** **
;** Current version of PDCLKSET can be obtained by anonymous FTP from **
;** ftp.lu.se:/pub/network/pdclkset/pdclkxxx.zip or from **
;** msdos.ftp.sunet.se:pub/network/pdclkset/pdclkxxx.zip or from Novell **
;** server LUSTORFS/ARC:PUB\NETWORK\PDCLKSET\PDCLKxxx.ZIP **
;** (Netware access only in Lund and around). **
;** Major releases will also be available on wsmr-simtel20.army.mil and **
;** its mirror archive sites in the msdos.pktdrvr directory. **
;** **
;* *
;* Jan Engvald, Lund University Computing Center *
;* ____________________________________________________________________ *
;* Address: Box 783 E-mail: Jan.Engvald@ldc.lu.se *
;* S-220 07 LUND Earn/Bitnet: xjeldc@seldc52 *
;* SWEDEN (Span/Hepnet: Sweden::Gemini::xjeldc) *
;* Office: Soelvegatan 18 VAXPSI: psi%2403732202020::xjeldc *
;* Telephone: +46 46 107458 (X.400: C=se; A=""; P=Sunet; O=lu; *
;* Telefax: +46 46 138225 OU=ldc; S=Engvald; G=Jan) *
;* Telex: 33533 LUNIVER S *
;* *
;*************************************************************************
Peter Whisker
============================================================================
From: Mills@UDEL.EDU [-/+]
Subject: Re: Looking for NTP for SVR4 [-/+]
Date: 12 Oct 93 01:51:44 GMT [-/+]
Ash,
Yes, the latest xntp3.3 has a SVR4 port. There is quite a bit of
information in the various README and man pages scattered through the
directories. Most directories have READMEs describing the contents.
The build process is mostly automated, unless you have an oddball
Unix port. For even more information, see the pub/ntp/doc directory
on louie.udel.edu.
Dave
============================================================================
From: schaede@lan.ccit.arizona.edu (Barry Schaede)
Subject: Re: Looking for NTP for SVR4 [-/+]
Date: 12 Oct 93 19:04:10 GMT [-/+]
Organization: U. of Az. Center for Comp. & Info. Tech.
In article <9310112134.AA07630@fender>, ash@DEVNULL.MPD.TANDEM.COM (Ashvini Nangia) says:
>
>tex deleted...
> I'm also interested in using a "radio-clock" as the external
> time source. If you have any information or tips as to where
> I can get the hardware (who sells it in the US) that would
> be very helpful.
>
We purchased the UTS-10, which is a radio receiver with display and an
RS-232 port from Odetics. Their address is:
Odetics - Precision Time Division
1515 South Manchester Avenue
Anaheim, Ca. 92802-2907
Phone 714-758-0400
============================================================================
From: amoss@picton.cs.huji.ac.il (Amos Shapira) [-/+]
Subject: clockdiff - measure difference in clock among UNIX machines
Date: 19 Oct 93 17:58:48 GMT [-/+]
Organization: Inst. of Comp. Sci., Hebrew University, Jerusalem, Israel
Hello,
Here is a small programme to measure the difference in the clocks among
machines across an Internet network.
It consists on just one file so I didn't bother to package it or anything.
It is also available for anonymous ftp on host ftp.huji.ac.il file
/pub/network/clockdiff.c.gz (in Gzip format).
I don't know how accurate this programme is, will appreciate any feedback.
Read the comments at the beginning for more info.
Bye,
--Amos
[[ It was 500 lines long, so I deleted it -- get it from FTP or send mail
to Amos -- Rick]]
============================================================================
From: rbthomas@jove.rutgers.edu (Rick Thomas) [-/+]
Date: Fri, 22 Oct 93 17:27:03 EDT [-/+]
Subject: RE -- What I've learned about sun clocks and ntp
X-Keywords: driftfile [-/+] syslog [-/+]
In a previous article, joey@tessi.com (Joey Pruett) says --
%>Let it run for at least a day, if not longer.
%>Over that time it should be able to figure out how bad your
%>clock is. This value is recorded in the driftfile (usually
%>/etc/ntp.drift) and is updated once an hour. Monitor this and when it
%>seems to have stabilized for a couple hours, you should be ready.
%>Kill the ntp server when you're ready to fiddle with things.
%>
%>Now the value you will want to use for 'tick' is 10000 + int(drift/100).
I have a couple of comments based on talking with a friend of
mine who has a Solbourne with a particularly horrible clock.
First, the formula Joey gives is appropriate for xntp version 3, only.
The units of the number reported in the drift file changed between
version 2 and version 3. For those of us still running version 2 (or
-- horrors! -- version 1) there is a different formula.
The version 3 "drift" value is reported in part per million. "Tick" is
parts per 10000, so the "100" in Joey's formula comes from
1000000/10000 = 100
(As a side note, the "parts-per-million" is really "parts per 2^20", so
the "real" value of the denominator should be 104.8576, but who's counting?)
The version 1 and 2 "drift" value is in parts per 4096. "Tick" is still
parts per 10,000, so we use 4096/10000 = 0.4096 as the denominator in
these cases.
Hence, for ntp (v1) and xntp (v2), the correct "tick" value for use in
the "tickadj -t <tick>" is 10000 + int (drift/0.4096)
Second, you can tell if the drift value has stabilized by looking in
your /var/adm/messages file (or wherever else you have configured the
syslog deamon to put messages from xntpd) for hourly historical drift
values. This advice is independent of which version of the software
you are using.
Rick
============================================================================
From: dundas@netcom.com (John A. Dundas III)
Date: Sun, 14 Nov 1993 13:25:13 -0800 [-/+]
Subject: Macintosh NTP Client
X-Keywords: FAQ [-/+] VMS [-/+]
Could you please add the following to the NTP FAQ? Thanks...John Dundas
Another NTP client for the Macintosh is 'NTP Client' by John Dundas. This
shareware is available at a number of archives; use archie to search for
'macntp'. This software features the ability to use NTP over either UDP/IP
or AppleTalk. (Special servers are required for AppleTalk. The author
currently has servers implemented for Macintosh, VAX/VMS (AppleTalk for VMS),
and A/UX. Contact the author for more details at dundas@netcom.com.)
============================================================================
From: duwe@immd4.informatik.uni-erlangen.de (Torsten Duwe)
Subject: Re: xntpd 3.3a on Linux: stuck?
Keywords: tickadj, Linux, PC
Date: 24 Nov 93 13:35:34 GMT [-/+]
Organization: CSD., University of Erlangen
X-Keywords: adjustment [-/+] Linux [-/+] reset [-/+] resolution [-/+]
>>>>> "HPA" == H Peter Anvin N9ITP <hpa@ahab.eecs.nwu.edu> writes:
[...]
HPA> However, when /etc/ntp.drift reached the value -100.0000 is got
HPA> firmly stuck, [...]
Yes, +-100 ppm is the limit, as you might know. One of the boxes I run Linux
on (a 486dx33, OPTI cs) gets as bad as -330 ppm. How do I know ? tick
adjustment - see below...
HPA> tickadj just gives me "The value of tick is silly", this is after
HPA> making a link from /vmunix to /usr/src/linux/zBoot/zSystem.
Right - this would be the way to do old-fashioned, ugly /dev/kmem-ing in
Linux, but even if you don't get errors it still wouldn't work. tick gets
reset to 10000 every tick :-(. Looks like you're another customer for the
hwtickadj for PCs I am (about) to write. It is going to do outb()s to adjust
the divider value in the timer chip. Temporary workaround: fix the divider in
linux/include/linux/timex.h (line 67:CLOCK_TICK_RATE) in steps of 100 (the
resolution that gets fed into the divider). +100 compensates for approx.
-83.8 ppm drift. After recompiling and booting the new kernel you should be
fine.
Hope that helps
Torsten
---
Torsten Duwe duwe@informatik.uni-erlangen.de | /etc/init: respawn failed.
Friedrich-Alexander-Universitdt Erlangen-N|rnberg | fork license for
Informatik IV (Betriebssyteme, verteilte Systeme) | uid 0 has expired.
============================================================================
From: shotokan@diku.dk (Kim H|glund)
Subject: Re: HP problem with ntp [-/+]
Date: 30 Nov 93 08:45:57 GMT [-/+]
Organization: Department of Computer Science, U of Copenhagen
darrin@engin.umich.edu (Darrin P Cardani) writes:
>I have a handful of hp's running hp_ux90 which are losing sync like crazy
>for some reason. We have several hp's running hp_ux90, which are running
>fine. For some reason these few machines (all on different subnets, all
>able to reach their broadcasters) are losing sync several times a day.
>Has anyone heard of this, and does anyone know of a solution? They're logging
>several thousand messages a day. Any help would be greatly appreciated.
Several people (including myself) have experienced this with xntpd v3.3.
For the time being I believe the solution is to use xntpd version 3.1.
--Kim
============================================================================
From: scottr@news.plexus.com (Scott Reynolds)
Subject: Re: HP problem with ntp [-/+]
Date: 30 Nov 93 19:36:46 GMT [-/+]
Organization: Plexus Corp. -- Neenah, Wisconsin
X-Keywords: adjtimed [-/+] HP-UX [-/+]
In <1993Nov30.084557.18923@odin.diku.dk> shotokan@diku.dk (Kim H|glund) writes:
>darrin@engin.umich.edu (Darrin P Cardani) writes:
>>I have a handful of hp's running hp_ux90 which are losing sync like crazy
>>for some reason. [...]
>Several people (including myself) have experienced this with xntpd v3.3.
>For the time being I believe the solution is to use xntpd version 3.1.
I have been running xntpd-3.3b for the last week with no ill effects on both
the 400 series HP-UX 9.0 and 700 series HP-UX 9.01 platforms. You might
consider giving this a try. Don't forget to install (and run!) adjtimed.
Note that the config script will understand the OS as v8, not v9.
--
Scott Reynolds
Assistant System Adminstrator
Technology Group, Inc.
scottr@plexus.com
============================================================================
From: philip@charon.citicorp.com (Philip Gladstone)
Subject: Re: request for example kernel PLLs
Date: 12 Dec 93 23:20:50 GMT [-/+]
Organization: Citicorp
X-Keywords: implementation [-/+] Linux [-/+] PLL [-/+]
Duane Voth (duanev@mpd.tandem.com) wrote:
: So, can anyone send me an example of a proper adjtime() (or ntp_adjtime())
: system call? Maybe even something with a PLL attached? We are running a
: USL SVR4 kernel here. Please, no actual copyrighted code.
You might like to look at the Linux kernel that includes a PLL clock
implementation that seems to work. Look at your local Linux archive
for sources or try tsx-11.mit.edu
--
Philip Gladstone - Consultant
Citicorp Global Information Network
I don't speak for Citicorp. I presume that somebody else does!
============================================================================
From: duanev@mpd.tandem.com (Duane Voth)
Subject: Re: ntp black box?
Date: 10 Dec 93 22:56:13 GMT [-/+]
Organization: TANDEM Computers, Inc (MPD)
X-Keywords: Bancomm [-/+] IRIG
In article <1993Dec8.194428.10913@advtech.uswest.com>, huntting@advtech.uswest.com (Brad Huntting) writes:
> I'm looking for a dedicated "plug-n-play" stratum 1 ntp server to
> attach to ethernet or fiddi.
>
> Does such a beast exist?
Yes. I know of two from one company, there should be a couple more companies
offering these things too...
The Bancomm division of DATUM INC. sells:
a) Tymserve 2000 LAN Time Server $ 8,500
b) BC700LAN GPS Network Time Server $12,700
You can get Global Positioning System receivers for both (prices quoted
include GPS) to make it truely worthy of a stratum 1 server: accuracies
quoted are less than +/- 2 usecs of UTC. If you have an IRIG time code
source near by you can skip the GPS option and knock off $2k-$4k. The
BC700 appears to free-run at 0.5ppm with an oven option to go to 0.002ppm!
(thats right 2x10e-9!) Can't seem to find a ppm spec on the Tymserve -
it may not free-run at all.
Bancomm is in San Jose, CA 1-800-348-0648
I have not used one of these yet but hope to soon.
============================================================================
Date: Wed, 22 Dec 93 16:58:34 EST [-/+]
From: rbthomas@jove.rutgers.edu (Rick Thomas) [-/+]
Subject: Re: faster scrolling on raw SPARCstation screen
X-Keywords: adjustment [-/+]
Here is the NVRAM patch that speeds up scrolling on Sun4c bare consoles
by copying the FORTH console driver into (fast) RAM, instead of allowing
it to execute out of (slow) ROM. It incidentally fixes (most) of the
dropped interrupts that cause "last adjustment didn't complete".
Heed the warnings! Do NOT use this with early ROM revisions!
Enjoy!
Rick
PS -- don't despair if you have a ROM rev below 2.2. Latest rev ROMs
can be purchased from SUN for a cost of about US$50.
> Date: Sun, 2 Jan 1994 21:47:41 -0800
> From: Nick Sayer <nsayer@quack.kfu.com>
>
> I didn't see any mention of this...
>
> You can make a vast improvement both in the clock accuracy and the speed
> of the ROM console (at the cost of 200K of RAM or so) with this (works
> only with boot ROM rev 2.0 or higher, which should be available on
> any sparc apart from the sun4_ kernel architecture. I just got an
> upgrade for my SS1+ that bumped it up from 1.mumble to 2.9!):
>
::::::::::::::: cut here and make an executable file ::::::::::::::::::::::
#! /bin/sh
echo 'Be VERY careful -- install this ONLY on machines with PROM revision 2.2'
echo 'or higher. This will cause very unpeasant hangs in lower revs. "Very'
echo 'unpleasant" means "refuses to boot and may require a service call to'
echo 'get it fixed." On PROM revs equal to or later than 2.2, you can use'
echo 'the "<L1>-N" sequence to set all EEPROM values back to factory default.'
echo '(Hold down the <L1> key and the "N" key while the power is turned on.)'
echo ''
echo 'got that?'
echo 'Answer "yes" to continue.'
read answer
if [ "$answer" != "yes" ]
then
exit 1
fi
eeprom 'nvramrc=probe-all install-console
ramforth
: cache-page dup pgmap@ cacheable swap pgmap! ;
up@ cache-page
here origin do i cache-page pagesize +loop
banner'
eeprom 'use-nvramrc?=true'
exit 0
::::::::::::::: cut here and make an executable file ::::::::::::::::::::::
============================================================================
From: ken@sdd.hp.com (Ken Stone) [-/+]
Subject: Re: adjtimed dies on HP-UX 9.0 (s800)
Date: 23 Dec 93 21:29:30 GMT [-/+]
Organization: Hewlett Packard, San Diego Division
X-Keywords: adjtimed [-/+] bug [-/+] FAQ [-/+] HP-UX [-/+] syslog [-/+]
In article <1993Dec23.093917.13538@walter.cray.com> osh@cray.com (John O'Shaughnessy) writes:
>I've installed xntp 3.1 on an HP 9000-845 running HP-UX 9.0.
>It builds just fine, and when launched manually, runs just fine.
>I've included the following in the /etc/netbsdsrc startup file:
>
> /usr/local/etc/adjtimed -r
> /usr/local/etc/xntpd
>
>Both startup OK, but adjtimed dies immediately, with the following line
>in syslog:
>
> Dec 22 18:06:16 a00308 adjtimed[188]: read message: Identifier removed
Geez ... maybe this oughta go in the FAQ ?
In a stock 9.X s700/s800 systems, there is a bug in DIAGMON that causes
it to trash all message queues when it starts up. The possible solutions
range as follows ....
a. Get the DIAGMON patch from the response center ....
b. Start adjtimed/xntpd shortly after DIAGMON (ie not in netbsdrc)
c. Just don't run DIAGMON (ie comment it out in /etc/rc)
And life will be much better ...
-- Ken
============================================================================
From: Mills@UDEL.EDU [-/+]
Subject: Culturally correct chime [-/+]
Date: 1 Jan 94 21:37:43 GMT [-/+]
X-Keywords: WWVB [-/+]
Folks,
A problem previously mentioned and often casually ignored has come to
the point I must vigorously protest; and, I suspect my problem may
be generic to a bunch of other places. It has to do with the use of
private, unannounced server resources. I have several private time
servers here used for experiment and local service, one of which is
being hounded by over 50 unapproved rascals, 12 of which from the
same net(!). That breaks several of the culturally correct expectations
spoused in the file clock.txt frequently announced to this list. I'd like
these rascals to go away, especially as this host is used for all kinds
of experiments and sometimes tells awful time. I'd rather not be more
specific; but, if anybody is punching net 128.4 clocks other than
public primary servers rackety.udel.edu (128.4.1.1) and churchy.udel.edu
(128.4.1.2) and secondary server louie.udel.edu (128.175.1.3), I`d
sure like them to contact me first.
On a related matter, cultural correctness calls for no more than two
clients from any net to gang up on any single primary server. On rackety
I see as many as 19 clients from the same net! It may be time, as I
had to do in the fuzzballs, to put code in the NTP daemon that enforces
this. It's a terrible idea in the first place, since it introduces a
serious hazard, should the primary server go berserk. In fact, rackety
has a dead radio right now and is operating at stratum 2 by chiming
another stratum-1 server. If that radio comes bum, all of our servers
back out to a WWVB radio, which is not working correctly either. See
what I mean?
Finally, note that we have on the order of 1000 clients now honking our
three servers, quite a few running old versions (1 and 2) of the
protocol. The problem is, these versions do not scale back the rate of
chime once the local clock has stabilized. There would be a considerable
reduction in network loads (about a factor of 16) if these old versions
could be upgraded to version 3 (xntp3.3b.tar.Z on louie.udel.edu in the
pub/ntp directory). This is one of those problems that we tend to
ignore until, one day, the network just freezes up.
Dave
============================================================================
From: scoggin@delmarva.com (John K Scoggin Jr)
Subject: Re: Question: How to time sync VAX/VMS and Ultr
Date: 9 Jan 94 15:13:01 GMT [-/+]
Organization: Delmarva Power & Light
X-Keywords: implementation [-/+] VAX [-/+] VMS [-/+]
In article 855@gtewd.mtv.gtegsc.com, gidleyk@gtewd.mtv.gtegsc.com writes:
> A (hopefully) quick question for the "Time-Gods":
>
> We have a small isolated network, with a mix of VAX 4000's (running VMS) and
> DECstation 5000's (running Ultrix 4.2/4.3a). The VAXes are all getting
> IRIG-B time signals and having their internal clocks sync'ed to that.
> We would like to have the VAXes distribute their time to the Ultrix
> machines, especially to a database server machine. Is there a simple way
> to accomplish this? Accuracy to less than one-half second is desirable, but
> less than one second is probably OK. I looked that the latest NTP (v3) stuff,
> but it is mostly greek to me, and I don't see anything that looks like it
> will compile on the VAX/VMS systems.
We use TGV Multinet - it has a version 1 NTP implementation. Old, but it is
functional.
- John
============================================================================
From: nsayer@quack.kfu.com (Nick Sayer) [-/+]
Subject: Re: Culturally correct chime [-/+]
Date: 12 Jan 94 14:27:57 GMT [-/+]
Organization: The Duck Pond public unix: +1 408 249 9630, log in as 'guest'.
X-Keywords: CHU [-/+]
terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.) writes:
>[...] I'm not sure what would be a good, inexpensive clock, though
>[the two seem rather mutually exclusive 8-].
Does this mean it's time for a CHU preach? :-)
A CHU receiver/modem is so durn close to being free I can't believe
there aren't more of them among the stratum 1 population.
Rather than bellow on and on, anyone who doesn't know about CHU,
write me and I'll fill you in. The reader's digest version is:
shortwave radio + 3 chips + Sun running 4.1.3 + 1 serial port = +/- 1-2 ms.
============================================================================
Date: Thu, 13 Jan 1994 15:40 -0500 [-/+]
From: SHIBUYA@process.com
Subject: Re: Preliminary FAQ -- send updates to rbthomas@rutgers.edu [-/+]
X-Keywords: VMS [-/+]
Concerning the question "NTP on VMS", it will be appreciated if you
could add our product TCPware from Process Software as another alternative
for supporting NTP on VMS.
--
Hiroto Shibuya
Process Software Corporation
Framingham, MA
============================================================================
From: mogul@pa.dec.com (Jeffrey Mogul)
Subject: Re: Unix boxes with only timed [-/+]
Date: 14 Jan 94 03:05:41 GMT [-/+]
Organization: DEC Western Research
X-Keywords: AIX [-/+]
In article <1994Jan13.160016.272@process.com> shibuya@process.com (Hiroto Shibuya) writes:
>|>Speaking in generalities, all modern UNIXen will *support* NTP, though few
>|>if any have it *bundled* with the OS. You'll have to obtain, compile and
>|>configure it. Your machine will support NTP just fine.
>
>Of course. Please read 'support' as 'vendor support'. I'm interested in
>this information since there is a demand to run timed on non-AIX box
>connected to network primarily consists of AIX, which is currently using
>timed for clock sync. I just wanted to find out if there is any other
>machine with timed as 'vendor supported' clock sync mechanims so I can
>have wider range of testing to interoperate with 'vendor supported' timed.
DEC "supports" both NTP and timed as bundled parts of the ULTRIX
and OSF/1 operating systems. From the Software Product Description
for OSF/1:
Network Time Protocol
DEC OSF/1 provides the Network Time Protocol (NTP) Version 2 to syn-
chronize and distribute the time for all machines in a network envi-
ronment. The time synchronization daemon, xntpd, is used to distribute
time to all machines in a network.
Time Synchronization Protocol
DEC OSF/1 provides Berkeley's Time Synchronization Protocol (TSP). TSP
synchronizes the time of all machines in a network without ensuring
the accuracy of the time that is provided.
TSP = timed, I believe.
I suspect that most other Unix vendors also support timed.
-Jeff
============================================================================
From: per@erix.ericsson.se (Per Hedeland) [-/+]
Subject: Re: Unix boxes with only timed [-/+]
Date: 15 Jan 94 12:05:02 GMT [-/+]
Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden
In article <2h5s95$ppi@spatula.csv.warwick.ac.uk> cudep@csv.warwick.ac.uk (Ian Dickinson) writes:
>In article <2h5265$fbb@usenet.pa.dec.com>,
> mogul@pa.dec.com (Jeffrey Mogul) writes:
>>I suspect that most other Unix vendors also support timed.
>
>Most do.
>
>SunOS 4.x does (but no NTP).
That's news to me - I certainly had to install it from 4.3BSD sources
(+ some additions) back when I started to take an interest in correct
timekeeping on our Suns (before I had learned about NTP:-), and the
only timed I can find on my current SunOS 4.1.3 system is in
/usr/local/etc, where it certainly wasn't put by Sun:-).
>Miraculously, Solaris 2.x ships with neither NTP or timed.
Seems that Sun's idea of timekeeping remains "use rdate every now and
then"...:-(
============================================================================
From: Jerry_Scharf@corpmis.sjc.hw.sony.com (Jerry Scharf)
Subject: Re: Latest/cheapest in GPS clocks ?
Date: 21 Jan 94 03:32:53 GMT [-/+]
X-Keywords: Datum Mills [-/+] Trimble TrueTime
Your timing is perfect. My GPSWorld issue with the annual
GPS receiver survey arrived yesterday. Here are some of the
vendors that list clock support specificly. As Dave Mills
said, you have to be a bit careful if you are after the full
accuracy. I have left out a >$5K units, and have listed some
OEM units, but it may be impossible for you to buy one of
the OEM units, so I will list them last. I just gave one
listing per company. This is a personal transcription of a
manufacturers survey, so lots of things may not be just
right, or omitted.
One plug. We have the TrueTime unit, and have a driver ready
for it. We like it alot.
Banncom bc627AT $3695 pc board
6541 Via Del Oro, San Jose, Ca 95119 (408)578-4161
Datum 9390-52000 $4000 rack
1363 S State College Blvd, Anaheim, Ca 92806 (714)553-6333
Odetics GPSync varies rack
1515 S Manchester Ave, Anaheim, Ca 92802 (714)758-0400
Spectrum Geophysical GPS Time-Machine $2795 box
1900 W Garvey Ave S., Ste 200, West Covina, Ca 91790 (714)544-3000
Stellar GPS model 100 $2495 box
800 Charcot Ave, Ste 110, San Jose, CA 95131 (408)383-1515
Trak Systems 8821 GPS clock $3500 rack
4726 Eisenhower Blvd, Tampa FL, 33634 (813)884-1411
TrueTime GPS-TMS $3495 box
2835 Duike St. Santa Rosa, CA 95407 (707)587-1230
----------
Magellan GPS Brain Timing ??? oem board
960 Overland Ct, San Dimas, Ca 91773 (909)394-5000
Trimble Acutime II ??? pod oem?
645 N MaryAve, Sunnyvale CA 94086 (408)481-8000
============================================================================
From: rbthomas@frogpond.rutgers.edu (Rick Thomas) [-/+]
Subject: Re: Newbie questions.
Date: 29 Jan 94 22:46:06 GMT [-/+]
Organization: Rutgers Engineering Supercomputer Lab
X-Keywords: CHU [-/+] FAQ [-/+] SCO [-/+] update [-/+]
robert@lunatix.lex.ky.us (Robert Sexton) writes --
robert> Hello All,
robert>
robert> After reading c.p.t.n for a while, I have decided to throw some
robert> basics on the table. I have read the FAQ, but it seems awfully
robert> slanted towards those people on BSD with access to the net.
That's cause the people who have the answers are that kind of people.
I'm afraid it's unavoidable. To try to redress the balance, I'll
include this question and my answers in the FAQ. (Ahhh! The power of
being an editor!)
robert> 1. Do you have to meet an accuracy requirement to be considered
robert> Stratum 1? Or is it enough to be connected to a radio clock?
robert> I think I can use CHU to get accuracy to about 1 ms.
One millisecond is just fine for a stratum 1 clock. As they say --
"Come on in, the water's fine!" And I might add, "And welcome! We can
always use another stratum 1."
robert> 2. I have the schematics for Marcus Leech's CHU reciever, but
robert> are there less expensive oftions for getting radio time signals?
robert> Can anybody recommend an inexpensive, easily interfaced radio
robert> clock? I have considered using WWV, but it looks like the signal
robert> may be harder to work with.
Nick Sayer also has schematics for a CHU receiver he designed. His
address is nsayer@quack.kfu.com . Take a look at them and see if they
meet your needs better.
robert>
robert> 3. What sort of time signals are the ntp sources designed to
robert> work with? will I have to write my own stuff for use with CHU?
robert> SCO UNIX does have adjtime(), so I have the basic tools
robert> available.
Well, for your purposes, Nick Sayer has contributed a CHU driver for
the current xntp (v3) that talks to his receiver. It may also talk
to other CHU receivers as well. In any case, it shouldn't take too
much work to make it talk to them.
robert> 4. Is there any software out there for non-tcp time update? I
robert> would like to offer time signals to BBS's in my area.
Not that I know of. Why don't you write some?
robert> Thanks for your time.
And thank you for your questions. They are good ones.
robert> Robert Sexton
Rick
============================================================================