Hello

I would be grateful if you could help me with this question. I would like,
for test purposes, to be able to simulate the introduction of a leap second
into UTC, as managed by NTP.

I do not care whether or not this is a real historical leap second (which
would involve setting my computers' times to an appropriate past date) or an
imaginary leap second at the current date. I also do not care about the
quality of my time - I am happy for my tests to be driven by a server's
undisciplined local clock (unless this prevents ntpd from synchronising
properly). What I care about is the insertion of the extra second.

I plan to have a single NTP server, with several clients on which I will
actually perform tests. I would like, by manual intervention, to ask the
server to insert a leap second.

I think this must be possible because I imagine people having to do this
when a leap second occurs but their time source does not provide this
information. I could not find a simple explanation in the documents of how
to do this.

My best guess has been to use ntpq, and type:

writevar 42956 leap=01

(42956 is the association ID of the undisciplined local clock). This has
failed because of authentication problems (which I have not yet overcome),
so I have no idea whether or not this would have produced the intended
result.

I would be grateful for any help you can give.


Thanks in advance

Tom Cowell



---
Posted via news://freenews.netfront.net
Complaints to news@netfront.net

> I would suggest to use shared memory driver (SHM, ntp/html/driver28.html)
> on primary server. You can write several lines of C code to simulate
> leap second as it comes from reference clock and then trace both your
> server and clients as they react.

Thanks for this suggestion. I guess this would amount to my C programme
actually being the clock. I anticipate a problem here, in that the C
programme would loop, updating the information in shared memory and sleeping
(using gettimeofday() and select()/usleep()). It seems to me that this
approach would be susceptible to the shift in the system clock interfering
with the timing of my programme. I'm also worried about the time_t, which
has an ambiguous meaning during the leap second. However, I'll give it a go.

I have also considered using another computer as the source of a time
signal, perhaps sending an ASCII string for consumption by the parse driver
(via a serial line, perhaps). Something tells me it should be easier than
that.

> As leap seconds can occur only in two moments in a year, I guess you
> should set system clock to about 31 Dec 23:45:00, start ntpd on server
> and clients, and feed leap second via bogus SHM driver.

Indeed. Although it seems to me that NTP would accept a leap second at
midnight on any arbitrary day, I think I will keep things simple and stick
to proper leap second times.

Tom



---
Posted via news://freenews.netfront.net
Complaints to news@netfront.net

In article <bejo7b$2a7q$1@adenine.netfront.net>, Tom Cowell wrote:
>I anticipate a problem here, in that the C
>programme would loop, updating the information in shared memory and sleeping
>(using gettimeofday() and select()/usleep()). It seems to me that this
>approach would be susceptible to the shift in the system clock interfering
>with the timing of my programme. I'm also worried about the time_t, which
>has an ambiguous meaning during the leap second. However, I'll give it a go.

try to use setitimer() and increment "internal" SHM generator timescale
on every handled signal -- this should not rely on OS time scale.

>I have also considered using another computer as the source of a time
>signal, perhaps sending an ASCII string for consumption by the parse driver
>(via a serial line, perhaps). Something tells me it should be easier than
>that.

If you already have a RS232 cable, of course. I have once written
driver 29 (trimble palisade) timestamps generator, which works fine
for me, can send on e-mail.

-- 
Piotr Trojanek

Piotr Trojanek suggested:

>> As leap seconds can occur only in two moments in a year, I guess you
>> should set system clock to about 31 Dec 23:45:00, start ntpd on server
>> and clients, and feed leap second via bogus SHM driver.

Tom Cowell replies:

> Indeed. Although it seems to me that NTP would accept a leap second at
> midnight on any arbitrary day, I think I will keep things simple and
> stick to proper leap second times.

The current UTC standard permits leap seconds at the end of any month,
not just June and December.  See http://iraf.noao.edu/~seaman/leap for a
discussion regarding possible changes to the UTC standard.  Steve Allen
of Lick Observatory has an excellent leap second bibliography at:
http://www.ucolick.org/~sla/leapsecs/onlinebib.html

BTW - the idea to insert a test leap second is commendable.  One has to
believe that the only reason leap seconds might be considered problematic
is that few engineers and programmers have taken this obvious precaution.

Rob Seaman
National Optical Astronomy Observatory

Tom,

Assuming your  have the kernel modifications in Solaris, Tru64, FreeBSD 
or Linux, use the ntptime program to set the kernel leap bits in the 
machine with the local clock driver. Tell us if it works.

Dave

Tom Cowell wrote:
> Hello
> 
> I would be grateful if you could help me with this question. I would like,
> for test purposes, to be able to simulate the introduction of a leap second
> into UTC, as managed by NTP.
> 
> I do not care whether or not this is a real historical leap second (which
> would involve setting my computers' times to an appropriate past date) or an
> imaginary leap second at the current date. I also do not care about the
> quality of my time - I am happy for my tests to be driven by a server's
> undisciplined local clock (unless this prevents ntpd from synchronising
> properly). What I care about is the insertion of the extra second.
> 
> I plan to have a single NTP server, with several clients on which I will
> actually perform tests. I would like, by manual intervention, to ask the
> server to insert a leap second.
> 
> I think this must be possible because I imagine people having to do this
> when a leap second occurs but their time source does not provide this
> information. I could not find a simple explanation in the documents of how
> to do this.
> 
> My best guess has been to use ntpq, and type:
> 
> writevar 42956 leap=01
> 
> (42956 is the association ID of the undisciplined local clock). This has
> failed because of authentication problems (which I have not yet overcome),
> so I have no idea whether or not this would have produced the intended
> result.
> 
> I would be grateful for any help you can give.
> 
> 
> Thanks in advance
> 
> Tom Cowell
> 
> 
> 
> ---
> 
> Posted via news://freenews.netfront.net
> 
> Complaints to news@netfront.net

> Assuming your  have the kernel modifications in Solaris, Tru64, FreeBSD
> or Linux, use the ntptime program to set the kernel leap bits in the
> machine with the local clock driver. Tell us if it works.

There is an ntptime -l argument, but it seems not to be implemented. Could
you please confirm that what I am doing is correct?

1) Use ntptime with no arguments, and note the value of "status" (in my case
this is 0x1 (PLL)).
2) "OR" this value with STA_INS (0x0010).
3) Submit this new number with ntpdate thus:

ntpdate -s 17

Am I going about this the right way? I am still experimenting to find out
whether or not this actually has any effect, but it would be nice to know
whether or not I'm barking up the wrong tree.

Thanks
Tom



---
Posted via news://freenews.netfront.net
Complaints to news@netfront.net

Tom,

It really gripes me to the max when folks tinker with the ntptime 
program behind my back. I see somebody tinkered with it since the last 
time I cleared out the weeds. There is no -l option; it has always been 
the -s option. When that program left my hands it had no help 
information other than the NTP documentation, which is correct. The help 
information is wrong. And, the argument is in DECIMAL. Not my choice at 
all. Take the status bits as found, OR in the leap bits, convert to 
decimal and to the -s thing.

Tom Cowell wrote:
>>Assuming your  have the kernel modifications in Solaris, Tru64, FreeBSD
>>or Linux, use the ntptime program to set the kernel leap bits in the
>>machine with the local clock driver. Tell us if it works.
> 
> 
> There is an ntptime -l argument, but it seems not to be implemented. Could
> you please confirm that what I am doing is correct?
> 
> 1) Use ntptime with no arguments, and note the value of "status" (in my case
> this is 0x1 (PLL)).
> 2) "OR" this value with STA_INS (0x0010).
> 3) Submit this new number with ntpdate thus:
> 
> ntpdate -s 17
> 
> Am I going about this the right way? I am still experimenting to find out
> whether or not this actually has any effect, but it would be nice to know
> whether or not I'm barking up the wrong tree.
> 
> Thanks
> Tom
> 
> 
> 
> ---
> 
> Posted via news://freenews.netfront.net
> 
> Complaints to news@netfront.net