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?
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?
> [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?
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?
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?
> 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?
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?
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?
> 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?
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?
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?
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?
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?
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] Help needed: Jupiter-T TU60-D120
Lasse & Richard Further to your discussions regarding interfacing the Jupiter TU60-D120. There would seem to be a number of varieties of these units which one would expect to find some common interface connections and software control, but I gather this is not the case. I am currently trying to set up two varieties, one is the TU30-D200 and the other is the TU30-D145, the latter being the simpler "Tracker" type. Can anybody confirm the connection field for each of these types as they do not seem to correspond to some printed/down-loaded data that I have ? I would appreciate any information on these two units. Roy Message - From: "Richard H McCorkle" To: "Discussion of precise time and frequency measurement" Sent: Monday, May 11, 2009 6:23 PM Subject: Re: [time-nuts] Help needed: Jupiter-T TU60-D120 Lasse, If you are getting a Message ID 1180 at power-on you are in Navman bin mode and the EEPROM power-on default has been set to this mode. You need to send Message ID 1331 using LabMon to set it back to Motorola protocol before TAC32 can talk to it. Richard I got a Jupiter-T TU60 off eBay and my intentions are (was) to get a diciplined oscillator running. Somehow I expected it to be pretty similar (command wise) to a TU-30 wich is up and running here, but must have missed the information that it starts in Motorola Bin?? My TU60 will just say "ff 81 9c 04 01 00 00 00 64 79 00 00 00 00" at power-up (Message ID 1180) once, then nothing. After installing TAC32 (demo) yesterday I managed (don't ask me how) get the uint running, everything looked OK, I then wanted to put it inot Navman Bin mode. This should be safe as according to datasheet as it will revert to Motorola commands when cycling the power. After trying @@Wb, but nothing from Labmon/WinLabmon, and now TAC32 cannot get in contact with the GPS, I let the GPS be off power over night but it sill refuses to connect to TAC32. Have I put my Jupiter in a mode that I cannot revert? It still reports the MessageID 1180 at power-on. Or was I just plain lucky once to somhow fool TAC32 to get the Jupiter to run? Any hints or comments are most welcome! /Lasse ___ 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. ___ 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?
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?
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: 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.
[time-nuts] FreeBSD, NetBSD, or Minix-III?
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 regard to time services? http://www.netbsd.org/ 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. http://en.wikipedia.org/wiki/MINIX_3 http://www.minix3.org/ -- 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.
