[K12OSN] More feedback on Fedora 10 + LTSP

[James P. Kinney III]

David,

As wonderful as tuxmath is (it's a great game/tool) is has a design
problem that makes it unsuitable for LTSP. The screen draw rate is
clocked by wait cycles as dummy loops. The system literally polls "is it
time to send a screen update now". While the load is minimal, it pushes
the next cycle onto a timer. So the system get dog slow and the load is
not high yet the client end is uselessly slow. The loop timer is
calculated once at startup and can't change as the load the goes up.

The _entire_ game loop depends on this timing cycle. The heavier the
server load the more out of sync this clocking becomes. Short of a
rewrite I was never able to do more than a few tweaks to it. Because of
the way multicore systems handle thread swaps, tuxmath actually makes a
killer test on cpu efficiency. 

On Tue, 2009-04-28 at 21:59 -0400, David Hopkins wrote:
> > With k12ltsp you should be able to enable ssh on the clients so you could
> > connect and run ifconfig.   Did you measure the server NIC throughput under
> > CentOS5.2+LTSP4.2 to see if there is a large difference?  I think you
> > mentioned the switch having flow control enabled.  Can you turn it off?
> > http://www.smallnetbuilder.com/index2.php?option=com_content&task=view&id=30212&pop=1&page=0&Itemid=54
> >
> 
> Thanks!!
> 
> The switches had flow control turned on which apparently was limiting
> the Gig-E link to appr 100Mbps. I turned it off and launched 21
> sessions of Tuxmath. It wasn't playable but once I backed it down to
> around 8-10 sessions, it was tolerable. However, tracking the
> throughput on the switch as I backed it down, the max I ever saw was
> 400Mbps and it stayed closer to 300Mbps.  Load on the server never
> exceeded 8 (on an 8cpu system).  So, while a lot better, something is
> still limiting the throughput. I thought it might be packet size
> related, so I ran NetIO from this system to another on a Gig-E link
> with  the folllowing typical results:
> 
> TCP connection established.
> Packet size  1k bytes:  82750 KByte/s Tx,  112086 KByte/s Rx.
> Packet size  2k bytes:  87499 KByte/s Tx,  113424 KByte/s Rx.
> Packet size  4k bytes:  95495 KByte/s Tx,  112055 KByte/s Rx.
> Packet size  8k bytes:  94037 KByte/s Tx,  114064 KByte/s Rx.
> Packet size 16k bytes:  102218 KByte/s Tx,  114743 KByte/s Rx.
> Packet size 32k bytes:  104406 KByte/s Tx,  114689 KByte/s Rx.
> 
> These are representative (I ran the test 10 times).  So, I'm not
> totally sure what is up with the Tx numbers.
> 
> Still, thanks to everyone ... I at least have a good idea of where to
> look now. And, worst case, I can get a card and just use channel
> bonding to get the throughput up if I have to with some hope that it
> will actually work.
> 
> Sincerely,
> Dave Hopkins
> Newark Charter School
> 
> _______________________________________________
> K12OSN mailing list
> K12OSN at redhat.com
> https://www.redhat.com/mailman/listinfo/k12osn
> For more info see <http://www.k12os.org>
> 
-- 
James P. Kinney III          
CEO & Director of Engineering 
Local Net Solutions,LLC                           
http://www.localnetsolutions.com

GPG ID: 829C6CA7 James P. Kinney III (M.S. Physics)
<jkinney at localnetsolutions.com>
Fingerprint = 3C9E 6366 54FC A3FE BA4D 0659 6190 ADC3 829C 6CA7


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.