Gary E. Miller writes:
>> There is nothing to normalize in a l_fp All bit patterns are valid.
>
> Sort of. The header notes imply the integral and fractional part may be
> signed or unsigned. Separately. I have not confirmed if the code use
> that.
No, most certainly not. What you're looking
e...@thyrsus.com said:
> I'm not pulling this estimate out of a hat. "It will last about as long as
> it already has" is, as it turns out, a pretty good heuristic for systems
> that evolve under selection.
I don't think that is the question I was trying to ask.
The case I was interested in is
Hal Murray :
>
> How long do we expect our code to last? Or perhaps more importantly, how
> long do our users expect it to last?
I expect it to last around the same among of time the ancestral codebase
already has, which is about 35 years.
I'm not pulling this estimate out of a hat. "It will
https://www.youtube.com/watch?v=QBu2Ae8-8LM
This talk was given by Google Senior Staff Engineer Dick Sites ('69-'70) on
Feb. 23, 2015 as part of the 50th Anniversary Distinguished Alumni Speaker
Series.
UNC Computer Science
Published on Jun 2, 2015
It runs 1:12:54
There is nothing directly rel
Gary E. Miller :
> Or, just go with the flow and use the epoch in a timepec like
> structure:
>
> ntp_time_t {
> int epoch;
> uint32 seconds;
> uint32 faction;
> }
Oh dear Goddess no. This is what I moved us away from, because it
was horrible. All kinds of things that are now
Hal Murray :
> > I am also baffled. The RFC defines NTP Date Format, but then never uses it
> > anywhere
>
> That confirms that it isn't used on the wire. I think the idea is to use it
> as a reference to show what the shorter version is trying to represent.
I believe this is correct.
Yo Hal!
On Fri, 10 Mar 2017 17:20:14 -0800
Hal Murray wrote:
> How long do we expect our code to last? Or perhaps more importantly,
> how long do our users expect it to last?
I sometimes log into machines where some of the software was installed
20 years ago. Not the same hardware, parts, lik
Yo Hal!
On Fri, 10 Mar 2017 17:00:21 -0800
Hal Murray wrote:
> > Yes, but the overhead of timespec arithmetic is small, and pretty
> > soon I don';t think we will do any arithmetic in l_fp.
>
> That seems strange. l_fp seems like an obvious choice to me.
Sure, if the raw data is already in
How long do we expect our code to last? Or perhaps more importantly, how
long do our users expect it to last?
If the time stamp on the wire wraps in 2036, how far back do we have to get
ready and/or when should we start announcing that we are or are/not ready?
2036 is only 20 years from now.
> Yes, but the overhead of timespec arithmetic is small, and pretty soon I
> don';t think we will do any arithmetic in l_fp.
That seems strange. l_fp seems like an obvious choice to me.
Please be very careful before undoing the current stuff.
You can find all the places that do arithmetic by
Yo Hal!
On Fri, 10 Mar 2017 14:07:52 -0800
Hal Murray wrote:
> g...@rellim.com said:
> >> There is nothing to normalize in a l_fp All bit patterns are
> >> valid.
> > Sort of. The header notes imply the integral and fractional part
> > may be signed or unsigned. Separately. I have not conf
g...@rellim.com said:
>> There is nothing to normalize in a l_fp All bit patterns are valid.
> Sort of. The header notes imply the integral and fractional part may be
> signed or unsigned. Separately. I have not confirmed if the code use that.
The whole point of l_fp is so you can do 64 bit a
Yo Hal!
On Fri, 10 Mar 2017 13:44:29 -0800
Hal Murray wrote:
> POSIX has time_t
> ntp_types.h has time64_t
>
> There are various places that are working with seconds since NTP
> epoch. They are using uint32_t and uint64_t.
>
> I think we want something like ntp_time32_t and ntp_time64_t.
Or,
POSIX has time_t
ntp_types.h has time64_t
There are various places that are working with seconds since NTP epoch. They
are using uint32_t and uint64_t.
I think we want something like ntp_time32_t and ntp_time64_t.
I'm looking for something that will tell the reader that it's a seconds since
Yo Hal!
On Fri, 10 Mar 2017 12:40:11 -0800
Hal Murray wrote:
> g...@rellim.com said:
> >> Be careful with making negative values. The case I'm worried about
> >> is dropping the carry out of the low half.
> > The code has a normalize_tspec() ir prolly needs a
> > normalize_lp().
>
> There
g...@rellim.com said:
>> Be careful with making negative values. The case I'm worried about
>> is dropping the carry out of the low half.
> The code has a normalize_tspec() ir prolly needs a normalize_lp().
There is nothing to normalize in a l_fp All bit patterns are valid.
> Because a RasPi
Yo Hal!
On Thu, 09 Mar 2017 23:30:43 -0800
Hal Murray wrote:
> I'd expect there would be one place that converts ntp to unix and one
> place that converts unix to ntp. Actually, the latter isn't
> necessary except maybe for debugging. You don't really need ntp to
> unix because you are going t
Hal Murray writes:
> Do any of the casts actually change any bits? (as compared to kill compiler
> warnings)
As I understand it, C99 essentially mandates that the bit pattern is
preserved for integer casts to the extent that the number of bits allows
that. In particular if the two types have th
Yo Hal!
On Fri, 10 Mar 2017 00:59:49 -0800
Hal Murray wrote:
> > I'm now leaning that way too. And two ways to make an l_fp, one
> > starting with int's and the other uint's.
>
> Be careful with making negative values. The case I'm worried about
> is dropping the carry out of the low half.
g...@rellim.com said:
>> How about something like l_fp_time (unsigned) and
>> l_fp_delta or l_fp_offset (signed)?
> I'm now leaning that way too. And two ways to make an l_fp, one starting
> with int's and the other uint's.
Be careful with making negative values. The case I'm worried about is
20 matches
Mail list logo
