I need a solution for a local NTP time server to distribute time adjusted to our local time zone.
The issue is the manufacturer of a product we use have updated their hardware to a newer model and have removed the option to select the time zone in the NTP server settings. As well as removing the RTC from the units so if we set the time manually and the unit is power cycled we lose the time that was set. So we currently have 30 units running a firmware that allows TZ adjusted timing and 20 units that do not. And the manufacturers data logger logs the time from the units instead of the local machines time.
This is posing an issue as we use the data for incident investigation and the times in the data logger need to be in local time not UTC.
So is there an option for a local hosted NTP server that can receive NTP time from 0.au.pool.org and then redistribute on the local network time zone adjusted time. Then I can point the units NTP server to a local address.
NTP does not care or know anything about timezones. The timezone is set by the local device.
There is NOT an option on ANY NTP server to redistribute time zone adjusted time since the NTP packet does not have bits for this (plus timezones are set by arbitrary government edicts, so as such were never considered in the NTP protocol design). So. IF there is such a tool then it would be effectively breaking NTP. You could of course do/hack this (basically, distribute the wrong time), but it is NOT how this objective (use time zones in geographically separated systems) is met in any of the probably millions of NTP systems I managed for decades (using UTC makes comparing log files easier in my opinion, but a few folks strongly prefer their more familiar local time--it's much harder for servers to keep up with decrees then client systems, esp. in global networks). Rather, as I've said, the time zone is set by the local client systems--NEVER by NTP server(s).
Related
What happens if for some reason a cell phones clock / calendar is off by a significant amount of time. Does the TOTP (Time based OTP) algorithm generate an invalid token? Also do time zones play a role in the token being correct or does both the client and the server talk to a Network Time Protocol server to ensure that everything is synced up?
Yes, if the clocks are out of sync then the totp will not validate. But unless you know that the client clock is wrong and the server clock correct, it is not semantically correct to say that the token is invalid.
No, time zones are not relevant provided that the systems are setup correctly - both devices should base the hash on a common datum. UTC or GMT is commonly used. It's possible to have your computer showing the right wall clock time but be configured in the wrong time zone. If this is the case, it won't be able to convert the time to the common timezone correctly.
Using NTP is one solution to keeping accurate time (and a cheap one if you have an internet connection) but there are other solutions.
How much clock jitter the authentication will support is dependent on the implemented algorithm.
Background
I have a system consisting of several distributed services, each of which is continuously generating events and reporting these to a central service.
I need to present a unified timeline of the events, where the ordering in the timeline corresponds to the moment event occurred. The frequency of event occurrence and the network latency is such that I cannot simply use time of arrival at the central collector to order the events.
E.g. in the following scenario:
E1 needs to be rendered in the timeline above E2, despite arriving at the collector afterwards, which means the events need to come with timestamp metadata. This is where the problem arises.
Problem
Due to constraints on how the environment is set up, it is not possible to ensure that the local time services on each machine are reliably aware of current UTC time. I can assume that each machine can accurately gauge relative time, i.e. the clock speeds are close enough to make measurement of short timespans identical, but problems like NTP misconfiguration/partitioning make it impossible to guarantee that every machine agrees on the current UTC time.
This means that a naive approach of simply generating a local timestamp for each event as it occurs, then ordering events using that will not work: every machine has its own opinion of what universal time is.
So the question is: how can I recover an ordering for events generated in a distributed system where the clocks do not agree?
Approaches I've considered
Most solutions I find online go down the path of trying to synchronize all the clocks, which is not possible for me since:
I don't control the machines in question
The reason the clocks are out of sync in the first place is due to network flakiness, which I can't fix
My own idea was to query some kind of central time service every time an event is generated, then stamp that event with the retrieved time minus network flight time. This gets hairy, because I have to add another service to the system and ensure its availability (I'm back to square zero if the other services can't reach this one). I was hoping there is some clever way to do this that doesn't require me to centralize timekeeping in this way.
A simple solution, somewhat inspired by your own at the end, is to periodically ping what I'll call the time-source server. In the ping include the service's chip clock; the time-source echos that and includes its timestamp. The service can then deduce the round-trip-time and guess that the time-source's clock was at the timestamp roughly round-trip-time/2 nanoseconds ago. You can then use this as an offset to the local chip clock to determine a globalish time.
You don't have to use a different service for this; the Collector server will do. The important part is that you don't have to ask call the time-source server at every request; it removes it from the critical path.
If you don't want a sawtooth function for the time, you can smooth the time difference
Congratulations, you've rebuilt NTP!
while using nagios with multiple hosts spread over the network,hosts status shows a recognizable lag and takes a long time to reflect on nagios server cgi.Thus what is the optimal nrpe/nagios configration to speed up the status process for a distributed host environment.
In my case I use nagios core 4.1
nrpe 1.5
server/clients: Amazon ec2
The GUI is usually only updated once each minute (automatically), though clicking refresh can provide you with 'nearly' the latest information. I say nearly because there is a distinct processing loop inside of the Nagios core that causes it to never be real time. NRPE is going to run at the speed of your network connection - it does little else besides sending and receiving tiny amounts of data. About the only delay here is the time it takes to actually perform the check and send back the response - which, of course, has way to many factors to mention. Try looking at the output of
[nagioshome]/bin/nagiostats
There are several entries that tell you:
'Latency' - the time between when the check was scheduled to start, and the actual start time.
'Execution Time' - the amount of time checks are actually taking to run.
These entries will have three numbers, which are; Min / Max / Avg
High latency numbers (in my book that means Avg is greater than 1 second) usually means your Nagios server is over worked. There are a few things you can do to improve latency times, and these are outlined in the 'nagios.cfg' file. This latency has nothing to do with network speed or the speed of NRPE - it is primarily hardware speed. If you're already using the optimal values specified in nagios.cfg, then its time to find some faster hardware.
High execution times (for me an Avg greater than 5 seconds) can be blamed on just about everything except your Nagios system. This can be caused by faulty networks (improper packet routing), over loaded networks, faulty and/or poorly designed checks, slow target systems, ... the list is endless. Nothing you do with the Nagios and/or NRPE configs will help lower these values. Well, you could disable NRPE's encryption to improve wire time; but if you have encryption enabled in the first place, then its not likely you'd want it disabled.
I'm using a virtual server in U.S.A/Texas and its time is synchronized with "Time.windows.com". I too have in Canada/Quebec 3 PCs with a time synchronized with the same internet time. Unfortunately, my server in Texas is 40 seconds less than my 3 others PCs in Canada.
All PCs use the same time zone (UTC-5). The only difference is the country set in "Region and Language/Location"
Can someone explain how is this possible.
Thanks
See the following article it explains the (not) working of time synchronize:
http://www.pretentiousname.com/timesync/
In short:
The time synchronize job only runs once a week, and because the interal clocks of computers are unreliable you get a time difference..
Solution is to create a special sync Task that runs more often to keep the time up to date.. (al explained in the article)
Setup
I have a setup with 2 routers acting like NTP servers for an NTP client (Meinberg NTP) installed on a test server on the network. I have been synchronizing with both servers but after experiencing weird behavior, I switched to only use a single NTP server to synchronize with to be able to debug a problem I seem to have.
It seems, that the offset varies a hole lot during the day and it has values between (+10ms and -150ms). This is way off and much much more than the required values for our setup wich is a few ms a maximum.
Screenshots of statistics
I have configured the NTP Client to drop log files with statistics and then I have used a graphical dot print tool to create some graphs of the offset, jitter etc. over time. The following shows the average time of the logfile for today:
Overview statistics
Following are the offset graph, the delay, dispersion and the jitter graphs:
Offset
Delay
Dispersion
Jitter
My observations
It seems that four times today there have been some remarkable spikes on the graphs. And each time a spike has occured, that offset seems to be in sync, hitting a very few ms offset. But then it seems to be drifting away again.
The NTP Client has been running for a week, so I would expect any initial calibrations to be done.
Does anyone have the abilities to point out some obvious reasons for this behavior?
Thankyou in advance!
I found out, that the NTP servers I was synchronizing with, had delayed responses depending on the load on the servers. After correcting this to have a higher priority for the NTP servers, the problem was gone.