On Jan 25, 2012, at 11:48 AM, Poul-Henning Kamp wrote:
> In message <43238110-5070-4223-a687-abb760759...@noao.edu>, Rob Seaman writes:
>
>> Indeed, but "real time" already means something completely different
>> in computing. I had a boss who named a server "data" (after the
>> Star Trek chara
Damn! Yet another joke I'll never be able to explain to my family.
On Jan 25, 2012, at 11:50 AM, Steve Allen wrote:
> On Wed 2012-01-25T18:48:28 +, Poul-Henning Kamp hath writ:
>> I really don't think the name is as important as the semantics.
>
> Stop the presses! We should forward this t
On Wed 2012-01-25T18:48:28 +, Poul-Henning Kamp hath writ:
> I really don't think the name is as important as the semantics.
Stop the presses! We should forward this to ITU-R SG 7 immediately!
--
Steve Allen WGS-84 (GPS)
UCO/Lick Observatory--ISB Natural Sci
In message <43238110-5070-4223-a687-abb760759...@noao.edu>, Rob Seaman writes:
>Indeed, but "real time" already means something completely different
>in computing. I had a boss who named a server "data" (after the
>Star Trek character). The resulting confusion was monumental.
If you really want
Poul-Henning Kamp wrote:
> The name refers to the data type.
Indeed, but "real time" already means something completely different in
computing. I had a boss who named a server "data" (after the Star Trek
character). The resulting confusion was monumental.
The data type is more properly terme
In message <20120125174437.gb12...@lake.fysh.org>, Zefram writes:
>Rob Seaman wrote:
>>Might I suggest that "real" is a poor descriptor here (no philosophy
>>intended)?
The name refers to the data type.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP s
Rob Seaman wrote:
>Might I suggest that "real" is a poor descriptor here (no philosophy intended)?
"linear".
-zefram
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
On Tue 2012/01/24 16:53:37 PDT, Rob Seaman wrote
in a message to: Leap Second Discussion List
>Might I suggest that "real" is a poor descriptor here (no
>philosophy intended)? There is a vast prior art of "real time"
>that means something entirely different.
In addition, there is nothing "unre
Might I suggest that "real" is a poor descriptor here (no philosophy intended)?
There is a vast prior art of "real time" that means something entirely
different. One facet of the idea is to use IEEE floating-point formats to
express time values. Whatever the desirability of that, is this real
If you want to make a nice project out of this, grab ser7.dat once
a day for a month and then make a nice graph of worst-case
error vs. prediction interval.
Oops, I see PHK already suggested this idea and also provided
a link to all the past bulletins. So with all that data readily available
it
Yea, the hard part is keeping that table up to date, but
I guess that's the job of a crontab entry not ntpd itself.
Warner,
Yes, a daily crontab entry would take care of it. Note the kernel
table really only needs two entries (today and tomorrow).
With two entries you have a full 24 hours in w
On Sep 22, 2011, at 11:15 AM, Tom Van Baak wrote:
>> Eyeballing it says around a couple of milliseconds, which, unless
>> you have done things to your hardware, is lost in the NTP noise.
>
> That was my conclusion too. It's one thing to work with hardware
> at the micro- nano- or picosecond leve
In message , "Tom Van Baak" writes:
>But the threshold with
>PC's, even PC's running NTP, is so relaxed [...]
Well, it doesn't have to be, but mostly it is.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD sinc
Eyeballing it says around a couple of milliseconds, which, unless
you have done things to your hardware, is lost in the NTP noise.
That was my conclusion too. It's one thing to work with hardware
at the micro- nano- or picosecond level. But the threshold with
PC's, even PC's running NTP, is so r
In message <20110922150945.gc5...@lake.fysh.org>, Zefram writes:
>But anyway: how do you imagine applying a Kalman filter?
I would use Bulletin A's as input, but I havn't given it more
thought that that.
First thing, I would probably grab all the recent Bul'As
(ftp://cddis.gsfc.nasa.gov/reports
Poul-Henning Kamp wrote:
>Have you tried giving that task to a Kalman filter ?
I haven't tried implementing it at all yet, I've only theorised about it.
But anyway: how do you imagine applying a Kalman filter? It would
normally be used where you have a substantial series of measurements
with simi
In message <20110922125304.gb5...@lake.fysh.org>, Zefram writes:
>The biggest issue, it seems to me, [...]
>but switching from one set of predictions
>to another.
Have you tried giving that task to a Kalman filter ? I would expect
it to do pretty well all things considered.
--
Poul-Henning Kam
Tom Van Baak wrote:
> Handling day boundaries smoothly would depend on how
>close to UT1 you want to be, philosophically. The IERS publishes
>past, present, and future DUT1 to sub-millisecond resolution, but
>I don't know if you want to interpolate from day to day, or if the
>IERS quantized tim
18 matches
Mail list logo
