NTPQ(1)

๐ŸŽ€ NAME ๐ŸŽ€

ntpq โ€” the standard NTP query program. Yep bestie, you found the NTPsec ntpq(1) page, and we're doing this together ๐Ÿซถ

โœจ SYNOPSIS โœจ

ntpq [-46adhinpkwWu] [-c command] [host] [...]

๐Ÿฆ‹ DESCRIPTION ๐Ÿฆ‹

Okay so picture this: ntpq is the utility program you use to monitor what the NTP daemon ntpd is doing and figure out its performance. It talks in the standard NTP mode 6 control message formats, which are defined in Appendix B of the NTPv3 specification RFC 1305. NTPv4 uses those exact same formats โ€” some variable names just changed and new ones got added. Heads up tho: everything described on this page is for the NTPv4 variables ๐Ÿ’…

You can run the program either in interactive mode or drive it entirely from command line arguments. Requests to read and write arbitrary variables can be assembled, and you get both raw and pretty-printed output options. It can also grab and print a list of peers in a common format by sending multiple queries to the server โ€” very main character of it โœจ

If one or more request options are included on the command line when ntpq is executed, each of the requests gets sent to the NTP servers running on each of the hosts you gave as command line arguments โ€” or on localhost by default. If no request options are given, ntpq will try to read commands from standard input and execute them on the NTP server running on the first host given on the command line, again defaulting to localhost when no other host is specified. And ntpq will prompt you for commands if standard input is a terminal device ๐ŸŽ€

ntpq uses NTP mode 6 packets to talk to the NTP server, which means it can query any compatible server on the network that permits it. Big note tho: since NTP is a UDP protocol, this communication will be somewhat unreliable ๐Ÿ˜ญ โ€” especially over large distances in terms of network topology. ntpq makes one attempt to retransmit requests, and will time requests out if the remote host isn't heard from within a suitable timeout time.

Also, in contexts where a host name is expected: a -4 qualifier preceding the host name forces DNS resolution to the IPv4 namespace, while a -6 qualifier forces DNS resolution to the IPv6 namespace. Periodt.

For examples and usage, see the NTP Debugging Techniques page (debug.html).

For a simpler near-real-time monitor, see ntpmon(1) โ€” she's chill like that ๐ŸŒธ


๐Ÿ’– OPTIONS ๐Ÿ’–

Command line options are described following, bestie. Specifying the command line options -c or -p will cause the specified query (queries) to be sent to the indicated host(s) immediately ๐Ÿ”ฅ Otherwise, ntpq will attempt to read interactive format commands from standard input.

  • -4, --ipv4 โ€” Force DNS resolution of following host names on the command line to the IPv4 namespace.
  • -6, --ipv6 โ€” Force DNS resolution of following host names on the command line to the IPv6 namespace.
  • -a num, --authentication=num โ€” Enable authentication with the numbered key ๐Ÿ”‘
  • -c cmd, --command=cmd โ€” The following argument is interpreted as an interactive format command and gets added to the list of commands to be executed on the specified host(s). You can give multiple -c options, no cap.
  • -d, --debug โ€” Increase debugging level by 1.
  • -D num, --set-debug-level=num โ€” The debug level is set to the following integer argument.
  • -l filename, --logfile=filename โ€” Log debugging output to the specified file.
  • -h, --help โ€” Print a usage message summarizing options and exit.
  • -n, --numeric โ€” Output all host addresses in numeric format rather than converting to the canonical host names. Tiny caveat: you may get hostnames anyway for peers in the initialization phase before DNS has resolved the peer name ๐Ÿ™ˆ
  • -p, --peers โ€” Print a list of the peers known to the server as well as a summary of their state; this is equivalent to the peers interactive command. The refid field is as described under "Event Messages and Status Words" in the NTP documentation on the Web.
  • -k filename, --keyfile=filename โ€” Specify a keyfile. ntpq will look in this file for the key specified with -a.
  • -V, --version โ€” Print the version string and exit.
  • -w, --wide โ€” Wide mode: if the host name or IP Address doesn't fit, write the full name/address and indent the next line, so columns line up. The default truncates the name or address (kinda rude of it ngl).
  • -W num, --width=num โ€” Force the terminal width. Only relevant for composition of the peers display.
  • -u, --units โ€” Display timing information with units.

๐Ÿงš INTERNAL COMMANDS ๐Ÿงš

Interactive format commands consist of a keyword followed by zero to four arguments. You only need to type enough characters of the full keyword to uniquely identify the command โ€” she's not gonna make you spell the whole thing out ๐Ÿ’… The output of a command is normally sent to standard output, but optionally the output of individual commands may be sent to a file by appending a >, followed by a file name, to the command line. Some interactive format commands are executed entirely within the ntpq program itself and don't result in NTP mode 6 requests being sent to a server. Those are described following:

  • ? [command_keyword], help [command_keyword] โ€” A ? by itself prints a list of all the command keywords known to ntpq. A ? followed by a command keyword prints function and usage information about that command.
  • addvars name [ = value] [...]; rmvars name [...]; clearvars โ€” The arguments to this command consist of a list of items of the form name = value, where the = value is ignored and can be omitted in read requests. ntpq maintains an internal list in which data to be included in control messages can be assembled and sent using the readlist and writelist commands described below. The addvars command allows variables and optional values to be added to the list. If more than one variable is to be added, the list should be comma-separated and not contain white space. The rmvars command can be used to remove individual variables from the list, while the clearlist command removes all variables from the list.
  • authenticate [yes | no] โ€” Normally ntpq doesn't authenticate requests unless they're write requests. The command authenticate yes causes ntpq to send authentication with all requests it makes. Authenticated requests causes some servers to handle requests slightly differently ๐Ÿ‘€ The command authenticate without arguments causes ntpq to display whether or not ntpq is currently authenticating requests.
  • cooked โ€” Display server messages in prettyprint format โœจ
  • debug more | less | off โ€” Turns internal query program debugging on and off.
  • noflake, +doflake probability โ€” Disables or enables the dropping of control packets by ntpq for testing. Probabilities 0 and 1 should be certainly accepted and discarded respectively. No default, but 0.1 should be a one in ten loss rate ๐Ÿ˜ฌ
  • logfile <stderr> | filename โ€” Displays or sets the file for debug logging. <stderr> will send logs to standard error.
  • delay milliseconds โ€” Specify a time interval to be added to timestamps included in requests which require authentication; this is used to enable (unreliable) server reconfiguration over long delay network paths or between machines whose clocks are unsynchronized. The server does not now require timestamps in authenticated requests, so this command may be obsolete ๐Ÿซ 
  • exit โ€” Exit ntpq.
  • host name โ€” Set the host to which future queries will be sent. The name may be either a DNS name or a numeric address.
  • hostnames [yes | no] โ€” If yes is specified, host names are printed in information displays. If no is specified, numeric addresses are printed instead. The default is yes unless modified using the command line -n switch.
  • keyid keyid โ€” This command specifies the key number to be used to authenticate configuration requests; this must correspond to a key ID configured with the controlkey command in the server's ntp.conf.
  • keytype โ€” Specify the digest algorithm to use for authenticated requests, with default MD5. The keytype must match what the server is expecting for the specified key ID.
  • ntpversion 1 | 2 | 3 | 4 โ€” Sets the NTP version number which ntpq claims in packets. Defaults to 2. Note that mode 6 control messages (and modes, for that matter) didn't exist in NTP version 1 ๐Ÿ’€
  • passwd โ€” This command prompts for a password to authenticate requests. The password must match what the server is expecting. Passwords longer than 20 bytes are assumed to be hex encoding.
  • quit โ€” Exit ntpq.
  • raw โ€” Display server messages as received and without reformatting. The only formatting/interpretation done on the data is to transform non-ASCII data into a printable (but barely understandable) form ๐Ÿ™ˆ
  • timeout milliseconds โ€” Specify a timeout period for responses to server queries. The default is about 5000 milliseconds. Note that since ntpq retries each query once after a timeout, the total waiting time for a timeout will be twice the timeout value set โฐ
  • units โ€” Toggle whether times in the peers display are shown with units.
  • version โ€” Print the version of the ntpq program.

๐Ÿ‘‘ CONTROL MESSAGE COMMANDS ๐Ÿ‘‘

Association IDs are used to identify system, peer and clock variables. System variables are assigned an association ID of zero and system name space, while each association is assigned a nonzero association ID and peer namespace. Most control commands send a single mode 6 message to the server and expect a single response message. The exceptions are the peers command, which sends a series of messages, and the mreadlist and mreadvar commands, which iterate over a range of associations.

  • associations โ€” Display a list of mobilized associations in the form
ind assid status conf reach auth condition last_event cnt

okay so that's the header line of the spreadsheet you're staring at whenever peers or associations spits out a table ๐Ÿ’… here's what each column is actually saying:

  • ind โ€” the index on this list. just the row number bestie, it's giving "seat number" ๐ŸŽŸ๏ธ
  • assid โ€” the association ID. this is the one you'll actually type into other commands, so likeโ€ฆ remember it ๐Ÿ‘‘
  • status โ€” the peer status word (decode.html#peer). the whole vibe of the peer in one word โœจ
  • conf โ€” yes means persistent, no means ephemeral. like a situationship vs. a real one ๐Ÿ™ˆ
  • reach โ€” yes means reachable, no means unreachable. can you text them back or not ๐Ÿ’€
  • auth โ€” one of ok, yes, bad and none. genuinely four separate moods ๐ŸŽ€
  • condition โ€” the selection status (peek at the select field of the peer status word, decode.html#peer). this is the "are we actually choosing them" field ๐Ÿ‘€
  • last_event โ€” the event report (see the event field of the peer status word, decode.html#peer). literally the receipts of what last happened ๐Ÿ“œ
  • cnt โ€” the event count (see the count field of the peer status word, decode.html#peer). how many times it's happened, no cap ๐Ÿ”ข

authinfo โ€” displays the authentication statistics. auth stats, served fresh ๐Ÿ“

clockvar assocID [name [ = value [...] ][...], cv assocID [name [ = value [...] ][...] โ€” displays a list of clock variables for those associations that support a reference clock. it's giving "clock lore" ๐Ÿ•ฐ๏ธ note that cv is just the short cute name for the same thing.

:config [...] โ€” sends the remainder of the command line, including whitespace, to the server as a run-time configuration command, in the same format as the configuration file. the leading colon? yeah that's the whole point, it's the "this is a config command" flag ๐Ÿ’…

โš ๏ธ heads up bestie: this command is experimental until further notice and clarification. and authentication is, of course, required ๐Ÿ”

config-from-file filename โ€” sends each line of filename to the server as run-time configuration commands, in the same format as the configuration file.

โš ๏ธ same energy: this one is also experimental until further notice and clarification, and authentication is required. don't say i didn't warn you ๐Ÿซถ

ifstats โ€” displays statistics for each local network address. authentication is required for this one ๐Ÿ”‘

iostats โ€” displays network and reference clock I/O statistics. both flavours, all the numbers ๐Ÿ“Š

kerninfo โ€” displays kernel loop and PPS statistics. as with all other ntpq output, the times are in milliseconds. and the precision value displayed is in milliseconds as well โ€” which, lowkey important, is unlike the precision system variable ๐Ÿ˜ญ don't mix them up.

lassociations โ€” does the exact same thing as the associations command, except it displays mobilized and unmobilized associations. the deluxe version, both bins, no gatekeeping ๐Ÿฆ‹

lpeers [-4 | -6] โ€” prints a peer spreadsheet for the appropriate IP version(s). dstadr (associated with any given IP version). pick your fighter: -4 or -6 ๐ŸŒˆ

monstats โ€” displays monitor facility statistics. the monitor's whole personality, quantified ๐Ÿ“ˆ

direct โ€” okay so normally, the mrulist command retrieves an entire MRU report (which might be more than one MRU span), sorts it, and then presents the result. but ๐Ÿ˜ฌ attempting to fetch that entire report can genuinely fail on a server so loaded that none of its MRU entries age out before they're shipped. with this option? each segment gets reported as it arrives. streaming era, we love to see it โœจ

mrulist [limited | kod | mincount=count | mindrop=drop | minscore=score | maxlstint=seconds | minlstint=seconds | laddr=localaddr | sort=sortorder | resany=hexmask | resall=hexmask | limit=limit | addr.num=address] โ€” obtains and prints traffic counts collected and maintained by the monitor facility. this is your "who is using or abusing my server" detective arc ๐Ÿ” iconic for tracking that.

so, except for sort=sortorder, all these options are filters on the list ntpd hands back. let's go through them:

  • limited and kod โ€” return only entries representing client addresses from which the last packet received triggered either discarding or a KoD response. messy behaviour, flagged ๐Ÿšฉ
  • addr.num= โ€” adds specific addresses to retrieve when limit=1. values of 0 to 15 are supported for num. it's also used internally with last.num=hextime to select the starting point for retrieving a continued response ๐Ÿ‘€
  • frags=frags โ€” limits the number of datagrams (fragments) in the response. newer ntpq versions use this instead of limit= when retrieving multiple entries ๐Ÿงฉ
  • limit= โ€” limits the MRU entries returned per response.
  • mincount=count โ€” filters out entries that have received fewer than count packets ๐Ÿ“ฆ
  • mindrop=drop โ€” filters out entries that have dropped fewer than drop packets due to rate limiting ๐Ÿšซ
  • minscore=score โ€” filters out entries with a score less than score ๐Ÿ’ฏ
  • maxlstint=seconds โ€” filters out entries where no packets have arrived within seconds โณ
  • minlstint=seconds โ€” filters out entries with a packet has arrived within seconds ๐Ÿ•
  • laddr=localaddr โ€” filters out entries for packets received on any local address other than localaddr ๐Ÿ 
  • resany=hexmask and resall=hexmask โ€” filter entries containing none or fewer than all, respectively, of the bits in hexmask, which must begin with 0x โš ๏ธ like, actually must. don't skip the 0x.

and now the limit= special case because it's genuinely a whole thing:

๐ŸŒ€ limit=1 is special. instead of fetching beginning with the supplied starting points (provided by a last.x and addr.x where 0 โ‡ x โ‡ 15, default the beginning of time) newer neighbor, it fetches the supplied entries. this enables fetching multiple entries from given IP addresses (provided by addr.x= entries where 0 โ‡ x โ‡ 15).

when limit is not one and frags= is provided, the fragment limit controls ๐ŸŽ›๏ธ

๐ŸŒธ NOTE: a single mrulist command may cause many query/response rounds, allowing limits as low as 3 to potentially retrieve thousands of entries in responses. tiny limit, massive haul. it's giving "small bag, infinite pockets" ๐Ÿ˜ญโœจ

Okay so the sortorder defaults to lstint, and it can be any of addr, count, avgint, lstint, score, drop โ€” or any of those with a minus sign (hyphen) in front to reverse the sort order. ๐Ÿ’… The output columns are:

  • lstint โ€” interval in s between the receipt of the most recent packet from this address and the completion of the retrieval of the MRU list by ntpq. โฑ๏ธ
  • avgint โ€” average interval in s between packets from this address. ๐Ÿ“ˆ
  • rstr โ€” restriction flags associated with this address. Most are copied unchanged from the matching restrict command, however 0x400 (kod) and 0x20 (limited) flags are cleared unless the last packet from this address triggered a rate control response. ๐Ÿšฆ
  • r โ€” rate control indicator, either a period, L or K for no rate control response, rate limiting by discarding, or rate limiting with a KoD response, respectively. ๐Ÿ‘€
  • m โ€” packet mode. ๐Ÿ“ฆ
  • v โ€” packet version number. ๐Ÿ”ข
  • count โ€” packets received from this address. ๐Ÿงฎ
  • score โ€” packets per second (averaged with exponential decay). โœจ
  • drop โ€” packets dropped (or KoDed) from this address. Always 0 unless a restrict ... limited line applies to the address. ๐Ÿ’€
  • rport โ€” source port of last packet from this address. ๐Ÿ”Œ
  • remote address โ€” DNS name, numeric address, or address followed by claimed DNS name which could not be verified in parentheses. ๐ŸŒ
mreadvar assocID assocID [ variable_name [ = value[ ... ], mrv assocID
assocID [ variable_name [ = value[ ... ]

Perform the same function as the readvar command, except for a range of association IDs. This range is determined from the association list cached by the most recent associations command. ๐Ÿซถ

  • opeers โ€” obtain and print the old-style list of all peers and clients showing dstadr (associated with any given IP version), rather than the refid. ๐Ÿ‘‘
  • passociations โ€” perform the same function as the associations command, except that it uses previously stored data rather than making a new query. ๐ŸŽ€
  • peers โ€” display a list of peers in the form
tally remote refid st t when pool reach delay offset jitter

The variables are giving:

  • tally โ€” single-character code indicating current value of the select field of the peer status word (decode.html#peer). โญ
  • remote โ€” host name (or IP address) of server. ๐ŸŒธ
  • refid โ€” association ID or kiss code (decode.html#kiss). ๐Ÿ’‹
  • st โ€” stratum. ๐Ÿชœ
  • t โ€” u: server (u for unicast), l: local (reference clock), p: Pool name, 1-8 NTS server with this number of cookies stored. ๐Ÿช
  • when โ€” sec/min/hr since last received packet. โณ
  • poll โ€” poll interval (log2 s). ๐Ÿ”
  • reach โ€” reach shift register (octal). ๐Ÿง 
  • delay โ€” roundtrip delay. ๐Ÿ›ฐ๏ธ
  • offset โ€” offset of server relative to this host. ๐Ÿ“
  • jitter โ€” jitter. ๐Ÿฆ‹

The t column has strange encodings due to historical use by old code. If you are looking at an old server, you might also see: s: symmetric (peer), server, B: broadcast server,

okay so the tally code โ€” that one little character hanging out in the front of every peer line โ€” is literally the peer's whole vibe check ๐Ÿ’… here's the decoder ring, no cap:

  • (blank) โ€” discarded as not valid ๐Ÿ™ˆ
  • x โ€” discarded by intersection algorithm
  • . โ€” discarded by table overflow (not used โ€” yeah it's just sitting there, historical icon behavior ๐Ÿ’€)
  • - โ€” discarded by the cluster algorithm
  • + โ€” included by the combine algorithm โœจ
  • # โ€” backup (more than tos maxclock sources)
  • * โ€” system peer ๐Ÿ‘‘ main character energy
  • o โ€” PPS peer (when the prefer peer is valid)

  • apeers โ€” shows ur peers like:
[tally]remote refid assid st t when pool reach delay offset jitter

and this is exactly like peers, except the refid gets shown in hex format and the association number (assid) also shows up. extra data, same slay ๐ŸŽ€

  • rpeers โ€” shows the peer list but with the columns flipped around, like:
st t when pool reach delay offset jitter refid tally remote
  • pstats assocID โ€” stats for the peer with that assocID. per-peer receipts fr fr ๐Ÿ“Š
  • readvar assocID [ name ] [,...] / rv assocID [ name ] [,...] โ€” shows the variables you asked for. if assocID is zero you're reading from the system variables <#system> name space; otherwise you're in the peer variables <#peer> name space. the assocID is required because the same name can legitimately live in both spaces, bestie, they're different rooms in the same house ๐Ÿ  if you don't include a name, it dumps all the operative variables in that name space โ€” and in that one specific case, if you leave off the assocID, it just assumes zero. multiple names get comma separators with no whitespace, ty. also heads up: time values come out in milliseconds and frequency values in parts-per-million (PPM). some NTP timestamps show up as YYYYMMDDTTTT where YYYY is the year, MM the month of the year, DD the day of the month, and TTTT the time of day ๐Ÿ•
  • reslist โ€” shows the access control (restrict) list for ntpq. ๐Ÿ”
  • timerstats โ€” displays interval timer counters. tick tick tick โฑ๏ธ
  • writelist assocID โ€” writes the system or peer variables that are in the variable list.
  • writevar assocID name = value [,...] โ€” writes the variables you specify. if assocID is zero it's the system variables <#system> name space, otherwise peer variables <#peer> name space. again, assocID is required since the same name can occur in both spaces. don't @ me, that's just how it is ๐Ÿซถ
  • sysinfo โ€” operational summary. the tl;dr of ur whole setup โœจ
  • sysstats โ€” prints the statistics counters that live in the protocol module. quick note tho: the relationships among these counters can look unlikely, and that's not a bug โ€” a packet can get flagged for inclusion in exception statistics in more than one way, like by having both a bad length and an old version at the same time. so yeah, numbers can double-dip ๐Ÿ“
  • mssntpinfo โ€” summary of the MS-SNTP traffic to a Samba server. this literally will not work unless the server you're looking at was built with the --enable-mssntp option, so check before u spiral ๐Ÿ˜ญ
  • ntsinfo โ€” summary of the NTS state, covering both the NTS client and the NTS server components (yes, the original says "the the", we love a typo icon ๐Ÿ’€). heads up: the format of the output text may change as this feature gets developed. this command is experimental until further notice and clarification. consider urself warned ๐Ÿงš

๐Ÿ” AUTHENTICATION ๐Ÿ”

four commands need you to authenticate to the server: config-from-file, config, ifstats, and reslist. an authkey file has to be in place and a control key declared in ntp.conf for any of these to work. no credentials, no entry, sorry bestie ๐Ÿšช

if you're running as root โ€” or you otherwise have read access to the authkey and ntp.conf file โ€” ntpq will mine the required credentials for you, like it's doing the homework so you don't have to ๐Ÿ’… otherwise you'll get prompted to enter a key ID and password.

credentials, once entered, are retained and used for the whole duration of your ntpq session. no re-typing, we love efficiency ๐ŸŒธ


๐Ÿฉบ STATUS WORDS AND KISS CODES ๐Ÿฉบ

the current state of the operating program is shown in a set of status words maintained by the system โ€” and by each association, separately. these words get displayed in the rv and as commands, both in hexadecimal and decoded into short tip strings โœจ the codes, tips, and short explanations live on the Event Messages and Status Words page (decode.html). that page also has a list of system and peer messages, and the code for the most recent of those is included in the status word.

info that comes out of protocol machine state transitions gets displayed using an informal set of ASCII strings called kiss codes (decode.html#kiss). the original purpose was for kiss-o'-death (KoD) packets that a server sends to tell the client about some unusual condition ๐Ÿ’€ they're now displayed, when appropriate, in the reference identifier field in various billboards. iconic behavior honestly ๐Ÿ‘‘

โœจ SYSTEM VARIABLES โœจ

Okay bestie, so these are the system variables that can show up in the rv billboard ๐Ÿ‘€ โ€” and yeah, not every single one is displayed in every configuration, because of course it isn't ๐Ÿ’….

  • status โ€” system status word <decode.html#sys>
  • version โ€” NTP software version and build time
  • processor โ€” hardware platform and version
  • system โ€” operating system and version
  • leap โ€” leap warning indicator (0-3)
  • stratum โ€” stratum (1-15)
  • precision โ€” precision (log2 s)
  • rootdelay โ€” total roundtrip delay to the primary reference clock
  • rootdisp โ€” total dispersion to the primary reference clock
  • peer โ€” system peer association ID
  • tc โ€” time constant and poll exponent (log2 s) (3-17)
  • mintc โ€” minimum time constant (log2 s) (3-10)
  • clock โ€” date and time of day
  • refid โ€” reference ID or kiss code <decode.html#kiss>
  • reftime โ€” reference time
  • offset โ€” combined offset of server relative to this host
  • sys_jitter โ€” combined system jitter
  • frequency โ€” frequency offset (PPM) relative to hardware clock
  • clk_wander โ€” clock frequency wander (PPM)
  • clk_jitter โ€” clock jitter
  • tai โ€” TAI-UTC offset (s)
  • leapsec โ€” NTP seconds when the next leap second is/was inserted
  • expire โ€” NTP seconds when the NIST leapseconds file expires
Heads up, bestie: not all variables are displayed in some configurations ๐Ÿ™ˆ.

And the jitter/wander tea โ˜•: the jitter and wander statistics are exponentially-weighted RMS averages. The system jitter is defined in the NTPv4 specification; the clock jitter statistic is computed by the clock discipline module. No cap, that's literally the whole breakdown ๐Ÿ’–.

โœจ PEER VARIABLES โœจ

Okay so this next bit is the receipts ๐Ÿ’… โ€” every variable that shows up in the rv billboard for each association. Heads up bestie: not all of these get displayed in some configurations. That's just how it is, no cap.

  • associd โ€” the association ID ๐ŸŽ€
  • status โ€” the peer status word, and yes there's more tea at decode.html#peer
  • srcadr srcport โ€” source (remote) IP address and port ๐ŸŒธ
  • dstadr dstport โ€” destination (local) IP address and port ๐Ÿฆ‹
  • leap โ€” leap indicator, ranging 0-3
  • stratum โ€” stratum, ranging 0-15
  • precision โ€” precision, in log2 s
  • rootdelay โ€” total roundtrip delay to the primary reference clock โฑ๏ธ
  • rootdisp โ€” total root dispersion to the primary reference clock
  • refid โ€” reference ID or kiss code, more at decode.html#kiss ๐Ÿ’‹
  • reftime โ€” reference time
  • reach โ€” reach register, in octal
  • unreach โ€” unreach counter
  • hmode โ€” host mode, ranging 1-6
  • pmode โ€” peer mode, ranging 1-5
  • hpoll โ€” host poll exponent, in log2 s, ranging 3-17
  • ppoll โ€” peer poll exponent, in log2 s, ranging 3-17
  • headway โ€” headway (see Rate Management and rate.html the Kiss-o'-Death Packet)"
  • flash โ€” flash status word, details at decode.html#flash โšก
  • offset โ€” filter offset
  • delay โ€” filter delay
  • dispersion โ€” filter dispersion
  • jitter โ€” filter jitter
  • bias โ€” fudge for asymmetric links/paths

๐ŸŽ€ CLOCK VARIABLES ๐ŸŽ€

And these are the clock variables, living their best life in the cv billboard for each association that has a reference clock ๐Ÿ•ฐ๏ธ. Same disclaimer fr fr: not every variable makes an appearance in some configurations.

  • associd โ€” the association ID
  • status โ€” the clock status word, extra lore at decode.html#clock
  • device โ€” device description
  • timecode โ€” ASCII time code string (specific to device) ๐Ÿ”ค
  • poll โ€” poll messages sent
  • noreply โ€” no reply ๐Ÿ™ˆ
  • badformat โ€” bad format
  • baddata โ€” bad date or time ๐Ÿ’€
  • fudgetime1 โ€” fudge time 1
  • fudgetime2 โ€” fudge time 2
  • stratum โ€” driver stratum
  • refid โ€” driver reference ID
  • flags โ€” driver flags ๐Ÿšฉ

๐Ÿฆ‹ COMPATIBILITY ๐Ÿฆ‹

okay bestie, here's the tea on how this version behaves differently from the old-school ntpq you might know ๐Ÿ‘€

  • when listing refids, addresses of the form 127.127.x.x are no longer automatically interpreted as local refclocks like they were in older versions of ntpq. instead, a clock-format display is requested by the NTPsec daemon when appropriate (by setting the srcaddr peer variable). this means that when you use it to query legacy versions of ntpd, which don't know how to request this, this program will do a slightly wrong thing ๐Ÿ˜ญ
  • in older versions, the type variable associated with a reference clock was a numeric driver type index. it's been replaced by name, a shortname for the driver type โœจ
  • in older versions, no count of control packets was listed under sysstats ๐Ÿซถ
  • the -O (--old-rv) option of legacy versions has been retired โ€” it's gone, periodt ๐Ÿ’…

๐Ÿ’€ KNOWN LIMITATIONS ๐Ÿ’€

ngl, there are some quirks you should know about before you @ me ๐Ÿ™ˆ

  • it's possible for a ":config unpeer" command to fail silently, yielding "Config Succeeded", if it's given a peer identifier that looks like a driver type name or a hostname not present in the peer list. the error will, however, be reported in the system log ๐Ÿ‘€
  • the config command cannot be used to change a server's default restrictions ๐Ÿšซ
  • under some circumstances python 2 cannot emit unicode. when true, the display of units is downgraded to non-unicode alternatives. one place you're likely to encounter this is when diverting output through a pipe. attempts have been made to force the use of UTF-8, all of which break the command history feature ๐Ÿ˜ญ
  • when using the -u option, very old xterms may fail to render ยต correctly. if this happens, be sure your xterm is started with the -u8 option, or the utf8 resource', and that your console font contains the UTF-8 ยต character. also confirm your LANG environment variable is set to a UTF-8 language, like this: export LANG=en_US.utf8 ๐Ÿงš
  • timestamp interpretation in this program is likely to fail in flaky ways if the local system clock has not already been approximately synchronized to UTC. querying a server based in a different NTP era than the current one is especially likely to fail โฐ
  • this program will behave in apparently buggy and only semi-predictable ways when fetching MRU lists from any server with sufficiently high traffic ๐Ÿ’€
  • the problem is fundamental. the Mode 6 protocol can't ship (and your client cannot accept) MRU records as fast as the daemon accepts incoming traffic. under these circumstances, the daemon will repeatedly fail to ship an entire report, leading to long hangs as your client repeatedly re-sends the request. eventually the Mode 6 client library will throw an error indicating that a maximum number of restarts has been exceeded ๐Ÿ˜ต
  • to avoid this problem, avoid monitoring over links that don't have enough capacity to handle the monitored server's entire NTP load ๐ŸŒˆ
  • you may be able to retrieve partial data in very high-traffic conditions by using the direct option ๐Ÿ‘‘
lowkey important: if your link is struggling, don't expect MRU lists to behave. the protocol is doing its best, but physics said no ๐Ÿ’…

โœจ EXIT STATUS โœจ

one of the following exit values will be returned, bestie:

  • 0 (EXIT_SUCCESS) โ€” successful program execution ๐ŸŽ‰
  • 1 (EXIT_FAILURE) โ€” the operation failed or the command syntax was not valid ๐Ÿ’”

xoxo, your ntpq bestie ๐Ÿ’… โ€” brought to you by NTPsec, dated 2026-10-21 ๐Ÿซถ

๐Ÿ“ฆ where this page comes from