[K12OSN] New K12LTSP installation

James P. Kinney III jkinney at localnetsolutions.com
Fri Jun 20 00:37:47 UTC 2008

On Thu, 2008-06-19 at 08:50 -0700, Huck wrote:
> http://lightfleet.com/?cat=11
> when this technology gets to be FULLY developed and produced... it might 
> cure some of the problems James lists below ;)

I believe it's IBM that has a working all-optical crossbar interconnect.
Basically a power-pc chip has it's top surface replaced with laser
diodes and a fiber block gets attached. It then connects to an optical
switch which route cpu/ram signals between cpu's. Cooling is a chore so
no commercial production any time soon. But the stacked 8-core process
has promise. 8 cores with optical interconnect each separated by a
diamond layer to disperse the heat to the edges. The heat sink is on 4
sides, power in at the bottom and data IO on the top.


> --Huck
> James P. Kinney III wrote:
> > On Thu, 2008-06-19 at 10:44 +0530, Sudev Barar wrote:
> >> 2008/6/19 James P. Kinney III <jkinney at localnetsolutions.com>:
> >>>> 4.  Is there a good writeup on load sharing between two K12LTSP servers if we
> >>>> decide to go a bit fancy?
> >>> Too much work to load balance with only 2 servers. Split the client list
> >>> with the network wiring and divide and conquer!
> >> Not really, running two servers with dhcpd load balancing and failover
> >> was relatively easy. There was link some where. If you want to try
> >> this I will dig it up.
> > 
> > DHCP is not the real load that needs balancing. It's the application
> > serving. While the DHCP load balancing can be used to split the boot up
> > and ultimately the server each client run from can be set this way, the
> > application load balancing is the issue I'm most interested in and
> > currently working on.
> > 
> > Picture this scenario: Large school with 800 students and 5 LTSP
> > servers. Several classes are fully populated with clients and make
> > extensive use of the heavy applications. Other classes do lighter stuff.
> > The teachers in the heavy use room will see the LTSP as slow. If there
> > is a way to dynamically shift the workload between running server so a
> > single server doesn't bog down under a classroom activity while others
> > are barely in use, that's a huge improvement.
> > 
> > This process is very technically challenging at this point. As each
> > running application has it's own PID, memory and threads, plus all the
> > associated communication credentials for X, migrating these processes to
> > more cpu's on more machines is not a trivial thing without disruption
> > that the client sees. LTSP5 does this at login time with the ldm server
> > load calculation. However, once connected, the client is firmly attached
> > to a single server. If it bogs down, all clients bog down.
> > 
> > The long term solution is a process used in high-end scientific
> > computing called single system image. The OpenSSI project is working
> > towards a solid solution in the lines of LTSP and OpenSource. There are
> > commercial projects like Mosix that already have this capability. This
> > process provides for a stack of servers that all provide cpu and RAM to
> > the cluster. A mother node monitors the load across all machines and can
> > migrate a process to a less used node as needed. As this process
> > migrates, all of it's associated records, ram and connections also
> > migrate seamlessly. The client never sees the change. This also allows
> > for hot node replacement as a node can be brought down, pulled, repaired
> > and replaced, and then restarted with no effect on clients other than
> > the loss of a bit of speed.
> > 
> > This has a ways to go before it is ready for use. It is under active
> > development and constant testing. Imagine the fun we can have when our
> > kids can reply to a normal students comment of "I use a Microsoft
> > windows machine every day at school." with "I use a 12 node, 96 cpu
> > super computer!"  :-)
> _______________________________________________
> 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                           

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.

More information about the K12OSN mailing list