I’m interested in your rather dismissive assertion about timekeeping in Windows. Your experience seems to differ considerably from mine.
So was I, once I actually measured what was going on when I observed timestamps and saw odd shifts in system time and looked at the NTP logs and then did my own polling.
(I'm running windows 7)
Windows calculates its time by counting clock pulses. As crystals vary from MB to MB, this varies from UTC, some are fast, some lag. Unfortunately, counting the clock pulses is a lazy process, and if the cpu is too busy, it doesn't get around to counting all of them, so some get missed/skipped. So how much the system time varies from UTC varies depending on load. With a nice steady load, with a long run of time for sampling, and a reasonably clean internet connection for quality poll times, NTP can compensate for this very very well, making slight adjustments over time to bring things into alignment.
With the processing time for trading strategies being a surprisingly light CPU load, many high-speed multi-core CPUs end up using power savings and cut CPU speed and shut down cores. But I wanted the processing results ASAP, so I set my bios to not shut down cores or dial back speed. Eight times a second, my code does different tasks. And it can receive incoming data from IB at anytime. So eight times a second I get a burst of heavy load, and each time the load can be different, and each second can be very different. This results in widely varying missed clock counts for system time. NTP does not adjust time frequently enough to track, let along adjust for this. It's a longer time frame aligner.
So by polling NTP sites I can maintain an offset of system time from UTC that is used to create a timestamp that is reasonably close to UTC.
Unfortunately, the rate that windows system clock lag increases, and variably, with varying loads, means that the offset quickly becomes surprisingly large. So I captured and graphed it. This required polling NPT sites, and quality sites close to me, very frequently. Which means short test runs, as polling every second is not a nice thing to do to a NTP site. The results showed that my widely varying heavy loads meant that I needed a very frequent update of the UTC offset, which meant I needed my own local time server that I could poll every second. The results also showed that my cable internet's inconsistent times resulted in lower quality NTP results, so this would required a GPS disciplined time server.
I'll attempt to attach the charts that demonstrate the issue of windows system time missed clock count when there are heavy loads. I don't know how this will work, so I'll do one graph per post. When an 18 hour run at idle with 10 minute polls is graphed, the result is very smooth straight line. Easily adjusted for. It's when you look at system time at the second level that it gets ugly, and a problem if you want to timestamp something to know when inside of a second that it arrived (i.e., at 228 ms from TOS).
First, is tracking six NPT sites offset against the increasing system time lag. The left axis is ms. The bottom axis is seconds. Outliers are not removed; this is the raw poll results.
