Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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. Why do you think Minix-III would be a good candidate for a time server? A "watch" isn't exactly a challenge to an operating system. -Chuck Harris ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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 "watch" as an example small embedded system it was meant to >> power. > 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. Take a look at the web site. http://www.minix3.org/ > A "watch" isn't exactly a challenge to an operating system. True. The challenge is putting the OS *in* the Watch, as the Embedded System that runs it. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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 gave a "watch" as an example small embedded system it was meant to power. 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. Take a look at the web site. http://www.minix3.org/ I spent an extensive amount of time writing system features for Minix, back in the day, and even though it was a microkernel, it was anything but fast. The good thing about microkernels is they have a very small section of "trusted" code in the kernel. Everything else is in user space. This has nothing to do with speed; it has to do with where the work gets done. Ultimately the work has to be done, and that is what causes bloat and slow operation. In microkernel systems, the kernel operates as a task starter, arbiter, allocator of system resources and messaging system. Everything is done by passing messages. The problem with the microkernel system is your messaging system has to copy tons of data to do even trivial things. Another problem is the kernel has to read the message, interpret what the message means, and check it for validity before it can do the bidding of the user level task. In academia, everyone talks of microkernel systems as being the wave of the future, but in the real world, things end up more in the monolithic kernel model... linux and BSD are both monolithic kernels. A "watch" isn't exactly a challenge to an operating system. True. The challenge is putting the OS *in* the Watch, as the Embedded System that runs it. Nobody with any sense would even try. A watch is such a closed system that it is easy to verify all parts of it, and there is no need for the frills an OS provides. -Chuck Harris ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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 time it took me and subsequently Warner to get it right and good in FreeBSD. I'll still claim that FreeBSD is a generation ahead of all other operating systems with respect to timekeeping, if for no other reason, because FreeBSD is the only OS that truly splits the nanosecond. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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. Past iterations of the Minix-III website : >> gave a "watch" as an example small embedded system it was meant to : >> power. : : > 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. : Take a look at the web site. http://www.minix3.org/ Right. But microkernels add latency to the dispatching of events. And the latency tends to be variable in a typical microkernel. Variable latency degrades performance. I've not measured minix3, so I don't know if it suffers from this problem or not. Even in a monolithic kernel you have issues with as well, since interrupts can be masked from time to time... Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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 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 apparent experience with real time operations, and has never been heard from on timenuts, I would guess it will be primitive. I'll still claim that FreeBSD is a generation ahead of all other operating systems with respect to timekeeping, if for no other reason, because FreeBSD is the only OS that truly splits the nanosecond. 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 ;-) -Chuck Harris ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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. >> Take a look at the web site. http://www.minix3.org/ > > I spent an extensive amount of time writing system features for > Minix, back in the day, and even though it was a microkernel, > it was anything but fast. > > The good thing about microkernels is they have a very small section > of "trusted" code in the kernel. Everything else is in user space. > This has nothing to do with speed; it has to do with where the work > gets done. Ultimately the work has to be done, and that is what causes > bloat and slow operation. In microkernel systems, the kernel operates > as a task starter, arbiter, allocator of system resources and messaging > system. Everything is done by passing messages. The problem with the > microkernel system is your messaging system has to copy tons of data > to do even trivial things. Another problem is the kernel has to read > the message, interpret what the message means, and check it for validity > before it can do the bidding of the user level task. > > In academia, everyone talks of microkernel systems as being the > wave of the future, but in the real world, things end up more in > the monolithic kernel model... linux and BSD are both monolithic > kernels. 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. > ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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 apparent > experience with real time operations, and has never been heard from > on timenuts, I would guess it will be primitive. > >> I'll still claim that FreeBSD is a generation ahead of all other >> operating systems with respect to timekeeping, if for no other >> reason, because FreeBSD is the only OS that truly splits the >> nanosecond. > > 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 radio that uses RTEMS, do the critical timing stuff in hardware, and the software just manages the hardware. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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 ;-) Well, this brings us into a philosophical area. If a piece of code calls a function to figure out what time it is, the tacit assumption is that the function takes zero time to execute and returns the timestamp of the time where it didn't take any time. In practice, the call will always occupy some duration of time, and the timestamp returned represents some instant during that interval. Depending on the function called, and the CPU hardware we execute it on, the timestamp returned may have more or less jitter relative to the call instruction and the first instrucation executed upon return. I call this jitter the "software-jitter" because it has nothing to do with the time keeping hardware, it is jitter introduced because we operate in software. In addition to the software jitte, we have whatever jitter the function runs into, trying to actually produce the timestamp: Bus contentions, hardware locking, page faults etc. etc. On the other side, if a piece of hardware yanks a signal line to record a timestamp, we can reasonably expect the timestamp will be the exact time of the signals reception +/-1 count on whatever hardware counter is used to keep track of time. These observations hold in general, even for the case where you have no operating system of any kind. If you look at this prism with your MACH-coloured glasses, what you see is that the access to the timekeeping hardware counter is likely to be restricted to one semi-priviledged process. Otherwise, why bother with microkernels in the first place ? It follows that all software calls to get a timestamp consequently becomes IPC calls. And we have 30 years experience telling us, that IPC calls are even more smeared out over time than direct calls and therefore the software jitter becomes worse. But other than that, and that is bad enough because of the scheduling latency/jitter typically present, there are no ill effects from running on a microkernel. If you feed your PPS signal in and do hardware timestamps like we FreeBSD's timecounters allows you to, for instance on the Soekris net4501[1], then your basic clock can be precise, but your microkernel will only allow your software to read fuzzy timestamps from it. If you hook the PPS signal to an interrupt line, and timestamp it in software, then your basic clock can never be precise, because your PPS timestamps are fuzzed by the microkernel. Poul-Henning [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. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
> 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 internal data structures and variables that it needs to access atomically. These critical regions are protected by locking the scheduler instead of disabling interrupts. Interrupts are disabled for almost zero clock cycles, ensuring the RTOS will be able to respond to some of the fastest interrupt sources." In the day job I'm designing near pager size devices, heading down to watch size devices. Current project has a U-Blox GPS hooked up to a AVR XMega Event System pin. Any Time Nut suggestions on what to do with it? Has 120x32 bit LCD display, and small speaker, also. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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 be small, and be the only "root" task. Everything else is pushed out into "user" land. 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. -Chuck Harris ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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 radio that uses RTEMS, do the critical timing stuff in hardware, and the software just manages the hardware. That's fine, as long as the critical timing stuff never has to pass into code space. If it does, then you are stuck with the OS's latency issues. -Chuck Harris ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
> 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 new features. No new bugs. [My memory could be fuzzy.] -- These are my opinions, not necessarily my employer's. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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 footprint at all! > > All it does is legislate that the kernel function be small, > and be the only "root" task. Everything else is pushed out > into "user" land. > > 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 system. (e.g. Traditional kernel functions). ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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 >>> a monolithic kernel ;-) >>> >> >> Or, do what I'm doing for a software radio that uses RTEMS, do the critical >> timing stuff in hardware, and the software just manages the hardware. > > That's fine, as long as the critical timing stuff never has to > pass into code space. If it does, then you are stuck with the > OS's latency issues. > That's the whole design requirement.. Thou shalt not touch the data with software. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
> [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 easily put the Unix format clock into the FPGA and map it (read only?) into user space. Then you just read the time. No kernel call. Adding PPS support would be simple. :) Things get interesting if your hardware splits a 64 bit read into 2 32 bit transfers. Many years ago, all Intel chips did that. I don't know about today. The usual fix is to do 3 reads: high, low, high, compare the highs, and try again if they are different. If they differ, the clock overflowed from the bottom word while you were reading it and you don't know which one matches the low bits. You can play other games, for example latch the high bits when the low bits are read. Then you have to ask what happens if 2 processs/threads read at the same time. You can assign a separate address for each thread/process, but that's probably more complicated than it's worth. You could read it from the kernel... -- These are my opinions, not necessarily my employer's. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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 system. (e.g. Traditional kernel functions). Traditional monolithic kernel operating systems can be built to include as much, or as little of these traditional kernel functions as you want. Size is not a factor in making the decision over whether you want/need a message passing microkernel, or a monolithic kernel. -Chuck Harris ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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 bit >transfers. Many years ago, all Intel chips did that. I don't know about >today. You don't need a 64bit counter in the first place. You are going to have a thread around anyway, which adjusts your clock based on the NTP PLL's output, that thread can maintain your "reference time" so that a 32 bit counter will never overflow. Which, I might add, is _exactly_ how FreeBSD does it :-) Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
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.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 bit >> transfers. Many years ago, all Intel chips did that. I don't know about >> today. > > You don't need a 64bit counter in the first place. You might want a 64 bit counter, if you want to keep time across processor resets. 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 roll over. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
> 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 roll over. Why read the low twice? I though the normal recipe was to read high, low, high. If the two highs are the same you know a carry didn't happen so a high/low pair is a valid reading. -- These are my opinions, not necessarily my employer's. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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 low #1 >> against low #2, and figure out if you had a roll over. > > Why read the low twice? > > I though the normal recipe was to read high, low, high. If the two highs are > the same you know a carry didn't happen so a high/low pair is a valid reading. 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. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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 check low #1 against low #2, and figure out if you had a roll over. Why read the low twice? I though the normal recipe was to read high, low, high. If the two highs are the same you know a carry didn't happen so a high/low pair is a valid reading. 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. No, if the high parts differs, then the MSB of the lower part indicates which of the higher parts to go with it, MSB low is the late high read and MSB high is the early high read. Infact, by always look at the MSB then it will always be correct. With a second lower read will the low read point in time be modulated and hence jitter is added. Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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 of the variability. And reduce the failed read due to software delay. Now a second interrupt / read will indicate delays greater than the tick rate if our OS has interrupts that are off greater than the tick rate minus the delay of the latch. Our choice would be to slow the tick rate or reduce the interrupts off blind time if we have many failed reads where the tick is more than one. The idea would be to reduce the error to a rare event. This problem is like the meta stable problem discussed here before so perhaps the fixes are the same. Stanley - Original Message From: "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.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 bit >> transfers. Many years ago, all Intel chips did that. I don't know about >> today. > > You don't need a 64bit counter in the first place. You might want a 64 bit counter, if you want to keep time across processor resets. 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 roll over. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
> 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... If the two highs are the same, you know a carry didn't happen between reading the highs so the answer is high, first-low. That gives you an answer that corresponds to some time when you read the first low. If the two highs differ, you know a carry did happen but you don't know if the first low was before or after the carry. You know the second low was after the carry. So use the second high, second low. That gives you a time between the carry and reading the second low. I think that works without disabling interrupts. If we are doing this with a FPGA and have interrupts disabled or a kernel lock or only one user or .., it would be easy to latch the other half on the first read so you always got a coordinated pair with just two reads. > No, if the high parts differs, then the MSB of the lower part > indicates which of the higher parts to go with it, MSB low is the > late high read and MSB high is the early high read. Infact, by always > look at the MSB then it will always be correct. With a second lower > read will the low read point in time be modulated and hence jitter is > added. My head hurts, but I think I have convinced myself that will work. Thanks. If there is no carry, you get the time of reading the low half. If there is a carry... If the MSB of the low half is high, you get a time that is someplace between reading the first high half and reading the low. If the MSB of the low half is low, you get a time that is someplace between the carry and reading the second high. -- These are my opinions, not necessarily my employer's. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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 your idea... If the two highs are the same, you know a carry didn't happen between reading the highs so the answer is high, first-low. That gives you an answer that corresponds to some time when you read the first low. If the two highs differ, you know a carry did happen but you don't know if the first low was before or after the carry. You know the second low was after the carry. So use the second high, second low. That gives you a time between the carry and reading the second low. I think that works without disabling interrupts. If we are doing this with a FPGA and have interrupts disabled or a kernel lock or only one user or .., it would be easy to latch the other half on the first read so you always got a coordinated pair with just two reads. No, if the high parts differs, then the MSB of the lower part indicates which of the higher parts to go with it, MSB low is the late high read and MSB high is the early high read. Infact, by always look at the MSB then it will always be correct. With a second lower read will the low read point in time be modulated and hence jitter is added. My head hurts, but I think I have convinced myself that will work. Thanks. It can be a bit hard to visualize this... yes. Hopefully it is worth it. If there is no carry, you get the time of reading the low half. If there is a carry... If the MSB of the low half is high, you get a time that is someplace between reading the first high half and reading the low. If the MSB of the low half is low, you get a time that is someplace between the carry and reading the second high. You also need to understand the basic most common case that no carry occur between the two high readings, in that case those will be the same so we can use either of them to form the result. 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 where as if it happends just after the low read but before the high read, the low read will be just below the maximum counter value. Thus, the MSB of the low value will disclose which of the two cases we have. We can now identify that the first high read would match the case where the wrapping occurs after the low read, they both are taken on the same side of the wrapping. The second high read would match the case where the wrapping occurs before the low read, they both are taken on the same side of the wrapping. If we have a continous counter of high speed, taking a second low value would actually polute the result, as it was taken at a later time. Such a 4 read solution would add a delay for the low value whenever the carry occurs between the high reads. Using the 3 read solution avoids that as the low count is samples once and at the same time for all instances. Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
> 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 where as if it happends just after the low read but > before the high read, the low read will be just below the maximum > counter value. I'm interested in the case where interrupts and scheduling are enabled so there may be arbitrary gaps inserted into the simple code. My rule-of-thumb for "works right" is that the final answer has to correspond to a time between the first read and the last read. (Anywhere in there is OK.) I though I had convinced myself the above scheme would work, but now that I try again I'm not so sure. 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 first high sample. That corresponds to a time 0.4 seconds before the overflow. That's outside the first-last window. (I'm assuming all the reads and checking take negligible time which seems reasonable if we are talking about 0.6 seconds of gap.) I think there is a mirror image case: read high read low long gap overflow read high Suppose the long gap is 0,6 seconds so the low half will read 0.4. The MSB will be off so we use the second high sample. That will produce an answer 0.4 seconds into the future. -- These are my opinions, not necessarily my employer's. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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 value. If the wrapping of : > counter happend before reading the low part, then the low part will : > be just above 0 where as if it happends just after the low read but : > before the high read, the low read will be just below the maximum : > counter value. : : 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. : 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 first high sample. That corresponds to a time 0.4 seconds before the : overflow. That's outside the first-last window. (I'm assuming all the reads : and checking take negligible time which seems reasonable if we are talking : about 0.6 seconds of gap.) : : I think there is a mirror image case: : read high : read low : long gap : overflow : read high : : Suppose the long gap is 0,6 seconds so the low half will read 0.4. The MSB : will be off so we use the second high sample. That will produce an answer : 0.4 seconds into the future. Yes, this is why you must disable interrupts. You aren't racing other parts of software, but rather you are racing the wrapping of the counter in hardware. To reliably cope, you have to make sure that a third-party can't interrupt you producing the cases you describe... Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
>> 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 disadvantage is that you get more jitter on how long it takes to get the answer. That may be better than taking the overhead of a system call to get into the kernel. -- These are my opinions, not necessarily my employer's. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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
and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
> 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 of the variability. And reduce the failed read due to > software delay. Now a second interrupt / read will indicate delays > greater than the tick rate if our OS has interrupts that are off > greater than the tick rate minus the delay of the latch. Our choice > would be to slow the tick rate or reduce the interrupts off blind time > if we have many failed reads where the tick is more than one. The idea > would be to reduce the error to a rare event. This problem is like the > meta stable problem discussed here before so perhaps the fixes are the > same. I don't understand what you are trying to describe. There are two separate problems. One is reading 64 bits. The other is metastability. Metastability is simple. Lets assume we have 2 clocks. The PCI clock is 33 MHz. The external good-timing clock is 10 MHz. Since 10 is slower than 33, the simple way to do things is to toggle a FF with the 10 MHz clock and send that through a synchronizer to the 33 MHz domain. Each time that FF changes, we know a tick has happened so we bump the counter by 1 clock tick at 10 MHz. That's just a clock enable on the register adding 100 (ns) to itself. (assuming the register counts ns) This is simple and clean. The disadvantage is that the clock has slightly lower resolution than what might be posible. The other way is do the counting with the 10 MHz clock, perhaps after PLLing it up to 100 MHz. Now, to read the clock, you send a signal from the PCI domain through a synchronizer to the external clock domain. That copies the counter to a holding register, sends a "ready" signal back through a synchronizer to the PCI domain so the PCI logic which has been stalled can read the stable copy. This is classic 4-way handshake. You can speed things up by "knowing" (by design) that X will happen within Y clock cycles, so you only have to count to Y rather than wait for the ACK to get ack. Another approach is to use a small FIFO. In this context, FIFO means magic that solves metastability, and small means as small as you can get away with to minimize latency. Again, lets assume the PCI clock is 33 MHz and the external clock is 10 MHz PLLed up to 100 MHz. The PCI would read samples from the FIFO and add them to its counter. The external side would write samples into the FIFO. Each sample would represent the number of ns to add to the counter. Since 100 is bigger than 33, the FIFO will normally be full. So the send side can't write a constant 10 each cycle. It has to collect those 10s in a register. When the FIFO has room, it writes that register into the FIFO and resets it to the 10 for this cycle. With 33 MHz and 100 MHz, the FIFO would contain samples of 30 and 40. I think there is a simple/sneaky way to build that FIFO. It needs 2 or 4 registers. I don't remember the trick. I might be able to work it out. The other problem is how to read a 64 bit register when the hardware only supports reading 32 bit chunks. I think you either have to: fFx the hardware (or get new hardware) so it can do 64 bit atomic reads. Read the halves separately and put things together with the tricks we have been discussing. That only works if you know something about the data, for example that the whole register is a counter and the high bits only change slowly. Read one half and put the other half into a holding register where you can read it later. If you only have 1 holding register, then you have to restrict things to only 1 context is doing the reads at a time. Otherwise somebody else will come along during an interrupt or reschedule and read things. Then when you get to run again you read their copy of the holding register rather than yours. You can have multiple holding registers, but then you have to allocate 1 to each context that needs it. I don't see how a "hardware latch with a fixed delay" is going to help and/or what you have in mind. Perhaps you wanted to have the right value of other half ready when the second read happened? The problem with that is that the timing on PCI isn't predictable so a fixed delay won't work. So you need a holding register triggered by logic rather than a fixed delay. -- These are my opinions, not necessarily my employer's. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
Yes hardware, the fixed delay is triggered by the input clock and would delay the sample and latch of the counter when it is stable. The problem I was trying to solve is latching the counter while it is changing. The latch is to save the sample value for as long as needed for it to be read by the computer. 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 you were counting pulse per second not 10 MHz with your counter but if the event is external to the computer it should also control the latch, that is only latch if the counter is stable and the external event is true. Not sure what you would do with 64 bit data at a 10MHz or 100MHz rate other than a FIFO buffer. This is sounding more like a better fit for a real time operating system plus some hardware if you really need a high 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 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 of the variability. And reduce the failed read due to > software delay. Now a second interrupt / read will indicate delays > greater than the tick rate if our OS has interrupts that are off > greater than the tick rate minus the delay of the latch. Our choice > would be to slow the tick rate or reduce the interrupts off blind time > if we have many failed reads where the tick is more than one. The idea > would be to reduce the error to a rare event. This problem is like the > meta stable problem discussed here before so perhaps the fixes are the > same. I don't understand what you are trying to describe. There are two separate problems. One is reading 64 bits. The other is metastability. Metastability is simple. Lets assume we have 2 clocks. The PCI clock is 33 MHz. The external good-timing clock is 10 MHz. Since 10 is slower than 33, the simple way to do things is to toggle a FF with the 10 MHz clock and send that through a synchronizer to the 33 MHz domain. Each time that FF changes, we know a tick has happened so we bump the counter by 1 clock tick at 10 MHz. That's just a clock enable on the register adding 100 (ns) to itself. (assuming the register counts ns) This is simple and clean. The disadvantage is that the clock has slightly lower resolution than what might be posible. The other way is do the counting with the 10 MHz clock, perhaps after PLLing it up to 100 MHz. Now, to read the clock, you send a signal from the PCI domain through a synchronizer to the external clock domain. That copies the counter to a holding register, sends a "ready" signal back through a synchronizer to the PCI domain so the PCI logic which has been stalled can read the stable copy. This is classic 4-way handshake. You can speed things up by "knowing" (by design) that X will happen within Y clock cycles, so you only have to count to Y rather than wait for the ACK to get ack. Another approach is to use a small FIFO. In this context, FIFO means magic that solves metastability, and small means as small as you can get away with to minimize latency. Again, lets assume the PCI clock is 33 MHz and the external clock is 10 MHz PLLed up to 100 MHz. The PCI would read samples from the FIFO and add them to its counter. The external side would write samples into the FIFO. Each sample would represent the number of ns to add to the counter. Since 100 is bigger than 33, the FIFO will normally be full. So the send side can't write a constant 10 each cycle. It has to collect those 10s in a register. When the FIFO has room, it writes that register into the FIFO and resets it to the 10 for this cycle. With 33 MHz and 100 MHz, the FIFO would contain samples of 30 and 40. I think there is a simple/sneaky way to build that FIFO. It needs 2 or 4 registers. I don't remember the trick. I might be able to work it out. The other problem is how to read a 64 bit register when the hardware only supports reading 32 bit chunks. I think you either have to: fFx the hardware (or get new hardware) so it can do 64 bit atomic reads. Read the halves separately and put things together with the tricks we have been discussing. That only works if you know something about the data, for example that the whole register is a counter and the high bits only change slowly. Read one half and put the other half into a holding register where you can read it later. If you only have
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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 | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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 first high sample. That corresponds to a time 0.4 seconds before the : overflow. That's outside the first-last window. (I'm assuming all the reads : and checking take negligible time which seems reasonable if we are talking : about 0.6 seconds of gap.) : : I think there is a mirror image case: : read high : read low : long gap : overflow : read high : : Suppose the long gap is 0,6 seconds so the low half will read 0.4. The MSB : will be off so we use the second high sample. That will produce an answer : 0.4 seconds into the future. Yes, this is why you must disable interrupts. You aren't racing other parts of software, but rather you are racing the wrapping of the counter in hardware. To reliably cope, you have to make sure that a third-party can't interrupt you producing the cases you describe... I agree. It is only the actual reads which needs protection for this processing to work. There might be other constraints which require a large part of the code to be protected, for only for the reliable readout you can make the post-processing anytime you want. The cases of my 3 read situation is: early overflow: read high overflow read low -+ read high -+- correct pair late overflow: read high -+ read low -+- correct pair overflow read high no overflow: read high -+- equal value => pick any of them freely read low | read high -+ Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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 different. This disadvantage is that you get more jitter on how long it takes to get the answer. That may be better than taking the overhead of a system call to get into the kernel. If we are talking about timestamping an interrupt for instance this should not be a major issue. For a micro-kernel, things which normally go into a device driver should be put in a suitable task. Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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 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. I was planning to drive that with a stable external clock, say a GPSDO. So if things were setup properly, it should be a very good clock. The typical Unix clock is implemented by looking at the TSC. I think that's Intel's term for a register that counts each CPU cycle, Time Stamp Counter. The CPU comes from an inexpensive crystal. The frequency of that crystal varies (wildly) with temperature. The temperature varies with activity. The basic idea is that you maintain a reference time and TSC value. To get the current time, you read the TSC, subtract off the reference TSC. That gives you the number of CPU clock ticks since the reference time. Convert that to nanoseconds, add on the reference time, and normalize. You have to update the reference info periodically, in particular before that subtract will over/underflow. phk points out that you can use the TSC type clock logic by reading a simple counter from the FPGA rather than the TSC register. That gets you a stable clock without all the problems with reading 64 bits from the FPGA. You could also replace the CPU crystal with a clock derived via a PLL from your stable 10 MHz clock. Things get slightly messy because the CPU and PCI clocks usually have some spread spectrum to reduce EMI. I don't have numbers. I expect it will be small/tiny, but I'll bet you can measure it. That just gets you a basic clock. If you also feed a PPS signal into the FPGA, then you can get very accurate timings by grabbing a copy of the time register(s) on the leading edge of the PPS signal. That has metastability opportunities, but if you can solve the basic metastability issues, the same trick will work here. As phk points out, the idea of putting the whole Unix clock in the FPGA may be silly. It seemed like a fun problem so I've been thinking about how to do it. Another variation that might be interesting... The implementations I described previously all assumed the clocks had round numbers so you could do things like add 30 or 40 ns to the counter each PCI clock tick. Those round numbers are convenient. You could also add fractions of a ns. Since this stuff can be pipelined as much as necessary to meet timings, you can make the fractional part as wide as you want to get better accuracy. This might be handy if your external clock was slightly off, say a Rubidium that wasn't calibrated. -- These are my opinions, not necessarily my employer's. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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 guys stop reinventing the octagonal wheel, and at least look at the blueprint for the round wheel ? http://phk.freebsd.dk/pubs/timecounter.pdf If there is anything you don't understand or wants explained in that paper, by all means ask! -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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 > order to get reasonable timings. > > 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. > I would make that "magic time" the time when power was applied. Do the transformation from "hardware time" to "Unix time" in software (since it requires just arithmetic.. An add (offset between the two time zeros) and a multiply (for the scale factor between "unix time" and your hardware counter) If you have a solution where you "jam" the hardware counter to "set it", you always have a question about the latency of that set operation. It's pretty easy in hardware (FPGA) to arrange an "atomic" read of an arbitrarily long counter into a holding register, which software then reads. > > > I was planning to drive that with a stable external clock, say a GPSDO. So if > things were setup properly, it should be a very good clock. > > The typical Unix clock is implemented by looking at the TSC. I think that's > Intel's term for a register that counts each CPU cycle, Time Stamp Counter. > The CPU comes from an inexpensive crystal. The frequency of that crystal > varies (wildly) with temperature. The temperature varies with activity. I don't know about wildly. Certainly in time-nuts land, a few tens of ppm is wild variation, but in the overall scheme of things, it's still reasonably good. > > The basic idea is that you maintain a reference time and TSC value. To get > the current time, you read the TSC, subtract off the reference TSC. That > gives you the number of CPU clock ticks since the reference time. Convert > that to nanoseconds, add on the reference time, and normalize. You have to > update the reference info periodically, in particular before that subtract > will over/underflow. > > ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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 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 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. >> > > I would make that "magic time" the time when power was applied. Do the > transformation from "hardware time" to "Unix time" in software (since it > requires just arithmetic.. An add (offset between the two time zeros) and a > multiply (for the scale factor between "unix time" and your hardware > counter) I also wouldn't have the low order counter count nanoseconds, or even set it up as seconds/subseconds. Use one long counter that counts whatever frequency you want to count. An integer divide in software is quite fast (unless you're working with something like a Z80). There's no real advantage in having "hardware" count seconds.. It takes more gates to count by arbitrary N than 2^M. Also, say you set your counters up to divide by 10E6..assuming you have a 10MHz source. And then you find that your source is really 10,000,001 Hz (I know... A 0.1 ppm error is anathema in this crowd).. Now, if you want to convert your (estimated seconds, estimated nanoseconds) into "real" time, you've got tricky arithmetic to do (with all the roundoff and arithmetic issues to deal with). Ticks = secondscounter*nominaltickrate + subsecondscounter; Realseconds = floor(ticks/actualtickrate) Realsubseconds = remainder/actualtickrate; ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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 in having "hardware" count seconds.. It takes more
>gates to count by arbitrary N than 2^M.
Not only that, it makes the calculation of timeintervals as differences
between two timestamps a royal mess:
#define timersub(tvp, uvp, vvp) \
do {\
(vvp)->tv_sec = (tvp)->tv_sec - (uvp)->tv_sec; \
(vvp)->tv_usec = (tvp)->tv_usec - (uvp)->tv_usec; \
if ((vvp)->tv_usec < 0) { \
(vvp)->tv_sec--;\
(vvp)->tv_usec += 100; \
} \
} while (0)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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 rounding could lead to systematic errors that would lead to a higher noise in the measurements. A simple counter is more flexible. It allows for a number of additional algorithms to be applied to the raw time measurements to account for drift in the underlying oscillator. Phk's timecounters allow for this. They assume a time source that is free-running. It can be measured against a known better source to improve its accuracy (which is what ntpd does). This allows one to correct over time for, say, the relatively crappy internal oscillator found in most PCs. The nice thing about timecounters is they allow hardware as described in this thread to replace the underlying system hardware. Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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 programmers. Out of pure interest: what makes handling of time difficult? >From an uneducated point of view it's just updating a counter in software from a time source in hardware. Attila Kinali -- If you want to walk fast, walk alone. If you want to walk far, walk together. -- African proverb ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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 that you can and should use a binary fraction instead of a decimal
fraction.
People are so used to thinking about milli-, micro- and nanoseconds
that they simply fail to recognize those as presentation formats for
an underlying real number.
Time is, for all we know, a continuous scale, it does not come in
small countable parcels, so the correct and ideal format is a
floating point format, not a fixed point format.
Time values have about 20 significant decimal places in regular
computer operation these days: subtracting two nanosecond resolution
timestamps will get you there, because of our choice of epoch for
time_t.
That _almost_ fits into a 64 bit integer in 32.32 format, even if
you choose to do the decimal fraction stupidity and let the fraction
count nanoseconds.
NTP does that or example.
However, we run out of seconds in slightly less than 30 years time
that way, NTP can live with that, it's packets are short lived,
but permanent records in an archive can not.
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.
It would get my vote however because it is the difference between:
int64_t t0, t1, dt;
[...]
dt = t1 - t0;
and
struct timespec t0, t1, dt;
[...]
dt = t0;
dt.tv_sec -= t1.tv_sec;
dt.tv_nsec -= t1.tv_nsec;
if (dt.tv_nsec < 0) {
dt->tv_sec--;
dt->tv_nsec += 10;
}
/* XXX: still left with a two-component time difference */
The truly long term solution is IEEE 128 bit floating point format,
you can resolve 1 years to femto-seconds and still have 7 decimal
digits of precsion to play with.
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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. : > : > Well, no. : > : > But figuring out correct handling of time is a challenge for operating : > system programmers. : : Out of pure interest: what makes handling of time difficult? : >From an uneducated point of view it's just updating a counter : >From an uneducated point of view it's just updating a counter : in software from a time source in hardware. Simple, naive time keeping is easy. Look at all the folks that make wrist watches. However, when you are trying to get higher and higher accuracy for the time, you have to talk to external folks. Doing this introduces latency. There's variation in this latency, and that limits the synchronization of the times. Also, there are a number of environmental factors that affect the quality of the underlying time keeping hardware since most crystals are sensitive to temperature. Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
> 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 supports two time scales: (1) TAI64, covering a few hundred billion years with 1-second precision; (2) TAI64NA, covering the same period with 1-attosecond precision. Both scales are defined in terms of TAI, the current international real time standard. " TAI64NA in FPGA? -- http://www.wearablesmartsensors.com/ http://www.softwaresafety.net/ http://www.designer-iii.com/ http://www.unusualresearch.com/ ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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 library for storing and manipulating dates and times.
>
> libtai supports two time scales: (1) TAI64, covering a few hundred
> billion years with 1-second precision; (2) TAI64NA, covering the same
> period with 1-attosecond precision. Both scales are defined in terms
> of TAI, the current international real time standard. "
>
> TAI64NA in FPGA?
>
Of course...buried in the install notes
"But keep in mind that this is a very early release. Some of
the code hasn't been tested at all! "
As of 1998...
It also breaks the time up into seconds, nanoseconds, and attoseconds, as
separate chunks, so math isn't trivial
struct taia {
struct tai sec;
unsigned long nano; /* 0...9 */
unsigned long atto; /* 0...9 */
} ;
I don't think this library buys you a whole lot (other than useful routines
to do things like calculate easter or leap days/seconds), but at the basic
"how does one keep time" level, not particularly an improvement.
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 spacecraft
running with "time" at the expected EDL time. But, you want to have
everybody sync'd to a common source.
So, it's easy to get all the computers controlling the test gear sync'd to
UTC or TAI using something like NTP, but you need a way to have precision
"simulated time" as well.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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 buys you anything, except trouble. It is a perfect example of what I said earlier: people cannot grasp that time do not come in parcels... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
> 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 spacecraft running with "time" at the expected EDL time. But, you > want to have everybody sync'd to a common source. > So, it's easy to get all the computers controlling the test gear > sync'd to UTC or TAI using something like NTP, but you need a way to > have precision "simulated time" as well. Is the "entire testbed" isolated from the rest of the network? (If not, what do you do about the time warp?) Just setup a ntpd running with the local clock (127.127.1.0). Set the time manually and point all of your other boxes at it. Details TBD. You will probably have to restart ntpd since they won't jump more than 1000 seconds once it is running. It local-server box keep (much) better time if you let it run normally for a while to calibrate the drift factor. You can also use one of the refclock drivers that supports an offset fudge factor. Just set the fudge factor to shift by the desired amount. (I haven't tried it. Please let me know if it does or doesn't work.) -- These are my opinions, not necessarily my employer's. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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 wrong with TAI64NA?
: >
: > http://cr.yp.to/libtai.html
: >
: > "libtai is a library for storing and manipulating dates and times.
: >
: > libtai supports two time scales: (1) TAI64, covering a few hundred
: > billion years with 1-second precision; (2) TAI64NA, covering the same
: > period with 1-attosecond precision. Both scales are defined in terms
: > of TAI, the current international real time standard. "
: >
: > TAI64NA in FPGA?
: >
:
: Of course...buried in the install notes
:
: "But keep in mind that this is a very early release. Some of
: the code hasn't been tested at all! "
:
: As of 1998...
:
: It also breaks the time up into seconds, nanoseconds, and attoseconds, as
: separate chunks, so math isn't trivial
:
: struct taia {
: struct tai sec;
: unsigned long nano; /* 0...9 */
: unsigned long atto; /* 0...9 */
: } ;
:
:
: I don't think this library buys you a whole lot (other than useful routines
: to do things like calculate easter or leap days/seconds), but at the basic
: "how does one keep time" level, not particularly an improvement.
:
:
: 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 spacecraft
: running with "time" at the expected EDL time. But, you want to have
: everybody sync'd to a common source.
:
: So, it's easy to get all the computers controlling the test gear sync'd to
: UTC or TAI using something like NTP, but you need a way to have precision
: "simulated time" as well.
We did something akin to this at a previous employer. On the whole,
we found that math was more compute intensive than the fractional
method that phk recommends, but that the presentation to the user was
easier with this break down. We opted to stick with this breakdown.
The other problem you run into is that you're often given a time in
UTC time, but need to operate on TAI time so that you kick something
every second and aren't affected by leap seconds. There are many
other time scales that are in use that you can get data from as well.
Plus many different conventions for dealing with things (like an
fractional MJD: is that always computed with / 86400 or do you use
/86401 on positive leap days?) All these details can be a pita to get
right and belong in a base library.
So libtai can work in theory, but we found we had to add a lot to it.
Warner
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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 entry,descent,landing scenario, you want >> the spacecraft running with "time" at the expected EDL time. But, you >> want to have everybody sync'd to a common source. > >> So, it's easy to get all the computers controlling the test gear >> sync'd to UTC or TAI using something like NTP, but you need a way to >> have precision "simulated time" as well. > > Is the "entire testbed" isolated from the rest of the network? (If not, what > do you do about the time warp?) Unfortunately not.. And you have the annoying thing of modern test instruments that run, e.g. Windows Embedded, and have internal clocks, so when you capture a measurement, the file date/time is the system date/time. In the long run, I think it's easier to keep everything on one time base (e.g. TAI/UTC), and fight the downstream battles to turn "observed time" into simulated time. But it gets tricky with things that use timecode (IRIG-B, for instance) and send 1553 messages. I don't think there is a universally "good" solution, in any case. > > Just setup a ntpd running with the local clock (127.127.1.0). Set the time > manually and point all of your other boxes at it. Details TBD. You will > probably have to restart ntpd since they won't jump more than 1000 seconds > once it is running. And, there's the problem of keeping things straight between the "local time" and "global time". > > It local-server box keep (much) better time if you let it run normally for a > while to calibrate the drift factor. > ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
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... ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
