4 ms·

This is exactly why I wrote the "clockperf" tool during the time I was working at AWS: https://github.com/tycho/clockperf https://github.com/tycho/clockperf At

This is exactly why I wrote the "clockperf" tool during the time I was working at AWS: https://github.com/tycho/clockperf https://github.com/tycho/clockperf At the time, we were trying to benchmark disk I/O for new platforms, but we found that things were underperforming compared to the specifications for the hardware. We figured out that fio was reading the clock before/after each I/O (which isn't really necessary unless you really care about latency measurement) and just by reading the clock we were rate limiting our I/O throughput. By switching to "clocksource=tsc" in our fio config, we managed to get the performance behavior we expected.

logicallee 8y ago
>we managed to get the performance behavior we expected. can you put this into roughly quantitative terms? How much of a performance hit did you remove this way?
- AbacusAvenger 8y ago
  I don't remember the exact numbers (this was 2011), but the overhead of using e.g. CLOCK_MONOTONIC were substantial. Under Xen, the cost of reading CLOCK_MONOTONIC was a few orders of magnitude higher than reading the TSC. I think on Xen PV it was like 500ns per read, while on HVM it was at about 2000ns-3000ns or something like that. I remember with 8 disks that should have been able to do 60K 4K IOPS each (early SSD models), we were capping out at 90K IOPS with all disks in parallel at a queue depth of 32 while reading from CLOCK_MONOTONIC. When we switched to TSC I think we ended up getting around 320K IOPS. Still not perfect, but we were also capped by the particular HBA we chose (which didn't have multiqueue support).