[K12OSN] TuxMath test on 8 core machine with teamed NICs 16GB RAM

[Jim Kronebusch]

On Thu, 06 Dec 2007 11:14:53 -0500, James P. Kinney III wrote
> On Thu, 2007-12-06 at 10:58 -0500, Jim Kronebusch wrote:
> > On Thu, 06 Dec 2007 09:53:52 -0500, James P. Kinney III wrote
> > > Bad stats, Jim. That's not good news as everyone I see whose seen
> > > tuxmath goes ape over it (especially the kids).
> > > 
> > > The version that ships with K12LTSP is a bazillion years old (the
> > > abandoned version). The new version is 1.5.8 (tux hides in igloos and
> > > cities are not destroyed, includes "lessons" and does negative
> > > numbers!).
> > > 
> > > The code is essentially unchanged at the base level (SDL is an easy
> > > cross platform toolset but is very inefficient). I don't have access to
> > > a large client count at the moment but I'll check the new version vs.
> > > the old version on Opteron systems ASAP.
> > > 
> > > I'm really floored that the hardware you threw at this test choked so
> > > badly. I suspect that the different memory management processes between
> > > Opteron and Xeon will show up here (my testing last year showed an
> > > average performance boost of 30+% in thin client speed between Opteron
> > > and Xeon - Simultaneous launch of 24 OOo instances took 65 seconds on
> > > Xeons and 42 seconds with freshly booted servers and client. Speed up
> > > was even more dramatic with cached copy).
> > 
> > I did not even think about the TuxMath version, here is the output of the Edubuntu
> > repository:
> 
> Yep, an older version. Try the development repo here:
> http://alioth.debian.org/frs/?group_id=31080
> 
> I compiles the new 1.5.8 on my Opteron test machine and it's quite
> speedy (note: one user - me). Code still has dead loops in it to
> deliberately slow it down and they are hard coded and not based on cpu
> speed or timed loops. so the game is faster on a fast machine and slower
> on a slow machine with both being equally loaded/unloaded.

Interesting, maybe this is precisely the problem.  Could this be why CPU usage grew with
no increased activity?  Maybe these dead loops keep the fast system and processors from
"catching" up with all the activity and unnecessarily consume the CPU?  Where this isn't
a problem for a single user, it may be exactly what is causing the problems in a
multiuser environment.  The application is designed to run at a certain constant speed,
no matter the hardware, thus it's reluctance to scale?  If this is the case, could this
be a setting in a conf file, or read from instances of current TuxMath processes running?
Maybe then it could optimize itself for x amount of users then.

Thoughts?

Jim

-- 
This message has been scanned for viruses and
dangerous content by the Cotter Technology 
Department, and is believed to be clean.