Richard B. Gilbert wrote:
>
> NTP could do worse than to adopt the VMS 64 bit time format. IIRC it
> was a count of 100 nanosecond "ticks" since some date in (I think)
> November 1857.

18 November, 1857 to be exact! See, I still remember!

The format will represent any date-time from the base
> date through the next thirty thousand years or so.

Actually I think it was only to the year 8000 or something for some reason.

Of course VMS
> updates the clock by adding 10,000 "ticks" at a time. There is no
> documented or supported interface that will allow you to set or read the
> clock to greater than centisecond precision. I've often thought that
> VMS Engineering should support a little greater precision;

At the time that was about as good as you could get. Don't forget that
VMS was originally designed in the mid-70's and first released in 1977.
Who could imagine that kind of precision in those days? And clocks were
not that good in those days. I remember working developing the clock
module tester for the Aquarius line (VAX 9000) at the end of the 1980's
and the precision that you could achieve was not that good at the time.

> Solaris can
> keep time to microsecond precision and even, with NTP, keep it
> accurately to that precision!
>

Solaris is modern in comparison.

> The current 64 bit NTP timestamp wastes some bits in picosecond
> precision. I say "wastes" because even today's computers cannot
> exchange time without an uncertainty of two or three microseconds and
> those low order bits are meaningless noise.
>

That's for today. In 10 years that may very well not be true.

Danny
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Danny Mayer wrote:

> Richard B. Gilbert wrote:
>
>>NTP could do worse than to adopt the VMS 64 bit time format. IIRC it
>>was a count of 100 nanosecond "ticks" since some date in (I think)
>>November 1857.
>

>
>>The current 64 bit NTP timestamp wastes some bits in picosecond
>>precision. I say "wastes" because even today's computers cannot
>>exchange time without an uncertainty of two or three microseconds and
>>those low order bits are meaningless noise.
>>
>
>
> That's for today. In 10 years that may very well not be true.
>

The limitation, I believe, is in the round trip delay. My Sun Ultra
10s, separated by a Cisco 1548M switch and a few feet of cable, show
delays of the order of 4 microseconds at 100mb full duplex. Gigabit
Ethernet might shave a little off of that but not a whole lot.

If you are getting time over the internet you don't, and won't, have a
clue what the nanoseconds should be. Even over a fast LAN, the delay is
a killer.

Danny Mayer wrote:
> Richard B. Gilbert wrote:
>>
>> NTP could do worse than to adopt the VMS 64 bit time format. IIRC it
>> was a count of 100 nanosecond "ticks" since some date in (I think)
>> November 1857.
>
> 18 November, 1857 to be exact! See, I still remember!

I often wondered why that base was chosen - something to do with the
Smithsonian?

David

On 2006-07-14, David J Taylor wrote:
>> 18 November, 1857 to be exact! See, I still remember!
>
> I often wondered why that base was chosen - something to do with the
> Smithsonian?

That date is the epoch of Modified Julian Date. Which is JD -
2400000.5

David J Taylor wrote:

> Danny Mayer wrote:
>
>>Richard B. Gilbert wrote:
>>
>>>NTP could do worse than to adopt the VMS 64 bit time format. IIRC it
>>>was a count of 100 nanosecond "ticks" since some date in (I think)
>>>November 1857.
>>
>>18 November, 1857 to be exact! See, I still remember!
>
>
> I often wondered why that base was chosen - something to do with the
> Smithsonian?
>
> David
>
>
Something to do with the Smithsonian and an astronomer's star catalog.

One suspects that these various base dates were chosen by rolling dice,
flipping coins, or picking them out of a hat. They all work. More or less!

Greg Hennessy wrote:
> On 2006-07-14, David J Taylor
> wrote:
>>> 18 November, 1857 to be exact! See, I still remember!
>>
>> I often wondered why that base was chosen - something to do with the
>> Smithsonian?
>
> That date is the epoch of Modified Julian Date. Which is JD -
> 2400000.5

Thanks,
David

Richard B. Gilbert wrote:
> Danny Mayer wrote:
>
>> Richard B. Gilbert wrote:
>>
>>> NTP could do worse than to adopt the VMS 64 bit time format. IIRC it
>>> was a count of 100 nanosecond "ticks" since some date in (I think)
>>> November 1857.
>>
>
>>
>>> The current 64 bit NTP timestamp wastes some bits in picosecond
>>> precision. I say "wastes" because even today's computers cannot
>>> exchange time without an uncertainty of two or three microseconds and
>>> those low order bits are meaningless noise.
>>>
>>
>>
>> That's for today. In 10 years that may very well not be true.
>>
>
> The limitation, I believe, is in the round trip delay. My Sun Ultra
> 10s, separated by a Cisco 1548M switch and a few feet of cable, show
> delays of the order of 4 microseconds at 100mb full duplex. Gigabit
> Ethernet might shave a little off of that but not a whole lot.
>
> If you are getting time over the internet you don't, and won't, have a
> clue what the nanoseconds should be. Even over a fast LAN, the delay is
> a killer.
>

On a network, that's true enough and is likely to be for a while,
despite Internet 2 and other advances. However, we also have refclocks
that are not limited in that way and I don't necessarily mean just GPS.
There are other technologies coming along which have the potential for
much improved accuracy. The current limitations there will be likely the
path between the peripherals and the drivers, the O/S and NTP itself.

Danny
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

David J Taylor wrote:
> Danny Mayer wrote:
>> Richard B. Gilbert wrote:
>>> NTP could do worse than to adopt the VMS 64 bit time format. IIRC it
>>> was a count of 100 nanosecond "ticks" since some date in (I think)
>>> November 1857.
>> 18 November, 1857 to be exact! See, I still remember!
>
> I often wondered why that base was chosen - something to do with the
> Smithsonian?
>

Oops, I'm off by a year, it's 1858. From this URL if you want all of the
details: http://vms.tuwien.ac.at/info/humour/...ime-origin.txt

"So why 1858? The Julian Day 2,400,000 just happens to be November 17,
1858.
[...]

The Modified Julian Day was adopted by the Smithsonian Astrophysical
Observatory (SAO) in 1957 for satellite tracking. SAO started tracking
satellites with an 8K (non-virtual) 36-bit IBM 704 computer in 1957,
when Sputnik was launched. The Julian day was 2,435,839 on January 1,
1957. This is 11,225,377 in octal notation, which was too big to fit
into an 18-bit field (half of its standard 36-bit word). And, with only
8K of memory, no one wanted to waste the 14 bits left over by keeping
the Julian Day in its own 36-bit word. However, they also needed to
track hours and minutes, for which 18 bits gave enough accuracy. So,
they decided to keep the number of days in the left 18 bits and the
hours and minutes in the right 18 bits of a word."

Danny
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Danny Mayer wrote:

> Richard B. Gilbert wrote:
>
>>Danny Mayer wrote:
>>
>>
>>>Richard B. Gilbert wrote:
>>>
>>>
>>>>NTP could do worse than to adopt the VMS 64 bit time format. IIRC it
>>>>was a count of 100 nanosecond "ticks" since some date in (I think)
>>>>November 1857.
>>>
>>
>>
>>>>The current 64 bit NTP timestamp wastes some bits in picosecond
>>>>precision. I say "wastes" because even today's computers cannot
>>>>exchange time without an uncertainty of two or three microseconds and
>>>>those low order bits are meaningless noise.
>>>>
>>>
>>>
>>>That's for today. In 10 years that may very well not be true.
>>>
>>
>>The limitation, I believe, is in the round trip delay. My Sun Ultra
>>10s, separated by a Cisco 1548M switch and a few feet of cable, show
>>delays of the order of 4 microseconds at 100mb full duplex. Gigabit
>>Ethernet might shave a little off of that but not a whole lot.
>>
>>If you are getting time over the internet you don't, and won't, have a
>>clue what the nanoseconds should be. Even over a fast LAN, the delay is
>>a killer.
>>
>
>
> On a network, that's true enough and is likely to be for a while,
> despite Internet 2 and other advances. However, we also have refclocks
> that are not limited in that way and I don't necessarily mean just GPS.
> There are other technologies coming along which have the potential for
> much improved accuracy. The current limitations there will be likely the
> path between the peripherals and the drivers, the O/S and NTP itself.
>

I'm sure that it's possible to integrate a refclock and a computer in
such a way the that time down to the picosecond level is gated directly
onto the computers data bus and so that computer will know what the nano
and pico seconds are. It still will not be able to convey that
information to another computer without loss of precision. The more
distant the two computers, the more difficult the problem becomes.

Danny Mayer wrote:
> David J Taylor wrote:
>> Danny Mayer wrote:
>>> Richard B. Gilbert wrote:
>>>> NTP could do worse than to adopt the VMS 64 bit time format. IIRC
>>>> it was a count of 100 nanosecond "ticks" since some date in (I
>>>> think) November 1857.
>>> 18 November, 1857 to be exact! See, I still remember!
>>
>> I often wondered why that base was chosen - something to do with the
>> Smithsonian?
>>
>
> Oops, I'm off by a year, it's 1858. From this URL if you want all of
> the details:
> http://vms.tuwien.ac.at/info/humour/...ime-origin.txt
>
> "So why 1858? The Julian Day 2,400,000 just happens to be November 17,
> 1858.
> [...]
>
> The Modified Julian Day was adopted by the Smithsonian Astrophysical
> Observatory (SAO) in 1957 for satellite tracking. SAO started tracking
> satellites with an 8K (non-virtual) 36-bit IBM 704 computer in 1957,
> when Sputnik was launched. The Julian day was 2,435,839 on January 1,
> 1957. This is 11,225,377 in octal notation, which was too big to fit
> into an 18-bit field (half of its standard 36-bit word). And, with
> only 8K of memory, no one wanted to waste the 14 bits left over by
> keeping the Julian Day in its own 36-bit word. However, they also
> needed to track hours and minutes, for which 18 bits gave enough
> accuracy. So, they decided to keep the number of days in the left 18
> bits and the hours and minutes in the right 18 bits of a word."
>
> Danny

Thanks, Danny. The reference also states:

"The year 1858 preceded the oldest star catalog in use at SAO, which
also avoided having to use negative time in any of the satellite tracking
calculations."

which explains why that particular year was chosen as the new base for
Modified Julian Date. It then goes on to say:

"This base time of Nov. 17, 1858 has since been used by TOPS-10,
TOPS-20, and VAX/VMS. Given this base date, the 100 nanosecond
granularity implemented within VAX/VMS, and the 63-bit absolute time
representation (the sign bit must be clear), VMS should have no trouble
with time until:

31-JUL-31086 02:48:05.47

"At this time, all clocks and time-keeping operations within VMS will
suddenly stop, as system time values go negative.

"Note that all time display and manipulation routines within VMS allow
for only 4 digits within the 'YEAR' field. We [Digital] expect this to be
corrected in a future release of VAX/VMS sometime prior to 31-DEC-9999."



David

Danny,

Careful what you say about the 704; I learned machine programming on it
in 1959. It had not 8K, but 32K of 36-bit words divided into four fields
in bigendian order, 3-bit opcode, 15-bit decrement (used in loop
instructions) known by Lispers as CDR, 3-bit tag (index register select)
and 15-bit address known by Lispers as CAR. It would be absolutely
stupid to divide the word in two 18-bit fields and very expensive in
programming. So far as I remember, the time was kept in two 36-bit
words, but then that was specific to the U Michigan operating system. In
that era there were lots of operating systems, all different and all
incompatible.

In 1957 your reference might be the 1820 or even the 650, which was an
absolutely stupid machine that used tables to do arithmetic add. The
1820 I remember fell of the back of a truck and was destroyed. The last
704 I remember was buried in the Negev desert because the Israelis
wouldn't pay the rent beyond one year. The Universities got them for
free, at least until the Feds told IBM they couldn't write them off for
tax purposes.

The successor to the 704 was the 709, also using vacuum tubes, and that
succeeded by the 709T (for transistorized), popularly called the 7090,
and then the 7094. The 70x breed was dead by 1968, killed by the System/360.

Dave

Danny Mayer wrote:
> David J Taylor wrote:
>
>>Danny Mayer wrote:
>>
>>>Richard B. Gilbert wrote:
>>>
>>>>NTP could do worse than to adopt the VMS 64 bit time format. IIRC it
>>>>was a count of 100 nanosecond "ticks" since some date in (I think)
>>>>November 1857.
>>>
>>>18 November, 1857 to be exact! See, I still remember!
>>
>>I often wondered why that base was chosen - something to do with the
>>Smithsonian?
>>
>
>
> Oops, I'm off by a year, it's 1858. From this URL if you want all of the
> details: http://vms.tuwien.ac.at/info/humour/...ime-origin.txt
>
> "So why 1858? The Julian Day 2,400,000 just happens to be November 17,
> 1858.
> [...]
>
> The Modified Julian Day was adopted by the Smithsonian Astrophysical
> Observatory (SAO) in 1957 for satellite tracking. SAO started tracking
> satellites with an 8K (non-virtual) 36-bit IBM 704 computer in 1957,
> when Sputnik was launched. The Julian day was 2,435,839 on January 1,
> 1957. This is 11,225,377 in octal notation, which was too big to fit
> into an 18-bit field (half of its standard 36-bit word). And, with only
> 8K of memory, no one wanted to waste the 14 bits left over by keeping
> the Julian Day in its own 36-bit word. However, they also needed to
> track hours and minutes, for which 18 bits gave enough accuracy. So,
> they decided to keep the number of days in the left 18 bits and the
> hours and minutes in the right 18 bits of a word."
>
> Danny
> _______________________________________________
> questions mailing list
> questions@lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions
>

Richard,

I can't claim preconition, as the current NTP timestamp format was
invented in 1978 when nominal accuracies were in the 16-ms range.
However, the resolution limit of 232 picoseconds is likely to be
exceeded when the CPU clock rate approaches 4 GHz, which might not be
long off.

Dave

Danny Mayer wrote:

> Richard B. Gilbert wrote:
>
>>Danny Mayer wrote:
>>
>>
>>>Richard B. Gilbert wrote:
>>>
>>>
>>>>NTP could do worse than to adopt the VMS 64 bit time format. IIRC it
>>>>was a count of 100 nanosecond "ticks" since some date in (I think)
>>>>November 1857.
>>>
>>
>>
>>>>The current 64 bit NTP timestamp wastes some bits in picosecond
>>>>precision. I say "wastes" because even today's computers cannot
>>>>exchange time without an uncertainty of two or three microseconds and
>>>>those low order bits are meaningless noise.
>>>>
>>>
>>>
>>>That's for today. In 10 years that may very well not be true.
>>>
>>
>>The limitation, I believe, is in the round trip delay. My Sun Ultra
>>10s, separated by a Cisco 1548M switch and a few feet of cable, show
>>delays of the order of 4 microseconds at 100mb full duplex. Gigabit
>>Ethernet might shave a little off of that but not a whole lot.
>>
>>If you are getting time over the internet you don't, and won't, have a
>>clue what the nanoseconds should be. Even over a fast LAN, the delay is
>>a killer.
>>
>
>
> On a network, that's true enough and is likely to be for a while,
> despite Internet 2 and other advances. However, we also have refclocks
> that are not limited in that way and I don't necessarily mean just GPS.
> There are other technologies coming along which have the potential for
> much improved accuracy. The current limitations there will be likely the
> path between the peripherals and the drivers, the O/S and NTP itself.
>
> Danny
> _______________________________________________
> questions mailing list
> questions@lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions
>

David L. Mills wrote:

> Richard,
>
> I can't claim preconition, as the current NTP timestamp format was
> invented in 1978 when nominal accuracies were in the 16-ms range.
> However, the resolution limit of 232 picoseconds is likely to be
> exceeded when the CPU clock rate approaches 4 GHz, which might not be
> long off.
>

I suppose that even a 2 GHz machine could slice time into 500 picosecond
increments. But I was thinking in terms of the ability to set a clock
that accurately. There's no way that I can think of that it could be
done over a network using today's technology. I'm seeing a ~4us delays
on my 100 Mb full duplex LAN. I think that means I can't pass time from
machine A to machine B over my LAN without an uncertainty of ~2us.
The error is probably less than that but probably is the best we can say.

So you could get delta time measurments with 232 picosecond resolution
but getting absolute time accurately with that precsion is not going to
be easy.

Richard B. Gilbert wrote:
> David L. Mills wrote:
>
>> Richard,
>>
>> I can't claim preconition, as the current NTP timestamp format was
>> invented in 1978 when nominal accuracies were in the 16-ms range.
>> However, the resolution limit of 232 picoseconds is likely to be
>> exceeded when the CPU clock rate approaches 4 GHz, which might not be
>> long off.
>>
>
> I suppose that even a 2 GHz machine could slice time into 500 picosecond
> increments. But I was thinking in terms of the ability to set a clock
> that accurately. There's no way that I can think of that it could be
> done over a network using today's technology. I'm seeing a ~4us delays
> on my 100 Mb full duplex LAN. I think that means I can't pass time from
> machine A to machine B over my LAN without an uncertainty of ~2us. The
> error is probably less than that but probably is the best we can say.
>
> So you could get delta time measurments with 232 picosecond resolution
> but getting absolute time accurately with that precsion is not going to
> be easy.

If you can get _repeatable_, at least some of the time, 4 us delays,
then you can use the same statistical methods which NTP is already using
to get absolute accuracy close to an order of magnitude better, i.e.
half a us or so.

The real limiter will be the need for (a) a really good local clock
source, i.e. better than the current 10 cent (?) quartz crystals, and
(b) a hardware method to measure the interrupt latency.

Poul-Henning of FreeBSD and NTP fame did both on his _very_ good NTP
servers, it might be possible that some new motherboards will include a
timing facility to handle (b).

Terje

--
-
"almost all programming can be viewed as an exercise in caching"