Note, I had Claude fix this, as it's completely out of my wheel house. It has fixed it, but it would be wise for someone knowledgeable to check that this fix doesn't break something else.
Body:
On tests longer than ~60 seconds (with the default 200ms ping interval), the reported ping value silently freezes at whatever it was around the 60-second mark, while the elapsed timer and chart continue advancing normally as if the test is still running correctly.
Cause: in stability_worker.js, each ping call uses performance.getEntries() for higher-precision timing:
let p = performance.getEntries();
p = p[p.length - 1];
The browser's Performance Timeline resource buffer has a capped size. At a ping roughly every 200ms, that buffer fills within about 30–60 seconds. Once full, browsers stop appending new entries, so p[p.length - 1] keeps returning the same stale entry indefinitely — freezing instspd at that value for the rest of the test.
Fix: clear the resource timing buffer after each read so it never fills:
} catch (e) {
// Performance API not available, use estimate
+ } finally {
+ try {
+ performance.clearResourceTimings();
+ } catch (e) {}
}
}
Tested on a self-hosted instance — durations of 2–5 minutes now show continuously varying ping values instead of freezing after ~60s.
The host is running Ubuntu 24.04 and the test was run from FireFox on Windows 10.
Note, I had Claude fix this, as it's completely out of my wheel house. It has fixed it, but it would be wise for someone knowledgeable to check that this fix doesn't break something else.
Body:
On tests longer than ~60 seconds (with the default 200ms ping interval), the reported ping value silently freezes at whatever it was around the 60-second mark, while the elapsed timer and chart continue advancing normally as if the test is still running correctly.
Cause: in stability_worker.js, each ping call uses performance.getEntries() for higher-precision timing:
The browser's Performance Timeline resource buffer has a capped size. At a ping roughly every 200ms, that buffer fills within about 30–60 seconds. Once full, browsers stop appending new entries, so p[p.length - 1] keeps returning the same stale entry indefinitely — freezing instspd at that value for the rest of the test.
Fix: clear the resource timing buffer after each read so it never fills:
} catch (e) { // Performance API not available, use estimate + } finally { + try { + performance.clearResourceTimings(); + } catch (e) {} } }Tested on a self-hosted instance — durations of 2–5 minutes now show continuously varying ping values instead of freezing after ~60s.
The host is running Ubuntu 24.04 and the test was run from FireFox on Windows 10.