From: Terje Mathisen <Terje.Mathisen@hda.hydro.com> [-/+]
Date: Wed, 10 Dec 1997 09:05:48 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Cheap GPS clocks for NTP stratum 1 [-/+]
X-Keywords: antenna [-/+] dial [-/+] Garmin [-/+] NMEA [-/+] PPS [-/+] resolution [-/+] TrueTime [-/+]
Peter Silva wrote:
>
> Rick Thomas wrote:
> >
> > fredbeck@ptd.net (Fred) writes:
> >
> > >I'm on a quest. I'm trying to time sync all our unix boxes to a
> > >stratum 2 clock on the net. I now have all the unix boxes
> > >synchronizing to a HP9000 H50 (running 10.20) using xntp - that part
> > >works good. Since we don't have any other source of time except the
> > >internet I'm trying to dial up an ISP over a modem connected to this
> > >HP H50. My plan is to connect to the internet kill xnptd on my H50
> > >then run ntpdate on a time source site on the net.
> >
> > Fred,
> >
> > Why are you doing this? For roughly twice the cost of the modem
> > (US$300, or so) you can get a GPS radio that will give you your own
> > personal stratum 1 clock.
> >
> > Rick
>
> I've got a Kinemetrics DC-468 receiver. It's expensive.
How expensive?
> I've never heard of much cheaper stuff., Rick doesn't use one (I asked him)
>
> Does anyone use a cheap GPS to drive an NTP on a workstation or PC (linux?)
I have recently installed my first proper Stratum-1 clock, a TrueTime
NTS-100-GPS.
This clock was a joy to install:
Attach the power plug, insert the antenna cable in the "Sync In" BNC
connector and watch the little LCD display as it booted up, established
contact with the first satellite, and then used that to figure out where the
rest of the satellites were.
After less than 30 minutes (with the antenna positioned in my office window:
Very bad view of the sky) it had figured out that it had been moved a _long_
way from where it was initialized, and automatically started a 24-hour
position averaging task.
At this point, the little LED was blinking a reassuring green once per
second.
The only thing that remained was to use the front-panel keyboard to enter IP
address, mask and gateway, and then mount the antenna on the roof. With a
standard 15m antenna cable, it was fairly easy to put the clock in a 19"
rack on the top floor, and the antenna on top of a lift shaft.
To get back to the subject, I now intend to test one of those cheap GPS
receivers with NMEA interface (Garmin or Micrologic), connecting it to an
old PC running Linux.
I know that this cannot give better than about 2 ms resolution (since the
NMEA is running at 4800 baud), what I'm going to check is how consistently
the time & position NMEA string is output, relative to the start of the
current second.
If the output varies a lot, then the accuracy won't be any good either, and
I'll have to fall back on an OEM version, with separate PPS signal.
Anyway, for redundancy reasons, I'd like to have several independent time
sources (manufactured by different companies), it would probably be a good
thing if at least one of them was based on a radio signal from Germany
instead. (Just in case all of the GPS systems glitches on the 1999 flag
day.)
Terje
PS. I originally intended to get both a TrueTime NTS-100 and the TymServe
2100, but the second NTP clock was more than 50% more expensive than the
first! (I'm in Oslo, Norway) What are the current prices of these systems in
the US?
--
- <Terje.Mathisen@hda.hydro.com>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
From: Tom Lane <tgl@netcom.com> [-/+]
Date: Wed, 10 Dec 1997 07:08:45 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntpd, ntpdate and 'Daylight Savings Time' [-/+]
X-Keywords: timezone [-/+]
Peter Silva <Peter.Silva@ec.gc.ca> writes:
> -- syslogd clients write times that are in the application time zone,
> with no indication of what time zone it's in.
Poor client programming, I agree, but that doesn't make the Unix
timekeeping model wrong. I spend a lot of time with applications
that are *very* timezone sensitive (we collect tick data from
financial markets worldwide) and there is just no other way to keep
one's sanity except to make the internal representation consistently
UTC. Local timezones are local views of the clock, and nothing more.
AFAIK Unix is the only widely used OS that isn't grossly broken
in this regard. (The standard <time.h> C library routines are not
too great, in that they can only deal with one local timezone at a
time; but at least you can ignore them and write your own. If the
OS didn't reliably deal in UTC that would be far more difficult.)
> -- cron/rsh jobs do are not "login" shells, so they often do not run
> anything to set the environment to the local time zone.
> so log messages from a cron job will typically be in UTC, while
> interactive or NQS jobs will be in the user time zone.
> I've seen workstations with timezones hard coded in the shell
> binaries to get around this problem (blech!) I put an
> override in /etc/profile and it still doesn't work for things
> that aren't login shells (so I have init processes running JST!)
Huh? You set your preferred timezone in /etc/rc (or local
equivalent), and you're done. cron is fired up from /etc/rc.
regards, tom lane
From: Peter Silva <Peter.Silva@ec.gc.ca> [-/+]
Date: Wed, 10 Dec 1997 15:48:42 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntpd, ntpdate and 'Daylight Savings Time' [-/+]
X-Keywords: timezone [-/+]
I agree that UTC is the way to go on a unix machine, I just want to
point out that UNIX doesn't do it right either, it's just less broken.
user time zones don't work consistently, and basically, the users will
have to get used to UTC, except for the very simplest cases (like
an xclock on your screen...)
Tom Lane wrote:
>
> > -- cron/rsh jobs do are not "login" shells, so they often do not run
> > anything to set the environment to the local time zone.
> > so log messages from a cron job will typically be in UTC, while
> > interactive or NQS jobs will be in the user time zone.
> > I've seen workstations with timezones hard coded in the shell
> > binaries to get around this problem (blech!) I put an
> > override in /etc/profile and it still doesn't work for things
> > that aren't login shells (so I have init processes running JST!)
>
> Huh? You set your preferred timezone in /etc/rc (or local
> equivalent), and you're done. cron is fired up from /etc/rc.
>
for cron:
/etc/rc is fine for cron itself as long as nothing goes wrong
but when cron dies (as it does from time to time), or someone stops
cron (for maintenance, for example) some bozo will inevitably
start cron as:
/sbin/cron
(ie. forgetting setenv TZ/export TZ= ) which is natural on a bsd'ish
system (because it doesn't have an init.d/cron file...)
Also, sh's started by cron do not run user initialization, so
they will inherit the TZ from cron, not the user setting, so the user
running a shell interactively will get his tz, and a cron job will use cron's.
for telnetd/rlogind/rshd:
these things are started by inetd which is somehow hardwired to whatever
it got from init (at least on several systems I've tried), so the only
tz that's useful is whatever they had, which is system dependent.
for rsh:
set whatever you want, in any file you want, for a user that had the
Korn/Bourne shell. and do "rsh <host> date" the time zone will be whatever
was inherited from inetd, not the user setting.
We have users across four timezones, and they gave up and use UTC, which is fine.
My point is that it's just plain wrong to say that on UNIX that users can have
any timezone they want. In practice, user time zones cannot be consistently
used. This is part of a larger missing piece of unix, which is a way to
consistently set an environment, regardless of how a session was started...
excercise left to the reader: set PATH variable for an rsh.
--
Peter.Silva@ec.gc.ca - Supercomputing, Environment Canada
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 10 Dec 1997 07:58:07 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Cheap GPS clocks for NTP stratum 1 [-/+]
X-Keywords: FreeBSD [-/+] PPS [-/+] precision [-/+]
In article <348D82BB.5516A26A@ec.gc.ca> Peter Silva <Peter.Silva@ec.gc.ca> writes:
> I've got a Kinemetrics DC-468 receiver. It's expensive.
> I've never heard of much cheaper stuff., Rick doesn't use one (I asked him)
>
> Does anyone use a cheap GPS to drive an NTP on a workstation or PC (linux?)
OK, let's define "cheap GPS": It's a GPS receiver that uses a standard
protocol that is supported by xntp, but delivers timestamps that are
not tightly bound to the transition of a second. Ok, the equipment
has to be cheap, too.
Now, what yan you do? Using almost ramdomly distributed timestamps is
useless for NTP. The only choice you have is using PPS support. So
your GPS receiver must deliver the precision pulse-per-second in
addition to the time-telegram sent out "about every second".
Xntp will then synchronize close to the correct second, and then will
switch to PPS to fine-tune the second. Unfortunately you'll have to do
some hardware work (a level converter like MAX232). And it seems you
also need some software support.
The current choice of software seems to be limited to (MHO) Solaris,
SUnOS, FreeBSD, Linux. I only know some details about Linux: You need
a recent kernel (2.0.3x) and you need my patch for PPS kernel support.
I hope this helps a bit.
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 10 Dec 1997 08:31:21 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Linux 2.0.32: kernel pll status change 89
X-Keywords: bug [-/+] FAQ [-/+] logconfig [-/+] PLL [-/+] PPS [-/+] specification [-/+] STA_FLL [-/+] stability [-/+] syslog [-/+] TIME_ERROR
As I can foresee this FAQ, I'm trying to give the answer ahead of time:
Q: Since I upgraded to Linux 2.0.32, I can find the message
"kernel pll status change 89" in my syslog. What is it about?
A: This message depends on your xntp "logconfig" and on the stability
of your PLL. The message idicates that the kernel PLL is in status
STA_FREQHOLD, STA_FLL, and STA_PLL. That is xntpd tries to estimate
the drift. Usually this happens only once during initial startup,
but if your reference servers have a bad network connection you may
see this message more frequently. I see this message about 10 times
a day. Usually xntpd just switched to a different reference just
before.
The message is triggered by the fact that STA_FLL and STA_FREQHOLD
are set at the same moment, which is illegal as per specification
(Time between calibrations must be bigger than MINSEC). Thus ntp_adjtime
will signal an error to xntpd.
(from Linux-2.0.32/kernel/time.c):
...
if (time_status & STA_FREQHOLD || time_reftime == 0)
time_reftime = xtime.tv_sec;
mtemp = xtime.tv_sec - time_reftime;
time_reftime = xtime.tv_sec;
if (time_status & STA_FLL) {
if (mtemp >= MINSEC) {
ltemp = (time_offset / mtemp) << (SHIFT_USEC -
SHIFT_UPDATE);
if (ltemp < 0)
time_freq -= -ltemp >> SHIFT_KH;
else
time_freq += ltemp >> SHIFT_KH;
} else /* calibration interval too short (p. 12) */
time_state = TIME_ERROR;
...
This is intended to be part of the bug fixes in the Linux kernel PLL,
a feature, not a bug.
If you are using the PPSkit and a PPS signal, you'll see some more
different states.
Regards,
From: Terje Mathisen <Terje.Mathisen@hda.hydro.com> [-/+]
Date: Wed, 10 Dec 1997 23:44:30 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Cheap GPS clocks for NTP stratum 1 [-/+]
X-Keywords: Datum [-/+] TrueTime [-/+]
Garrett Wollman wrote:
>
> In article <348E4D5C.A3834820@hda.hydro.com> you write:
> >PS. I originally intended to get both a TrueTime NTS-100 and the TymServe
> >2100, but the second NTP clock was more than 50% more expensive than the
> >first! (I'm in Oslo, Norway) What are the current prices of these systems in
> >the US?
>
> About the same. The NTS-100 was about $5K, and the TS2100 was about
> $6.5K.
OK, in Norway they charged me NOK 40K ($5.5K) and NOK 61K ($8.5K).
The 10% markup from TrueTime is OK, but I had to tell the TS2100
importer that they should try to bring their prices more in line.
(Actually, it seems TymServe (Datum) was charging the Norwegian
distributor more than $5.5K: At least according to the guy I spoke with,
they would loose money by trying to match the NTS-100 price.)
Terje
--
- <Terje.Mathisen@hda.hydro.com>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
From: per@erix.ericsson.se (Per Hedeland) [-/+]
Date: 11 Dec 1997 14:49:40 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Cheap GPS clocks for NTP stratum 1 [-/+]
X-Keywords: Arbiter [-/+] arbiter [-/+] FreeBSD [-/+] PPS [-/+] precision [-/+]
In article <WIU09524.97Dec10085807@rrzc4>, wiu09524@rrzc4 (Ulrich Windl)
writes:
>In article <348D82BB.5516A26A@ec.gc.ca> Peter Silva <Peter.Silva@ec.gc.ca> writes:
>
>> I've got a Kinemetrics DC-468 receiver. It's expensive.
>> I've never heard of much cheaper stuff., Rick doesn't use one (I asked him)
>>
>> Does anyone use a cheap GPS to drive an NTP on a workstation or PC (linux?)
Well, we still haven't heard *your* definition of "cheap" I believe, but
the Arbiter 1092A is/was $850 (add usual markup if in Europe, 10-15%),
and was basically just as easy to set up as what Terje described for the
NTS-100 (the Arbiters aren't "network servers" though, i.e. you connect
them to the RS-232 port of a computer running a modern version of xntp)
- it doesn't have a keyboard/display and "only" 1ms precision, but if
you're not satisfied with this you can/could get a 1093B with 1us option
for $1550.
>OK, let's define "cheap GPS": It's a GPS receiver that uses a standard
>protocol that is supported by xntp, but delivers timestamps that are
>not tightly bound to the transition of a second. Ok, the equipment
>has to be cheap, too.
That's probably "cheaper" than the Arbiter:-) - the docs for it
specifies that "the start-bit of carriage return is transmitted on-time"
(for the timestamp format that xntpd uses with this clock), i.e. at
9600Bd this should be ~0.1ms precision - which on most Unices is lost
when the characters travel up to user-land where xntpd lives, of
course.:-)
>Xntp will then synchronize close to the correct second, and then will
>switch to PPS to fine-tune the second. Unfortunately you'll have to do
>some hardware work (a level converter like MAX232). And it seems you
>also need some software support.
No real hardware work needed for the Arbiter, it can (when jumpered for
it) deliver PPS through the RS-232 interface, at RS-232 levels (pulse
length is software settable) - only problem is, as H. Peter Anvin
mentioned in another thread here, it has the "wrong" polarity.
Yes, you need kernel-level software support for PPS on the computer
where xntpd is running - for Linux you (Ulrich) have done it (including
the polarity thing), for FreeBSD support is included in the standard
distribution (at least as of 2.2 I believe) though you need a very small
kernel mod to switch the polarity, for SunOS 4 you need the ppsclock
package (needs a couple of mods and may not be for the faint of heart -
I'm using it successfully right now though), for Solaris I don't know of
any solution that works with the Arbiter, for anything else I don't know
period.
For further info about Arbiter, their web site seems more messed up than
ever:-), but a combination of http://www.arbiter.com/catalog/catalog.html
(ignoring the links:-) with http://www.arbiter.com/pdf/, and some
patience, should give results...
"Just a satisfied customer"
--Per Hedeland
per@erix.ericsson.se
From: per@erix.ericsson.se (Per Hedeland) [-/+]
Date: 11 Dec 1997 15:22:05 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: puzzling large offset problem
X-Keywords: AIX [-/+] bug [-/+] syslog [-/+]
In article <slrn68tcqu.b82.mark@marksys.misty.com>, mark@misty.com (Mark
G. Thomas) writes:
>I am having a frustrating problem with xntpd on some AIX boxes.
>
>On this machine xntpd runs okay for a day or a few, but then gets really
>far off, and stops logging synchronisation messages to the syslog.
>I'm running AIX-4.1.4, with xntpd-3-5.90.
Don't know if this is your problem, but 3-5.90 had a really nasty bug
where it would happily consider itself sync'ed while being an
arbitrarily large number of integral seconds off wrt its source. Try
3-5.91 instead.
--Per Hedeland
per@erix.ericsson.se
From: Five <Five@infamous.demon.co.uk> [-/+]
Date: Thu, 04 Dec 1997 09:32:55 +0000 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NT server as Time server [-/+]
X-Keywords: Windows [-/+]
look on the time server web site, http://www.eecis.udel.edu/~ntp/ , there are
many tools for setting time on various platforms, although, you say you wish
to use NT to set the time on 95 & unix etc.
if you actually have a live unix box around, I would be tempted to use that as
the master time server, and have the NT/95 machines get their time from it.
But if you would like to set the time on NT machines from other NT machines,
there is a tool in the reskit called timeserv which will do it.
Vesna Ciglar wrote:
> Can I set one NT server 4.0 as Time server for other and how?
> Other is NT workstation, Windows 95, NT server, UNIX etc.
>
> Maybe anyone can me say where I can find good information about setting NT
> as Time server for all
> network.
>
> Thanks,
> Vesna
From: per@erix.ericsson.se (Per Hedeland) [-/+]
Date: 14 Dec 1997 02:23:06 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntpd broadcast [-/+]
X-Keywords: authentication [-/+] broadcast [-/+] update [-/+]
In article <3491C050.41C6@cadlab.de> Michael Joosten <joost@cadlab.de> writes:
>I was just today bitten by this when (trying to) update from 3.4t to
>3.591. In fact, authentication is required by default, and the broadcast
>flag does not switch it off, even with '-b'. I really wonder if this is
>intentional - as it precludes an easy broadcast setup...
Yes, it's intentional, but no, it doesn't preclude an easy broadcast
setup - just use -A with -b (after considering that anyone can set the
time on the broadcastclient with this setup, of course:-).
--Per Hedeland
per@erix.ericsson.se
From: Terje Mathisen <Terje.Mathisen@hda.hydro.com> [-/+]
Date: Sun, 14 Dec 1997 23:19:59 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: [++] Re: Determine NTP seconds for a time between 1/1/1900 and 1/1/1970
X-Keywords: calendar [-/+]
John Knapp wrote:
>
> I'm working on an app that stores time in NTP, that is, seconds since
> midnight (00:00:00) January 1, 1900. I need to convert a time in human
> readable format, for example, "1900/1/1 00:00:00," to NTP seconds.
That is _very_ easy: The answer is 0. :-)
> The C library routine mktime() will not work for times before midnight
> (00:00:00) January 1, 1970.
>
> Does anyone have any ideas how to do this?
First, I have written several algorithms to do this from scratch, it is
fairly easy. :-)
You can however get away with the library calls, while still achieving
proper day_of_week etc by observing that the calendar we have repeats
itself every 28 (4*7) years, as long as we have leap years every 4
years! This is OK from 1901 to 2099.
NTP will of course wrap around after 2^32 seconds (2036, right?), so the
high end is OK, but we'll have to handle the low end specially:
This means that you should be able to do something like this:
unsigned long ymdhms2ntp(int year, int month, int day, int hour, int
min, int sec)
{
int blocks_of_28_years = 0, y = year;
unsigned long ntp;
while (y < 1970) {
blocks_of_28_years++;
y += 28;
}
// The next block is (maybe?) not needed?
while (y > 2038) {
blocks_of_28_years--;
y -= 28;
}
ntp = mktime(...) + blocks_of_28_years * SECONDS_IN_28_YEARS;
// This will fail if the input was less than 1900-03-01, so handle this:
if (ntp < (31+29)*86400) ntp -= 86400;
return ntp;
}
Anyway, here's an example of some code I wrote to be fast, for regular
1970+ dates. It should be trival to convert it to work with NTP seconds
instead! ;-)
typedef long int32;
typedef struct _datetime {
unsigned year;
unsigned month;
unsigned day;
unsigned hour;
unsigned min;
unsigned sec;
} datetime;
static daysToMonth[12] = {-1,30,60,91,121,152,183,213,244,274,305,336};
unsigned long datetime2time(datetime *dt)
{
long y, m, d, daynr;
unsigned long sec;
int32 mask;
m = dt->month - 3; /* March is month zero! */
mask = m >> 31;
y = dt->year - 1967;
d = dt->day;
y += mask; /* Subtract one if before march */
m += mask & 12; /* Makes jan,feb into month 10,11 of previous year
*/
daynr = (y * 365) + ((y + 3) >> 2) + daysToMonth[m] + d -
(365+366+365-59);
sec = (daynr << 3) + (daynr << 4) + dt->hour; // daynr * 24 +
hour
sec = (sec << 6) - (sec * 4) + dt->min; // s * 60 + min
sec = (sec << 6) - (sec * 4) + dt->sec; // s * 60 + sec
return sec;
}
The reverse conversion is slightly more interesting!
Terje
--
- <Terje.Mathisen@hda.hydro.com>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 15 Dec 1997 15:16:09 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Over-synchronisation?
X-Keywords: documentation [-/+] FAQ [-/+] maxpoll [-/+] minpoll [-/+] peer [-/+] poll [-/+] restrict [-/+] synchronized [-/+]
In article <3494F1AB.155F7036@cpd.co.uk> Ross Golder <rossg@cpd.co.uk> writes:
> This is a multi-part message in MIME format.
Yes, sigh!
> --------------43CF38A07F8D6892213A2BDF
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> I have just installed xntpd-3 on two of my servers in-house. One
> (scooby) is set to poll some remote time-servers, and the other
> (GolfGTI) is set to poll Scooby. I had intended to set it up so that
> scooby to remote would be polled about once a day, whereas GolfGTI could
> poll Scooby perhaps every hour, since they are local.
>
> However, I noticed a sharp increase in network traffic once I had got
> them both going. A 'tcpdump port ntp' is attached.
Four packets per minute?
>
> Problem is, I can't seem to find any way to cut down the polling
> frequency. Surely there's an option for /etc/ntp.conf that could
> restrict it, but I can't find it anywhere in the docs.
>
> Summary: How do I restrict the polling interval?
You could set minpoll to some higer value as well as maxpoll
(e.g. minpoll 12, maxpoll 12), but it will take a long time until your
system is synchronized and stable (if ever!).
See the documentation on xntpd (keywords peer, server) and look into
the NTP FAQ.
From: Jim Reid <jim@pc37.mpn.cp.philips.com>
Date: 12 Dec 1997 13:41:31 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: more xntp
X-Keywords: configuration [-/+] restrict [-/+] UDP [-/+]
Five <Five@infamous.demon.co.uk> writes:
> I'm getting a thoughly good thumping headache from xntp now.
> I have a machine which tries to sync its time to a couple of internet
> time servers, but it never gets a response. But I've tracked this down
> to the packets being killed off at the router, it seems that the time
> servers are not sending back the packets to 123, but various (maybe even
> be random, I haven't watched it enough to find out) low ports, and the
> router kills them off. If I open all the udp port below 1024 then it
> seems to work fine, but I don't want them all open, I'd like it a bit
> more closed, but I don't know which ports I need open for it to work.
> Is this a feature of NTP itself, or is it some cock-up I've made in my
> ntpd.conf?
No. It's got nothing to do with NTP. It's to do with the
(mis)configuration of your routers/firewalls.
NTP traffic between servers will use UDP port 123 for both the source
and destination port numbers, so your router should be configured to
allow that. [You might want to add filters on the source and
destination addresses to restrict the traffic to authorised or
"trusted" systems.] Stuff like ntpdate, ntpq and xntpdc will use
random non-privileged ports to talk to an NTP daemon. If you use these
to query a remote NTP daemon, you will need to configure your router
to allow this traffic too.
More details on filtering principles for common network services can
be found in a decent book on firewalls: see the excellent books by
Chapman & Zwicky or Cheswick & Bellovin.
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 16 Dec 1997 11:30:13 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: SGI O2 and NTP Stratum 1, What should I buy? [-/+]
X-Keywords: Bancomm [-/+] caesium PPS [-/+] precision [-/+] resolution [-/+] SGI [-/+] synchronized [-/+] TrueTime [-/+] WWV [-/+]
In article <67463d$pgb@smash.gatech.edu> "Andy Register" <andy.register@gtri.gatech.edu> writes:
> Dear NTP Experts,
>
> I have an application where I need to collect data on two machines and time
> tag the data so that the time-tags are synchronized to an error smaller than
> 1 milli-second. One machine will probably be in Maryland and the other in
> Texas. What I think I need to do is either use NTP and configure each
> machine as a stratum 1 NTP machine I have to use SGI O2 machines, sponsor
> requirements.
For 1ms you need a local reference clock unless you have a extremely
fast and reliable network connection (ATM?).
>
> I have read just about all the FAQs and info I can find on NTP and it
> _appears_ that 1 milli-second may be pretty optimistic with a 1-PPS serial
> synch method. True or Not True? If the serial sync method will support < 1
Only with PPS you can get the required precision. I'd recommend a good
GPS with a precision less than one microsecond. On a reasonable fast
machine you should get as close as few microseconds, but be aware that
the system timer has a resolution independent from this (maybe 10ms
for HZ == 100). Most systems have additional hardware to interpolate
time between timer interrupts, so you might get 1 microsecond
resolution.
> mS, whose GPS unit should I buy? (Of course this presumes GPS is the way to
> go.) If a radio receiver (e.g., WWV) is just as good, I would also like
> someone to tell me this as well.
I think only GPS or a local caesium clock will give the accuracy you need.
>
> When operating in the serial sync mode, do you need two serial connections,
> one for the 1-PPS signal and one to transfer the timecode?
It depends on the kernel's hard and software. You can use one port for
both in theory. I don't know SGIs.
>
> I have read that if you can have a bus-based timecode generator, then you
> can sync to about 100 micro-seconds. The O2 machines have a 64-bit PCI card
> slot. Can I put a 32-bit GPS PCI card from Datum-Bancomm or TrueTime or
> Odetics in this 64-bit slot and expect the hardware to function? Is anyone
> aware of a hardware/driver combination that will work with the PCI slot in
> the SGI O2 machine? Is anyone aware of a driver that has been written to
> support one of these cards on _any_ unix platform?
>
No idea for these issues.
Ulrich
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 17 Dec 1997 14:20:22 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Question, how to read time with high resolution/accuracy?
X-Keywords: CIOGETEV delay [-/+] HP-UX [-/+] PPS [-/+]
In article <678hiv$3mu@smash.gatech.edu> "Andy Register" <andy.register@gtri.gatech.edu> writes:
> Dear NTP Experts,
>
> I am trying to figure out exactly how you go about reading the time once you
> set up a stratum 1 NTP machine.
>
> Lets say you have a GPS clock connected to the workstation via a serial
> connection. (Almost all the clocks fix the rate at 9600 baud.) A 1-PPS
> pulse is available and the serial timecode is also available.
>
> The most obvious answer is to use the GetTimeOfDay call to return the time.
> This would be fine except it is typically accurate to something like 1/100th
> sec (10 mS). So there appears to be only two options: read the timer
> hardware or read the serial timecode. Are there any other options with this
> kind of setup?
>
> <Read the Hardware Timer>
> How easy is it in general to read the timer hardware on various Unix
> machines? Is there a general solution or will this be platform dependent?
Most reasonable operating systems include an interpolation of clock
interrupts when reading timestamps (gettimeofday). HP-UX does, and
Linux on i386 does. Solaris also does... Windows/NT 3.51 does not...
> What accuracy will I be able (in general) to achieve. The NTP docs hint
> that 1 to 1.5 mS is about the best you can do even with this approach.
> True/False?
Your forgot sceduling. With a kernel interface (like the suggested PPS
API) you can get below one microsecond with good hardware.
>
> <Read the Serial TimeCode>
> Is this even possible to do? Issue a read command over the serial port and
> read the resulting timecode. If this is possible, the basic problem is the
You need OS support for that. That's what CIOGETEV is about.
> communication delays between the workstation and the clock. Can the delays
> be characterized to a high enough accuracy so that the resulting timecode
> can be compensated? What is the expected accuracy that can be obtained with
> this approach?
Depends on the clock rate of the UART, the baud rate and the interrupt
delay. You can be happy if you are as close a 1ms.
Readrds
Ulrich
From: rnews@whirlpool.river.com (Richard Johnson) [-/+]
Date: Mon, 15 Dec 1997 17:33:57 -0700 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Cheap GPS clocks for NTP stratum 1 [-/+]
X-Keywords: Garmin [-/+] PPS [-/+]
In article <348D82BB.5516A26A@ec.gc.ca>, Peter Silva
<Peter.Silva@ec.gc.ca> wrote:
>
> I've got a Kinemetrics DC-468 receiver. It's expensive.
> I've never heard of much cheaper stuff., Rick doesn't use one (I asked him)
>
> Does anyone use a cheap GPS to drive an NTP on a workstation or PC (linux?)
>
I'm planning to try out a Garmin TracPak GPS-35 soon. It is supposed to
provide a PPS signal accurate to 1ms. It cost less than $250.
I just have to finish cobbling together a power cable, and figure out a
way to get the thing out where the satellites are visible. I'm hesitant
to drill a hole in the wall until I know the GPS-35 can be made to work...
Richard
--
To reply via email, make sure you don't enter the whirlpool on river left.
From: Russ Garber <rgarber@k4ziv.erols.com> [-/+]
Date: Wed, 17 Dec 1997 22:50:58 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Does ntp modify RTC parameters?? [-/+]
Rick Thomas wrote:
>
> >In article <34969CC1.2018@lafn.org> Art Hurst <ae799@lafn.org> writes:
>
> >> We've been running ntp on local machines for several months w/
> >> connection to internet from 7AM to 6PM. Now I need to study ways to
> >> adjust clock parameters for remote machines that don't have inet access.
>
> >> My question is-- after having run ntp for several months, has my RTC or
> >> system clock been affected such that the parameters are now different
> >> than when the systems first ran ntp?? My objective is to set up systems
> >> so that when they ship they will remain stable within a minute over one
> >> or more month's time without intervention. (I can't afford dial-up to
> >> time servers or radio clocks. Cost of the system is very tight and
> >> remote systems may be anywhere and usually 3rd world locations). The
> >> reason for my question is that I don't know if by stopping ntp service
> >> my experiments are running on a well tuned system because of prior ntp
> >> activity and the results would be tainted and different from a system
> >> out of the box.
>
Hi Art,
To my knowledge, you didn't say what operating system you are
running. And
since you said ntp and not xntpd, I suppose it could be dos or win95..
Just in
case, here is info about a shareware product called "RighTime" (from
www.RighTime.com)
that can do what you want, it handles cmos and dos clock accuracy
problems:
RighTime makes possible sustained clock accuracies on the order of tens
of milliseconds per day, easily and
automatically. There are many other problems with the PC system
clocks; RT2@PTTI.Txt is a detailed
discussion of them and how RighTime solves them.
Russ
From: Bill McGovern <wem@lucent.com> [-/+]
Date: Wed, 17 Dec 1997 17:47:13 -0600 [-/+]
Newsgroups: comp.unix.solaris,comp.protocols.time.ntp
Subject: Re: ntp support in Solaris 2.6? [-/+]
X-Keywords: configuration [-/+] dispersion [-/+] FAQ [-/+] PLL [-/+]
Dima,
Thanks for your suggestion to turn off kernel pll support at compile time. I
too was seeing high offsets and and dispersion with 3-5.91 compiled on the
Solaris 2.6 box (SPARC 5). After following your suggestion, the resultant
xntpd runs very nicely now, like the way it did under 2.5.1!
Another item for the FAQ?
Bill McGovern
Lucent Technologies
Dima Volodin wrote:
> I had equally bad experience with xntpd in 2.6 until I turned kernel PLL
> support off - it looks like 2.6 and xntpd have drastically different ideas
> about what it means. After that, the boxes I run xntpd on run rock solid
> without any complaints. All these boxes are x86 platforms of very dirrefent
> configurations - two of them are your basic PCI pcs with dual IDE and all,
> the third one is an EISA/PCI SCSI-equipped combo. One note - I tried to run
> xntpd (no kernel PLL support) under 2.6 beta on a box with the hard disk
> drive and the CD drive on one IDE controller and IDE driver configuration
> was the worst-case one (smallest possible block_factor). And it did look to
> me that the system would lose timer interrupts when any disk activity
> appeared.
>
> Dima
From: Frank Cusack <fcusack@freebird.voicenet.com>
Date: Thu, 18 Dec 1997 03:47:32 GMT [-/+]
Newsgroups: comp.unix.solaris,comp.protocols.time.ntp
Subject: Re: ntp support in Solaris 2.6? [-/+]
X-Keywords: dispersion [-/+] dosynctodr [-/+] FAQ [-/+]
In <2.6 (without kernel pll support) you had to have
set dosynctodr=0
in /etc/system. Is this necessary in 2.6 if you compile without pll support?
(My guess is yes.)
per@erix.ericsson.se (Per Hedeland) writes:
> In article <34986480.E1997E79@lucent.com> Bill McGovern <wem@lucent.com>
> writes:
> >Dima,
> >
> >Thanks for your suggestion to turn off kernel pll support at compile time. I
> >too was seeing high offsets and and dispersion with 3-5.91 compiled on the
> >Solaris 2.6 box (SPARC 5). After following your suggestion, the resultant
> >xntpd runs very nicely now, like the way it did under 2.5.1!
>
> Ditto!
>
> >Another item for the FAQ?
>
> Definitely - and it should also mention that you need a reboot to get
> rid of the damage caused by a default build of xntp on 2.6 trying to use
> the kernel stuff (took me a while to figure that out:-).
>
> --Per Hedeland
> per@erix.ericsson.se
--
~frank
* I am Pentium of Borg. Division is futile. You will be approximated. *
* PGP ID: C001AA75 -|- fcusack@voicenet.com *
From: rbthomas@lilypad.rutgers.edu (Rick Thomas) [-/+]
Date: 17 Dec 1997 16:24:34 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Does ntp modify RTC parameters?? [-/+]
>In article <34969CC1.2018@lafn.org> Art Hurst <ae799@lafn.org> writes:
>> We've been running ntp on local machines for several months w/
>> connection to internet from 7AM to 6PM. Now I need to study ways to
>> adjust clock parameters for remote machines that don't have inet access.
>> My question is-- after having run ntp for several months, has my RTC or
>> system clock been affected such that the parameters are now different
>> than when the systems first ran ntp?? My objective is to set up systems
>> so that when they ship they will remain stable within a minute over one
>> or more month's time without intervention. (I can't afford dial-up to
>> time servers or radio clocks. Cost of the system is very tight and
>> remote systems may be anywhere and usually 3rd world locations). The
>> reason for my question is that I don't know if by stopping ntp service
>> my experiments are running on a well tuned system because of prior ntp
>> activity and the results would be tainted and different from a system
>> out of the box.
Art,
The answer is: Yes, as long as NTP has stabilized on the system
(values in the ntp.drift file don't change much from day to day) --
this usually takes between two days and a week for this to happen --
you can disconnect the machine from the network and -- as long as it
is still running xntpd -- the clock will not drift much from UTC.
Turning off the machine in order to ship it to a third world country
could be a problem, but if you can afford a single long-distance call
when you're installing it at the eventual destination (and each time
it's rebooted thereafter) you can mediate the problem by running
ntpdate or some equivalent that sets the clock to UTC, then starting
up xntpd.
The saved state information that allows the xntpd daemon to regulate
the system's clock, even though it's not connected to the internet, is
kept in the ntp.drift file.
To quantify this discussion - the units of the ntp.drift file are
parts per million (actually, parts per 2**20, but who's counting?) so
if the drift number is stable in the unit's place -- as is not unusual
for commercial x86 hardware -- then xntpd will be able to regulate the
system clock to plus/or/minus one part per million, or about 0.6
seconds/week. If it's stable in the ten's place -- can happen, but
it's rare to see a crystal that bad! -- then xntpd can only regulate
the system clock to about 6 seconds/week (or about half a minute per
month.)
Does this help?
Rick
From: Terje Mathisen <Terje.Mathisen@hda.hydro.com> [-/+]
Date: Wed, 17 Dec 1997 22:32:11 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: ]++] Re: Question, how to read time with high resolution/accuracy? [-/+]
X-Keywords: HP-UX [-/+] PPS [-/+] reset [-/+] resolution [-/+]
Ulrich Windl wrote:
>
> In article <678hiv$3mu@smash.gatech.edu> "Andy Register" <andy.register@gtri.gatech.edu> writes:
>
> > Dear NTP Experts,
> >
> > I am trying to figure out exactly how you go about reading the time once you
> > set up a stratum 1 NTP machine.
> >
> > Lets say you have a GPS clock connected to the workstation via a serial
> > connection. (Almost all the clocks fix the rate at 9600 baud.) A 1-PPS
> > pulse is available and the serial timecode is also available.
> >
> > The most obvious answer is to use the GetTimeOfDay call to return the time.
> > This would be fine except it is typically accurate to something like 1/100th
> > sec (10 mS). So there appears to be only two options: read the timer
> > hardware or read the serial timecode. Are there any other options with this
> > kind of setup?
> >
> > <Read the Hardware Timer>
> > How easy is it in general to read the timer hardware on various Unix
> > machines? Is there a general solution or will this be platform dependent?
>
> Most reasonable operating systems include an interpolation of clock
> interrupts when reading timestamps (gettimeofday). HP-UX does, and
> Linux on i386 does. Solaris also does... Windows/NT 3.51 does not...
From all the tests I've done, it seems that about 10ms is the resolution
of the clock in NT, assuming you're using the FTime calls. Now, this API
is capable of returning timestamps with 100ns resolution, but NT doesn't
even seem to try to interpolate.
If I switch to the Multimedia calls instead, then I can get 1 ms
resolution, if I wrap all timeGetTime() calls in a timeBeginPeriod(1),
timeEndPeriod(1) pair, but I haven't found a way to do this on absolute
time stamps (timeGetTime() returns milliseconds since reset, and wraps
around after 2^32 ms).
The best alternative I've found for NTP would be to use the performance
timer (QueryPerformanceTimer()), which normally returns timings with 0.8
microsec resolution, but then we're back at the problem of relating
these times to clock time.
By raising the thread priority to near realtime, it might be possible to
busy-wait until the clock is updated, and note the performace timer at
that moment.
At this point, all NTP client requests could be timestamped relative to
this base time, this would probably work as long as the drift between
clock time and the performace timer would stay much smaller than the
basic tick interval.
The _real_ solution would of course be an OS driver which fixed the
GetSystemTimeXXX calls, by interpolation from the last hardware timer
tick.
Would this even be possible, or would it require an OS patch?
Terje
PS. As long as NTP is running on a Pentium or similar/better cpu, the
internal cpu timestamp is the best way to go, since RDTSC returns a
64-bit clock cycle count, and it is useable from all protection levels.
--
- <Terje.Mathisen@hda.hydro.com>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 18 Dec 1997 10:01:23 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ]++] Re: Question, how to read time with high resolution/accuracy? [-/+]
X-Keywords: HP-UX [-/+] reset [-/+] resolution [-/+]
In article <349844DB.12FF@hda.hydro.com> Terje Mathisen <Terje.Mathisen@hda.hydro.com> writes:
> > Most reasonable operating systems include an interpolation of clock
> > interrupts when reading timestamps (gettimeofday). HP-UX does, and
> > Linux on i386 does. Solaris also does... Windows/NT 3.51 does not...
>
> From all the tests I've done, it seems that about 10ms is the resolution
> of the clock in NT, assuming you're using the FTime calls. Now, this API
> is capable of returning timestamps with 100ns resolution, but NT doesn't
> even seem to try to interpolate.
>
> If I switch to the Multimedia calls instead, then I can get 1 ms
> resolution, if I wrap all timeGetTime() calls in a timeBeginPeriod(1),
> timeEndPeriod(1) pair, but I haven't found a way to do this on absolute
> time stamps (timeGetTime() returns milliseconds since reset, and wraps
> around after 2^32 ms).
>
> The best alternative I've found for NTP would be to use the performance
> timer (QueryPerformanceTimer()), which normally returns timings with 0.8
> microsec resolution, but then we're back at the problem of relating
> these times to clock time.
>
> By raising the thread priority to near realtime, it might be possible to
> busy-wait until the clock is updated, and note the performace timer at
> that moment.
That's the problem with MS operating systems: Instead of having one
function that works well, you have a couple of them, each with
different defects.
Busywaiting in a server operating system is good if you have one CPU
per waiting task... Have you considered using the Pentium cycle
counter instead? It does not need special priviledges, and you have a
resolution as high as your CPU's speed (e.g. 1/100MHz).
>
> At this point, all NTP client requests could be timestamped relative to
> this base time, this would probably work as long as the drift between
> clock time and the performace timer would stay much smaller than the
> basic tick interval.
>
> The _real_ solution would of course be an OS driver which fixed the
> GetSystemTimeXXX calls, by interpolation from the last hardware timer
> tick.
>
> Would this even be possible, or would it require an OS patch?
Other question: Ask MS what function to use if you need the precise
time of day. Maybe they learn it that way...
>
> Terje
>
> PS. As long as NTP is running on a Pentium or similar/better cpu, the
> internal cpu timestamp is the best way to go, since RDTSC returns a
> 64-bit clock cycle count, and it is useable from all protection levels.
Right!
Ulrich
From: per@erix.ericsson.se (Per Hedeland) [-/+]
Date: 18 Dec 1997 00:02:24 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Stratum-1 Server [-/+]
X-Keywords: Arbiter [-/+] arbiter [-/+] delay [-/+] documentation [-/+] FreeBSD [-/+] fudge [-/+] implementation [-/+] PPS [-/+] precision [-/+]
In article <882293587.6320.0.nnrp-07.c1c3e001@news.demon.co.uk>
joew@demon.net (Joe Warren-Meeks) writes:
>Pentium PC (Any one have a guide to the loading it would be expected to
>take?) running OpenBSD 2.2 and using the Arbiter 1092 GPS clock, running 3.5f
>
>However if this isnt suitable we can use a sparc (5-10-20) with 2.5.1
>
>Does anyone have any experience running a stratum-1 with a set up like this?
>Anyone have any experience with the arbiter under BSD?
I have used the Arbiter 1092 on FreeBSD (2.2.2 IIRC) and Solaris 2.5.1
(and SunOS 4.1.4), with xntp3-5.90ish. Some comments:
You didn't say anything about what precision you want to achieve - the
1092 is spec'ed as 1 ms, which is probably more than good enough for
most people - and unless you use the PPS signal, your OS will introduce
variations that are greater than that. 1 us precison is available as an
option, but this is pointless without using PPS.
The Arbiter is an excellent choice IMO - reasonable price, good
functionality, and easy installation - including PPS without any
additional hardware. Xntp 3.5f doesn't support it at all though, I don't
know why you're considering such an old version (perhaps it's the one
that ships with OpenBSD?). Arbiter support (formally for the 1088, but
the interface is essentially identical) appeared somewhere around
xntp3-5.80; you should definitely use the latest version 3-5.91.
I don't know how much OpenBSD differs from FreeBSD these days, but on
FreeBSD: "Default" usage, i.e. only timestamps via the serial port,
entails variations of +/- 5 ms as observed by xntpd, due to the serial
I/O driver being optimized for high throughput rather than low latency.
This can be overcome, and variations pushed into the sub-ms area, with a
trivial modification of the driver (not really a modification even, just
setting a variable). PPS support is included in the standard FreeBSD
distribution, and used automagically by xntpd - however the Arbiter has
the "wrong" polarity in its PPS signal, so a trivial driver mod is
needed for this too.
Solaris 2.5.1, even on faster machines than those you consider,
introduces variations in "time stamp only" mode that are at least as big
as the abovementioned, sometimes on the order of tens of ms - for no
particular reason other than poor implementation of the serial I/O
system, I believe, and with no known "fix". There is no PPS support for
the Arbiter available on Solaris. I see no reason to recommend this over
any of the free x86-based Unices.
Even though you don't mention it (and I haven't tried it), you should
also definitely have a look at Linux with the patch package that Ulrich
Windl has produced, and posted about here occasionally.
As to load on the machine, this is totally dependant on how many clients
you intend to serve - the load from xntpd with the reference clock alone
is hardly measurable on any half-way modern hardware.
>And is there any documentation specific to setting up a stratum 1 around?
There isn't much to it as long as you don't use the PPS signal (and if
you do, it varies...) - but I believe the docs are frequently incomplete
if not downright wrong in this area. For a single Arbiter:
1. Create a symlink /dev/gps0 -> /dev/cuaa0 (or whatever the name/number
of the serial port is - make sure that it does *not* require a DCD signal)
2. Put this in ntp.conf:
server 127.127.11.0
You can also use a line like 'fudge 127.127.11.0 time1 0.0043' to
compensate for a fixed delay for the timestamps' traveling from serial
port to xntpd, but you need some way to determine the value... The rest
is basically standard stuff, i.e. not particular to stratum-1.
--Per Hedeland
per@erix.ericsson.se
From: rbthomas@lilypad.rutgers.edu (Rick Thomas) [-/+]
Date: 18 Dec 1997 14:45:15 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: SGI O2 and NTP Stratum 1, What should I buy? [-/+]
X-Keywords: Bancomm [-/+] PPS [-/+] resolution [-/+] SGI [-/+] synchronized [-/+] TrueTime [-/+] WWV [-/+]
>In article <67463d$pgb@smash.gatech.edu> "Andy Register" <andy.register@gtri.gatech.edu> writes:
>> Dear NTP Experts,
>>
>> I have an application where I need to collect data on two machines and time
>> tag the data so that the time-tags are synchronized to an error smaller than
>> 1 milli-second. One machine will probably be in Maryland and the other in
>> Texas. What I think I need to do is either use NTP and configure each
>> machine as a stratum 1 NTP machine I have to use SGI O2 machines, sponsor
>> requirements.
>>
>> I have read just about all the FAQs and info I can find on NTP and it
>> _appears_ that 1 milli-second may be pretty optimistic with a 1-PPS serial
>> synch method. True or Not True? If the serial sync method will support < 1
>> mS, whose GPS unit should I buy? (Of course this presumes GPS is the way to
>> go.) If a radio receiver (e.g., WWV) is just as good, I would also like
>> someone to tell me this as well.
>>
>> When operating in the serial sync mode, do you need two serial connections,
>> one for the 1-PPS signal and one to transfer the timecode?
>>
>> I have read that if you can have a bus-based timecode generator, then you
>> can sync to about 100 micro-seconds. The O2 machines have a 64-bit PCI card
>> slot. Can I put a 32-bit GPS PCI card from Datum-Bancomm or TrueTime or
>> Odetics in this 64-bit slot and expect the hardware to function? Is anyone
>> aware of a hardware/driver combination that will work with the PCI slot in
>> the SGI O2 machine? Is anyone aware of a driver that has been written to
>> support one of these cards on _any_ unix platform?
>>
Andy,
NTP will be hard-pressed to give you guaranteed sub-millisecond
accuracy. On some lightly loaded SGI O2 systems here, offsets average
less than 1 ms, but have occasional excursions to 10 ms or more.
Whatever you do, it ain't gonna be cheap! (but then, SGI O2's usually
mean money, so that's probably not a problem in your case...) The
ultimate best solution would be to ignore NTP entirely, and put a
bus-based timecode generator in each of your O2's. That should give
you micro-second resolution and, (assuming the time-base comes from
GPS with good long-term averaging to overcome the DoD's silly
"selective availability") micro-second accuracy as well. I know that
Odetics (at least, and probably others as well) make PCI cards with
GPS derived time-bases. Whether they have software for the SGI O2
machines, I can't tell. Best bet would be to call the vendors and
ask. Worst-comes-to-worst, they will probably be willing to give you
the source for an x86 PC driver, so you can roll your own for the
SGIs.
My recommendation would be to take your time-tags directly from the
card, and ignore the OS clock entirely as far as your applications
program is concerned.
Just out of curiosity, what is the application? VLBI radio-astronomy
comes to mind, but there are other possibilities.
Rick
From: per@erix.ericsson.se (Per Hedeland) [-/+]
Date: 18 Dec 1997 21:30:02 GMT [-/+]
Newsgroups: comp.unix.solaris,comp.protocols.time.ntp
Subject: Re: ntp support in Solaris 2.6? [-/+]
X-Keywords: dosynctodr [-/+] prefer [-/+]
In article <yjrvhwnqprd.fsf@freebird.voicenet.com> Frank Cusack
<fcusack@freebird.voicenet.com> writes:
>In <2.6 (without kernel pll support) you had to have
>
>set dosynctodr=0
>
>in /etc/system. Is this necessary in 2.6 if you compile without pll support?
>(My guess is yes.)
Mine too:-) (though you can do it with a modern tickadj -s if you
prefer). I haven't actually verified its effects, but the variable is
still there, and still set to 1 by default - I assume that it has the
same evil purpose as before.
--Per Hedeland
per@erix.ericsson.se
From: per@erix.ericsson.se (Per Hedeland) [-/+]
Date: 18 Dec 1997 21:54:23 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: SunOS 4.1.4 xntpd errors
In article <34989fad.0@satellite.premier1.net> devin@premier1.net (Devin
Ganger) writes:
>I'm having a puzzling error with xntpd 3-5.91 on SunOS 4.14 on a
>Sparc20.
>xntpd[11502]: xntpd 3-5.91 Wed Dec 17 19:07:15 PST 1997 (1)
>xntpd[11502]: tickadj = 1000, tick = 10000, tvu_maxslew = 99000, est. hz = 100
You should run tickadj -Aqs before starting xntpd...
>xntpd[11502]: socket(AF_INET, SOCK_DGRAM, 0) failed: Too many open files
>
>What'd I do wrong, and how do I fix it?
My guess is that you have a huge amount of "virtual interfaces" (kind of
difficult on SunOS 4, but it can be done), and run into the per-process
max of 256 open files (which can't easily be raised) as xntpd wants to
have a socket for each address used on the machine.
If this is the case, you can either hack the source to not open all
those sockets (it still needs them for all addresses that are going to
be used for NTP), or start xntpd before those interfaces are configured
(temporarily 'ifconfig down'ing them when starting xntpd seems to work
too, and would be needed if you want to start xntpd other than at boot
time).
--Per Hedeland
per@erix.ericsson.se