dubslow

I complained about this practice on Discord a couple days ago, and was greeted with mostly silence, and one comment that running tests to -2.94 LLR is too dogmatic (and...

Untested. This patch is based on vondele's profile data, which suggested that rendering the home page was by far the most time consuming thing the server did. Digging through the...

I've stored the original, more detailed commit history here: https://github.com/glinscott/fishtest/compare/master...dubslow:fishtest:rejectTimeLosses2Orig and instead have forcepushed a simplified history more suitable for merging.

I think it's probably a benefit to have "this run was purged of n tasks" as an event log, in parallel with the time or crashes log event, but I'll...

@vdbergh btw I would very much appreciate your review/feedback of this patch, since among other reasons you're the most familiar with the code.

`currmove` spam is annoying and im glad its gone (we should delete even more of it)

First, as a general comment: having a "master" device could be a flaw in some way, though it certainly makes it easier to think about. On stray thought I had,...

yea but what about when the purge is legit and the run *should* be resumed. possibly it may make sense to use your solution, since users can still manually restart...

(For completeness' sake, the homepage and eventlog were still loadable, but were totally frozen data-wise, as if cached. The info on the homepage didn't change for the 3 hours it...

Not sure if this is related: > [6:55 PM]Dubslow: for vdbergh's benefit, the recent server marginal-overload cost us around 12ish kcores. the log was littered with "stale active task", "Too...