Benchmarks running at (what may appear to be) realtime priority is a typical manifestation of the worthlessness of Windows priority levels and scheduling.

Its impossible to have an IDLE priority process and have responsive GUI and file/net I/O at the same time, so what the client does is boost the priority of the main thread (the one doing file/net I/O) and the GUI thread to the lowest thread priority that is greater than or equal to what other applications have (9 when in the foreground, 7 when in the background).

At some point in the distant past, and on a day when everybody at Redmond wasn't thinking very well, the Win32 designers decided that all of the IDLE priority class priority levels with the exception of the very highest would be lower than the above mentioned "9 or 7" (normal) priority level. And the very highest is almost twice that of normal priority. The priority table for IDLE priority class looks like this: 1, 2, 3, 4, 5, 6, 15. As you see, there is nothing between 6 and 15.

The reason the client has to use IDLE priority class is because its the only way to ensure that the user's "priority" setting does not cause a cruncher to have a thread priority >= 7, which would otherwise cause the whole system permanently be fighting for cpu time.