For our project, we would like to have all servers and systems synchronised to a linear time reference (without leap second).
Therefore, we would discard UTC but are very interested in advertising TAI time (or GPS time).
Our time server will be connected to an atomic clock (or possibly a GPS receiver).
Is NTP suitable to advertise TAI or GPS time? If yes how to configure it?
Should we use other protocol to advertise such time?
Final note: AFAIK there is no TAI or GPS time configurable for the Linux kernel. I guess our best option is to "fake" it by configuring the kernel time to be UTC and providing it a TAI or GPS time instead. Or is there a better alternative?
According to the NTP project's page on the subject, you're going about this the wrong way. UTC is pretty heavily embedded as an assumption in NTP, but "right" timezone files are generally available - my desktop, which is Fedora 20, has them as a standard part of the
tzdata
package, in/usr/share/zoneinfo/right/
.Instead of trying to get NTP to keep the clock sync'ed to a non-UTC standard, let NTP keep the clock sync'ed in UTC, and have the system take its standard timezone from a TAI-compliant timezone file, to express this time in TAI for all requesting applications.
You can create your own time standard on an isolated network that you control. This is a little kludgy. In order for this to work you must have all of your machines configured to only synch with the time servers you control. I have provided four possibilities. I think your best bet is the first or second depending on how strict your time constraints.
Remember for all of the following options you need to ensure that the server does not have a leap file and that none of the computers ask the outside world for the time.
ntpd reference implementation with Undiciplined Local Clock (Recommended/Easiest):
If you want to have an ntp server serve a time different from UTC this is pretty easy. Set the hardware/kernel clock to whatever faketime you need. Then configure ntpd to use the Undisciplined Local Clock driver (127.127.1.x) and no external clocks. The ntp server will happily chug along and serve the local clock. The one problem is that since you are using the local clock driver the time will not be stable and will drift milliseconds one way or the other because that quartz crystal is no rubidium reference. If you need the faketime and stability; you need to use the option #2.
ntpd reference implementation w/ ULC and PPS source (Recommended/Stability):
Use the ULC described above and add a PPS source. Once you add the PPS source you will need to add the prefer keyword for the ULC entry in ntp.conf. This will mean that the server's clock is kept stable because the PPS source ticks off each second for you.
ntpd reference implementation with External Clock Discipline and the Local Clock Driver (Complicated):
This is still a solution that relies on using the ntpd reference implementation but I am not very familiar with it. All I can do is give you the link to more details: http://www.eecis.udel.edu/~mills/ntp/html/extern.html
Jans - third party ntp testing tool (easier than #3 but unknown entity)
I have no experience with this product but I know of it from the ntp mailing list. It will allow you to server faketime but it does none of the clock discipline like the reference implementation. More info: http://www.vanheusden.com/time/jans/