Basically, there are 4 sets of benchmarks that matter a lot for us: fs, tcp, tls, and http.  The buffer/array/misc benchmarks are good to have, but should not be run often.  They're crazy fast compared to other stuff, and so aren't that relevant.  But, still, consistent "ops/time" results are a lot easier to track and talk about.  We're not seeking zero, we're trying to keep the line from going down.  We're looking to serve as many requests per second, or push as many Gbits per second, as possible.  That's the primary main objective, that's what "fast" means.  That's why we measure car speed in "miles per hour" rather than "minutes per mile", because a bigger number means a bigger speed.

I agree of course that the numbers should be proportional.  The misc tests are in bazillions, so they're kind of pointless.  I only divide them by a fixed number so that we don't have results like 1.23412e25, but maybe it'd be better to just go ahead and show it that way, so that it's clear that it's too fast to matter :)  I've moved them from `make bench` to `make bench-all`, so we can run them if we need to, but basically, if you're not working on something directly in that area, there's probably no need.  We can track them to catch regressions, but otherwise, meh.

For the relevant benchmarks, every tool in the world talks about "requests per second" or "gigabits per second", so we ought to report the same numbers.  If our relevant benchmarks are reporting ops/time, then our microbenchmarks should as well.  There is a lot of value in consistency here.