Messages in this thread | | | Subject | Re: PREEMPT_RT vs ADEOS: the numbers, part 1 | From | Kristian Benoit <> | Date | Sun, 12 Jun 2005 22:32:24 -0400 |
| |
On Sun, 2005-06-12 at 15:49 -0400, Karim Yaghmour wrote: > James R Bruce wrote: > > It seems that running lmbench improves the maximum response time > > considerably compared to an idle system, unless you touch the > > hard drive. That sort of thing makes very little sense though, > > and thus is likely an artifact of the testing. Maybe the test > > needs to be run for longer, or maybe each test should be > > duplicated a few times? I realize the max is always going to be > > pretty noisy, but we can't really compare approaches much if it > > jumps around by a factor of 2.5. Then again, maybe lmbench *does* > > improve latency and that would definitely be a bug somewhere that > > you've uncovered :) > > Actually I personally read these numbers as being very good. What > I see here is that there were exactly two maximums on 5 different > configs and that standard deviation was always close to 0. What that > means is that Adeos' performance degradation is stepwise and can be > studied (i.e. in order to obtain things like: 60% of the time your > maximum will be 53us and 40% of the time, it'll be 22us.) I don't > think there's any correlation between the setup and the maximum > observed. Instead, it's more like ints were generated by the logger > every 1ms and 1ms is an eternity, so on every odd moon, a combination > of factors resulted in the 53 us actually occuring, but on other > setups, with luck, the maximum was less. > > The real remedy to this would be to certainly run longer tests, but > more importantly, it would be to generate a lot more interrupts from > the logger at random times instead of just every 1ms. This would > avoid any sort of artificial sync that may occur between the logger > and the target by virtue of having the logger generate interrupts at > exactly every 1ms. This type of test, though, would be more > complicated and it would require very careful design on the logger > side to avoid introducing any sort of articial latency into the > measurement process. > > > The nicest results would be CDFs or histograms of the response > > times, plotted againts each other for east comparison. Obviously > > that makes more work for you, however. If we can get full traces > > from the logger as text, then its easy for us to make such graphs, > > or add some scripts to your testbed once its released to generate > > them automatically with gnuplot/etc. > > We will be providing full traces, amongst other things. And > getting additions/modifications allowing the automatic generation > of graphs, and other stuff would be great. > > Karim
All that sounds like lots of job and fun tomorrow morning. I better go to sleep !!!
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |