How well will ntpd work when the latency is highly variable?

I have an application where we are using some non-standard networking equipment (cannot be changed) that goes into a dormant state between traffic bursts. The network latency is very high for the first packet since it's essentially waking the system, waiting for it to reconnect, and then making the first round-trip. Subsequent messages (provided they are within the next minute or so) are much faster, but still highly-latent. A typical set of pings will look like 2500ms, 900ms, 880ms, 885ms, 900ms, 890ms, etc.

Given that NTP uses several round trips before computing the offset, how well can I expect ntpd to work over this kind of link? Will the initially slow first round trip be ignored based on the much different (and faster) following messages to/from the ntp server?

The short answer is yes, NTP will prefer low round trip timestamps over high round trip timestamps. There used to be a calldelay option to tell NTP about this problem, typically created by networks that used dial-on-demand technologies that impose a call delay. However, now NTP does this automatically.

If you want to speed up initial timesync, you may wish to use the iburst keyword on the server/peer lines. This tells NTP to use 8 spaced out packets instead of 1 to measure the time. It will ignore any packets that have much higher round trip times. If you have the bandwidth, you can use burst to make it use 8 packets every time it measures the time.