Cdock source code#
Offset later by code that derives wall-clock time from the combination of boot Time retrieved from the RTC is stored in memory in the kernel, and is used as an Particularly accurate, since it is driven from a cheap crystal oscillator whoseįrequency can vary depending on temperature and other factors. This is a hardware clock that is powered by a battery so itĬontinues to run even when the machine is powered off. When the system boots up, when Linux gets the current time from the RTC (Real With that out of the way, let’s take a look at how Linux keeps time. We’re not going to talk much more about inter-machine timing in this article,īut may get into it another time. Lucky to get accuracy better than some small number of microseconds. The clock synchronization works, and in all but the best cases you’ll be In thisĬase, the accuracy of your timing measurements will obviously depend on how well That is synchronized across the two (or more) machines you are testing. Segal’s Lawįor inter-machine timings, you’re pretty much stuck with the CLOCK_REALTIMEĬlock source (the source for gettimeofday), since you presumably need a clock Having two clock sources is described somewhat amusingly by this old chestnut: A man with a watch knows what time it is. Round-trip intervals – if that’s the case, you’re lucky). With (at least) two different clock sources. The problem with inter-machine timing is that, by definition, you’re dealing Generally pretty easy to ensure that you use the same clock source for all your Intra-machine timing is the simplest scenario, since it is Talk a little about the different problems in intra-machine vs. However, before jumping into the details of the above recommendations, I want to
Cdock source how to#
The various clocks from software, and how to measure the overhead of accessing The following sections will talk about how clocks work on Linux, how to access The RDTSCP instruction (a recent MacBook Air), overhead is down around 14ns. To issue a CPUID instruction prior to RDTSC to serialize its execution.
Note that the 100ns mentioned above is largely due to the fact that my Linux boxĭoesn’t support the RDTSCP instruction, so to get reasonably accurate timings it’s also necessary.YMMV, of course, which is why I’ve included source code that you can use to do your own measurements. To read the TSC from software, so that is the limit of this method’s accuracy. You should be measuring the interval between two events that happen on theįor intra-machine timing, your best bet is generally going to be to read the The TSC should be configured as the clock source for the Linux kernel at Supports the RDTSCP instruction, so much the better. The TSC runs at a constant rate across all sockets/cores, regardless ofįrequency changes made to the CPU by power management code. Support for most of the different clock sources.Ī CPU with a constant, invariant TSC (time-stamp counter). Even better is 2.6.32 or above, since this includes Linux kernel 2.6.18 or above – this is the first version that includes the The short version is that for best results you should be using: The different edge cases might be to ensure that your results are accurate. Is that with relatively modern hardware and software, it is possible toĪccurately measure time intervals as small as (some smallish number of)īut, it’s important to understand what you’re measuring and what In microseconds at least, and preferably in nanoseconds or better. For measuring latency in modern systems, we need to be able to measure intervals
0 kommentar(er)
