Hello Ando, Pierangelo Masarati <[EMAIL PROTECTED]> writes:
> Dieter Kluenter wrote: >>>> Due to a real time scheduler I was expecting the results to be vice > Dieter, > > I don't know how much this could be of any help, but today I tried to > run a simple test using OpenLDAP 2.3.28 running on Linux 2.6.17 with > RTAI, compared to the stock 2.3.6.15 kernel f the distribution used on > that PC. I created a database with ~10000 users, fully indexed and > fully cacheable (cachesize 10000). What I found (strange enough) is > that the execution time of ldapsearch would differ a lot on the two > systems, but sort of the reverse of what you experienced. I checked > few cases: > > - entry not yet in cache vs. entry already in cache > - system unloaded vs. system heavily loaded > > in the case of RTAI, I also considered some hard real-time load, which > gets the highest priority and accurate scheduling. > > - searching for an entry not in cache, w/ RTAI, requires a little bit > longer than w/o RTAI; this requires access to disk; but > - searching for the same entry, after it's in cache, requires ~0.008s > w/ RTAI, and ~0.080s w/o RTAI (ten times longer! It's a slightly > different kernel, but running on exactly the same machine, so, without > too much investigation, I have no clue about the exact reason) > > - under load (repeated disk and network access), the above entry in > cache times are occasionally delayed, but not that much, on both > systems. w/ RTAI the average goes to ~0.010s, with peaks to ~0.020s; > w/o RTAI no significant extra delay is added to the ~0.080s. The > latter case makes sense, since the system already appears > significantly delayed. > > - under hard RT load (30% of one CPU, and 15% of the other CPU on a > dual CPU system), performances drop significantly; occasionally, the > response time for not-in-cache entry, which requires access to disk, > may raise to ~0.500s, with an average above ~0.100s. The response > time when the entry is in cache is not significantly worse than in the > case with non-RT load, ~0.020s. > > This seems to indicate that with a (possibly) different hard RT > scheduling there is no significant impact on basic OpenLDAP's slapd > performances, so its design seems to have no impact on its execution > in conjunction with RT schedulers. I have no clue, right now, about > how the two RT systems compare. > > I would like to acknowledge the support of Paolo Mantegazza, the main > developer of RTAI, in performing those tests with a devel snapshot > (called "magma") of that system; it should not differ from recent > releases (3.4) in terms of scheduling policies and related issues. Thank you for your test and report and thanks to Paolo Mantegazza. I think I have to dive a bit more into Montavista scheduler and have a chat with their support. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de N 53°37'10.08" E 10°08'02.82" GPG Key ID:8EF7B6C6
