Been there, tried it, the results have very low variance:
RT: 5.42 (5.52 5.47 5.43 5.42 5.42 5.42 5.42 5.41 5.40 5.40 5.39)
!RT: 4.65 (4.86 4.85 4.84 4.83 4.66 4.65 4.61 4.55 4.55 4.54 4.54)
With 10 background processes:
RT: 11.04 (11.13 11.11 11.11 11.07 11.07 11.04 11.04 11.00 11.00 10.98 10.98)
!RT: 6.76 (6.99 6.80 6.79 6.79 6.76 6.76 6.75 6.51 6.49 6.48 6.47)
: > It's perfectly fine that you want to do something else. I have no
: > problem with your goals but serious problems with your methodology.
: > The problem is based an apples to apples comparison: when you run your
: > pipe version with no background processes, you should be able to duplicate
: > my results very closely. But you can't - you get this huge variance.
: > Until that part of your benchmark is fixed, I, for one, am unwilling
: > to even consider any other part of your results - I have no reason to
: > believe them and a substantial reason not to believe them.
:
: As I've explained before and above, your test doesn't used SCHED_FIFO
: and hence you are unlikely to get other processes lengthening your run
: queue. This lengthening seems to have a substantial impact on the
: variance. When I gave my shell, xterm and X server time to get off the
: run queue, the variance went right down.
Been there, tried that, I get non-varing results with and without RT, with
and without background processes.
: I'm left with variance (up to 50%) in the long run queue case. I can
: sometimes see this variance even with SCHED_OTHER. So there is still
: some other effect going on. Again, I don't see a variance this large
: with your test, so again there is something that my test is sensitive
: too.
: Using pipes and token passing doesn't change the variance, BTW.
It does if you design the benchmark right. Look, you keep setting
yourself up to take a fall. You may be right about everything else,
but you're just dead wrong about the variance. There is no reason for
it to be there. It's not just my benchmark that doesn't see it, every
other variation of this benchmark is stable in the small process case
(where they are basically simulating or calling sched_yield()).
: Instead of abusing me and my test, why not look at the code and try to
: figure out *why* we are getting different numbers? That's how science
: is done. If your results are different from someone else, you go and
: figure out why, not abuse them and their work.
: I'm looking at your code to see why it yields less variance. When the
: answer is found, I'm sure it will be useful.
: If I knew *why* my test is more sensitive, the problem would be
: solved.
Richard, you seem to have a bit of a complex here. I'm not ``abusing''
you, I'm simply holding you up to the normal standards of engineering.
You seem to want to be a contributing member of the Linux kernel hacker
crowd. That's cool, I have no problem with that. I do have a problem
when you show up and tell be that important parts of the system should
be redesigned based on what I know to be a flawed analysis. That leads
to crappy, needlessly bloated systems and I consider it part of my
contribution to prevent that wherever possible.
And, I'm sorry, but it isn't my job to figure out where you went wrong
with your benchmark. The reason that it is your job, not my job, is that
you are proposing that the system get changed. As such, it is up to you
to justify the change. That's just basic engineering. You seem to want
to be part of the kernel engineering crowd; this isn't how you get there.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/