5 ms·

Wouldn't those operations reduce the accuracy of the time stamp?

datenwolf 3y ago
What is this "accuracy" you're talking about? Between the scheduler hanging over a process's head, ready to yank away its compute time for milliseconds between the syscall to read out the HPTC or the CPU cycle counter, and the process actually writing the timestamp into a variable/in-memory struct, reading the HPTC from the underlying hardware also not being super accurate, and the CPU cycle counter being influence by frequency scaling, on a bog-standard machine the highest precision you can reasonable expect is on the order of 100µs or so.
crote 3y ago
Modern CPUs don't really give you accurate nanosecond-scale time stamps anyways. The CPU will randomly speed up or slow down, execute instructions out of order, and even speculatively execute instructions. Not to mention that it'll have a dozen different clocks - which are not guaranteed to be in sync.
- blibble 3y ago
  > The CPU will randomly speed up or slow down constant_tsc has been a thing for more than a decade > execute instructions out of order, and even speculatively execute rdtscp serialises > Not to mention that it'll have a dozen different clocks - which are not guaranteed to be in sync. synchronised_tsc has been a think for about 6 years now
  - lazide 3y ago
    None of these are performant, no? Generally, you can have consistency, speed, or low cost - but not more than two at the same time.
    - kprotty 3y ago
      Invariant (Constant) TSC is detectable via `cpuid` and applies to `rdtsc/rdtscp` by default. In that aspect, there's no tradeoff being made there (observable to software) AFAICK.
      - lazide 3y ago
        interesting results! i guess it depends in if you consider 35ish cycles expensive or not. [https://community.intel.com/t5/Software-Tuning-Performance/High-impact-of-rdtsc/m-p/1092539#M5675 https://community.intel.com/t5/Software-Tuning-Performance/H...]
        kprotty 3y ago
        Are there cheaper ways of getting elapsed time with sub microsecond precision? Interested as I've only ever heard of rdtsc at the lowest level in userspace for x86.
        lazide 3y ago
        I ran across a random stackoverload thread with benchmarks claiming it was about 2x the cost of doing a naive gettime(). But frankly, hard to figure out when you factor in all the various caches, OO execution pipelines, etc,
- byteknight 3y ago
  This may be coming from a place of ignorance, but if that were the case, then time would drift significantly constantly due to Intel speed step for example. And if that were the source of truth for time, then when your computer is off, it wouldn’t be able to keep. I’m pretty sure they all have real time clock chips in the motherboards.
  - nomel 3y ago
    There's time keeping (which uses the real time clock) and high resolution clocks, which are good for relative timers. They're never the same components.

What is this "accuracy" you're talking about? Between the scheduler hanging over a process's head, ready to yank away its compute time for milliseconds between the syscall to read out the HPTC or the CPU cycle counter, and the process actually writing the timestamp into a variable/in-memory struct, reading the HPTC from the underlying hardware also not being super accurate, and the CPU cycle counter being influence by frequency scaling, on a bog-standard machine the highest precision you can reasonable expect is on the order of 100µs or so.

crote 3y ago

Modern CPUs don't really give you accurate nanosecond-scale time stamps anyways. The CPU will randomly speed up or slow down, execute instructions out of order, and even speculatively execute instructions. Not to mention that it'll have a dozen different clocks - which are not guaranteed to be in sync.

blibble 3y ago
> The CPU will randomly speed up or slow down constant_tsc has been a thing for more than a decade > execute instructions out of order, and even speculatively execute rdtscp serialises > Not to mention that it'll have a dozen different clocks - which are not guaranteed to be in sync. synchronised_tsc has been a think for about 6 years now
- lazide 3y ago
  None of these are performant, no? Generally, you can have consistency, speed, or low cost - but not more than two at the same time.
  - kprotty 3y ago
    Invariant (Constant) TSC is detectable via `cpuid` and applies to `rdtsc/rdtscp` by default. In that aspect, there's no tradeoff being made there (observable to software) AFAICK.
    - lazide 3y ago
      interesting results! i guess it depends in if you consider 35ish cycles expensive or not. [https://community.intel.com/t5/Software-Tuning-Performance/High-impact-of-rdtsc/m-p/1092539#M5675 https://community.intel.com/t5/Software-Tuning-Performance/H...]
      - kprotty 3y ago
        Are there cheaper ways of getting elapsed time with sub microsecond precision? Interested as I've only ever heard of rdtsc at the lowest level in userspace for x86.
        lazide 3y ago
        I ran across a random stackoverload thread with benchmarks claiming it was about 2x the cost of doing a naive gettime(). But frankly, hard to figure out when you factor in all the various caches, OO execution pipelines, etc,
byteknight 3y ago
This may be coming from a place of ignorance, but if that were the case, then time would drift significantly constantly due to Intel speed step for example. And if that were the source of truth for time, then when your computer is off, it wouldn’t be able to keep. I’m pretty sure they all have real time clock chips in the motherboards.
- nomel 3y ago
  There's time keeping (which uses the real time clock) and high resolution clocks, which are good for relative timers. They're never the same components.