ntp.ttwagner.com
I like to think that this server has an interesting story. Or, at least, about as interesting as a story about a stratum 2 timeserver can get.
Server Configuration
For one, it's based on a Xen host. The NTP server itself runs in Dom0 (the 'host' system space), but this webpage and all the monitoring is done from a virtual machine guest. Virtual machines can't set the hardware clock, and I noticed odd timing issues on top of that. (Such as 30+ ms offsets with an ntpdate -q to the Dom0 host.) As far as I can tell, there are no issues with the configuration we have, as ntpd isn't stuck in the virtual machine, but it's not exactly the most common time-keeping platform.
Pool & Traffic
We participate in the NTP Pool Project, essentially a huge virtual cluster of timeservers, allowing pool.ntp.org to always give you a handful of nearby timeservers. (Participating servers are monitored for accuracy; our stats are here.) What's interesting for this server, though, is that the code mapping our IP to the country labeled our server as being in Brazil. (It's actually in Burst.net's Pennsylvania datacenter.) This had an unforseen impact: South America has 17 NTP servers, whereas the United States has just shy of 500. Thus we're seeing astronomically more clients than is normal. I used to run a server that was correctly placed in the "US" pool, and set its connection speed (used to regulate the percentage of traffic directed to any given host) to 100 Mbps, which resulted in me having about 4,000 "tracked" clients. We're set at 3 Mbps on this machine, and see much more than that, often with more than 4,000 active clients.
Stats & Graphs
This page shows the output of ntp_clients_stats, one of a set of scripts that's often dubbed "Wayne's Scripts." NTP uses UDP (as opposed to TCP), which means that there are no states or connections to track, but with tcpdump, it's able to watch traffic and generate stats. (Part of me wants to do some of my own analysis of some traffic, such as looking at version information that gets passed. In theory, looking at the low-level protocol, it's also possible to determine things like a client's offset, which, while not terribly useful as a statistic, would be interesting.)
The graphs come from the scripts on this page which generate graphs every 5 minutes using RRDTool. They're only slightly adapted, really, from the default script...
I'm still learning the finer points of this process, so I have no example for some things, like why our stability and frequency charts jump around so much. (Some day, maybe, I'll get it...)