for X in `cat YourList.txt`
do
Y=`ssh $X -l root 'ntpdate -q 10.168.XX.XX' | awk -F, '{print $3}'`
echo $X $Y
done

Your output

HOST1 offset 0.007304
HOST2 offset 0.044396
HOST3 offset 0.038323
HOST4 offset 274.636170
HOST5 offset 189.366374

To see how far your servers are from the NTP source

for X in `cat YourList.txt`
do
Y=`ssh $X -l root 'ntpdc -c loopinfo' | grep offset`
echo $X $Y
done

Output

HOST1 offset: 0.009959 s
HOST2 offset: 0.042295 s
HOST3 offset: 0.038320 s
HOST4 offset: 0.000000 s
HOST5 offset: 0.000000 s

0.000000 s means you haven’t picked up an authoritative time source yet.

Enable syncing with upstream servers from your NTP source. These settings are set in /etc/ntp.conf

# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
# Limiting to three servers as requested by pool.ntp.org
server myTIME01.domain.com
server myTIME02.domain.com

Now we need to make sure our time is somewhat accurate – within a minute or so. But before we do that we have to stop the ntpd daemon.

service ntpd stop

Now sync time

ntpdate -u qantp01.qa.testlab.com

Make sure the NTP daemon is enabled

chkconfig --list ntpd
ntpd           	0:off	1:off	2:off	3:off	4:off	5:off	6:off

If it’s not, enable it

chkconfig --level 2345 ntpd on

and verify

chkconfig --list ntpd
ntpd           	0:off	1:off	2:on	3:on	4:on	5:on	6:off

And restart the daemon

service ntpd start

Now we need to make sure time is syncing correctly. We can do this with ntpq \-p (or use \-np for ip’s, and not names.) This provided you with a list of time servers and the delay, offset and jitter that your server is experiencing with them. The delay and offset values should be non-zero and the jitter value should be under 100. The times are in milliseconds (1/1000 of a second.) The important thing to look for is the * you see in the first line. The * means you are syncing with a server on the internet. If you don’t see it right away, wait a few minutes and try again. It may take up to 15 minute for the local clock to get in sync with the remote server. Patience is your friend.

ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*qantp01.qa.test 209.20.66.253    3 u  113  256  377    0.165   -2.251   2.791
 LOCAL(0)        .LOCL.          10 l   27   64  377    0.000    0.000   0.001

The first character in the leftmost column indicates the status of the peer, followed by the name or IP of the peer

“*” selected for synchronization
“o” selected for synchronization, PPS signal in use.
“+” included in the final selection set;
“sp” discarded as unreachable, synchronized to this server (synch loop) or outrageous synchronization distance;
“x” designated falsticker by the intersection algorithm;
“.” culled from the end of the candidate list;
“-” discarded by the clustering algorithm;
“#” selected for synchronization but distance exceeds maximum;The third column (st) is the stratum of your peer. LOCAL is a loopback address used for when no other clocks are available, and has a default setting of 10. Valid values are between 1 and 15. A value of 16 is a invalid stratum value representing “this server is not considered as a time provider”. This can be for various reasons, the most common reasons are “time provider not synchronized”, “configured source does not exist” or “ntp server not running”.

The fourth column indicates the type of server it is, and isn’t of much concern.

l = local (such as a GPS, WWVB)
u = unicast (most common)
m = multicast
b = broadcast
- = netaddr

The seventh column indicates reach, and should be at 377. An explanation of why from Linux Journal

Each remote server or peer is assigned its own buffer by ntpd. This buffer represents the status of the last eight NTP transactions between the NTP daemon and a given remote time server. Each bit is a boolean value, where a 1 indicates a successful transaction and a 0 indicates a failure. Each time a new packet is sent, the entire eight-bit register is shifted one bit left as the newest bit enters from the right.
The net result is that dropped packets can be tracked over eight poll intervals before falling off the end of the register to make room for new data. This recycling of space in the register is why it’s called a circular buffer, but it may make more sense to think of it in linear terms, as a steady, leftward march–eight small steps, and then the bit ends up wherever bits go when they die.
For reasons that seemed good to the developers, this register is displayed to the user in octal values instead of binary, decimal or even hex. The maximum value of an eight-bit binary number is 11111111, which is 377 in octal, 255 in decimal and 0xFF in hex.

The ninth column indicates offset in milliseconds, and should be less than 150
If you want to see how accurate your time is, you can use

ntpdc -c loopinfo
offset:               -0.064429 s
frequency:            -19.206 ppm
poll adjust:          30
watchdog timer:       175 s

To see the remaining correction

[root@QANTP01 ~]# ntpdc -c kerninfo
pll offset:           4294.91 s
pll frequency:        -19.206 ppm
maximum error:        0.437245 s
estimated error:      0.06018 s
status:               0001  pll
pll time constant:    6
precision:            1e-06 s
frequency tolerance:  512 ppm

You can get the same rough information from ntptime

ntptime
ntp_gettime() returns code 0 (OK)
  time cd6e9ff0.43c3e000  Fri, Mar 20 2009 16:06:24.264, (.264708),
  maximum error 468477 us, estimated error 60180 us
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset -60495.000 us, frequency -19.206 ppm, interval 1 s,
  maximum error 468477 us, estimated error 60180 us,
  status 0x1 (PLL),
  time constant 6, precision 1.000 us, tolerance 512 ppm,

To query your time server, but not change it, you can use ntpdate -q. However, you’ll need to supply an IP address. I suggest you use the one with the * when you do an ntpq -np, as that is the one you are using for syncing.

ntpdate -q 192.168.106.34
server 192.168.106.34, stratum 3, offset -0.001684, delay 0.02576
26 Mar 16:21:46 ntpdate[23454]: adjust time server 192.168.106.34 offset -0.001684 sec

You can also use ntpdate -d to look at the same information, but with debugging information.

ntpdate -q 192.168.106.34
server 192.168.106.34, stratum 3, offset -0.001684, delay 0.02576
26 Mar 16:21:46 ntpdate[23454]: adjust time server 192.168.106.34 offset -0.001684 sec
ntpdate -d 192.168.10.10
26 Mar 16:22:28 ntpdate[23457]: ntpdate 4.2.2p1@1.1570-o Tue Jun 10 00:07:14 UTC 2008 (1)
Looking for host 192.168.106.34 and service ntp
host found : qantp01.qa.testlab.com
transmit(192.168.106.34)
receive(192.168.106.34)
transmit(192.168.106.34)
receive(192.168.106.34)
transmit(192.168.106.34)
receive(192.168.106.34)
transmit(192.168.106.34)
receive(192.168.106.34)
transmit(192.168.106.34)
server 192.168.106.34, port 123
stratum 3, precision -20, leap 00, trust 000
refid [192.168.106.34], delay 0.02576, dispersion 0.00000
transmitted 4, in filter 4
reference time:    cd7688e3.2844bded  Thu, Mar 26 2009 16:06:11.157
originate timestamp: cd768cb4.2295b2a8  Thu, Mar 26 2009 16:22:28.135
transmit timestamp:  cd768cb4.22fc6972  Thu, Mar 26 2009 16:22:28.136
filter delay:  0.02579  0.02576  0.02579  0.02576
         0.00000  0.00000  0.00000  0.00000
filter offset: -0.00164 -0.00164 -0.00165 -0.00164
         0.000000 0.000000 0.000000 0.000000
delay 0.02576, dispersion 0.00000
offset -0.001646
 
26 Mar 16:22:28 ntpdate[23457]: adjust time server 192.168.106.34 offset -0.001646 sec

You can also use ntptrace to watch the system time synchronization (the -n flag turns off name lookups.) This will allow you to follow the time synchronization to it’s master time source.

ntptrace -n 192.168.106.34
192.168.106.34: stratum 3, offset -0.005207, synch distance 0.299721
209.20.66.253: stratum 2, offset 0.004282, synch distance 0.061297
192.5.41.40: stratum 1, offset -0.000018, synch distance 0.000000, refid 'USNO'

If you find you are experiencing trouble (and you’ve waited more than 15 minutes for your client clock to sync) you can enable more extensive logging. This is part of the /etc/ntp.conf configuration file.

# These should enable statistics to be kept
statsdir /var/log/ntp/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

Don’t forget to make the directory and make it readable by the ntp user (which the ntp daemon runs as.)

mkdir /var/log/ntp/
chown ntp:ntp /var/log/ntp

Now restart ntpd

service ntpd restart