Fix inconsistent process start time

[Neo-vortex]

Fix: Improve Clock Offset Calculation Stability by Using CLOCK_REALTIME

fixes :#108959

Summary

This pull request updates the SystemNative_GetBootTimeTicks function to use CLOCK_REALTIME instead of CLOCK_REALTIME_COARSE for calculating the time elapsed since the Unix Epoch.

This change is critical because the instability of the coarse clock was causing unstable process start time reads. Switching to CLOCK_REALTIME significantly reduces the observed clock synchronization jitter, leading to a much more stable and accurate boot-time offset value.

---

Detailed Rationale

The function calculates the boot time offset using the formula:

$$ Offset = UnixEpochTicks + Ticks(CLOCK_REALTIME_COARSE) - Ticks(CLOCK_BOOTTIME) $$

This calculated offset is used to determine key system timestamps, including the time when a process started.

Issue with CLOCK_REALTIME_COARSE

The coarse clock, designed for speed over accuracy, introduced substantial jitter into the offset calculation. Benchmark results showed the CLOCK_REALTIME_COARSE path exhibited a peak-to-peak jitter of up to approximately 1 ms (978 μs).

#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <unistd.h>
#include <math.h>
#include <string.h>

#define NUM_TRIALS 100        
#define CALLS_PER_TRIAL 1000   

#define NSEC_PER_SEC 10000000LL
#define NSEC_PER_TICK 100LL  

long long timespec_to_ns(const struct timespec *ts) {
    return (long long)ts->tv_sec * NSEC_PER_SEC + ts->tv_nsec;
}

long long ns_to_ticks(long long ns) {
    return ns / NSEC_PER_TICK;
}

long long get_boot_ticks_fine() {
    struct timespec realtime, boottime;

    if (clock_gettime(CLOCK_REALTIME, &realtime) != 0) return -1;
    if (clock_gettime(CLOCK_BOOTTIME, &boottime) != 0) return -1;

    long long real_ns = timespec_to_ns(&realtime);
    long long boot_ns = timespec_to_ns(&boottime);
    return ns_to_ticks(real_ns - boot_ns);
}

long long get_boot_ticks_coarse() {
    struct timespec realtime_coarse, boottime_coarse;

    if (clock_gettime(CLOCK_REALTIME_COARSE, &realtime_coarse) != 0) return -1;
    if (clock_gettime(CLOCK_BOOTTIME, &boottime_coarse) != 0) return -1;

    long long real_ns = timespec_to_ns(&realtime_coarse);
    long long boot_ns = timespec_to_ns(&boottime_coarse);
    return ns_to_ticks(real_ns - boot_ns);
}

typedef struct {
    long long min_value;
    long long max_value;
    double mean;
    double std_dev; 
} AnalysisResult;

AnalysisResult analyze_results(long long *data, int n) {
    AnalysisResult res = { 
        .min_value = data[0], 
        .max_value = data[0], 
        .mean = 0.0, 
        .std_dev = 0.0 
    };
    double sum = 0.0;

    for (int i = 0; i < n; i++) {
        long long val = data[i];
        if (val < res.min_value) res.min_value = val;
        if (val > res.max_value) res.max_value = val;
        sum += val;
    }

    res.mean = sum / n;

    double sum_sq_diff = 0.0;
    for (int i = 0; i < n; i++) {
        sum_sq_diff += pow((double)data[i] - res.mean, 2);
    }
    res.std_dev = sqrt(sum_sq_diff / n);

    return res;
}

void run_benchmark(long long (*func)(void), long long *results_array) {
    
    
    for (int t = 0; t < NUM_TRIALS; t++) {
        
        long long final_offset_value = 0;
        for (int c = 0; c < CALLS_PER_TRIAL; c++) {
            final_offset_value = func();
        }
        results_array[t] = final_offset_value;

        
    }
}

// --- Conversion Macros ---
#define TICKS_TO_NS(ticks) ((double)(ticks) * NSEC_PER_TICK)
#define TICKS_TO_US(ticks) ((double)(ticks) * NSEC_PER_TICK / 1000.0)
#define TICKS_TO_MS(ticks) ((double)(ticks) * NSEC_PER_TICK / 1000000.0)

// --- Main Execution ---

int main() {
    printf("--- Clock Offset Stability Benchmark (Consecutive Trials) ---\n");
    printf("Goal: Measure the consistency (jitter) of the calculated clock offset.\n");
    printf("Settings: %d trials, %d calls per trial (run back-to-back).\n", NUM_TRIALS, CALLS_PER_TRIAL);
    printf("Offset unit: 1 tick = %lld nanoseconds\n\n", NSEC_PER_TICK);
    
    long long fine_results[NUM_TRIALS];
    long long coarse_results[NUM_TRIALS];

    printf("Running Fine Clock Benchmark (CLOCK_REALTIME/CLOCK_BOOTTIME)...\n");
    run_benchmark(get_boot_ticks_fine, fine_results);
    AnalysisResult fine_analysis = analyze_results(fine_results, NUM_TRIALS);

    printf("Running Coarse Clock Benchmark (CLOCK_REALTIME_COARSE/CLOCK_MONOTONIC_COARSE)...\n");
    run_benchmark(get_boot_ticks_coarse, coarse_results);
    AnalysisResult coarse_analysis = analyze_results(coarse_results, NUM_TRIALS);

    printf("\n--- RESULTS: Stability of Clock Offset ---\n");

    long long fine_jitter_ticks = fine_analysis.max_value - fine_analysis.min_value;
    long long coarse_jitter_ticks = coarse_analysis.max_value - coarse_analysis.min_value;

    // FINE Results
    printf("\n[Fine Clock Offset (High-Resolution)]\n");
    printf("  Mean Calculated Offset: %.0f ticks\n", fine_analysis.mean);
    
    printf("  Observed Range (Peak-to-Peak Jitter):\n");
    printf("    Min Offset: %lld ticks\n", fine_analysis.min_value);
    printf("    Max Offset: %lld ticks\n", fine_analysis.max_value);
    
    // --- FINE: PEAK-TO-PEAK JITTER DURATION (Max - Min) ---
    printf("  Total Peak-to-Peak Jitter:\n");
    printf("    In Ticks: %lld ticks\n", fine_jitter_ticks);
    printf("    In Time:  %.0f ns / %.2f us / %.3f ms\n",
           TICKS_TO_NS(fine_jitter_ticks),
           TICKS_TO_US(fine_jitter_ticks),
           TICKS_TO_MS(fine_jitter_ticks));
        


    // COARSE Results
    printf("\n[Coarse Clock Offset (Low-Resolution)]\n");
    printf("  Mean Calculated Offset: %.0f ticks\n", coarse_analysis.mean);
    
    printf("  Observed Range (Peak-to-Peak Jitter):\n");
    printf("    Min Offset: %lld ticks\n", coarse_analysis.min_value);
    printf("    Max Offset: %lld ticks\n", coarse_analysis.max_value);
    
    // --- COARSE: PEAK-TO-PEAK JITTER DURATION (Max - Min) ---
    printf("  Total Peak-to-Peak Jitter:\n");
    printf("    In Ticks: %lld ticks\n", coarse_jitter_ticks);
    printf("    In Time:  %.0f ns / %.2f us / %.3f ms\n",
           TICKS_TO_NS(coarse_jitter_ticks),
           TICKS_TO_US(coarse_jitter_ticks),
           TICKS_TO_MS(coarse_jitter_ticks));
        

    return 0;
}

--- RESULTS: Stability of Clock Offset ---

[Fine Clock Offset (High-Resolution)]
  Mean Calculated Offset: 176397190940062 ticks
  Observed Range (Peak-to-Peak Jitter):
    Min Offset: 176397190940062 ticks
    Max Offset: 176397190940062 ticks
  Total Peak-to-Peak Jitter:
    In Ticks: 0 ticks
    In Time:  0 ns / 0.00 us / 0.000 ms

[Coarse Clock Offset (Low-Resolution)]
  Mean Calculated Offset: 176397190925664 ticks
  Observed Range (Peak-to-Peak Jitter):
    Min Offset: 176397190921175 ticks
    Max Offset: 176397190930953 ticks
  Total Peak-to-Peak Jitter:
    In Ticks: 9778 ticks
    In Time:  977800 ns / 977.80 us / 0.978 ms

This high variability directly results in unstable process start time reads, making the resulting boot time offset unreliable for high-precision scenarios.

Stability of CLOCK_REALTIME

The corresponding high-resolution clock path, using CLOCK_REALTIME instead of COARSE, showed zero jitter, providing a stable and consistent offset value.

Performance Justification

Although CLOCK_REALTIME_COARSE is intended to be faster, performance profiling confirms that the difference in call overhead between the two clock functions is negligible in our target execution environment.

---

Proposed Change

The function is updated to use CLOCK_REALTIME to ensure the final calculation relies on stable, high-precision time sources, thereby eliminating the approximately 1 ms jitter currently observed.

This guarantees that SystemNative_GetBootTimeTicks returns a highly consistent value across all calls.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR stabilizes Linux/Android process start time calculations by changing SystemNative_GetBootTimeTicks to use CLOCK_REALTIME (higher resolution) instead of CLOCK_REALTIME_COARSE when computing the boot-time-to-Unix-epoch offset.

Changes:

• Switch boot time offset calculation from CLOCK_REALTIME_COARSE to CLOCK_REALTIME in SystemNative_GetBootTimeTicks.

[danmoseley]

@copilot address feedback push to this PR

[danmoseley]

I believe Copilot can't modify this PR as it's on a fork. @Neo-vortex do you want to give it a shot?

[Neo-vortex]

@danmoseley
Ckeck it out

[am11]

LGTM, if this makes result more reliable.

[adamsitnik]

Overall it LGTM. If it turns out that the test takes too much time, we can move it to outerloop.

I am going to update the branch and apply my suggestions and hit the approve button once the CI is green.

Thank you for your contribution @Neo-vortex !

[jkotas]

Do we need 5 processes? 2 (or 3 max) should be enough. Launching child processes is relatively expensive.

[Neo-vortex]

2 seemed too few, two processes could read same number by coincidence, the more processes count the less coincide chance, if you think we are ok with 3 let's do that.

[jkotas]

The test does not need to find the problem 100% of the time. It is ok if the test finds the problem only fraction of the time.

[jkotas]

It is not clear what the "/10 thing" is this referring to. The actual code that this is referring to is ~50 lines below.

[Neo-vortex]

Stating why we do /10 when measuring, it is also repeated ~50 lines later, if you think we can remove it from here, I am ok with it

[jkotas]

Do the tests need to account to for the thread being rescheduled at this point? We can see very significant drift when that happens.

I think the test as written is going to be flaky.

[Neo-vortex]

I thought of using Yield(), but it is a no-op if nothing else wants to run so reads could stay on the same scheduling slice. Sleep(1) blocks for at least one timer tick, forcing a real
context switch so each reading comes after a genuine reschedule.
Correct me if I am wrong, I have limited knowledge in this area.

[jkotas]

I do not think you can reliably trick the scheduler into not rescheduling it. Also, these tricks are expensive.

I think the best way to make this reliable may be to read CLOCK_BOOTTIME second time, and keep looping if it is too far from the first read.

[Neo-vortex]

Can you provide the fix yourself for the test part?

[Neo-vortex]

@jkotas
can we merge this as is and maybe add more testing later on ?
this fix seems to fix some parts of the problem at least.

[jkotas]

I am pretty sure this test is going to be flaky. I am sorry - not merging changes that add obviously flaky tests.

[am11]

@jkotas, I tested a few related APIs https://godbolt.org/z/1E9eT6qve, as we can see some are deterministic across two consecutive calls and some aren't. Is this how we understood / expect them to work? If not, I think we can converge the behaviors while working on this.

[jkotas]

https://godbolt.org/z/1E9eT6qve

All APIs in this test are non-deterministic across two consecutive calls. It is by-design and expected for all APIs that return variants of current time.

We would like SystemNative_GetBootTimeTicks to be deterministic since it does not return current time. The current implementation of SystemNative_GetBootTimeTicks is not deterministic. The test needs to accept some non-determinism and/or the implementation needs to be made deterministic.

[github-actions]

Workflow state for the Holistic Review Orchestrator.

{
  "version": 5,
  "last_dispatched_commit": "1dabd2970e28f1ea32fb2c7715bf70195385695b",
  "last_dispatched_base_ref": "main",
  "last_dispatched_base_sha": "abaf96f8a4c14179248dcbc0f73d137344303345",
  "last_reviewed_commit": "1dabd2970e28f1ea32fb2c7715bf70195385695b",
  "last_reviewed_base_ref": "main",
  "last_reviewed_base_sha": "abaf96f8a4c14179248dcbc0f73d137344303345",
  "last_recorded_worker_run_id": "29681928979",
  "review_attempt_commit": "",
  "review_attempt_base_ref": "",
  "review_attempt_count": 0,
  "max_review_attempts": 5,
  "review_history_format": "holistic-review-disclosure-v1",
  "review_history": [
    {
      "commit": "1dabd2970e28f1ea32fb2c7715bf70195385695b",
      "review_id": 4730547899
    }
  ]
}

[github-actions]

Holistic Review

Motivation: The PR addresses #108959, where Process.StartTime on Linux can produce inconsistent values across processes. The root cause is SystemNative_GetBootTimeTicks, which computes a boot-time-to-realtime offset used to translate a process's /proc start time into a wall-clock timestamp. The prior implementation read CLOCK_REALTIME_COARSE, whose coarse (~jiffy) resolution injected up to ~1 ms of jitter into the offset, causing different readers to disagree.

Approach: A one-line native change swaps CLOCK_REALTIME_COARSE for CLOCK_REALTIME in pal_time.c, plus a new Linux/Android xunit test (StartTime_IsDeterministicAcrossProcesses) that spawns 5 remote-executor children, each reads StartTime 10 times, and asserts all 50 readings agree after a /10 normalization.

Summary: The native change is small, low-risk, and well-justified — CLOCK_REALTIME is the correct high-resolution clock and the negligible extra cost is acceptable on a path that is not hot. This is a reasonable, mergeable fix. My concerns are all in the test, not the product change. The core assertion demands exact equality (after only one low-order digit is dropped), but GetBootTimeTicks still performs two non-atomic clock_gettime calls and recomputes the offset per read, so real elapsed time between the two reads can shift the offset by more than a single tick under scheduling pressure. That makes the test at risk of being flaky in CI even with a correct fix. I recommend asserting a tolerance window rather than exact equality. Secondary nits: informal/uncertain wording in a committed test comment, over-claiming "jiffies" as the noise source, and trailing whitespace on many added lines that will fail formatting checks. Overall: approve the product change; please harden the test before merge.

Detailed Findings

All findings are inline on the test file:

• Exact-equality assertion may be flaky — the two-read, non-atomic offset computation is not guaranteed to be tick-stable across independent processes; prefer a tolerance-based assertion. (test line ~1363–1370)
• Informal/uncertain comment — "Or maybe I'm overthinking it and it's fine either way" should be replaced with a definitive rationale for the /10 normalization. (line ~1297)
• "jiffies" over-claim — the explanatory comment overstates the precise source of the low-order noise. (line ~1282)
• Trailing whitespace on many newly added lines will trip formatting checks. (e.g. line ~1356)

The native pal_time.c change itself looks correct and I have no actionable concerns with it.

Note

This review was generated by this repository's Holistic Review agentic workflow to complement the built-in Copilot review.

Generated by Holistic Review · 128.5 AIC · ⌖ 11.2 AIC · ⊞ 10K

[github-actions]

This exact-equality assertion (after only a single-digit /10 normalization) looks prone to intermittent failures. SystemNative_GetBootTimeTicks reads CLOCK_BOOTTIME and CLOCK_REALTIME in two non-atomic clock_gettime calls and recomputes the offset on every StartTime read. Any wall-clock time that elapses between the two reads (scheduling delay, preemption, page fault) is added into the computed offset, so independent processes can legitimately observe offsets that differ by more than 100 ns (one tick). Switching from CLOCK_REALTIME_COARSE to CLOCK_REALTIME reduces the quantization jitter but does not make the two reads atomic, so exact equality across 50 readings from 5 separate processes is not guaranteed. Consider asserting a tolerance (e.g. all readings within a small millisecond window of each other) instead of exact equality to avoid a flaky test.

[github-actions]

The [PlatformSpecific(TestPlatforms.Linux | TestPlatforms.Android)] scoping is a bit misleading: the underlying SystemNative_GetBootTimeTicks path (#if defined(TARGET_LINUX)) that this test exercises is only compiled for Linux/Android, but the C# StartTime value is derived from /proc on all Unix flavors. That's fine for scoping, but note the comment block references "jiffies" — on Linux the process start time comes from /proc/<pid>/stat (clock ticks since boot) combined with this boot-time offset, so the value is not purely a double conversion of jiffies. Consider tightening the explanatory comment to avoid over-claiming the precise source of the low-order noise.

[github-actions]

Please remove the speculative/informal closing line "Or maybe I'm overthinking it and it's fine either way." A committed test comment should assert a clear rationale for the /10 normalization rather than expressing uncertainty about whether the approach is correct. If the normalization is needed, state why definitively; if it isn't, drop it.

[github-actions]

Many of the newly added lines in this method (blank lines within the method body, e.g. here and lines 1280, 1298, 1300, 1304, 1307, 1310, etc.) contain trailing whitespace. This will trip the repository formatting checks. Please strip trailing whitespace from the added lines.