Table of Contents

Class TelemetryPercentile

Namespace
Typhon.Engine
Assembly
Typhon.Engine.dll

The engine's one definition of a percentile over telemetry samples: nearest-rank, no interpolation.

public static class TelemetryPercentile
Inheritance
TelemetryPercentile
Inherited Members

Remarks

It lives in one place because two paths report the same numbers to different audiences — the STATS wire block to game clients, and ReadStats(int) to an HTTP endpoint, a CLI verb or a log line. Two implementations of "p99" that disagree by a rank produce two plausible-looking figures for one tick, and whichever a reader happens to see becomes the one they trust. A shared function makes them equal by construction rather than by review.

Nearest-rank, deliberately. An interpolated percentile invents a value between two measured ticks, which for a latency figure means reporting a duration no tick had. At the window sizes here — one second, so 50 samples at 50 Hz — interpolation also moves the answer more than the sampling noise it is meant to smooth.

Methods

NearestRank(double[], int, double)

The nearest-rank percentile of the first count samples.

public static double NearestRank(double[] samples, int count, double q)

Parameters

samples double[]

The samples. Reordered in place — the caller must not rely on their order afterwards.

count int

How many leading entries of samples are live samples.

q double

The percentile, in [0, 1]. 0.5 is the median.

Returns

double

The sample at the nearest rank, or 0 when there are no samples.

Remarks

Sorting in place is what keeps this allocation-free on the STATS path, which reuses one buffer sized at construction and must not allocate after it. Zero for an empty window is a reading, not a sentinel: a runtime that has not ticked has no duration, and a caller that needs to tell the two apart reads the sample count it passed in.