[opensuse] Time stability
This is probably a hardware issue, but I need to see how to investigate: I run SUSE 10.0 and 10.1 on various computers. Usually, we set it up so that the computer time is set to UTC, and we then state where we are in the world. On many machines, we have a problem where the time seems to get screwy between boots. It is usually the time of day more than the date. The error seems to be random. Not just the hour. But the minutes as well. So, we then tried setting the computer to local time, informing SUSE of this. Same problem. I am guessing that the motherboards have some issues. They are all rather new and made by SuperMicro. I am not sure if they are all the exact same model (I am checking). How could I get SUSE to record what the hardware time was when it boots, before making any changes, and then what it is after any changes? Same thing on power down. I guess this is tricky because these things probably happen when there are no disks mounted. Any ideas? I know I could check the BIOS each time. But I am not sure I can get the users to do this reliably. Any ideas or suggestions? -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Tel: Int +46 8-615 60 20 Fax: Int +46 8-31 42 23 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Friday 16 March 2007, Roger Oberholtzer wrote:
This is probably a hardware issue, but I need to see how to investigate:
Any ideas or suggestions?
Can't you use NTP to set the time on boot i take it they are all connected to the net or a network with one machine connected to the internet setup a ntp server use that to check against at boo time .. Pete -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, 2007-03-16 at 10:32 +0000, peter nikolic wrote:
On Friday 16 March 2007, Roger Oberholtzer wrote:
This is probably a hardware issue, but I need to see how to investigate:
Any ideas or suggestions?
Can't you use NTP to set the time on boot i take it they are all connected to the net or a network with one machine connected to the internet setup a ntp server use that to check against at boo time ..
Ahh. I forgot to mention one important fact. These computers are in vehicles on the road. If they cannot figure it out on their own, it wont be figured out. They do have GPS. However, I have not found an efficient way to share the GPS NMEA recored with nntp and our measurement software, which needs the records with little (read no) delay. -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Tel: Int +46 8-615 60 20 Fax: Int +46 8-31 42 23 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer wrote:
On Fri, 2007-03-16 at 10:32 +0000, peter nikolic wrote:
Can't you use NTP to set the time on boot i take it they are all connected to the net or a network with one machine connected to the internet setup a ntp server use that to check against at boo time ..
Ahh. I forgot to mention one important fact. These computers are in vehicles on the road. If they cannot figure it out on their own, it wont be figured out.
They do have GPS. However, I have not found an efficient way to share the GPS NMEA recored with nntp and our measurement software, which needs the records with little (read no) delay.
I don't know anything about this, but it's an interesting topic to me (I go sailing :) A quick http://www.google.com/linux?q=gps+nmea+time+ntp showed lots of hits including one that says "The Star Sync GPS receiver plugs into a serial port and interfaces with the generic GPS NMEA driver included with the standard NTP distribution." If there's a generic GPS driver in the NTP distribution, as it claims, couldn't you use that to sync the machines? Or is the key word in your problem 'share'? Aren't the NMEA time sentences broadcast so you just need some 'plumbing' to send it to both destinations (an extra cable, a small shell script, a one-line C program, whatever is appropriate) The gpsd man page has a section on 'use with ntp', for example. Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, 2007-03-16 at 13:39 +0000, Dave Howorth wrote:
Roger Oberholtzer wrote:
On Fri, 2007-03-16 at 10:32 +0000, peter nikolic wrote:
Can't you use NTP to set the time on boot i take it they are all connected to the net or a network with one machine connected to the internet setup a ntp server use that to check against at boo time ..
Ahh. I forgot to mention one important fact. These computers are in vehicles on the road. If they cannot figure it out on their own, it wont be figured out.
They do have GPS. However, I have not found an efficient way to share the GPS NMEA recored with nntp and our measurement software, which needs the records with little (read no) delay.
I don't know anything about this, but it's an interesting topic to me (I go sailing :)
A quick http://www.google.com/linux?q=gps+nmea+time+ntp showed lots of hits including one that says "The Star Sync GPS receiver plugs into a serial port and interfaces with the generic GPS NMEA driver included with the standard NTP distribution."
If there's a generic GPS driver in the NTP distribution, as it claims, couldn't you use that to sync the machines?
The systems are high speed high data rate data collection systems. We strive to eliminate repackaging data all over the place. Also, the gpsd method removes any supplier-specific NMEA records, which we want. It is part of the reason for going tor the Trimble line.
Or is the key word in your problem 'share'? Aren't the NMEA time sentences broadcast so you just need some 'plumbing' to send it to both destinations (an extra cable, a small shell script, a one-line C program, whatever is appropriate)
The values are over a serial port. These are high-end Trimble receivers. The reason for the serial port is that there is a pulse-per-second signal that tells when certain calculations in the receiver were done. We are striving for sub-meter accuracy in a vehicle traveling up to 110 km/h. Any transmission delay from when something is calculated to when it is received is a source of error. The pps signal helps eliminate this. I would be very happy if there was an ethernet or usb receiver that still had all these features. Unfortunately, they typically are geared for less demanding location requirements and so do not provide these extra signals. We keep looking and hoping. There are some PCI-based models that look interesting.
The gpsd man page has a section on 'use with ntp', for example.
I would be happy if the ntp daemon could be told when to use the receiver, and when not to use it. But I do not think this is the way it is. The GPS will give bad/old/misc times when there are no receivers. Like in a garage. Which is where the measurement systems often are started. -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Tel: Int +46 8-615 60 20 Fax: Int +46 8-31 42 23 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer wrote:
The values are over a serial port. These are high-end Trimble receivers. The reason for the serial port is that there is a pulse-per-second signal that tells when certain calculations in the receiver were done. We are striving for sub-meter accuracy in a vehicle traveling up to 110 km/h. Any transmission delay from when something is calculated to when it is received is a source of error. The pps signal helps eliminate this.
gpsd appears to know about PPS signals.
I would be very happy if there was an ethernet or usb receiver that still had all these features. Unfortunately, they typically are geared for less demanding location requirements and so do not provide these extra signals. We keep looking and hoping. There are some PCI-based models that look interesting.
The gpsd man page has a section on 'use with ntp', for example.
I would be happy if the ntp daemon could be told when to use the receiver, and when not to use it. But I do not think this is the way it is. The GPS will give bad/old/misc times when there are no receivers. Like in a garage. Which is where the measurement systems often are started.
So the GPS is connected to your software and that is deciding whether the signals are good? So why not set the system time from your software, either by starting and stopping ntpd appropriately or by directly setting the time? Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, 2007-03-16 at 15:40 +0000, Dave Howorth wrote:
Roger Oberholtzer wrote:
The values are over a serial port. These are high-end Trimble receivers. The reason for the serial port is that there is a pulse-per-second signal that tells when certain calculations in the receiver were done. We are striving for sub-meter accuracy in a vehicle traveling up to 110 km/h. Any transmission delay from when something is calculated to when it is received is a source of error. The pps signal helps eliminate this.
gpsd appears to know about PPS signals.
Which is good. But it does not propagate them. We sync with other external systems when we get the pps signal. So, we really want it! On Linux, there is an ioctl() that returns when the serial port line changes. It is rather quick. We checked this by manipulating the line from the same computer's parallel port. The time from when we toggled the line to when our ioctl() returned were usually on the order of 20 microseconds, according to gettimeofday(). We also use this with photocells to precisely locate control measurements. As serial and parallel ports go away in modern computers, I wonder how this functionality will be maintained. Expensive I/O cards will now be required.
I would be very happy if there was an ethernet or usb receiver that still had all these features. Unfortunately, they typically are geared for less demanding location requirements and so do not provide these extra signals. We keep looking and hoping. There are some PCI-based models that look interesting.
The gpsd man page has a section on 'use with ntp', for example.
I would be happy if the ntp daemon could be told when to use the receiver, and when not to use it. But I do not think this is the way it is. The GPS will give bad/old/misc times when there are no receivers. Like in a garage. Which is where the measurement systems often are started.
So the GPS is connected to your software and that is deciding whether the signals are good? So why not set the system time from your software, either by starting and stopping ntpd appropriately or by directly setting the time?
We do not run as root. And, we do not want the time to change when we are up and running. Only when we start. I am sure something could be cobbled together. We are not requiring that the PC time be in sync with the GPS. Our software figures out what the differences are and happily sorts that out. The main annoyance is that data file access and all does not have the proper time. Files that were created in the future are problematic for some software. Not to mention poor data control droids. Also, if you reboot in a garage without gps availability, you have the odd times. The question is still, why does a reboot cause a messed up time. -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Tel: Int +46 8-615 60 20 Fax: Int +46 8-31 42 23 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2007-03-16 at 16:59 +0100, Roger Oberholtzer wrote:
photocells to precisely locate control measurements. As serial and parallel ports go away in modern computers, I wonder how this functionality will be maintained. Expensive I/O cards will now be required.
rs232 <--> usb converters, that's the cheap way...
The question is still, why does a reboot cause a messed up time.
That part is the adjtime file. The rest, I don't know. However, if you touch the clock in anyway, this file is affected: it will be incorrect, so it's better to force a reset deleting it. About the ntpd, if you are developing, I would think about your software feeding data to ntpd, instead of the other way round. Or duplicate the data via a "splitter". Maybe there is a simple way. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFF+uyWtTMYHG2NR9URAmNAAJ4w8D5UbnxTRZ8p2FPDrTrbkl6RXwCeLXOg +4Lh1DqolpUY5HD2+AqxItg= =z8Mt -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, 2007-03-16 at 20:14 +0100, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The Friday 2007-03-16 at 16:59 +0100, Roger Oberholtzer wrote:
photocells to precisely locate control measurements. As serial and parallel ports go away in modern computers, I wonder how this functionality will be maintained. Expensive I/O cards will now be required.
rs232 <--> usb converters, that's the cheap way...
Except that usb converters do not transfer all the modem control lines quickly. At least the ones I have tried.The pps signal is on a modem control line. The modem control lines are very quick - not related to the baud rate.
The question is still, why does a reboot cause a messed up time.
That part is the adjtime file. The rest, I don't know. However, if you touch the clock in anyway, this file is affected: it will be incorrect, so it's better to force a reset deleting it.
About the ntpd, if you are developing, I would think about your software feeding data to ntpd, instead of the other way round.
Or duplicate the data via a "splitter". Maybe there is a simple way.
Another reason we want to avoid having ntpd running when we do our thing is that we do not want the time to change. And ntpd will always do tiny adjustments. -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Tel: Int +46 8-615 60 20 Fax: Int +46 8-31 42 23 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2007-03-16 at 20:30 +0100, Roger Oberholtzer wrote:
rs232 <--> usb converters, that's the cheap way...
Except that usb converters do not transfer all the modem control lines quickly. At least the ones I have tried.The pps signal is on a modem control line. The modem control lines are very quick - not related to the baud rate.
True enough. And it probably rises an interrupt, so you can get almost real time response. Then you will have to get port pci cards, but if you are using portables, you are out of luck. pcmcia then?
About the ntpd, if you are developing, I would think about your software feeding data to ntpd, instead of the other way round.
Or duplicate the data via a "splitter". Maybe there is a simple way.
Another reason we want to avoid having ntpd running when we do our thing is that we do not want the time to change. And ntpd will always do tiny adjustments.
Very true. You have to wait till the clock is synced, but even then, it will be very slightly nudged now and then. But I suppose you can use the gps clock directly, instead of system time. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFF+w8atTMYHG2NR9URAoH+AJ4soqIJ2WnqQ0uHOnNLAaMeEUcNtACfRR4m lv6ZfHZOTGo8PTxFYGFsD1c= =Si6S -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Carlos E. R. wrote:
Then you will have to get port pci cards, but if you are using portables, you are out of luck. pcmcia then?
I would be shocked if no one makes a USB device with some input and output terminals for this kind of basic "bit-banging" I/O. PC Cards with RS-232 ports or parallel ports also still exist, although they probably aren't cheap. Basically, where you used to get one or two ports for free on each machine that you could use for this kind of basic I/O, in the future you're going to have to pay for them. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2007-03-16 at 15:11 -0700, David Brodbeck wrote:
Then you will have to get port pci cards, but if you are using portables, you are out of luck. pcmcia then?
I would be shocked if no one makes a USB device with some input and output terminals for this kind of basic "bit-banging" I/O.
But not all signals are considered.
PC Cards with RS-232 ports or parallel ports also still exist, although they probably aren't cheap.
Dunno about price.
Basically, where you used to get one or two ports for free on each machine that you could use for this kind of basic I/O, in the future you're going to have to pay for them.
If I have to pay for a port that I'm going to use for some kind of DAQ, I would get a real DAQ card instead: even a cheap one would be much better. A D/O, D/I card is far easier to use than a printer parallel port (a single cpu instruction, that's all). And, for cheap I/O, there are usb things doing the job already (not really cheap, probably). The problem is when you need speed and/or sync, as Roger says. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFF+z3EtTMYHG2NR9URAvHsAJ4kkJ0SAV/UVKMELuhThQ8DjRqWWQCfcHeE n8SdbagsC2jisKf9XhayOPU= =Qtob -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, 2007-03-16 at 15:11 -0700, David Brodbeck wrote:
Carlos E. R. wrote:
Then you will have to get port pci cards, but if you are using portables, you are out of luck. pcmcia then?
I would be shocked if no one makes a USB device with some input and output terminals for this kind of basic "bit-banging" I/O. PC Cards with RS-232 ports or parallel ports also still exist, although they probably aren't cheap.
The USB protocol is not instantaneous. It is packet based. A packet needs to get across the interface, be decoded, find its way up the USB driver chain to the client app. The serial port, OTOH, provides an interrupt direct into one driver without any hardware packeting. It is measurably quicker.
Basically, where you used to get one or two ports for free on each machine that you could use for this kind of basic I/O, in the future you're going to have to pay for them.
Progress. -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Tel: Int +46 8-615 60 20 Fax: Int +46 8-31 42 23 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, 2007-03-16 at 22:41 +0100, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The Friday 2007-03-16 at 20:30 +0100, Roger Oberholtzer wrote:
rs232 <--> usb converters, that's the cheap way...
Except that usb converters do not transfer all the modem control lines quickly. At least the ones I have tried.The pps signal is on a modem control line. The modem control lines are very quick - not related to the baud rate.
True enough. And it probably rises an interrupt, so you can get almost real time response.
Then you will have to get port pci cards, but if you are using portables, you are out of luck. pcmcia then?
No laptops. They do not survive regular use in road measurement. We already use PCI serial port cards. But they are so much more than a nice 16550-ish chip. Seems like a bit of overkill.
About the ntpd, if you are developing, I would think about your software feeding data to ntpd, instead of the other way round.
Or duplicate the data via a "splitter". Maybe there is a simple way.
Another reason we want to avoid having ntpd running when we do our thing is that we do not want the time to change. And ntpd will always do tiny adjustments.
Very true. You have to wait till the clock is synced, but even then, it will be very slightly nudged now and then. But I suppose you can use the gps clock directly, instead of system time.
As a result of our synchronization, we do that: read the system clock and, using the offset determined at sync time, convert that to the gps time. So we never really require that we get gps data over the serial port in a deterministic fashion. Of course, if the PC system clock drifts, we are screwed. -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Tel: Int +46 8-615 60 20 Fax: Int +46 8-31 42 23 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2007-03-16 at 23:19 +0100, Roger Oberholtzer wrote:
Then you will have to get port pci cards, but if you are using portables, you are out of luck. pcmcia then?
No laptops. They do not survive regular use in road measurement. We already use PCI serial port cards. But they are so much more than a nice 16550-ish chip. Seems like a bit of overkill.
Well... it is what happens using out of the self hardware.
Very true. You have to wait till the clock is synced, but even then, it will be very slightly nudged now and then. But I suppose you can use the gps clock directly, instead of system time.
As a result of our synchronization, we do that: read the system clock and, using the offset determined at sync time, convert that to the gps time. So we never really require that we get gps data over the serial port in a deterministic fashion. Of course, if the PC system clock drifts, we are screwed.
I thought you were using the data message from the gps unit to get both position and time stamp to use in your calculations, ignoring computer system time. At least, that's how I would try to do it. The system time without ntpd will surely drift, but constantly, no variation (hopefully). With ntpd it is supposed to be kept in sync with the "real world perfect time", but of course, you have to check if it is synced, and it will be slowed or accelerated now and then: thus variable drift. If the source for ntpd sync is a gps unit, it should be able, after a stabilization time, to keep almost perfect sync. Should. You would have to do measurements to ensure this is really so, I guess. Or study the source code to check what variations you cold be getting. And/or read ntpd documentation: I don't suppose they had precision measurements in mind when they designed it, but... maybe the did consider it and wrote about that somewhere.. The cmos clock drift and adjtime file is a completely different matter. It is only considered during boot and halt sequences; the intention is to set the system clock as accurately as possible, once: during start up. Unfortunately, it can misfire. I wrote a small description of how suse handles this. It was included in the old unofficial suse faq, somewhere in sourceforge, time ago. You might find it interesting. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFF+zuXtTMYHG2NR9URAm3FAJ9t7OmO3E4CybCyZVQDkNLJ0j1qcQCglhOW Qld5OvaPQ/eexHeKDGnhB0s= =zdsb -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, 2007-03-17 at 01:51 +0100, Carlos E. R. wrote:
I thought you were using the data message from the gps unit to get both position and time stamp to use in your calculations, ignoring computer system time. At least, that's how I would try to do it.
GPS data over the serial port is non-deterministic. You cannot make reasonable time assumptions with it because it arrives when it arrives. If you want precise and current time, look at something like http://www.spectracomcorp.com/Portals/0/products/pdf/TSAT-PCI.pdf. It makes gps time available via the pci bus. This type of card eliminates problems with PC clock drift. Too bad the cards cost > $3000 USD. In addition, they charge $300 for the Linux device driver. OK. At least they support Linux. And, they charge the same for the Windows driver, so I guess they are at least consistent.
The system time without ntpd will surely drift, but constantly, no variation (hopefully). With ntpd it is supposed to be kept in sync with the "real world perfect time", but of course, you have to check if it is synced, and it will be slowed or accelerated now and then: thus variable drift.
This is our opinion as well. But it is a risky assumption. Any motherboard is free to have a bug.
I wrote a small description of how suse handles this. It was included in the old unofficial suse faq, somewhere in sourceforge, time ago. You might find it interesting.
I will look it up. -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Tel: Int +46 8-615 60 20 Fax: Int +46 8-31 42 23 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2007-03-17 at 18:03 +0100, Roger Oberholtzer wrote:
I wrote a small description of how suse handles this. It was included in the old unofficial suse faq, somewhere in sourceforge, time ago. You might find it interesting.
I will look it up.
http://susefaq.sourceforge.net/howto/time.html I wrote it years ago (2003), but I believe it is still correct. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFF/FPwtTMYHG2NR9URAhPuAJ9CWSSkppHMvkCqztD8UDWF4uyVtACeIhh8 lTA6oWXAYhTcol+V/L0mEQY= =bwuR -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Op zaterdag 17 maart 2007 21:47, schreef Carlos E. R.:
http://susefaq.sourceforge.net/howto/time.html
I wrote it years ago (2003), but I believe it is still correct.
Anyway it is very educative! -- Richard Bos Without a home the journey is endless -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
We are striving for sub-meter accuracy in a vehicle traveling up to 110 km/h. Is that even possible? Even with WAAS, I've never seen anything better
Roger Oberholtzer wrote: than 2m accuracy. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, 2007-03-16 at 19:10 -0400, James Knott wrote:
We are striving for sub-meter accuracy in a vehicle traveling up to 110 km/h. Is that even possible? Even with WAAS, I've never seen anything better
Roger Oberholtzer wrote: than 2m accuracy.
We also have a fair assortment of inclinometers, accelerometers, gyroscopes and distance measurement devices. GPS alone is never going to cut it. It is when synchronizing all these devices that small variations in time are relevant. We are at the point where a big part of the error is that the driver can't keep the vehicle in the correct part of the lane! -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Tel: Int +46 8-615 60 20 Fax: Int +46 8-31 42 23 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer wrote:
We are at the point where a big part of the error is that the driver can't keep the vehicle in the correct part of the lane!
Ah... So you're measuring taxis. ;-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2007-03-17 at 18:06 +0100, Roger Oberholtzer wrote:
We also have a fair assortment of inclinometers, accelerometers, gyroscopes and distance measurement devices. GPS alone is never going to cut it. It is when synchronizing all these devices that small variations in time are relevant.
Ah! Now I understand why you need precision system time, and the time stamp of the gps data is not enough. You need to measure and sync other sensors data. Very interesting project :-) By the way, if you are using a data adquisition card, they often have their own clock of one kind or another. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFF/FBCtTMYHG2NR9URAuUgAJ974Es46JA5IvcXRrMSiJfPDTD7kwCaAsRR a8L93R5FEcEJ71Kisz6pGG4= =E1RG -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, 2007-03-17 at 21:31 +0100, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The Saturday 2007-03-17 at 18:06 +0100, Roger Oberholtzer wrote:
We also have a fair assortment of inclinometers, accelerometers, gyroscopes and distance measurement devices. GPS alone is never going to cut it. It is when synchronizing all these devices that small variations in time are relevant.
Ah! Now I understand why you need precision system time, and the time stamp of the gps data is not enough. You need to measure and sync other sensors data.
Very interesting project :-)
By the way, if you are using a data adquisition card, they often have their own clock of one kind or another.
We have our own VME-based cards that capture and analyze. It indeed does have a clock and stamps all collected data. But it is external to the computer, so we need to sync time with it, the gps and other devices. Glad we use Linux for this. -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Tel: Int +46 8-615 60 20 Fax: Int +46 8-31 42 23 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, 2007-03-17 at 18:06 +0100, Roger Oberholtzer wrote:
GPS alone is never going to cut it.
I remember I was impressed a long time ago, when I did some work with the BBC, because the clock signal they had coming out of the wall in every room came from their atomic clock. Years later in a telecom switchroom I was shown five clocks. The first four were GPS clocks. Only if all of those failed did they refer to the atomic clock. So I guess they agreed with you! And they had the advantage of being in a fixed location :) Cheers, Dave PS Have you got any further with the boot clock problem? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Dave Howorth wrote:
On Sat, 2007-03-17 at 18:06 +0100, Roger Oberholtzer wrote:
GPS alone is never going to cut it.
I remember I was impressed a long time ago, when I did some work with the BBC, because the clock signal they had coming out of the wall in every room came from their atomic clock.
Years later in a telecom switchroom I was shown five clocks. The first four were GPS clocks. Only if all of those failed did they refer to the atomic clock. So I guess they agreed with you! And they had the advantage of being in a fixed location :)
I also used to work for a major telecom company. In the network management center there was a digital clock that I had noticed was off a bit. The guy working there said it couldn't be, because it was controlled by the network time base (derived from WWVB), which was correct. However, what he didn't realize was that while it had a very accurate time base, it was manually set according to someone's watch and was therefore continually wrong by precisely the same amount. These days, when setting clocks on network and telecom equipment and NTP is not available, I set according to my cell phone time, which is quite accurate. At home, I use the NTP controlled clock on my computer. BTW, should anyone want the correct time, it can be found here: http://www.time.gov -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Friday 16 March 2007 08:07, Roger Oberholtzer wrote:
On Fri, 2007-03-16 at 10:32 +0000, peter nikolic wrote:
On Friday 16 March 2007, Roger Oberholtzer wrote:
This is probably a hardware issue, but I need to see how to investigate:
Any ideas or suggestions?
Can't you use NTP to set the time on boot i take it they are all connected to the net or a network with one machine connected to the internet setup a ntp server use that to check against at boo time ..
Ahh. I forgot to mention one important fact. These computers are in vehicles on the road. If they cannot figure it out on their own, it wont be figured out.
They do have GPS. However, I have not found an efficient way to share the GPS NMEA recored with nntp and our measurement software, which needs the records with little (read no) delay.
-- Roger Oberholtzer
OPQ Systems / Ramböll RST
Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden
Tel: Int +46 8-615 60 20 Fax: Int +46 8-31 42 23
The GPS downloads the Zulu time with every transmission. The only delay would be decoding the actual transmission. You need some hardware and software that will parse the transmission and extract the time and date (if you need it) and this probably exists somewhere--even for DOS, I would guess. The software is trivial, and I could probably write it myself, but I'm not volunteering to do so. (I'm not a programmer.) I should think that an ordinary laptop would do all of this for you easily, but you could find a small engineering firm that does RF stuff and has, like all modern firms, a programmer, that would create for you whatever you need--a printed record, or whatever. --Doug, wa2say -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2007-03-16 at 19:15 -0400, Doug McGarrett wrote:
The GPS downloads the Zulu time with every transmission. The only delay would be decoding the actual transmission.
You need some hardware and software that will parse the transmission and extract the time and date (if you need it) and this probably exists somewhere--even for DOS, I would guess. The software is trivial, and I could probably write it myself, but I'm not volunteering to do so. (I'm not a programmer.)
I'm told that it is terrible easy. Some gps units (modules) output a plain ascii "message" containing time and position trough a serial port: so simple that a PIC can decode it. Haven't got one to try myself, though. Elektor magazine wrote a pic design using a gps module used as a radar or dangerous spot warning device for motorists not long ago. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFF+z8AtTMYHG2NR9URAg34AKCULaqzIICTRT8ki75kgiDJv4XjjACgiDSj lwgwVgNP/zEmNS0mfuz+yFc= =lQ3W -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, 2007-03-17 at 02:06 +0100, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The Friday 2007-03-16 at 19:15 -0400, Doug McGarrett wrote:
The GPS downloads the Zulu time with every transmission. The only delay would be decoding the actual transmission.
You need some hardware and software that will parse the transmission and extract the time and date (if you need it) and this probably exists somewhere--even for DOS, I would guess. The software is trivial, and I could probably write it myself, but I'm not volunteering to do so. (I'm not a programmer.)
I'm told that it is terrible easy. Some gps units (modules) output a plain ascii "message" containing time and position trough a serial port: so simple that a PIC can decode it.
Haven't got one to try myself, though.
There is a standard format called NMEA. Most receivers can provide this. In addition, most support a proprietary format. That one usually provided info specific to that receiver, like current settings and other vendor-specific stuff. There is a GPS moving map program that comes with SUSE. I think it may be called gpsdrive. It parses NMEA. We have our own highly optimized parser as we need the info quickly. -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Tel: Int +46 8-615 60 20 Fax: Int +46 8-31 42 23 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, 2007-03-16 at 19:15 -0400, Doug McGarrett wrote:
The GPS downloads the Zulu time with every transmission. The only delay would be decoding the actual transmission.
In fact, GPS can report any time. We use UTC. Parsing the data is trivial and we do it all the time. Both NMEA and Trimble's own protocol. The tricky part is that by the time you get the data, it is too late. So you have to synchronize (hence the pulse-per-second signal provided by good gps receivers) and use some other clock that you sync'd with to get a better 'current time'.
You need some hardware and software that will parse the transmission and extract the time and date (if you need it) and this probably exists somewhere--even for DOS, I would guess. The software is trivial, and I could probably write it myself, but I'm not volunteering to do so. (I'm not a programmer.)
I should think that an ordinary laptop would do all of this for you easily, but you could find a small engineering firm that does RF stuff and has, like all modern firms, a programmer, that would create for you whatever you need--a printed record, or whatever.
We already do all this. My original question was not really about gps at all. It was simple about a computer keeping time correct across boots. Not changing the time by, say, 8.3 hours. The gps discussion has been an aside. -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Tel: Int +46 8-615 60 20 Fax: Int +46 8-31 42 23 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, 2007-03-17 at 18:13 +0100, Roger Oberholtzer wrote:
On Fri, 2007-03-16 at 19:15 -0400, Doug McGarrett wrote:
We already do all this. My original question was not really about gps at all. It was simple about a computer keeping time correct across boots. Not changing the time by, say, 8.3 hours. The gps discussion has been an aside. Which is what I thought you were asking in the first place. So was it a
problem with the /etc/adjtime file? We've been using GPS per-second pulse for years, and usually involves phase-locking a clock. (Simulcasting and HDTV, for example. To the point of calculating the delay site-to-site for location AND elevation.) Sounds like you are on that path, but I haven't heard you mention a "master-car-clock" you would then sync all your equipment to. There are even stand-alone time servers you could install in each vehicle, referenced to GPS and serving the in-car lan (not necessarily Ethernet-type, but your sensor "network") . Each device would "learn" its inherent delay and compensate accordingly, if the lan was synchronous and predictable. Include the time pole concurrently with your other sensor polling. Your "get-data" loop would know precisely how many cycles it took, assuming it didn't get interrupted. Perhaps you actually need TWO clocks, one known stable to very tight tolerance (short-term), and the other phase-locked to the GPS so you would know the GPS variance to apply, compensating for the movement your sensors detect. Sounds like you are caught in an "oops" mode and trying to avoid an earlier oversight in the plan stage, necessitating a major re-write? ...no offense intended. If you are really pushing the envelope, then BEST of luck, and have FUN. Tom in NM -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, 2007-03-16 at 19:15 -0400, Doug McGarrett wrote:
We already do all this. My original question was not really about gps at all. It was simple about a computer keeping time correct across boots. Not changing the time by, say, 8.3 hours. The gps discussion has been an aside.
Doug: What is the age & type of mobo? Does this happen if you boot some other OS version on that same hardware? Maybe using Knoppix Live or something similar? I agree that some on this list go off willy-nilly on tangents that have little, if anything, to do with the original problem. Did you ever find a cause/resolution to the problem? Fred -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, 2007-03-17 at 14:50 -0500, Stevens wrote:
On Fri, 2007-03-16 at 19:15 -0400, Doug McGarrett wrote:
We already do all this. My original question was not really about gps at all. It was simple about a computer keeping time correct across boots. Not changing the time by, say, 8.3 hours. The gps discussion has been an aside.
Doug:
What is the age & type of mobo? Does this happen if you boot some other OS version on that same hardware? Maybe using Knoppix Live or something similar? I agree that some on this list go off willy-nilly on tangents that have little, if anything, to do with the original problem. Did you ever find a cause/resolution to the problem?
We have not tried other OSs. Only two releases of SUSE (10.0 and 10.1). I will have to get a machine and try myself. So far all this is based on reports from users. I do have one machine that confirms their observations. But I have not had time to investigate. This question was in preparation for this. -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Tel: Int +46 8-615 60 20 Fax: Int +46 8-31 42 23 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, 2007-03-17 at 13:31 -0600, Tom Patton wrote:
On Sat, 2007-03-17 at 18:13 +0100, Roger Oberholtzer wrote:
On Fri, 2007-03-16 at 19:15 -0400, Doug McGarrett wrote:
We already do all this. My original question was not really about gps at all. It was simple about a computer keeping time correct across boots. Not changing the time by, say, 8.3 hours. The gps discussion has been an aside. Which is what I thought you were asking in the first place. So was it a problem with the /etc/adjtime file?
We've been using GPS per-second pulse for years, and usually involves phase-locking a clock. (Simulcasting and HDTV, for example. To the point of calculating the delay site-to-site for location AND elevation.) Sounds like you are on that path, but I haven't heard you mention a "master-car-clock" you would then sync all your equipment to. There are even stand-alone time servers you could install in each vehicle, referenced to GPS and serving the in-car lan (not necessarily Ethernet-type, but your sensor "network") . Each device would "learn" its inherent delay and compensate accordingly, if the lan was synchronous and predictable. Include the time pole concurrently with your other sensor polling. Your "get-data" loop would know precisely how many cycles it took, assuming it didn't get interrupted.
Perhaps you actually need TWO clocks, one known stable to very tight tolerance (short-term), and the other phase-locked to the GPS so you would know the GPS variance to apply, compensating for the movement your sensors detect.
Sounds like you are caught in an "oops" mode and trying to avoid an earlier oversight in the plan stage, necessitating a major re-write? ...no offense intended. If you are really pushing the envelope, then BEST of luck, and have FUN.
No offence taken. Not a design oversight. Systems evolve over time. New things get added that need to be integrated. It would be great if one could retro-design existing hardware based on new requirements. In fact we have two independent time sync methods. One is based on our own hardware. We are trying to move away from that as we move to a COTS solution. Or, at least, 95% COTS. There are few solutions for this that do not simply change the problem to a different one. We are trying to keep problems limited to those we understand and can explain, it not actually solve. Also, the original question I had was not so much about not being able to sync. It was that it makes quality control ever so much more reliable when dates on files somewhat (within some minutes of tolerance) match the real time. The sync/accuracy thing was also an aside. We just want the damned PC clock not to change random amounts at reboot. -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Tel: Int +46 8-615 60 20 Fax: Int +46 8-31 42 23 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2007-03-19 at 08:17 +0100, Roger Oberholtzer wrote:
the real time. The sync/accuracy thing was also an aside. We just want the damned PC clock not to change random amounts at reboot.
In my experience, this problem is caused by a misfired adjtime file, and simply deleting it solves it (the file is recreated automatically). My "experience" is actually that of people reporting that same problem here, me telling them to delete etc, them reporting solved, me ticking a new notch in my crystal ball pedestal - so you see, I'm eagerly waiting for your final report ;-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFF/mN3tTMYHG2NR9URAua8AKCE5GS3RyTvN2JjTpAtjUePYLVCwACeJu1l Ze2FVtHsUPXBjWCw4hmP/oE= =nLEj -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Mon, 2007-03-19 at 08:17 +0100, Roger Oberholtzer wrote:
No offence taken. Not a design oversight. Systems evolve over time. New things get added that need to be integrated. It would be great if one could retro-design existing hardware based on new requirements. In fact we have two independent time sync methods. One is based on our own hardware. We are trying to move away from that as we move to a COTS solution. Or, at least, 95% COTS. There are few solutions for this that do not simply change the problem to a different one. We are trying to keep problems limited to those we understand and can explain, it not actually solve.
Also, the original question I had was not so much about not being able to sync. It was that it makes quality control ever so much more reliable when dates on files somewhat (within some minutes of tolerance) match the real time. The sync/accuracy thing was also an aside. We just want the damned PC clock not to change random amounts at reboot. Well, I hope "man hwclock" and the other links lead you to the problem.
Thanks for bringing it up, BTW. This pc seldom gets re-booted, other than kernel updates. I haven't set the time since installing 10.2, and "hwclock --show" indicates I have a 40 second drift in the past 6 days. Guess I'll spend the next few days "walking" the correction factor into range. Good luck to you! Tom in NM -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday 17 March 2007 13:13, Roger Oberholtzer wrote:
On Fri, 2007-03-16 at 19:15 -0400, Doug McGarrett wrote:
The GPS downloads the Zulu time with every transmission. The only delay would be decoding the actual transmission.
and it went on from there, in the list. I think a lot of us would like to know, if it is within the clearances of your company, why you are trying to pinpoint the location of a vehicle moving at 60 MPH or so (100KPH) to within 1 meter. Such a vehicle would probably be moving slower than the old German Buzz-bomb, but faster than a taxicab, and who cares what the exact position of a cab is, so why would you want to know to that accuracy? --dm -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday 17 March 2007 16:58, Doug McGarrett wrote:
On Saturday 17 March 2007 13:13, Roger Oberholtzer wrote:
On Fri, 2007-03-16 at 19:15 -0400, Doug McGarrett wrote:
The GPS downloads the Zulu time with every transmission. The only delay would be decoding the actual transmission.
and it went on from there, in the list. I think a lot of us would like to know, if it is within the clearances of your company, why you are trying to pinpoint the location of a vehicle moving at 60 MPH or so (100KPH) to within 1 meter. Such a vehicle would probably be moving slower than the old German Buzz-bomb, but faster than a taxicab, and who cares what the exact position of a cab is, so why would you want to know to that accuracy?
Here's one example of why (taken from a project I did recently): You capture video out the sides of the vehicle and correlate each frame with the precise location. Then when someone wants to see what a particular location looks like (this was done primarily in business districts, but the problem doesn't change all that much when you slow to 40 or 50 kph), you geocode the address in question (often derived from a keyword search on a business directory) and display the location of the storefront. Another project, started at Stanford and then taken up by Google, uses laser scanners to build three-dimensional models of a city's buildings (at least those faces of the buildings that can be seen from publicly accessible streets and roads). GIS applications are manifold, and only just beginning to be developed. The ability to accurately and precisely locate a vehicle (or a person walking, for that matter) is often a key to capturing real-world information. Another example is capturing street maps. It's actually big business, and the firms that do this use vehicles very much like those described by Roger to capture current street networks. They simply (though in reality it's far from simple) drive the entire street and road network on an ongoing basis (things change rapidly, especially in urban areas) and build street maps from the sequences of captured (captured, augmented and corrected) GPS coordinates.
--dm
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, 2007-03-17 at 19:58 -0400, Doug McGarrett wrote:
On Saturday 17 March 2007 13:13, Roger Oberholtzer wrote:
On Fri, 2007-03-16 at 19:15 -0400, Doug McGarrett wrote:
The GPS downloads the Zulu time with every transmission. The only delay would be decoding the actual transmission.
and it went on from there, in the list. I think a lot of us would like to know, if it is within the clearances of your company, why you are trying to pinpoint the location of a vehicle moving at 60 MPH or so (100KPH) to within 1 meter. Such a vehicle would probably be moving slower than the old German Buzz-bomb, but faster than a taxicab, and who cares what the exact position of a cab is, so why would you want to know to that accuracy?
We measure road surface conditions. Things engineers want to know in order to track road wear. So they can evaluate construction methods, materials, and plan maintenance in an objective way. These engineers (world wide) have been reading the big print in GPS and INS advertisements and are asking for locations these adverts claim to be possible. They never read the fine print that tells the conditions under which these levels of accuracy are possible. A GPS receiver can provide data at 10 Hz. At 90 km/h, that is one value every 2.5 meters. So, we need to report accuracies at almost 1/3 the measurement rate. Ain't gonna happen. So, one needs to add inclinometers, gyroscopes and other doodads to fill in the spaces. This require time synchronization between the GPS and the other transducers. Not to mention that GPS has drift, multipath error and other little nasties. What they dream of is that a vehicle will roam the highways and when the data is returned, it will magically be identified. To compare subsequent measurements requires some level of accuracy in locating the data. There are existing identification systems, but these are difficult/expensive to maintain, compared to a GPS method. There are some basic flaws in this collection methodology, but it is even more beyond the scope of this group. Wow, even more off topic... -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Tel: Int +46 8-615 60 20 Fax: Int +46 8-31 42 23 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Monday 19 March 2007 00:29, Roger Oberholtzer wrote:
...
We measure road surface conditions. Things engineers want to know in order to track road wear. So they can evaluate construction methods, materials, and plan maintenance in an objective way. ... So, one needs to add inclinometers, gyroscopes and other doodads to fill in the spaces. This require time synchronization between the GPS and the other transducers. Not to mention that GPS has drift, multipath error and other little nasties.
We captured tracks in lots of U.S. cities, few worse than Manhattan. What nightmare. The raw GPS tracks sometimes meandered one or two whole blocks over! Inventing algorithms to correct that sort of thing was a pretty interesting challenge. Once you add the accelerometers and other sensor modalities, then you have the sensor fusion problem. All very fascinating.
What they dream of is that a vehicle will roam the highways and when the data is returned, it will magically be identified. To compare subsequent measurements requires some level of accuracy in locating the data. There are existing identification systems, but these are difficult/expensive to maintain, compared to a GPS method. There are some basic flaws in this collection methodology, but it is even more beyond the scope of this group.
Wow, even more off topic...
Maybe, but I think it's good to see realistic applications beyond mundane office tasks.
-- Roger Oberholtzer
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Mon, 2007-03-19 at 07:53 -0700, Randall R Schulz wrote:
Wow, even more off topic...
Maybe, but I think it's good to see realistic applications beyond mundane office tasks.
We do those, too. But the main thing we do is measurement control systems. All based on Linux. -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Tel: Int +46 8-615 60 20 Fax: Int +46 8-31 42 23 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Fredag 16 marts 2007 11:23 skrev Roger Oberholtzer:
This is probably a hardware issue, but I need to see how to investigate:
I run SUSE 10.0 and 10.1 on various computers. Usually, we set it up so that the computer time is set to UTC, and we then state where we are in the world.
On many machines, we have a problem where the time seems to get screwy between boots. It is usually the time of day more than the date. The error seems to be random. Not just the hour. But the minutes as well.
So, we then tried setting the computer to local time, informing SUSE of this. Same problem.
I am guessing that the motherboards have some issues. They are all rather new and made by SuperMicro. I am not sure if they are all the exact same model (I am checking).
How could I get SUSE to record what the hardware time was when it boots, before making any changes, and then what it is after any changes? Same thing on power down. I guess this is tricky because these things probably happen when there are no disks mounted. Any ideas? I know I could check the BIOS each time. But I am not sure I can get the users to do this reliably.
Any ideas or suggestions?
-- Roger Oberholtzer
OPQ Systems / Ramböll RST
Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden
Tel: Int +46 8-615 60 20 Fax: Int +46 8-31 42 23
FWIW: I used to buy SuperMicro servers to run SuSE on. I eventually gave it up. Hardware was MS only. I had an endless (and still have...) array of problems with that SM hardware.. -- ------------------------------------------------------------------------- Med venlig hilsen/Best regards Verner Kjærsgaard -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2007-03-16 at 11:23 +0100, Roger Oberholtzer wrote:
On many machines, we have a problem where the time seems to get screwy between boots. It is usually the time of day more than the date. The error seems to be random. Not just the hour. But the minutes as well.
Simple: delete /etc/adjtime. Actually: - set up the clock. - check and reset time zone with yast. - ensure clock is correct running "date" as root. - delete /etc/adjtime
So, we then tried setting the computer to local time, informing SUSE of this. Same problem.
It is not SuSE's problem, it is yours :-p
I am guessing that the motherboards have some issues. They are all rather new and made by SuperMicro. I am not sure if they are all the exact same model (I am checking).
If it is from boot to boot, no, nothing there. Just a screwed adjtime file. Look for older messages on this list about this very issue. I have explained it many times and I don't have time right now ;-) The main cause is setting the up clock... - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFF+nSMtTMYHG2NR9URAoyYAJ42xXqWZHAJd1REBdMgBjiZyQQ/gQCfbh6o 793IBgSLvDgp1XXjBmbgE5M= =6ode -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, 2007-03-16 at 11:42 +0100, Carlos E. R. wrote:
So, we then tried setting the computer to local time, informing SUSE of this. Same problem.
It is not SuSE's problem, it is yours :-p
By 'informing SUSE of this', I meant that we made sure the sysconfig was set to understand that we had a UTC clock or a local clock. Not that we contacted SUSE AG offices and had a chat. -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Tel: Int +46 8-615 60 20 Fax: Int +46 8-31 42 23 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, 2007-03-16 at 13:14 +0100, Roger Oberholtzer wrote:
On Fri, 2007-03-16 at 11:42 +0100, Carlos E. R. wrote:
I'm not a script wizard, maybe someone will chime it...
Couldn't you parse a NEMA sentence to get "mmddhhmmyyyy.ss" to use for
the argument to date? Use that in a script
parse nema
rm /etc/adjtime
date
On Fri, 2007-03-16 at 07:12 -0600, Tom Patton wrote:
On Fri, 2007-03-16 at 13:14 +0100, Roger Oberholtzer wrote:
On Fri, 2007-03-16 at 11:42 +0100, Carlos E. R. wrote:
I'm not a script wizard, maybe someone will chime it...
Couldn't you parse a NEMA sentence to get "mmddhhmmyyyy.ss" to use for the argument to date? Use that in a script
Of course. As long as you track when the values are good. GPS data is notorious for this. This includes time. A proper solution would require that the operators ensure that they are in favorable conditions when the script is run. Programs like ntpd always run and can decide this. Also, most people with a computer have a fixed place to put the gps antenna that does not move. So they can choose a place with good reception. A moving vehicle is not so predictable. We have also considered using the radio beacon time signal for this.
parse nema rm /etc/adjtime date
hwclock --systohc hwclock --hctosys rm /etc/adjtime Then, on the next shutdown, a true /etc/adjtime will be written to the disk...so the next boot SHOULD be reasonably accurate. If they all have GPS available on the road, I'd run the script daily anyway. The script would have to run as root, of course.
Tom in NM
-- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Tel: Int +46 8-615 60 20 Fax: Int +46 8-31 42 23 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, 2007-03-16 at 11:42 +0100, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The Friday 2007-03-16 at 11:23 +0100, Roger Oberholtzer wrote:
On many machines, we have a problem where the time seems to get screwy between boots. It is usually the time of day more than the date. The error seems to be random. Not just the hour. But the minutes as well.
Simple: delete /etc/adjtime.
Actually:
- set up the clock.
To local or UTC time?
- check and reset time zone with yast. - ensure clock is correct running "date" as root. - delete /etc/adjtime
When is this file created? Who makes it? Does this file tell how much to adjust the clock when shutting down a UTC hardware clock system? -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Tel: Int +46 8-615 60 20 Fax: Int +46 8-31 42 23 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2007-03-16 at 13:18 +0100, Roger Oberholtzer wrote:
Actually:
- set up the clock.
To local or UTC time?
To whatever time your clock uses. For instance, if I do (as root): nimrodel:~ # date Fri Mar 16 20:00:02 CET 2007 then I would use "CET" time. However, the "date" syntax allows me to use any timezone I want.
- check and reset time zone with yast. - ensure clock is correct running "date" as root. - delete /etc/adjtime
When is this file created? Who makes it?
By the script "/etc/init.d/boot.clock" on boot and shutdown. It is read on boot, and updated un shutdown. Deleting it forces a reset. This file serves to compensate the hardware (cmos) clock for drift. If the drift is very wrong, your clock will be set very wrong on next boot.
Does this file tell how much to adjust the clock when shutting down a UTC hardware clock system?
Yes. UTC or local, doesn't matter: it knows. The command "apropos adjtime" will tell you that there are some man pages on this. However, better look up "man hwclock", which is the actual program creating and using that file. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFF+uqutTMYHG2NR9URAvaUAJwMqnlbOAn04Rsd9gW91X49dbIBgQCdGCvP DEsjaghQR1+AKTmBnEBzTMc= =zN5G -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, 2007-03-16 at 20:06 +0100, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The Friday 2007-03-16 at 13:18 +0100, Roger Oberholtzer wrote:
Actually:
- set up the clock.
To local or UTC time?
To whatever time your clock uses. For instance, if I do (as root):
nimrodel:~ # date Fri Mar 16 20:00:02 CET 2007
then I would use "CET" time. However, the "date" syntax allows me to use any timezone I want.
- check and reset time zone with yast. - ensure clock is correct running "date" as root. - delete /etc/adjtime
When is this file created? Who makes it?
By the script "/etc/init.d/boot.clock" on boot and shutdown. It is read on boot, and updated un shutdown. Deleting it forces a reset.
This file serves to compensate the hardware (cmos) clock for drift. If the drift is very wrong, your clock will be set very wrong on next boot.
Do you know how drift is computed? -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Tel: Int +46 8-615 60 20 Fax: Int +46 8-31 42 23 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2007-03-16 at 20:32 +0100, Roger Oberholtzer wrote:
This file serves to compensate the hardware (cmos) clock for drift. If the drift is very wrong, your clock will be set very wrong on next boot.
Do you know how drift is computed?
I can guess, but no, I don't know. Look at "man hwclock" and friends. Basically, it calculates how much the cmos clock deviates from the "real" time as kept by the system since last time, and calculates a factor to compensate the cmos clock drift, to be applied on next boot (actually, next time you copy the time from cmos to system), - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFF+w25tTMYHG2NR9URAhtxAJwNnVw3Pi3Gn0NAJt3xKKiN1fUtAwCfU7im 4J23grRX/xVKRplqx5RyEzA= =OO6N -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer wrote:
This is probably a hardware issue, but I need to see how to investigate: How could I get SUSE to record what the hardware time was when it boots, before making any changes, and then what it is after any changes? Same thing on power down. I guess this is tricky because these things probably happen when there are no disks mounted. Any ideas? I know I could check the BIOS each time. But I am not sure I can get the users to do this reliably.
Any ideas or suggestions?
To go back to your original question. The time is set by /etc/init.d/boot.clock when called from the various rc directories. I believe you could hack that script so it writes the hw time to a disk file before it changes anything. You might also need to either hack the script some more or rename the appropriate rc files so it isn't called until some disk is mounted. Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Friday 16 March 2007 10:22, Dave Howorth wrote:
Roger Oberholtzer wrote:
This is probably a hardware issue, but I need to see how to investigate: How could I get SUSE to record what the hardware time was when it boots, before making any changes, and then what it is after any changes? Same thing on power down. I guess this is tricky because these things probably happen when there are no disks mounted. Any ideas? I know I could check the BIOS each time. But I am not sure I can get the users to do this reliably.
Any ideas or suggestions?
To go back to your original question. The time is set by /etc/init.d/boot.clock when called from the various rc directories. I believe you could hack that script so it writes the hw time to a disk file before it changes anything. You might also need to either hack the script some more or rename the appropriate rc files so it isn't called until some disk is mounted.
Root partition is mounted when you read /etc/init.d/boot.clock :-) -- Regards, Rajko. http://en.opensuse.org/Portal -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, 2007-03-16 at 19:10 -0500, Rajko M. wrote:
On Friday 16 March 2007 10:22, Dave Howorth wrote:
To go back to your original question. The time is set by /etc/init.d/boot.clock when called from the various rc directories. I believe you could hack that script so it writes the hw time to a disk file before it changes anything. You might also need to either hack the script some more or rename the appropriate rc files so it isn't called until some disk is mounted.
Root partition is mounted when you read /etc/init.d/boot.clock :-)
Doh! I need to drink coffee before posting :) So, it's very easy, Roger! Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (14)
-
Carlos E. R. -
Dave Howorth -
Dave Howorth -
David Brodbeck -
Doug McGarrett -
James Knott -
peter nikolic -
Rajko M. -
Randall R Schulz -
Richard Bos -
Roger Oberholtzer -
Stevens -
Tom Patton -
Verner Kjærsgaard