This was discovered while reading the code. The topology scanner sets each server's round trip time in microseconds, then compares the round trip time to localThresholdMS, which is specified in milliseconds (default 15ms).

In theory, this means that when the driver is doing secondary reads, it ignores a member that is even 15 microseconds higher-latency than the nearest secondary.

In practice, I believe the behavior is this: the driver always reads from the lowest-latency member matching the read preference, instead of the specified behavior of reading from the lowest-latency member and all members not more than 15ms higher-latency. But in many users' replica sets, secondaries have similar latencies. Which secondary is lowest-latency varies from one scan to the next, so the driver accidentally distributes reads reasonably evenly.