> On 5 Oct 2015, at 19:06, Dan Geist <[email protected]> wrote: > > Greetings, all. I've been challenged to show some evidence that ntpd running > on a VM (as a stratum 2 server in a company-internal pool) really does > perform differently than on bare metal. Can anyone point me to any > non-anecdotal scenarios or tests that might help demonstrate the > performance/accuracy differences? One thought I had was to make a small > cluster of several VM servers and several bare metal ones and add all of them > to some clients and simply observe deltas in ntpq stats. Does anyone know of > other good ways to get some "apples-to-apples" comparison data?
I don’t think you'll need much of a cluster. The issues with time in most virtual machine architectures are well understood and well documented. Ask your VM architecture vendor for the documentation. In my (limited) experience the time accuracy of off-the-shelf server hardware running NTP is measured in microseconds, and most VMs have millisecond like accuracy, which gets worse when they are stressed (do stress test the host box (or its other guests) in your testing). Most users of NTP don’t need better than millisecond accuracy, my current employer mostly needs the nearest second on a timestamp to correlate events. In a previous role I ended up running NTPd on Linux VMs with Jiffies as the clock source to avoid the insanity which is clock source under various virtual architectures. This is an inelegant approach, but practical if you just need the nearest second, and fewer headaches. Although if the nearest second will do this may be the wrong mailing list. Fundamentally it is a soluble problem, the host just need to trust the NTP server guest as a time source (in some manner), and the VM needs to know how the architecture will give it resource in a reliable and predictable fashion (be it hardware clock, network bandwidth/latency, or regular CPU). The virtual server architectures may have progressed since our evil jiffie hack days, but the betting man inside me is thinking probably not this fast, because most people don’t care, and there are layers upon layers of clock handling in Linux kernel to get “just right” to cope with the wide variety of hardware over the decades before we can expect it to “just work” for all virtual architectures. _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
