On 9/14/2012 1:15 AM, Jan de Kruyf wrote: > Hallo, > this is the plot from this board with a slightly different cpu, under > reasonable load: > https://www.osadl.org/Latency-plot-of-system-in-rack-4-slot.qa-latencyplot-r4s7.0.html > You might look up there also exactly how they do their tests. > > The Pagefault message says that the LCNC memory is not properly locked in > place (i.e. the kernel needs to page, it should not) > So I would say, speak to your friendly software developer, or if you really > want to try, throw lots of memory at it and hope the kernel stops paging > after a while. > > By the way you can also look up the kernel compile switches here: > https://www.osadl.org/Profile-of-system-in-rack-4-slot-7.qa-profile-r4s7.0.html > and try to build a new kernel. At first I thought the problem might be > there, but the pagefault message convinced me otherwise. > > cheers, > > j. > > > > On Fri, Sep 14, 2012 at 6:30 AM, Kent A. Reed <kentallanr...@gmail.com>wrote: > >> Gentle persons: >> >> First, a statement. >> >> On my ASUS AT5NM10-I board (Intel Atom D510 CPU, 2GB RAM, yada yada >> yada) I followed in Charles Steinkeuhler's footsteps >> <...see original post...>
Hi, Jan. Thanks for reminding me of the OSADL site. Rack 1/slot 4 is an Intel motherboard with the same CPU as on my ASUS, an Atom D510. Max latency reported (as of tonight): 76us Rack 4/slot 7 is essentially the same ASUS motherboard as mine but with the slightly different Atom D525. Max latency reported (as of tonight): 82us I've convinced myself that the basic problem with my first report was that the board and O/S just can't run the fast thread at 25us. I note the OSADL tests are done with the cycletest interval=200us. When I stretch out the latency-test base-thread period to 50us, 75us, 100us, things get much better in my testing. For 15 minute test durations (yeah, I know, I always tell others to run 24 hours, but I wanted to get some data before I went to bed): 1. no-load base thread max latency servo thread max latency 25000ns 95375ns 1000000ns 50915ns 50000ns 45660ns 1000000ns 21262ns 75000ns 41100ns 1000000ns 38133ns 100000ns 21245ns 10000000ns 21539ns 2. with 2 copies of glxgears running base thread max latency servo thread max latency 25000ns 103621ns 1000000ns 72998ns 50000ns 47179ns 1000000ns 26142ns 75000ns 48045ns 1000000ns 67100ns 100000ns 30893ns 1000000ns 19971ns 200000ns 32553ns 1000000ns 20464ns That last was to duplicate the OSADL interval. To my point, stretching out the base-thread period removes the scheduling overrun error in all the cases above 25us except for one of the 50us runs (I forget which). As an aside, I don't know why the max latency for the servo thread is higher for a base-thread period of 75us compared to 50us and 100us. Above a 25us base-thread period, my max latencies are less than the OSADL numbers. I'm going to compile and run their cycletest code to see if I get their number or mine or yet another number :-) I understand at some level what the pagefaults mean. That doesn't mean I can do the right thing. And so to bed. Regards, Kent ------------------------------------------------------------------------------ How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
