0

I was searching for a solution but didn't find clear answer.

In my company, all our servers are syncing time with one of our private ntp servers (which are stratum 3 if I'm correct).

These stratum 3 servers are of course configured to get time of some public NTP servers (stratum 2 if i'm correct)

because of some regulations related to our business, we need to constantly be sure that our client servers don't have big offset with the stratum 2 servers.

So we are monitoring that, but the offset our client servers are seeing are only the offset with our stratum 5 servers, is there something to do to get the offset with stratum 2 servers, even if it's configured to use internal stratum 3 servers? Note that our client servers don't have internet access and the goal is to stay like that.

I was wondering if there is something to do, on our client servers, to get the offset with stratum 2. by doing a calculation? (offset client srv + offset stratum 3?) any other possibilities?

I imagine this is a concern several company have, a solution should exist

thx a lot in advance

edit : I changed the stratum number that I wrote at the beginning, at my understanding was nto correct at this time

1
  • Actually I don't quite understand the question: The Offset shown in ntpq the the offset from the reference time, not the offset to the next higher (lower) stratum. So why do you care about stratum-2 servers?
    – U. Windl
    Dec 30, 2019 at 14:08

4 Answers 4

2

Root dispersion of 81 ms over the Internet is quite believable. The stratum 0 may be halfway around the world. Total error adds up over multiple hops.

Consider adding a NTP hardware appliance, with radio receivers and a decent oscillator. Your performance requirements justify the cost and inconvenience. Bonus, it doesn't require Internet to work, but keep your Internet sources too.

1

Have you ever considerated about using a GPS receiver (probably coupled with gpsd) as a time source for your NTP?

1
  • no because the regulator ask us to use the public NIST servers (which are stratum 2)
    – vercetty92
    Mar 14, 2019 at 15:12
1

This is answered at Verify internal NTP server is sending the correct time?. Short summary:

  1. Make sure you have a good configuration.

  2. NTP already monitors offset from its upstream stratum as part of its normal operation, so all you need is to use an appropriate tool to extract that information and plug it into your alerting/telemetry system.

Your ntpq output shows a stratum 3 server with a system offset of less than 1 millisecond difference. That is about as good as you can expect over Internet links without implementing special measures. The root dispersion is a bit high, but that's almost entirely due to your upstreams, since your delay to them is only a bit over 2 ms.

If you configure your internal systems to sync with your stratum 3 servers, and they show a similar system offset, then you have achieved your goal. But make sure you have at least 4 public stratum 1/2 servers and at least 4 internal servers as well.

Don't forget to read the NTP Best Current Practices draft RFC, which explains why you need multiple sources and why monitoring is important.

12
  • Hi Paul,thx for your answer. I'm surprised I have a big "root dispersion value" (0.19151 s) on a client srv. If I look at the offset on my NTP server (offset -0.003075 sec), and the offset on the cleint srv (0.007211 sec), this is quite a big difference. I got them by running "ntpdate -q" at the same time (yeah I know it's not accurate at 100% but it can give us a good idea I think, and even if i look at the loopstat file, I see same kind of offset). Do you know why? FYi the regulation ask us to be under 0.05s of offset, so if I use the root distance I will always be alerted^^ thx
    – vercetty92
    Mar 13, 2019 at 13:58
  • damn I'm noticing that my "stratum" understanding was not so good. Example on my final server (ntp client): ntpstat synchronised to NTP server (10.243.144.1) at stratum 5 time correct to within 81 ms polling server every 32 s so in fact my goal is to have the offset with stratum 4 (the public server that my stratum 5 is using), and not stratum 1 ...if "root dispersion" is the offset with stratum 0, it maybe explain why I have a big value (as stratum 0 is several hops far...no?) if it's correct, is there a way to have the offset with stratum 4?
    – vercetty92
    Mar 13, 2019 at 15:47
  • Please edit your question to add the new details and format them legibly. Mar 13, 2019 at 19:04
  • @vercetty92: If your regulators are asking for offset, you should give them the system offset value. It sounds like you are well within their regulations, but post the output of ntpq -npc rv and we can confirm for sure.
    – Paul Gear
    Mar 13, 2019 at 23:33
  • Hi, I have edited the question with the good stratum number. Here is the output requested: pastebin.com/zzMhzem6 so now the question is, how to get the offset my server have with stratum 2, while he is syncing with stratum 3^^ thx
    – vercetty92
    Mar 14, 2019 at 14:01
0

ok I found the solution!. I can ask to my stratum n-1 what is the offset he have with stratum n-2 using ntpdc command, then I can look on peerstat file what the offset my client server have with the stratum n-1. I did a little script:

#!/bin/bash
#determine the IP of the currently used stratum n-1 srv as NTP source
used_ntp_source=`ntpq -np | grep "*" | awk '{print $1}' | sed 's/*//'`

#determine the offset between used stratum n-1 srv and the stratum n-2 (in seconds)
offset_between_stratn_1_and_stratn_2=`ntpdc -np $used_ntp_source | grep "*" | awk '{print \$7}'`

#determine the offset between localhost and the stratum n-1  srv (in seconds),looking in the last 20 lines of peerstats file, but keeping only the last one
local_offset_with_stratn_1=`tail -20 /var/log/ntpstats/peerstats | grep $used_ntp_source | tail -1 | awk '{print $5}'`

#calculation
calculated_offset=$(python -c "from decimal import Decimal; print(Decimal('$offset_between_stratn_1_and_stratn_2') + Decimal('$local_offset_with_stratn_1'))")

echo "the calculated offset is $calculated_offset"

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .