> JACK needs to know the CPU speed in order to be able to use RDTSC for
> timing. Yes that might be "broken" but gettimeofday() is simply not
It is broken then. Was always broken, will be broken etc.
> fast enough for our use, we can't afford the overhead of thousands of
> system calls per second. And until recently 99.999% of desktop machines
> had a monotonic TSC so this worked very well.
You're wrong. First if you say "monotonic" you don't understand the problem.
Monotonicity is only a small part of it. The bigger one is just
getting the current frequency and figuring out of if the information
is safe to use.
Chips where it doesn't work:
- Intel Prescott and derivatives (newer Pentium 4, newer Xeon, on
Celeron you are still lucky because they normally don't have speedstep):
TSC runs at a different frequency than the current P state and P state often
varies with speedstep [These are the most common desktop chips in the world,
although not all have speedstep enabled. Many newer ones have though.]
- Intel P-M and earlier P4,P3 mobile chips, Athlon 64, Athlon XP-M,
Opteron etc:
TSC varies with P state and user space has no way to get timely
updates on P-state changes.
- VIA C3: I believe TSC stops in idle (at least it used to on
older versions, don't know if they fixed it)
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
