Hi I need micro second level time synchronisation within a group of systems, But I found it difficult.
My experiment: in a LAN, constantly comparing 2 x64 linux system hardware time clocks between via some ruby code: which is using udp packets to send microseocond timestamp to the other and comparing the difference. experiment code: https://github.com/c2h2/chrono-diff
Results: The time drift quickly! Interestingly they are also not drifting within one direction, the difference of two clocks is sometimes positive, sometimes negative, random manner. And they might differ as apart as 1 second after several hours from pervious sync.
How should I keep the perfectly sync'ed all the time? run time sync every several minutes?
setup one of the host as ntp server and let the other host use that server as ntp server.
http://www.ntp.org/documentation.html
Related
Is there a clock in Linux with nanosecond precision that is strictly increasing and maintained through a power cycle? I am attempting to store time series data in a database where each row has a unique time stamp. Do I need to use an external time source such as a GPS receiver to do this? I would like the time stamp to be in or convertible to GPS time.
This is not a duplicate of How to create a high resolution timer in Linux to measure program performance?. I am attempting to store absolute times, not calculate relative time differences. The clock must persist over a power cycle.
Most computers now have software that periodically corrects the system time using the internet. This means that the system clock can go up or down some milliseconds every so often. Remember that the computer clock has some drift. If you don't want problems with leap seconds, use sidereal time (no leap second corrections). ntp will be off in the microsecond or millisecond range because of differences in latency over the internet. The clocks that would meet your requirements are fifty thousand dollars and up.
Based on the question, the other answers, and discussion in comments...
You can get "nanosecond precision that is strictly increasing and maintained through a power cycle" by combining the results of clock_gettime() using the CLOCK_REALTIME and from using CLOCK_MONOTONIC - with some caveats.
First, turn off NTP. Run NTP once at each system restart to sync your time with the world, but do not update the time while the system is up. This will avoid rolling the time backwards. Without doing this you could get a sequence such as
20160617173556 1001
20160617173556 1009
20160617173556 1013
20160617173555 1020 (notice the second went backward)
20160617173556 1024
(For this example, I'm just using YYMMDDhhmmss followed by some fictional monotonic clock value.)
Then you face business decisions.
• How important is matching the world's time, compared to strictly increasing uniqueness?
. (hardware clock drift could throw off accuracy with world time)
• Given that decision, is it worth the investment in specialized hardware, rather than a standard (or even high-end) PC?
• If two events actually happen during the same nanosecond, is it acceptable to have duplicate entries?
• etc.
There are many tradeoffs possible based on the true requirements that lead to developing this application.
In no particular order:
To sure your time is free of savings time changes use date's -u argument to use UTC time. That is always increasing, baring time corrections from system admins.
The trouble with %N is that the precision you actually get depends on the hardware and can be much less than %N allows. Run a few experiments to find out. Warnings on this tend to be everywhere but it is still overlooked.
If you are writing Cish code, see the utime() function and use gmtime(), not localtime() type functions to convert to text. Look at the strftime() function to format the integer part of the time. You will find the strftime() format fields magically match those of the date command formats as basically, date calls strftime. The true paranoid willing to write additional code can use CLOCK_MONOTONIC to be sure your time is increasing.
If you truly require increasing times you may need to write your own command or function that remembers the last time. If called during the same time add and offset of 1. Keep incrementing the offset as often as required to assure unique times until you get hardware time greater than your adjusted time.
Linux tends to favor NTP to obtain Network time. The previously mentioned function to assure increasing time will help with backwards jumps as the jumps are usually not large.
If nanosecond precision is really sufficient for you:
date +%s%N
I want to know is there any way to change Windows or Linux clock rate or the system clock rate (maybe via BIOS)? I mean accelerate or decelerate system clock!
For example every 24 hours in the computer lasts 12 hours or 36 hours in real!!!
NOTE :
Using the below batch file, I can decelerate Windows time. But I want something in a lower level! I want to change clock pace in a way that all time for all the programs and tool be slower or faster! not only Windows time!
#echo off
:loop
set T=%time%
timeout 1
time %T%
timeout 1
goto loop
So your CPU's clock is not actually programmable via system calls. It's actually working off of an oscillator w/ crystal. You cannot change during booting up. This is done intentionally so that your CPU is able time regardless of your power/wifi/general system status.
As commented by That Other Guy you might perhaps use adjtimex(2) syscall, but you first should be sure that no NTP client daemon -which uses adjtimex- is running (so stop any ntpd or chrony service).
I'm not sure it would work, and it might make your system quite unstable.
A more rude possibility might be to forcibly set the date(1) -or also hwclock(8)- quite often (e.g. in some crontab job running every 5 minutes).
I believe it (i.e. decelerating a lot the system clock) is a strange and bad thing to do. Don't do that on a production machine (or even on some machine doing significant requests on the Web). Be prepared to perhaps break a lot of things.
The Raspberry Pi has no real clock to keep track of time. Instead it uses the NTP daemon to keep date and time as accurate as possible. This should work, I guess, but in my case it doesn't for some reason.
Without going into too much detail, I use my Raspberry Pi in a way where it's always plugged in but doesn't always have an Internet connection. Sometimes the CPU has allot to do. Sometimes it doesn't. This results in the Rpi losing track of time. I would think that once it gets back on the Internet, it would sync the clock using the NTP servers to get back on track. However, it doesn't. From what I understand, if the offset is too big, the system doesn't sync the time.
Is there any way to force NTPD to sync the time no matter how big the offset is compared to the NTP servers? Or will I have to set up a cronjob say every hour running:
ntpd -g"
Add this to /etc/ntp.conf:
tinker panic 0
That will cause ntpd to sync despite the large clock offset.
You need to add a real time clock as a local clock. I suggest you shop for something with 3ppm or better accuracy. Then set it up as a stratum 10 clock. You may also connect a stratum 0 clock, e.g. a wwvb, msf or dcf77 receiver. However in all cases you need a reasonable local clock. That is your only chance to keep accurate timing is to add an RTC.
I am implementing a distributed audio repository on which registered users can create audio recordings and share these with other registered users. Ideally we would like to run the repository on a few (n<5) laptops that are intermittently connected to a wireless mesh network. So repository nodes running couchdb would replicate with each other when connectivity is available. The repository will be situated in a rural village, which has no power infrastructure, so repository laptops are powered by solar panels and car batteries. In the past we have run into problems where laptop batteries drain completely resetting the computers clock to 0 -- January 1st, 1970. Internet connectivity is also very patchy and very expensive. Keeping in mind intermittent power and connectivity as well as very inaccurate clocks, I was wondering how best to sequence documents (or recordings) so that they roughly correspond to the chronology of when recordings were created on different repository nodes, both before and after replication. I would be very grateful for any help on how I could create a replicating by_date, by_sequence, by_chronology (or whatever you want to call it) view that could work within these constrained conditions. It doesn't have to be perfect, just good enough or better than a naive solution.
Thank you!
Thomas
Well, you could start by including a simple incrementing integer in each new document, by looking at the last number available in the database and taking the next one. This gets you a few things:
Consistent ordering for locally recorded segments in the absence of connectivity
After synchronization with other nodes, new segments will get a higher sequence number than all replicated segments
This will mean that you cannot piece together if sequence number 45 from one node was recorded earlier or later than sequence number 45 from another node, but it does let you piece together a directed acyclic graph, imposing at least a rudimentary ordering of the documents.
You could add a value representing the node on which the segment was recorded to make it even better.
We have two Linux servers, ServerA and ServerB. The system time on ServerA seems to be slightly behind ServerB, only by a few hundredths of a second.
I am trying to diagnose an issue with a distributed transaction and have noticed slight inconsistencies between the times of the two servers, but I need some way to prove it. I need something that will tell me "ServerA is 0.002 of a second behind ServerB". Perhaps not as verbose as this but you get the picture.
Is there any way to prove this? I.e. Is there a utility/script/command that I can use to tell me what exactly the offset is?
You can use ntpdate in query-only mode on both servers and compare the results (e.g., how far out does it report each server to be). Compare them against the same time source, of course. And recommend to the admins that if the machines aren't already keeping themselves up to date with ntpd, they should be. If timing is that critical to what you're doing, you should have a local timeserver that periodically syncs to the outside world, and which your local servers sync with.
Using a utility called clockdiff, part of the iputils package. You need to run it with root, e.g. sudo clockdiff <hostname> and its output looks like this:
..
host=<hostname> rtt=562(280)ms/0ms delta=-3ms/-3ms Tue Dec 12 13:34:26 2017
you can use NTP to sync the 2 servers, eg ntpdate