Paul, you are mostly right, but you forget about hardware-specific properties of current CPU and chipset design, namely clock skipping that is fully automated to save power, even as little as running an empty loop might disable it effectively forcing CPU and chipset abandon that particular power saving option. The clock skipping is feature that adds latency in an unpredictable manner, since a clock pulse appears only on every n-th occasion compared to full-power run. Somebody claimed that as much as 100 thousand such circuits are applied in a CPU and if CPU-chipset link uses similar technique it adds to latency there and if chipset has in the internal logic such a thing it adds more latency there too. In other words, we need a latency optimised CPU and chipset with proper hardware support for our software, otherwise we depend only on tricking the hardware into doing what we imagine we want it to do.
On Tue, Feb 10, 2009 at 12:58 PM, paul_c <pau...@users.sourceforge.net> wrote: > On Monday 09 February 2009, EBo wrote: >> There are some interesting patterns in the actual results. I was >> watching not only the ovr_max, but also the lat_max. For me the lat_max >> will bounce around between a say -200ns to maybe 300ns, and then jump to >> 2000ns to 4000ns blocks, and then sometimes settle back to near 0. > > A result (from the RTAI latency test) of 2-4uSec is quite good depending on > actual load - What you need to watch for is spikes in the millisecond range > indicating a possible SMI issue. > >> > My own theory (and it is only a theory) about why the cpu hog works is >> > related to cache. The hog uses very little memory, and since it keeps >> > one CPU busy, that CPU never runs any other code. So the RT code >> > doesn't get flushed out of cache, and doesn't have to get fetched back >> > into cache later. > > Running a minimal script that just burns CPU cycles is of little value - An > analogy would be to jack up the wheels of a car and run the engine to the red > line and claim it will do 150MPH. > >> The cache theory (which makes seance) would explain the jumping blocks seen >> above, but it does not explain my current problem with the non RT side of >> the latency test stalling the way it does. > > If you want to see the effects of cache misses, run a "cache calibrator" - One > that has been recommended in the past is http://monetdb.cwi.nl/Calibrator/ > >> Maybe what is needed is another latency test which uses a >> continuous/periodic interrupt. > > What you _should_ be doing is providing some real-world loads over an extended > period, i.e: > > Start the RTAI latency test then: > > dd if=/dev/urandom of=/dev/null > ping -f -s 1600 -l 1000 localhost # also flood-ping from another box. > cd <kernel-src>/ && make -j > > For more extreme testing, run cpuburn or `:(){ :|:& };:` [1] - Starting up X > while the latency-test is running will also give the system a good short term > loading, and if it doesn't lock up starting/stopping X, then you will have a > solid setup. With X running, any graphics intensive processes will also > provide a good workout - Try some of the OpenGL screensavers. > > > > > [1] :(){ :|:& };: is otherwise known as a fork bomb - Do not try this at > home. > > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code to > build responsive, highly engaging applications that combine the power of local > resources and data with the reach of the web. Download the Adobe AIR SDK and > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
