TSC is a Go library that provides extremely low-latency, high-precision Unix timestamps using the processor's Time Stamp Counter register. It's 6-10x faster than and can significantly improve performance for time-sensitive applications. time.Now().UnixNano()
- Overview
- Key Features
- Getting Started
- Use Cases
- Performance Comparison
- Clock Drift Analysis
- Best Practices
- Virtual Machine Support
- Limitations
- References
- Related Projects
TSC leverages the processor's Time Stamp Counter (TSC) register to provide extremely fast timestamp generation. With Invariant TSC support, the library offers reliable frequency measurements across multiple cores/CPUs, delivering timestamps with sub-10ns overhead. Unlike the system clock, TSC provides stable invocation costs and higher precision, while still maintaining calibration with the wall clock to minimize drift.
( abs(system_clock - tsc_clock)
for each second min: 0.00us, max: 10.75us, mean: 1.18us within 82,800 seconds)
- Blazing fast: 6-10x faster than standard
time.Now().UnixNano()
- High precision: Better precision than kernel implementations
- Stable overhead: Consistent cost for each invocation (under 10ns)
- Auto-calibration: Periodically aligns with the system clock
- Cross-platform compatibility: Falls back to standard time functions when TSC isn't supported
package main
import (
"fmt"
"github.com/templexxx/tsc"
)
func main() {
ts := tsc.UnixNano() // Getting unix nano timestamp
fmt.Println(ts, tsc.Supported()) // Print result & whether TSC is supported
}
Here is an example of using TSC with calibration
TSC is ideal for applications where timestamp performance matters:
- High-performance logging systems (timestamp field generation)
- Benchmarking and performance measurement
- Low-latency applications with frequent timestamp needs
- Cloud-native applications with performance constraints
OS | CPU | time.Now().UnixNano() ns/op | tsc.UnixNano() ns/op | Improvement |
---|---|---|---|---|
macOS Catalina | Intel Core i7-7700HQ | 72.8 | 7.65 | 89.49% |
Ubuntu 18.04 | Intel Core i5-8250U | 47.7 | 8.41 | 82.36% |
Ubuntu 20.04 | Intel Core i9-9920X | 36.5 | 6.19 | 83.04% |
Fedora 40 | Intel Core i7-12700K | 22.34 | 5.81 | 73.99% |
Fedora 41 | AMD Ryzen 9 7950X3D | 29.81 | 6.27 | 78.97% |
TSC provides tools to analyze the stability and drift characteristics in your environment:
- Linux testing: Demonstrates how the library handles frequency variations on different hardware qualities. For modern hardware, drift is about 1μs for long-term running.
- macOS testing: Shows excellent stability with minimal drift within 1μs
- Windows testing: Have not been tested yet. May need High-resolution timer support for calibration
- Calibration effects: Visualizations showing how periodic calibration minimizes long-term drift
Detailed drift analysis charts are available in the tools/longdrift directory.
- Periodic calibration: Call every 5 minutes to align with system clock (NTP adjustments typically occur every 11 minutes)
tsc.Calibrate()
- Verify stability: Use provided tools to verify TSC stability in your environment
- Ordered execution: Use when measuring execution time of short code segments
tsc.ForbidOutOfOrder()
- Fallback awareness: Check to know if the hardware TSC is being used or if standard time functions are the fallback
tsc.Supported()
When running in virtualized environments:
- Some cloud providers handle TSC clock source correctly (like AWS EC2)
- Feature detection may be limited by CPUID restrictions in VMs
- TSC will be used as clock source when detected as the system clock source
- Verify with your VM provider before deploying in production
- Platform support: Best results on Linux with Intel Enterprise CPUs
- Hardware quality: Consumer-grade crystals may show higher drift
- VM uncertainty: Behavior in virtualized environments depends on provider implementation