Re: How bandwidth requirement could be reduced when using thin clients?
On Tue, Oct 05, 2004 at 12:07:27AM +0200, Knut Yrvin wrote:
> mandag 04 oktober 2004, 21:08, skrev Vagrant Cascadian:
> > it is called "Lessdisks" or "lessdisks" :)
>
> Tanks. Fixed in the document :-)
>
> > > I'll appreciate your comments on this document Jim, Jonas and
> > > others:
> > > http://developer.skolelinux.no/driftskonsepter/2004-09-06-thin-clie
> > >nts.html
> >
> > i'm curious about several things in the chart.
> >
> > is the "3. alt." "Lessdisk" exploring lessdisks as a "half-thick
> > client"?
>
> It's a figure of speak. When a user application runs at the local CPU,
> not the server, then I call it half-thick.
>
> > what are the memory requirements based on? i've mostly used
> > lessdisks with 32-64MB of ram.
>
> I corrected it.
>
> > what does the "Band width" mean? it is a range of used bandwidth,
> > from boot-up to average useage? does that include loading the initrd
> > at boot-time? there are some simple machanisms to reduce the size of
> > the initrd dramatically, which will save a lot of bandwidth during
> > boot.
>
> "band width" is a unfortunate misspelling of bandwidth.
>
> > i hope to have a new upstream lessdisks release by the end of the
> > week, with some significant changes and improvements.
>
> We have questions concerning use of bandwidth, maintenance, and
> integration with Skolelinux. Finn-Arne will follow this up tomorrow ...
Well, it has to be the day after tomorrow, which turns out to be today
:)
KnutY has in another email explained what we need to accomplish with
regards to Oslo kommune. We need a thin-client solution that works with
a wan, with centralized application servers. There is 1 reason for this
and that is that we don't want to have 5-10 application servers on the
schools, and that is what we need for todays solution with Skolelinux
and LTSP on the hardware that is here today. The reason why we cant
have this is that this will call for building specialized server rooms
on each school, something that we dont want to do. Some schools could
do with fewer servers, but we want to have a complete solution.
Short about todays solution base on MSWindows and Citrix
Centralized server for file/print/authentication/email ++
Centralized server for Application servers (Citrix)
1/3 thick clients (WindowsXP)
2/3 thin clients, both prefabricated thin clients running ica-client in
flash, and reused old i386 hardware booted with Linux and ica client
(much like LTSP)
They found out that the thick clients needed a local server for file,
print and autentication, and so most (all?) schools got two aditional
servers, that are black boxes, and that are replicating the services
that was ment to be on the centralized server location. Actually the
job that is done is good, it's cheap, and when everything works as
planned it would be a nice solution, except for 2 things:
The cost
The licensing
Using the Solution that exists today. This calls for at least
Application servers out on the Schools, The wan is like 2-8MBit/s,
ltsp+Skolelinux calls for 2MBit/s per thin client (this is based on
experience, I guess we could do som theoretic calculations and end up
with lower bandwidth demands. But we want to talk tpo the people that
is using the network afterwards.
So what we need to do is lower the bandwidth demands to what is
expected from a citrix solution. (the salespeople are talking as low as
9-16 kbit/sek, I guess we all know that we are talking about 40+kbit/s.)
This is over the Wan.
There are several to do this. and we currently are talking about 2
different projects for the Thin-client setup, both using well known
components that just works. The alternatives are LTSP and lessdisks,
both using netbootable kernels in some way, and a root filesystem that
is mounted using NFS. The difference is how the two
solutions/distributions are built. LTSP is using it's own build
environment, and installs from there, and lessdisks is using standard
debian-packages installed in a chroot environment. Both are capable of
running lowend computer as Thin client, using the Thin-client server as
the Application server, and using the Thin client as the Xserver only.
But running this way, we se the demands for the 2MBit/s per client. So
what we want is either to move the application out on the thin client,
using them as diskless workstations. Or we want to use som technollogy
to lower the bandwidth demand betwenn the Xserver (thin client) and the
application server (ideally placed at the centralized server farm).
Using the NX technology we can achieve this in the same way (or
according to some people) better than how this is achived with Citrix.
With ltsp4 it now became a bit easier to build and install applications
on the thin client, but we need to have a build environment. For those
who haven't tried, I can tell that this is not an easy task. I've been
told that there exists clients for NX technology that works with ltsp.
So ltsp is the way I see it a solution for still using thin clients,
but maybe running a NX-client on the thin client, and then reducing the
bandwidth.
With lessdisks we can have the same thing as with ltsp. We may have an
easier/better chance to get securoty patches in, but making lessdisks
autoinstall and ready set up is a longer shot than doing this with
ltsp.
We have ltsp 3 working already, and the packages for ltsp 4.1 is beeing
debugged as i write this. But ltsp is a long way from making it into
debian as a "native debian-package"
So if we want to go for "thicker clients", I think the correct
technology is lessdisks. And with lessdisks we could install into the
chroot a full Debian-edu-workstation, and use this if the thin client
is powerfull enough. (say PIII with 128MB memory or better). The only
thing that is lacking today is the possibility to use very lowend
machines, like 486 with 16 MB. For that we need swap over NFS or
something similar, which is already built into ltsp, (but not enabled
for now in the new debian-edu setup)
There also might be that the ltsp-way of doing things is better for
using different cpu-architecture on the thin client and the thin-client
server.
--
Finn-Arne Johansen
faj@bzz.no
http://bzz.no/
Reply to: