[K12OSN] Where is K12LTSP at?

[Robert Arkiletian]

On 3/4/09, R. Scott Belford <scott at hosef.org> wrote:
> 2009/3/2 Moon <moon at smbis.com>:
>> What has been your experience with DRBL for the following:
>>
>> 1. Boot time
>
> As fast as the network - pretty much the same booting experience as
> the k12ltsp/k12linux, etc.
>
>> 2. Reliability
>
> DRBL is just a project that pre-scripts some really cool behavior from
> standard packages.  So, since you can install DRBL (diskless remote
> booting linux) on pretty much any distro, reliability is a function of
> the team behind the distro.
>
>> 3. Scalability - as in how many TCs have you seen running simultaneously
>> one
>> one server? Server specs.?
>
> I have multicast imaged 25 clients at once using Clonezilla on DRBL.
> Kristian just spoke at SCALE about DRBL in 'pod' settings of 4 or 5
> clients.  You have to consider this - you can, by default, configure
> DRBL to be a fat and a thin client server.  The client's behavior can
> be pre-determined by MAC address, it can be determined by the user's
> interaction, or it can be determined by setting the default boot
> option.
>
> If you are booting fat clients, then you need very little CPU
> horsepower, but you need bandwidth and disk i/o.  I have noticed, when
> running Top with a 1s refresh, that NFSD is barely hit when I boot a
> fat client.  I have not tested this in scale beyond 5 clients.  It is
> scary impressive, but it is also just NFS/NIS/DHCP/TFTP, etc.
>

Kamloops school district uses a DRBL-like home grown solution for all
schools. One server per school. They tested booting 120 clients. I
thought disk i/o would go through the roof but it didn't. After the
first system boots everything is in the cache of the server, so
subsequent requests for the same data (which is exactly the case for
booting) doesn't hit the disk. So the network becomes the bottleneck.
So they bonded 2 gigabit nics to the switch. 802.3ad Link Aggregation.

Clients are 100Mbps NOT 1000Mbps. DRBL servers are just file servers
so they can handle many more clients than LTSP servers.

Programs do take a *bit* longer to launch but once up, they are fast.
Provided you have good/powerful clients.  Also, second time launch of
a program (eg. Firefox) is much faster since the client kernel caches
app memory. 2GB is $25 USD now.

Plus there is nothing special required for local devices or sound. The
only thing that's not local is the disk.

> If you are booting thin clients, then you need the horsepower on the
> server.  I have not tested this in scale, but I do know that you have
> to enable XDMCP in order for the thin-client element to work.  I
> imagine the same scalability as the K12LTSP, but, I really don't know.
>
>> 4. TC performance compared to LTSP and stand-alone workstation
>
> For me, it seems that modern thin clients are well served with
> K12Linux.  I hope that some of this makes its way into an EL release.
> For older clients, as has been stated, the K12LTSP el is still so very
> good.  Of course we are now learning about how to run both, as in
> LTSP5 and LTSP4.2, on the same server.
>
> However, I am discovering just how good the fat client world can be,
> and 'older' hardware for us is a PII and PIII nowadays.  For this, I
> am in love with DRBL on any distro, including redhat or centos or
> fedora.  I am intrigued by the default NFS/NIS integration in DRBL
> since, aside from security concerns, this is a great, out-of-the-box,
> central authentication and roaming profile solution.
>
> I shared this photo in another post, but, this is the CPU load on a
> fat client.  There is nearly no load on the server.
>
> https://links.hosef.org/topfatclient
>
> --scott
>
> _______________________________________________
> K12OSN mailing list
> K12OSN at redhat.com
> https://www.redhat.com/mailman/listinfo/k12osn
> For more info see <http://www.k12os.org>
>


-- 
Robert Arkiletian
Eric Hamber Secondary, Vancouver, Canada