[K12OSN] New K12LTSP installation

[James P. Kinney III]

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.

<drool!>

> 
> --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                           
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.