Oh yes it does... the postman just brought me a parcel full of time from China
;-) ... including rubidium time, DOCXO time, and some GPS time.
---Poul-Henning Kamp wrote:
>
> It is a perfect example of what I said earlier: people cannot grasp that time
> do not come i
Some (Penrose, Nottale) suggest that time may be discrete rather
than continuous.
Though 10E-43 second might be difficult to measure.
Poul-Henning Kamp wrote:
It is a perfect example of what I said earlier: people cannot grasp
that time do not come in parcels...
On 5/24/09 11:13 AM, "Hal Murray" wrote:
>
>
>> Also, someone I was discussing this with at work reminded me of a
>> common problem. We often run tests in a testbed where we need to have
>> the entire testbed running at some time *not the actual time*.. E.g.
>> If you're simulating a Mars e
In message:
"Lux, James P" writes:
:
:
:
: On 5/24/09 8:32 AM, "Bob Paddock" wrote:
:
: >> A 33.31 format would buy us a century, still allow us to get
: >> nanoseconds right, but it be computationally inconvenient and
: >> looks messy, so people balk at it.
: >
: > Anything wro
> Also, someone I was discussing this with at work reminded me of a
> common problem. We often run tests in a testbed where we need to have
> the entire testbed running at some time *not the actual time*.. E.g.
> If you're simulating a Mars entry,descent,landing scenario, you want
> the spacecraf
In message , "Lux, James P" writes:
>> Anything wrong with TAI64NA?
>>
>> http://cr.yp.to/libtai.html
>>
>It also breaks the time up into seconds, nanoseconds, and attoseconds, as
>separate chunks, so math isn't trivial
>I don't think this library buys you a whole lot [...]
I dont' think it b
On 5/24/09 8:32 AM, "Bob Paddock" wrote:
>> A 33.31 format would buy us a century, still allow us to get
>> nanoseconds right, but it be computationally inconvenient and
>> looks messy, so people balk at it.
>
> Anything wrong with TAI64NA?
>
> http://cr.yp.to/libtai.html
>
> "libtai is a l
> A 33.31 format would buy us a century, still allow us to get
> nanoseconds right, but it be computationally inconvenient and
> looks messy, so people balk at it.
Anything wrong with TAI64NA?
http://cr.yp.to/libtai.html
"libtai is a library for storing and manipulating dates and times.
libtai
In message: <20090519095316.1e1f4b46.att...@kinali.ch>
Attila Kinali writes:
: On Sat, 16 May 2009 15:09:07 +
: "Poul-Henning Kamp" wrote:
:
: > In message <4a0ebdee.2020...@erols.com>, Chuck Harris writes:
: >
: > >A "watch" isn't exactly a challenge to an operating system.
: >
In message <20090519095316.1e1f4b46.att...@kinali.ch>, Attila Kinali writes:
>On Sat, 16 May 2009 15:09:07 +
>Out of pure interest: what makes handling of time difficult?
That people don't think about it the right way.
I think the biggest challenge for people to wrap their head around,
is th
On Sat, 16 May 2009 15:09:07 +
"Poul-Henning Kamp" wrote:
> In message <4a0ebdee.2020...@erols.com>, Chuck Harris writes:
>
> >A "watch" isn't exactly a challenge to an operating system.
>
> Well, no.
>
> But figuring out correct handling of time is a challenge for operating
> system progr
In message:
"Lux, James P" writes:
: I also wouldn't have the low order counter count nanoseconds, or even set it
: up as seconds/subseconds.
I'd echo this, since you are artificially limiting the clocks that are
input to having a period of an exact number of nanoseconds. This
round
In message , "Lux, James P" writes:
>An integer divide in software is quite fast
>(unless you're working with something like a Z80).
You only need to divide when you want to change your estimate of the
counters range, for generating timestamps a multiplication will do.
>There's no real advantage
On 5/18/09 6:18 AM, "Lux, James P" wrote:
>
>
>
>
> On 5/18/09 1:12 AM, "Hal Murray" wrote:
>
>>
>>
>> stanley_reyno...@yahoo.com said:
>>> I need to go back and read what you are trying to measure with your
>>> clock. Is it internal to the computer or an external event ?
>>
>> I was
On 5/18/09 1:12 AM, "Hal Murray" wrote:
>
>
> stanley_reyno...@yahoo.com said:
>> I need to go back and read what you are trying to measure with your
>> clock. Is it internal to the computer or an external event ?
>
> I was thinking of a FPGA on a PCI bus. It has to be PCI rather than USB
In message <20090518081256.97f2bb...@ip-64-139-1-69.sjc.megapath.net>, Hal Murr
ay writes:
>I was going to put the Unix clock in the FPGA. It's a pair of 32 bit words.
>The high word is seconds since some magic date/time. The low word is
>nano-seconds within this second.
Please, will you guy
stanley_reyno...@yahoo.com said:
> I need to go back and read what you are trying to measure with your
> clock. Is it internal to the computer or an external event ?
I was thinking of a FPGA on a PCI bus. It has to be PCI rather than USB in
order to get reasonable timings.
I was going to put
Hal Murray skrev:
I'm interested in the case where interrupts and scheduling are
enabled so there may be arbitrary gaps inserted into the simple
code.
Interrupts enabled means that you can't make it reliable.
Sure you can. Just compare the two high samples and try again if they are
differe
M. Warner Losh skrev:
: I think this case doesn't work right:
: read high
: overflow
: long gap
: read low
: read high
:
: Suppose the low half overflows once a second so I can use handy numbers.
:
: If the long gap is 0.6 second, the MSB of the low half will be on so we use
: the f
In message <20090518041523.7b7cdb...@ip-64-139-1-69.sjc.megapath.net>, Hal Murr
ay writes:
>
>> Why not add a hardware latch with a fixed delay to read.
Because then you need locking to prevent multiple threads/processes
from accssing the hardware at the same time.
--
Poul-Henning Kamp |
data rate.
Sorry I'm totally confused now.
Stanley
- Original Message
From: Hal Murray
To: Discussion of precise time and frequency measurement
Sent: Sunday, May 17, 2009 11:15:22 PM
Subject: Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
> Why not add a hardware latc
> Why not add a hardware latch with a fixed delay to read. That is the
> delay controls the latch function after the counter is static as well
> as the interrupt. Then reset the latch buffer on the last read. We
> have a fixed hardware delay plus a software delay to allow for but
> eliminate some
do {
t32a = read.high
t32b = read.low
t32c = read.high
} while (t32a != t32c)
time64 = (t32a << 32) | t32b
/tvb
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
a
>> I'm interested in the case where interrupts and scheduling are
>> enabled so there may be arbitrary gaps inserted into the simple
>> code.
> Interrupts enabled means that you can't make it reliable.
Sure you can. Just compare the two high samples and try again if they are
different.
This
In message: <20090517233218.01d11b...@ip-64-139-1-69.sjc.megapath.net>
Hal Murray writes:
:
: > If a carry occurs between the two high readings, then we can expect
: > the low reading to be close to 0 on either side of the wrapping.
: > Which side determines which holds the right val
> If a carry occurs between the two high readings, then we can expect
> the low reading to be close to 0 on either side of the wrapping.
> Which side determines which holds the right value. If the wrapping of
> counter happend before reading the low part, then the low part will
> be just above 0
Hal Murray skrev:
Yes, but then, if it did happen, then you need to read low again. If you do
the 4 reads as a block (say, with interrupts disabled), then you get a nice
deterministic timing for the code. In practice, it's just a design decision
which way one does it.
Let's see if I understand
> Yes, but then, if it did happen, then you need to read low again. If you do
> the 4 reads as a block (say, with interrupts disabled), then you get a nice
> deterministic timing for the code. In practice, it's just a design decision
> which way one does it.
Let's see if I understand your idea...
t;Lux, James P"
To: Discussion of precise time and frequency measurement
Sent: Sunday, May 17, 2009 9:19:50 AM
Subject: Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
On 5/16/09 10:00 PM, "Poul-Henning Kamp" wrote:
> In message <20090517031525.292e7b...@ip-64-139-1-69.sjc
Lux, James P skrev:
On 5/17/09 9:24 AM, "Hal Murray" wrote:
In which case, if you're saddled with 32 bit (or 8 bit!) reads, you
have to do multiple reads, so that by the end of the process, you can
assure yourself it's consistent.
E.g read high, read low, read high, read low So you can che
On 5/17/09 9:24 AM, "Hal Murray" wrote:
>
>
>> In which case, if you're saddled with 32 bit (or 8 bit!) reads, you
>> have to do multiple reads, so that by the end of the process, you can
>> assure yourself it's consistent.
>
>> E.g read high, read low, read high, read low So you can check
> In which case, if you're saddled with 32 bit (or 8 bit!) reads, you
> have to do multiple reads, so that by the end of the process, you can
> assure yourself it's consistent.
> E.g read high, read low, read high, read low So you can check low #1
> against low #2, and figure out if you had a rol
On 5/16/09 10:00 PM, "Poul-Henning Kamp" wrote:
> In message <20090517031525.292e7b...@ip-64-139-1-69.sjc.megapath.net>, Hal
> Murr
> ay writes:
>
>> This is one of the reasons why I was looking for a low-cost FPGA on PCI board
>> with some way to get a couple of external inputs.
>>
>> Thing
In message <20090517031525.292e7b...@ip-64-139-1-69.sjc.megapath.net>, Hal Murr
ay writes:
>This is one of the reasons why I was looking for a low-cost FPGA on PCI board
>with some way to get a couple of external inputs.
>
>Things get interesting if your hardware splits a 64 bit read into 2 32 bi
Lux, James P wrote:
You do the work in the kernel, or you do the work outside of
the kernel, but you still have to do the work, and that takes
code.
But lots of embedded applications don't need, e.g., a file system.
All they need is device drivers, a scheduler, and some sort of messaging
syste
> [1] This is why I say that FreeBSD is a generation ahead, I have yet
> to see any other operating system support PPS-API on hardware captured
> signals.
This is one of the reasons why I was looking for a low-cost FPGA on PCI board
with some way to get a couple of external inputs.
You could e
On 5/16/09 4:32 PM, "Chuck Harris" wrote:
> Lux, James P wrote:
>
>>> I don't believe that will be happening in a message passing microkernel
>>> (like minix) anytime soon... unless you build all of the timekeeping
>>> software into the kernel, and then you are in the process of becoming
>>>
On 5/16/09 4:30 PM, "Chuck Harris" wrote:
> Lux, James P wrote:
>
>>
>> I think there is more use of microkernels (eCos, RTEMS, Erlang, etc.) in the
>> embedded world. The environment is more constrained, so reducing the
>> footprint is useful.
>
> That's just it, it doesn't reduce the foot
> Anyone know how NetBSD stands in regard to time services?
>From a couple of years ago...
Good, not fantastic.
It has the 20(?) year old kernel code from Dave Mills in the kernel sources.
You probably have to build your own kernel to get it.
It doesn't have anything newer than that.
No ne
Lux, James P wrote:
I don't believe that will be happening in a message passing microkernel
(like minix) anytime soon... unless you build all of the timekeeping
software into the kernel, and then you are in the process of becoming
a monolithic kernel ;-)
Or, do what I'm doing for a software r
Lux, James P wrote:
I think there is more use of microkernels (eCos, RTEMS, Erlang, etc.) in the
embedded world. The environment is more constrained, so reducing the
footprint is useful.
That's just it, it doesn't reduce the footprint at all!
All it does is legislate that the kernel function
> I think there is more use of microkernels (eCos, RTEMS, Erlang, etc.) in the
> embedded world. The environment is more constrained, so reducing the
> footprint is useful.
There is also the new µC/OS-III (yes, three) that "provides near zero
interrupt disable time. µC/OS-III has a number of inter
In message <4a0f2581.7000...@erols.com>, Chuck Harris writes:
>I don't believe that will be happening in a message passing microkernel
>(like minix) anytime soon... unless you build all of the timekeeping
>software into the kernel, and then you are in the process of becoming
>a monolithic kernel ;
On 5/16/09 1:43 PM, "Chuck Harris" wrote:
> Poul-Henning Kamp wrote:
>
>> I have no idea how the timing code is in minix3, but I do know
>> how much time it took me and subsequently Warner to get it right
>> and good in FreeBSD.
>
> Given that minix was written by a CS professor who has no
On 5/16/09 8:04 AM, "Chuck Harris" wrote:
> Bob Paddock wrote:
>> On Sat, May 16, 2009 at 9:21 AM, Chuck Harris wrote:
>
>>
>>> Why do you think Minix-III would be a good candidate for a time server?
>>
>> Minix-III is based on the microkernel approach of keeping things small and
>> fast.
>
Poul-Henning Kamp wrote:
In message <4a0ebdee.2020...@erols.com>, Chuck Harris writes:
A "watch" isn't exactly a challenge to an operating system.
Well, no.
But figuring out correct handling of time is a challenge for operating
system programmers.
Very true...
I have no idea how the timi
In message:
Bob Paddock writes:
: On Sat, May 16, 2009 at 9:21 AM, Chuck Harris wrote:
: > Bob Paddock wrote:
: >
: >> Anyone ever look at Minix-III (Minix-I was the progenitor to Linux)?
: >> Seems like it would be easy to make a decent time server, on
: >> embedded hardware with it
In message <4a0ebdee.2020...@erols.com>, Chuck Harris writes:
>A "watch" isn't exactly a challenge to an operating system.
Well, no.
But figuring out correct handling of time is a challenge for operating
system programmers.
I have no idea how the timing code is in minix3, but I do know
how much
Bob Paddock wrote:
On Sat, May 16, 2009 at 9:21 AM, Chuck Harris wrote:
Bob Paddock wrote:
Anyone ever look at Minix-III (Minix-I was the progenitor to Linux)?
Seems like it would be easy to make a decent time server, on
embedded hardware with it. Past iterations of the Minix-III website
gav
On Sat, May 16, 2009 at 9:21 AM, Chuck Harris wrote:
> Bob Paddock wrote:
>
>> Anyone ever look at Minix-III (Minix-I was the progenitor to Linux)?
>> Seems like it would be easy to make a decent time server, on
>> embedded hardware with it. Past iterations of the Minix-III website
>> gave a "wat
Bob Paddock wrote:
Anyone ever look at Minix-III (Minix-I was the progenitor to Linux)?
Seems like it would be easy to make a decent time server, on
embedded hardware with it. Past iterations of the Minix-III website
gave a "watch" as an example small embedded system it was meant to power.
Wh
I'm not out to start any kind of OS war here, I'm simply curious
as to alternatives.
On Fri, May 15, 2009 at 12:02 PM, Poul-Henning Kamp wrote:
> ... which you can read more about in my paper from 2002:
>
>http://phk.freebsd.dk/pubs/timecounter.pdf
Anyone know how NetBSD stands in regar
52 matches
Mail list logo
