[opensuse] openSUSE + gpsd + PPS + NTP
Hi Is anyone using a GPS (gpsd) with the PPS signal as a time source for NTP? My main interest is how such systems are acting at system boot. We have a mobile measurement system that syncs time using home brewed software. We would like instead to use the standard tools. Our main question is how the system acts if, at boot, there is no GPS data. Is the time left alone? When the time does arrive, how quickly will the system clock reflect the time? For example, it may turn out that the PC clock and the GPS time differ by some hours. Does NTP always do a gradual time shift? Can that be disabled? These systems are booted a couple times a day. Any other things to consider? TIA for any experiences. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
Hi
Is anyone using a GPS (gpsd) with the PPS signal as a time source for NTP?
My main interest is how such systems are acting at system boot. We have a mobile measurement system that syncs time using home brewed software. We would like instead to use the standard tools.
Our main question is how the system acts if, at boot, there is no GPS data. Is the time left alone? When the time does arrive, how quickly will the system clock reflect the time? For example, it may turn out that the PC clock and the GPS time differ by some hours. Does NTP always do a gradual time shift? Can that be disabled? These systems are booted a couple times a day.
Any other things to consider?
Check the NTP mailing list, it has a lot of very knowledgeable people. I think you're more likely to get a useful answer there. -- Per Jessen, Zürich (4.4°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 1/14/2014 12:51 AM, Roger Oberholtzer wrote:
Hi
Is anyone using a GPS (gpsd) with the PPS signal as a time source for NTP?
My main interest is how such systems are acting at system boot. We have a mobile measurement system that syncs time using home brewed software. We would like instead to use the standard tools.
Our main question is how the system acts if, at boot, there is no GPS data. Is the time left alone? When the time does arrive, how quickly will the system clock reflect the time? For example, it may turn out that the PC clock and the GPS time differ by some hours. Does NTP always do a gradual time shift? Can that be disabled? These systems are booted a couple times a day.
Any other things to consider?
TIA for any experiences.
Your system should run using it's internal clock until there is a NTP source, be that via GPS or over the net. (Your local computer clock is set up as a stratum 10 time source, which means it will be used as a last resort). NTP will often NOT compensate for several hours of difference. This is by design, but, there may be a switch to over-ride it. When it does get a connection to NTP, even after weeks of being disconnected or turned off, it will sync immediately, and adjust time all at once, provide the clocks are reasonably close. When I say immediately, I mean as soon as NTP elects a clock from the list you provide to it. I don't recall any gradual time shift, but I haven't read the man page in a while. Your GPS source should provide you UTC time. (Well, US GPS sats provide GMT plus an offset to arrive at UTC, but Glonas and Galileo only provide UTC). However, I've seen many references on the net about GPS being a poor source, probably due to the delay in getting time as you mentioned. It might be wise to not start NTP until you have believable time from the GPS. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
John Andersen wrote:
On 1/14/2014 12:51 AM, Roger Oberholtzer wrote:
Hi
Is anyone using a GPS (gpsd) with the PPS signal as a time source for NTP?
My main interest is how such systems are acting at system boot. We have a mobile measurement system that syncs time using home brewed software. We would like instead to use the standard tools.
Our main question is how the system acts if, at boot, there is no GPS data. Is the time left alone? When the time does arrive, how quickly will the system clock reflect the time? For example, it may turn out that the PC clock and the GPS time differ by some hours. Does NTP always do a gradual time shift? Can that be disabled? These systems are booted a couple times a day.
Any other things to consider?
TIA for any experiences.
Your system should run using it's internal clock until there is a NTP source, be that via GPS or over the net. (Your local computer clock is set up as a stratum 10 time source, which means it will be used as a last resort).
NTP will often NOT compensate for several hours of difference.
I think the limit is one hour.
This is by design, but, there may be a switch to over-ride it.
on ntpdate it used to "-g", I think.
Your GPS source should provide you UTC time. (Well, US GPS sats provide GMT plus an offset to arrive at UTC, but Glonas and Galileo only provide UTC).
Er, GMT is UTC+0, i.e. the same thing.
However, I've seen many references on the net about GPS being a poor source, probably due to the delay in getting time as you mentioned. It might be wise to not start NTP until you have believable time from the GPS.
AFAIK, the main GPS advantage of DCF77 (et al) is getting the PPS signal. -- Per Jessen, Zürich (2.5°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 1/14/2014 12:09 PM, Per Jessen wrote:
Er, GMT is UTC+0, i.e. the same thing.
Not exactly. They differ by 16 seconds or so. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
John Andersen wrote:
On 1/14/2014 12:09 PM, Per Jessen wrote:
Er, GMT is UTC+0, i.e. the same thing.
Not exactly.
They differ by 16 seconds or so.
Really? I was not aware, but I guess I have always seen those acronyms to be timezones, not actual time. https://en.wikipedia.org/wiki/UTC
Universal Time Coordinated (French: Temps Universel Coordonné, UTC) is the primary time standard by which the world regulates clocks and time. It is one of several closely related successors to Greenwich Mean Time (GMT). For most purposes, UTC is synonymous with GMT, but GMT is no longer precisely defined by the scientific community.
Do US GPS satellites really supply GMT ??? -- Per Jessen, Zürich (2.7°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 1/14/2014 12:17 PM, Per Jessen wrote:
Do US GPS satellites really supply GMT ???
Wiki seems to think so, http://en.wikipedia.org/wiki/Global_Positioning_System#Timekeeping but I haven't actually looked at the message format in a while. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
John Andersen wrote:
On 1/14/2014 12:17 PM, Per Jessen wrote:
Do US GPS satellites really supply GMT ???
Wiki seems to think so, http://en.wikipedia.org/wiki/Global_Positioning_System#Timekeeping but I haven't actually looked at the message format in a while.
GPS != GMT. I have the same problem occasionally, I read what I want to read, not what is actually written :-) -- Per Jessen, Zürich (2.8°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 1/14/2014 12:25 PM, Per Jessen wrote:
John Andersen wrote:
On 1/14/2014 12:17 PM, Per Jessen wrote:
Do US GPS satellites really supply GMT ???
Wiki seems to think so, http://en.wikipedia.org/wiki/Global_Positioning_System#Timekeeping but I haven't actually looked at the message format in a while.
GPS != GMT. I have the same problem occasionally, I read what I want to read, not what is actually written :-)
But there is still a difference. GMT is simply the time in Greenwich, as kept by the British Naval Observatories atomic clocks. UTC is a calculated value based on the structure of the planet, its un-even rotation, and a whole bunch of esoteric minutia. Now days, GMT is no longer scientifically defined, it use to be defined at noon in Greenwich, but that varies quit a bit. As such GMT is essentially simply synced with UTC these days, but it is still actually different. http://en.wikipedia.org/wiki/Greenwich_Mean_Time -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
John Andersen wrote:
On 1/14/2014 12:25 PM, Per Jessen wrote:
John Andersen wrote:
On 1/14/2014 12:17 PM, Per Jessen wrote:
Do US GPS satellites really supply GMT ???
Wiki seems to think so, http://en.wikipedia.org/wiki/Global_Positioning_System#Timekeeping but I haven't actually looked at the message format in a while.
GPS != GMT. I have the same problem occasionally, I read what I want to read, not what is actually written :-)
But there is still a difference.
Splitting hairs, aren't we?
GMT is simply the time in Greenwich, as kept by the British Naval Observatories atomic clocks.
"was", not "is". There are no British Naval Observatories in operation anymore, they're all museums.
UTC is a calculated value based on the structure of the planet, its un-even rotation, and a whole bunch of esoteric minutia.
Right.
Now days, GMT is no longer scientifically defined, it use to be defined at noon in Greenwich, but that varies quit a bit.
As such GMT is essentially simply synced with UTC these days, but it is still actually different. http://en.wikipedia.org/wiki/Greenwich_Mean_Time
Is there an official source of GMT ? Just curious. -- Per Jessen, Zürich (2.6°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tuesday, January 14, 2014 09:17:02 PM Per Jessen wrote:
John Andersen wrote:
On 1/14/2014 12:09 PM, Per Jessen wrote:
Er, GMT is UTC+0, i.e. the same thing.
Not exactly.
They differ by 16 seconds or so.
Really? I was not aware, but I guess I have always seen those acronyms to be timezones, not actual time.
https://en.wikipedia.org/wiki/UTC
Universal Time Coordinated (French: Temps Universel Coordonné, UTC) is the primary time standard by which the world regulates clocks and time. It is one of several closely related successors to Greenwich Mean Time (GMT). For most purposes, UTC is synonymous with GMT, but GMT is no longer precisely defined by the scientific community.
Do US GPS satellites really supply GMT ???
The NMEA standard, which is the most data common format from GPS receivers, defines the time in records as being UTC. Receivers often also provide a proprietary data stream, and the time in that is up to the manufacturer. We use NMEA, and thus UTC, as that is the data attached to the PPS. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tuesday, January 14, 2014 09:09:44 PM Per Jessen wrote:
AFAIK, the main GPS advantage of DCF77 (et al) is getting the PPS signal.
Which is why precise GPS systems provide data over the serial port. There is no accurate way to provide a PPS over USB or ethernet. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tuesday, January 14, 2014 11:47:31 AM John Andersen wrote:
NTP will often NOT compensate for several hours of difference.
This is a worry. These systems are in vehicles on the road. We have no control over the time on the PC clock at boot. We do NOT (repeat NOT) want the users entering the BIOS and mucking about.
This is by design, but, there may be a switch to over-ride it. When it does get a connection to NTP, even after weeks of being disconnected or turned off, it will sync immediately, and adjust time all at once, provide the clocks are reasonably close. When I say immediately, I mean as soon as NTP elects a clock from the list you provide to it.
I don't recall any gradual time shift, but I haven't read the man page in a while.
Your GPS source should provide you UTC time. (Well, US GPS sats provide GMT plus an offset to arrive at UTC, but Glonas and Galileo only provide UTC).
However, I've seen many references on the net about GPS being a poor source, probably due to the delay in getting time as you mentioned. It might be wise to not start NTP until you have believable time from the GPS.
As it turns out, we want to set the time because we time stamp everything. And the way we hook all the parts together is by location as provided by the GPS. So, what we really are after is having the PC clock match the GPS time as closely as possible. How that relates to some global correct time is not really interesting. I should add that our GPS are really inertial navigation systems that have the GPS as one source to maintain location. There are also inclinometers, gyroscopes and distance measurement devices as well. INS systems use the GPS time to time stamp locations. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Tuesday, January 14, 2014 11:47:31 AM John Andersen wrote:
NTP will often NOT compensate for several hours of difference.
This is a worry. These systems are in vehicles on the road. We have no control over the time on the PC clock at boot.
The ntp init script used to run 'ntpdate -g', I'm sure it does something similar now. That'll set the clock, but with a jump, not a slow adjustment. -- Per Jessen, Zürich (0.9°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wednesday, January 15, 2014 08:08:29 AM Per Jessen wrote:
Roger Oberholtzer wrote:
On Tuesday, January 14, 2014 11:47:31 AM John Andersen wrote:
NTP will often NOT compensate for several hours of difference.
This is a worry. These systems are in vehicles on the road. We have no control over the time on the PC clock at boot.
The ntp init script used to run 'ntpdate -g', I'm sure it does something similar now. That'll set the clock, but with a jump, not a slow adjustment.
Provided that the GPS is providing times at the time the init script runs. What if the user turns on the measurement system in a parking garage where there is no satellite available? Time will not be available when the init script runs. In typical Catch 22 fashion, the operator cannot know the GPS has acquired sats and thus be able to provide correct time unless they turn on the computer. At which time the init script runs. We do not want the operator to have to assess if the GPS is ready and then run the init script. Maybe we will need to modify the script so it runs a program that waits until the GPS has satellites before proceeding? I suspect that this is the bigger issue than if the BIOS clock is within one hour of UTC. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
If you have a bios clock you are probably good. Any pc grade clock will be within a couple minutes even after months in the powered off state.
Should be Easy to test this, just put two of them away somewhere and check the drift after a month with no gps and no Internet connection.
Your local clock should be fine.
Roger Oberholtzer
On Wednesday, January 15, 2014 08:08:29 AM Per Jessen wrote:
Roger Oberholtzer wrote:
On Tuesday, January 14, 2014 11:47:31 AM John Andersen wrote:
NTP will often NOT compensate for several hours of difference.
This is a worry. These systems are in vehicles on the road. We have no control over the time on the PC clock at boot.
The ntp init script used to run 'ntpdate -g', I'm sure it does something similar now. That'll set the clock, but with a jump, not a slow adjustment.
Provided that the GPS is providing times at the time the init script runs. What if the user turns on the measurement system in a parking garage where there is no satellite available? Time will not be available when the init script runs. In typical Catch 22 fashion, the operator cannot know the GPS has acquired sats and thus be able to provide correct time unless they turn on the computer. At which time the init script runs. We do not want the operator to have to assess if the GPS is ready and then run the init script. Maybe we will need to modify the script so it runs a program that waits until the GPS has satellites before proceeding? I suspect that this is the bigger issue than if the BIOS clock is within one hour of UTC.
-- Yours sincerely,
Roger Oberholtzer
Ramböll RST / Systems
Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________
Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tuesday, January 14, 2014 11:26:58 PM John Andersen wrote:
If you have a bios clock you are probably good. Any pc grade clock will be within a couple minutes even after months in the powered off state.
Should be Easy to test this, just put two of them away somewhere and check the drift after a month with no gps and no Internet connection.
Your local clock should be fine.
This has been our general experience as well. What I worry about is that the clock starts to mess up because of, say, a battery. We need to be certain that when ntp fails to set the clock we can reliably know about this and call this to the attention of the operator. Our problem is not so much with ntp failing to set the correct time as is is with knowing that ntp has failed to set the correct time. If we know it has failed we can take steps to correct the cause of failure. If we do not know it has failed, we collect lots of very expensive and unfortunately useless data. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Tuesday, January 14, 2014 11:26:58 PM John Andersen wrote:
If you have a bios clock you are probably good. Any pc grade clock will be within a couple minutes even after months in the powered off state.
Should be Easy to test this, just put two of them away somewhere and check the drift after a month with no gps and no Internet connection.
Your local clock should be fine.
This has been our general experience as well. What I worry about is that the clock starts to mess up because of, say, a battery. We need to be certain that when ntp fails to set the clock we can reliably know about this and call this to the attention of the operator.
Our problem is not so much with ntp failing to set the correct time as is is with knowing that ntp has failed to set the correct time. If we know it has failed we can take steps to correct the cause of failure. If we do not know it has failed, we collect lots of very expensive and unfortunately useless data.
It seems to me you have two different scenarios - a) time needs to be set at start-up, when a reliable time signal is available. b) time needs to be kept accurate during operations. You've already looked at (a) and found a solution. (b) is taken care of by ntpd, and you can query it to check whether it is sync'ed or not. -- Per Jessen, Zürich (1.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
Our problem is not so much with ntp failing to set the correct time as is is with knowing that ntp has failed to set the correct time. If we know it has failed we can take steps to correct the cause of failure. If we do not know it has failed, we collect lots of very expensive and unfortunately useless data.
As I mentioned earlier, you can use ntpd -q to initially set time. Perhaps you could use a script to verify time has been set before allowing other processes that need the accurate time. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Wednesday, January 15, 2014 08:08:29 AM Per Jessen wrote:
Roger Oberholtzer wrote:
On Tuesday, January 14, 2014 11:47:31 AM John Andersen wrote:
NTP will often NOT compensate for several hours of difference.
This is a worry. These systems are in vehicles on the road. We have no control over the time on the PC clock at boot.
The ntp init script used to run 'ntpdate -g', I'm sure it does something similar now. That'll set the clock, but with a jump, not a slow adjustment.
Provided that the GPS is providing times at the time the init script runs. What if the user turns on the measurement system in a parking garage where there is no satellite available? Time will not be available when the init script runs.
Okay.
In typical Catch 22 fashion, the operator cannot know the GPS has acquired sats and thus be able to provide correct time unless they turn on the computer. At which time the init script runs. We do not want the operator to have to assess if the GPS is ready and then run the init script. Maybe we will need to modify the script so it runs a program that waits until the GPS has satellites before proceeding? I suspect that this is the bigger issue than if the BIOS clock is within one hour of UTC.
Like Cristian suggested, I think this is type of situation that "chrony" was explicitly written for. Anyway, assuming that your GPS device is able to notify the system when it has a stable time signal, it ought not be a big deal to trigger a set-time command of that event. -- Per Jessen, Zürich (0.9°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wednesday, January 15, 2014 08:32:42 AM Per Jessen wrote:
Anyway, assuming that your GPS device is able to notify the system when it has a stable time signal, it ought not be a big deal to trigger a set-time command of that event.
So, on openSUSE (the reason we are discussing it here), could it be that I should make a separate system service that: 1. Waits for the GPS to get sat fix 2. Sets the PC time accordingly. This brings the time to within a couple seconds of being accurate. 3. Exits. This should only be done once. How will npt (as started by default in openSUSE) respond to this time change that was done while it was running? My goal is to not change any init scripts provided with openSUSE. Except when all else fails. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Wednesday, January 15, 2014 08:32:42 AM Per Jessen wrote:
Anyway, assuming that your GPS device is able to notify the system when it has a stable time signal, it ought not be a big deal to trigger a set-time command of that event.
So, on openSUSE (the reason we are discussing it here), could it be that I should make a separate system service that:
1. Waits for the GPS to get sat fix
2. Sets the PC time accordingly. This brings the time to within a couple seconds of being accurate.
3. Exits. This should only be done once.
That is probably what I would do, yes. It's not the most elegant, but it's an easy script to write: while time-not-available; do sleep 1; done set-time. I guess it's only needed on boot-up? I.e. once the vehicle is on the road, the GPS time is always available or only sporadically unavailable?
How will ntp (as started by default in openSUSE) respond to this time change that was done while it was running?
Using 'ntpd -q -g' to set the time, there should be no problem, but it's easily tested. I've just tried it on a test-system, but because the system is currently running ntpd sync'ed to DCF77, I don't see any effect :-( -- Per Jessen, Zürich (1.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wednesday, January 15, 2014 09:14:17 AM Per Jessen wrote:
I guess it's only needed on boot-up? I.e. once the vehicle is on the road, the GPS time is always available or only sporadically unavailable?
Yes. Of course satellites may go away. But if the time in the GPS locations drifts a bit, we are happy that the system clock follows. Our goal is to match the GPS time stamps more than to have some absolute correct time.
How will ntp (as started by default in openSUSE) respond to this time change that was done while it was running?
Using 'ntpd -q -g' to set the time, there should be no problem, but it's easily tested. I've just tried it on a test-system, but because the system is currently running ntpd sync'ed to DCF77, I don't see any effect :-(
It makes sense that ntpd would be told about the time change. But if I make a script that must complete before ntpd starts, this may not be an issue. Time to jump in to systemd scripts. I have a few older scripts that have been waiting for a bit of care anyway... -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 15/01/2014 08:18, Roger Oberholtzer a écrit :
Provided that the GPS is providing times at the time the init script runs. What if the user turns on the measurement system in a parking garage where there is no satellite available? Time will not be available when the init script runs.
hello, I did not follow the hread since the beginning, exuse me if this have already been said. Time ago one could buy quartz controlled PC clocks with very good accuracy, a radio controlled clock could also be used. I do'nt know if this still exists, but I don't see either why it shouldn't. that said it could be pretty easy to record "pc time" and "gps time" and "sta time" and do not the gps have an internal timer??? professional gps, at least, should have one https://buy.garmin.com/en-US/US/oem/sensors-and-boards/gps-18x-oem/prod27594... http://static.garmincdn.com/pumac/GPS_18x_Tech_Specs.pdf says: "Onboard rechargeable backup battery can maintain the real - time clock for up to 10 days" Garmin could certainly give detailed infos and ntp soud be able to sync with the module jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wednesday, January 15, 2014 09:32:20 AM jdd wrote:
Le 15/01/2014 08:18, Roger Oberholtzer a écrit :
Provided that the GPS is providing times at the time the init script runs. What if the user turns on the measurement system in a parking garage where there is no satellite available? Time will not be available when the init script runs.
hello, I did not follow the hread since the beginning, exuse me if this have already been said.
Time ago one could buy quartz controlled PC clocks with very good accuracy, a radio controlled clock could also be used. I do'nt know if this still exists, but I don't see either why it shouldn't.
that said it could be pretty easy to record "pc time" and "gps time" and "sta time"
Our current solution does something similar in the context of a single application. We are hoping to make a solution that is available at the system level.
and do not the gps have an internal timer??? professional gps, at least, should have one
We already have the GPS in the systems. These are very high end inertial navigation systems that have a GSP as a component. We use equipment from http://www.oxts.com/. Another supplier is http://www.applanix.com/ Garmin are amateur level devices with low accuracy. Great for biking and such. No use at all in vehicles traveling up to 110 km/h (68 mph) and requiring sub- meter accuracy. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 15/01/2014 13:22, Roger Oberholtzer a écrit :
We already have the GPS in the systems. These are very high end inertial navigation systems that have a GSP as a component. We use equipment from http://www.oxts.com/. Another supplier is http://www.applanix.com/
yes, the question is do these device have a way to maintain clock when there are no satellite? they should! jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
jdd wrote:
yes, the question is do these device have a way to maintain clock when there are no satellite?
Doesn't ntpd measure the hardware clock error and adjust accordingly when there's no ntp available? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Jan 15, 2014 at 5:10 PM, James Knott
jdd wrote:
yes, the question is do these device have a way to maintain clock when there are no satellite?
Doesn't ntpd measure the hardware clock error and adjust accordingly when there's no ntp available?
Yes, except clock error is not constant either. If computer clocks were stable, we would not need ntpd in the first place :) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrey Borzenkov wrote:
Yes, except clock error is not constant either. If computer clocks were stable, we would not need ntpd in the first place :) There should be some long term drift (known as "rate"), in addition to short term variation. It's this long term rate that ntpd should be correcting. Back in the days before atomic clocks, astronomers had to determine the rate of their clocks and apply the correction in their calculations.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wednesday, January 15, 2014 08:10:58 AM James Knott wrote:
jdd wrote:
yes, the question is do these device have a way to maintain clock when there are no satellite?
Doesn't ntpd measure the hardware clock error and adjust accordingly when there's no ntp available?
Our ultimate goal is for the PC clock to match the GPS' UTC time. If that can be maintained, we are happy. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wednesday, January 15, 2014 02:03:12 PM jdd wrote:
Le 15/01/2014 13:22, Roger Oberholtzer a écrit :
We already have the GPS in the systems. These are very high end inertial navigation systems that have a GSP as a component. We use equipment from http://www.oxts.com/. Another supplier is http://www.applanix.com/
yes, the question is do these device have a way to maintain clock when there are no satellite?
They do. But I don't know how consistent they are. We would not collect data when the GPS is in that state anyway. I think we will gate having the GPS obtain a sat fix. When that happens, the system ntp init script can then do it's thing. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 15/01/2014 14:39, Roger Oberholtzer a écrit :
On Wednesday, January 15, 2014 02:03:12 PM jdd wrote:
Le 15/01/2014 13:22, Roger Oberholtzer a écrit :
We already have the GPS in the systems. These are very high end inertial navigation systems that have a GSP as a component. We use equipment from http://www.oxts.com/. Another supplier is http://www.applanix.com/
yes, the question is do these device have a way to maintain clock when there are no satellite?
They do. But I don't know how consistent they are. We would not collect data when the GPS is in that state anyway. I think we will gate having the GPS obtain a sat fix. When that happens, the system ntp init script can then do it's thing.
ntp is certainly not as good as a professional time keeper like the one you have in your high end GPS. Did you ask the GPS maker about this? lot of things makes gps (satellite) clock out of sync, let only the distance and resulting travel time that needs correction. a correct (usual grade) quartz clok is probably enough for any work under the 1s a month drift. I use a Wave casio clock, under €100 and radio piloted and always in sync. PC original clock was horrible, I never understood really why a better clock was not implemented, even at this time quartz clocks where pretty cheap... in conclusion, You should probably ask ntp to use the gps clock satellite or not. By the way is there a way to compare the gps internal clock and the satellite time? jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wednesday, January 15, 2014 03:40:41 PM jdd wrote:
ntp is certainly not as good as a professional time keeper like the one you have in your high end GPS. Did you ask the GPS maker about this?
You mean could the receiver act as a ntp server? I have asked. It does not do so. The accuracy of the GPS receiver internally is only part of the issue. I need to get that time into the PC with small error. At 90 km/h (you move 25 meters a second), an error of 0.1 seconds produces an error of 2.5 meters. The problem is that the times in records from a GPS are when that record was calculated. It is not the time when I see it. The difference in those times can result in a many meters error. This is why the PPS from the GPS is interesting. It tells when certain things are calculated in the receiver. There is a kernel driver specifically for using the PPS signal. gpsd/ntpd use this signal to improve interpretation of the time in the GPS data when it eventually and non-deterministically arrives, and thus set the PC clock more accurately. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 15/01/2014 15:52, Roger Oberholtzer a écrit :
meters a second), an error of 0.1 seconds produces an error of 2.5 meters.
any correct clock is better than 1s for a hole month!
The problem is that the times in records from a GPS are when that record was calculated. It is not the time when I see it.
? two things. * if the gps clock is really unusable, read this: http://tf.nist.gov/service/pdf/computertime.pdf for some very good solutions (two last paragraphs) * I do not own a gps like yours nor have ever tried to connect the gps clock to ntp, but I wonder how the gps internal clok is advertised to the world. I mean, what is the gps saying when there are no satellite visible? is it transmitting anything? don't it transmit at least the time? jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wednesday, January 15, 2014 04:19:40 PM jdd wrote:
Le 15/01/2014 15:52, Roger Oberholtzer a écrit :
meters a second), an error of 0.1 seconds produces an error of 2.5 meters.
any correct clock is better than 1s for a hole month!
The problem is that the times in records from a GPS are when that record was calculated. It is not the time when I see it.
?
two things.
* if the gps clock is really unusable, read this:
http://tf.nist.gov/service/pdf/computertime.pdf
for some very good solutions (two last paragraphs)
* I do not own a gps like yours nor have ever tried to connect the gps clock to ntp, but I wonder how the gps internal clok is advertised to the world.
The problem is not the accuracy of the GPS clock. Let's pretend it is perfect. That is only internal. It must communicate this information externally somehow. This is via serial, USB or ethernet. All three of those are non- deterministic in that you do not know how long it takes for the data to get from the GPS into your system. That jitter is a source of error. With the serial port, the GPS can toggle a line that interrupts the client device, allowing improved interpretation of the time when, eventually, it arrives.
I mean, what is the gps saying when there are no satellite visible? is it transmitting anything? don't it transmit at least the time?
This is not standard. Some report whatever their clock says. Others transmit nothing. We use the NMEA ZDA record for this. It seems to be transmitted even when there are no satellites. Until you see something like a GGA record, you have to assume there has not been a sat fix and thus the time in the ZDA record is not known to be current UTC time. The NMEA protocol is highly bad. Read Eric Raymond's assessment at http://esr.ibiblio.org/?p=801 -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 15/01/2014 17:00, Roger Oberholtzer a écrit :
The problem is not the accuracy of the GPS clock. Let's pretend it is perfect. That is only internal. It must communicate this information externally somehow. This is via serial, USB or ethernet. All three of those are non- deterministic in that you do not know how long it takes for the data to get from the GPS into your system. That jitter is a source of error. With the serial port, the GPS can toggle a line that interrupts the client device, allowing improved interpretation of the time when, eventually, it arrives.
I mean, what is the gps saying when there are no satellite visible? is it transmitting anything? don't it transmit at least the time?
This is not standard. Some report whatever their clock says. Others transmit nothing. We use the NMEA ZDA record for this. It seems to be transmitted even when there are no satellites.
is this not enough? I hardly see hox you can get better result :-( Until you see something like a GGA record, you
have to assume there has not been a sat fix and thus the time in the ZDA record is not known to be current UTC time. The NMEA protocol is highly bad. Read Eric Raymond's assessment at http://esr.ibiblio.org/?p=801
Eric being one of the best author I know, I see no other solution than the one I quoted in the pdf in my last post, that is radio time or physical timer, ntp should try to fix the transmission problems - what other solution?? jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wednesday, January 15, 2014 10:34:48 PM jdd wrote:
Eric being one of the best author I know, I see no other solution than the one I quoted in the pdf in my last post, that is radio time or physical timer, ntp should try to fix the transmission problems - what other solution??
Indeed. Part of our plan is to move from our own solution to gpsd, which has attempted to make sense of the NMEA data delivery. And to use the PPS when available to improve things even more. I think that my questions here revolve more around ntpd/chrony than gpsd. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
The ntp init script used to run 'ntpdate -g', I'm sure it does something similar now. That'll set the clock, but with a jump, not a slow adjustment.
Ntpdate is deprecated. Use ntpd -q instead. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
This is a worry. These systems are in vehicles on the road. We have no control over the time on the PC clock at boot. We do NOT (repeat NOT) want the users entering the BIOS and mucking about.
IIRC, it's possible to just set the time with ntpd -q. Once that's done, you can start ntpd and let it keep the time. This is quite easy to do in a start up script, such as /etc/init.d/after.local. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-01-14 09:51, Roger Oberholtzer wrote:
Our main question is how the system acts if, at boot, there is no GPS data. Is the time left alone? When the time does arrive, how quickly will the system clock reflect the time? For example, it may turn out that the PC clock and the GPS time differ by some hours. Does NTP always do a gradual time shift? Can that be disabled? These systems are booted a couple times a day.
When the NTP daemon is already running, it always compensates very slowly. It simply speeds up or slows down the system clock till it gets in sync with the reference, and this can take hours. It is done intentionally slowly so as not to disrupt (much) Linux processes that rely on clock timings. When the difference between the computer time and the found reference is too large, ntp simply bails out. However, when you start the ntp service, the service startup script does first a clock setup to the reference, and this can jump years if needed in a milisecond. Once the computer clock is adjusted, the daemon is started and takes over syncing the computer system clock and the reference (maybe again adjusting the clock, but slowly). You probably will need "something" to tell the operator if the system clock is in absolute sync with GPS or not, and then... well, you have to decide if your software does something or if the operator does something or whatever :-) -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)
On Tuesday, January 14, 2014 09:47:42 PM Carlos E. R. wrote:
When the NTP daemon is already running, it always compensates very slowly. It simply speeds up or slows down the system clock till it gets in sync with the reference, and this can take hours. It is done intentionally slowly so as not to disrupt (much) Linux processes that rely on clock timings.
Leaving those Linux processes that rely on accurate time at all times to fend for themselves... This is a I understand things to be.
When the difference between the computer time and the found reference is too large, ntp simply bails out.
However, when you start the ntp service, the service startup script does first a clock setup to the reference, and this can jump years if needed in a milisecond. Once the computer clock is adjusted, the daemon is started and takes over syncing the computer system clock and the reference (maybe again adjusting the clock, but slowly).
Sounds good. But in the case of a GPS providing the times, it assumes that the GPS has satellite fix when it runs. In a moving vehicle, this is not always the case.
You probably will need "something" to tell the operator if the system clock is in absolute sync with GPS or not, and then... well, you have to decide if your software does something or if the operator does something or whatever :-)
This is something I am trying to design. I need to know (1) did the GPS have sat fix when ntp started and (2) has the time completed being adjusted as needed. #2 must, I would imagine, be ascertainable from NTP logs. #1 is most likely something we will need to implement. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 14/01/14 05:51, Roger Oberholtzer escribió:
Our main question is how the system acts if, at boot, there is no GPS data. Is the time left alone?
It uses the rtc time.
When the time does arrive, how quickly will the system clock reflect the time?
It depends on the ntp client and server, it takes ntpd to settle from a few minutes to several hours. If that's not desired, try NTP server named "chrony" (the default ntp daemon in RHEL 7 and later) but it has limited support for gps devices. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tuesday, January 14, 2014 09:02:52 PM Cristian Rodríguez wrote:
El 14/01/14 05:51, Roger Oberholtzer escribió:
Our main question is how the system acts if, at boot, there is no GPS data. Is the time left alone?
It uses the rtc time.
When the time does arrive, how quickly will the system
clock reflect the time?
It depends on the ntp client and server, it takes ntpd to settle from a few minutes to several hours. If that's not desired, try NTP server named "chrony" (the default ntp daemon in RHEL 7 and later) but it has limited support for gps devices.
I looked at chrony a while back. It seems to be designed for systems that are turned on and off alot. Like laptops. Or mobile systems such as ours. Opinion is divided as to whether chrony is really needed as an alternative to ntp. I think it depends on what your problem is. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Just saw on the Factory list that someone was having an issue with ntpd starting on a systemd-type system. Seems that the boot process will wait for ntpd startup to complete before the system boot completes. This I did not expect. The reason given was that things like dovecot will die if the time jumps some amount. To keep that from happening, ntpd must start and presumably complete time sync before many services complete. I just know this will be a problem for me. I wonder if that behavior can be modified without too much pain... -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
I just know this will be a problem for me. I wonder if that behavior can be modified without too much pain...
You could add a line to /etc/init.d/after.local to start it again. I have to do that to get the Ethernet port working on one system. The line I added for that is "systemctl restart network.service". If I don't do that, the port isn't usable. Between systemd and Apparmor, using openSUSE has become real "fun". -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-01-17 13:38, Roger Oberholtzer wrote:
Just saw on the Factory list that someone was having an issue with ntpd starting on a systemd-type system. Seems that the boot process will wait for ntpd startup to complete before the system boot completes. This I did not expect. The reason given was that things like dovecot will die if the time jumps some amount. To keep that from happening, ntpd must start and presumably complete time sync before many services complete.
That was my hypothesis, it has to be verified. -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)
Roger Oberholtzer wrote:
Just saw on the Factory list that someone was having an issue with ntpd starting on a systemd-type system. Seems that the boot process will wait for ntpd startup to complete before the system boot completes. This I did not expect. The reason given was that things like dovecot will die if the time jumps some amount. To keep that from happening, ntpd must start and presumably complete time sync before many services complete.
My ntpd completes startup in less than a second. I use broadcast though, so no DNS etc. -- Per Jessen, Zürich (7.0°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Friday, January 17, 2014 03:33:16 PM Per Jessen wrote:
Roger Oberholtzer wrote:
Just saw on the Factory list that someone was having an issue with ntpd starting on a systemd-type system. Seems that the boot process will wait for ntpd startup to complete before the system boot completes. This I did not expect. The reason given was that things like dovecot will die if the time jumps some amount. To keep that from happening, ntpd must start and presumably complete time sync before many services complete.
My ntpd completes startup in less than a second. I use broadcast though, so no DNS etc.
But our evil users will start the system in a underground car park / atom bomb shelter. They won't like if it won't allow them to log in until the GPS gets sats. So I think I will configure but not enable ntpd. Then my new script will start ntpd when it sees the GPS has come on line. And I will pray that none of the services I need barf if the time changes in a way not to their liking. Seems a potentially fragile solution. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Friday, January 17, 2014 03:33:16 PM Per Jessen wrote:
Roger Oberholtzer wrote:
Just saw on the Factory list that someone was having an issue with ntpd starting on a systemd-type system. Seems that the boot process will wait for ntpd startup to complete before the system boot completes. This I did not expect. The reason given was that things like dovecot will die if the time jumps some amount. To keep that from happening, ntpd must start and presumably complete time sync before many services complete.
My ntpd completes startup in less than a second. I use broadcast though, so no DNS etc.
But our evil users will start the system in a underground car park / atom bomb shelter. They won't like if it won't allow them to log in until the GPS gets sats.
So you disable the setting of time on startup. That way there's nothing to wait for. Your services that require a correct time will have to wait until your GPS is working anyway, right?
So I think I will configure but not enable ntpd. Then my new script will start ntpd when it sees the GPS has come on line. And I will pray that none of the services I need barf if the time changes in a way not to their liking. Seems a potentially fragile solution.
I suggest 's/pray/test/g' -- Per Jessen, Zürich (6.7°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Friday, January 17, 2014 03:48:14 PM Per Jessen wrote:
So you disable the setting of time on startup. That way there's nothing to wait for. Your services that require a correct time will have to wait until your GPS is working anyway, right?
Indeed. Knowing when this is the case is part of the issue.
So I think I will configure but not enable ntpd. Then my new script will start ntpd when it sees the GPS has come on line. And I will pray that none of the services I need barf if the time changes in a way not to their liking. Seems a potentially fragile solution.
I suggest 's/pray/test/g'
First you hope. Then you pray. Then you test. Then you pray. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-01-17 17:35, James Knott wrote:
Roger Oberholtzer wrote:
First you hope. Then you pray. Then you test. Then you pray.
Rinse and repeat.
Programmer found death this morning, in his shower. In his hand he still held a shampoo bottle... :-) -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)
On 2014-01-17 15:38, Roger Oberholtzer wrote:
sats. So I think I will configure but not enable ntpd. Then my new script will start ntpd when it sees the GPS has come on line. And I will pray that none of the services I need barf if the time changes in a way not to their liking. Seems a potentially fragile solution.
If the CMOS clock was withing seconds, everything should survive. -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)
On Friday, January 17, 2014 07:01:15 PM Carlos E. R. wrote:
On 2014-01-17 15:38, Roger Oberholtzer wrote:
sats. So I think I will configure but not enable ntpd. Then my new script will start ntpd when it sees the GPS has come on line. And I will pray that none of the services I need barf if the time changes in a way not to their liking. Seems a potentially fragile solution.
If the CMOS clock was withing seconds, everything should survive.
That is a core problem. I can't guarantee this will be the case. I have to build for the worst case scenario. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (8)
-
Andrey Borzenkov
-
Carlos E. R.
-
Cristian Rodríguez
-
James Knott
-
jdd
-
John Andersen
-
Per Jessen
-
Roger Oberholtzer