useful commands:
ntpq -crv
ntpq -p

if ntpq -p looks like this:

remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
time.nrc.ca     .INIT.          16 u  836 1024    0    0.000    0.000   0.000
time1.chu.nrc.c .INIT.          16 u  825 1024    0    0.000    0.000   0.000
ntp1.torix.ca   .INIT.          16 u  835 1024    0    0.000    0.000   0.000

i.e. refid is ".INIT." and reach and all columns to the right of it are 0

that means... your ntpd is too old? This was seen on an ancient gentoo box,
which was working fine until 2014 March 11, when the output of ntpq -p suddenly
changed to this for no discernable reason. ntpdate still worked from this
machine.

if ntpq -p looks alright (there are nonzero values in the right four columns), check
"ntpq -crv". If it says 'stratum=16', the server probably hasn't had time to 
synch up yet. ntpd takes an annoyingly long time to do this. Even after stratum has
become not 16, sometimes other parameters also take a while to show up, during which
your server looks like it should be "suitable for synchronization" but isn't.

Sample output from a recently started ntp server that clients think is still
"unsuitable":

associd=0 status=c018 leap_alarm, sync_unspec, 1 event, no_sys_peer,
version="ntpd 4.2.6p2@1.2194-o Sun Oct 17 13:45:13 UTC 2010 (1)",
processor="i686", system="Linux/2.6.32-5-686", leap=11, stratum=16,
precision=-21, rootdelay=0.000, rootdisp=1.305, refid=STEP,
reftime=00000000.00000000  Wed, Feb  6 2036 22:28:16.000,
clock=d6d0953a.8e45e0a1  Sun, Mar 16 2014 14:25:14.555, peer=0, tc=6,
mintc=3, offset=0.000, frequency=-782.492, sys_jitter=0.000,
clk_jitter=0.000, clk_wander=0.000

A bit later, but still unsuitable:

associd=0 status=c618 leap_alarm, sync_ntp, 1 event, no_sys_peer,
version="ntpd 4.2.6p2@1.2194-o Sun Oct 17 13:45:13 UTC 2010 (1)",
processor="i686", system="Linux/2.6.32-5-686", leap=11, stratum=3,
precision=-21, rootdelay=83.471, rootdisp=1073.343, refid=24.215.0.24,
reftime=d6d09578.04dff32b  Sun, Mar 16 2014 14:26:16.019,
clock=d6d0959e.438fe792  Sun, Mar 16 2014 14:26:54.263, peer=55573, tc=6,
mintc=3, offset=0.000, frequency=-782.492, sys_jitter=51.278,
clk_jitter=24.776, clk_wander=0.000

Here is a suitable one (same server, quite a while later):

associd=0 status=0618 leap_none, sync_ntp, 1 event, no_sys_peer,
version="ntpd 4.2.6p2@1.2194-o Sun Oct 17 13:45:13 UTC 2010 (1)",
processor="i686", system="Linux/2.6.32-5-686", leap=00, stratum=4,
precision=-21, rootdelay=112.853, rootdisp=1078.759, refid=72.51.27.50,
reftime=d6d09918.b1e4c910  Sun, Mar 16 2014 14:41:44.694,
clock=d6d09939.2e0fe48f  Sun, Mar 16 2014 14:42:17.179, peer=55572, tc=6,
mintc=3, offset=-35.018, frequency=-500.000, sys_jitter=26.038,
clk_jitter=12.381, clk_wander=101.024

Note that in order for the server to become suitable, all of the following had to happen:
- Stratum had to become lower than 16
- leap_alarm / leap=11 had to be cleared (this seems to be a hack, setting the
  leap second alarm as a way to indicate 'server not ready yet'. I don't
  understand why they can't just have a "server_ready" flag or
  something...)
- need nonzero values for:
	clk_jitter
	clk_wander
	offset
	frequency
	sys_jitter
	...basically everything. If your stratum looks low enough but things still aren't synching,
	just assume you need to wait for ntpd to measure all these other things?