LTSP over wireless?

[Michael]

I'd think that the biggest problem with LTSP over wireless would be
finding a wireless card or minimal boot image capable of initiating a
connection to the correct AP (how does it know the right one?) and
authenticating (if using WEP or WPA).


-- 
Michael Hall
mhall119 at gmail.com



On Sun, 2011-01-09 at 17:41 -0600, David Groos wrote:
> Hi All,
> Here's an update on this topic from the discussion on the edubuntu
> channel today.  I edited it a bit for brevity and focus and ease of
> reading.  This will be useful to document the ideas given.
> David
> 
> 
> alkisg: LTSP over wireless will be kinda slow, maybe *nx would fare
> better
> 
> dgroos: Possible, though?  How about with gigabit wireless with a
> ratio of 1 router to 10 clients?
> 
> alkisg: Sure, it's possible, as long as you have an appropriate
> initramfs locally, e.g. in a usb stick
> To check if the performance suffices, you can temporarily test with
> XDMCP, it has the same performance as ltsp
> I.e. enable xdmcp in /etc/gdm/custom.conf, and run X -query on e.g. 10
> standalone clients over wireless
> I've never seen a gigabit wireless link so I don't know how that would
> perform
> 
> vmlintu:  fat clients might perform better over wireless
> 
> dgroos:  Right, wireless N is rated at 300 MB/sec...
> Thanks for the ideas to try the XDMCP, I'll give that a go in the
> coming month or 2 and get back to the list.
> thanks for the idea--I would just need an additional 512 MB ram for
> each thin client I'm on and they should work fine (Pentinum 4's).
> 
> vmlintu:  I should do some testing with fat clients over wireless some
> day too
> 
> alkisg:  Some form of local image cloning + syncing is needed there,
> otherwise with regular 50mbps wireless they're slow
> I read a paper once about a modified nfs client that used lots of
> local caching, that would be ideal but I don't think they're
> maintaining it after the initial implementatino
> 
> mhall119:  IIRC, samba does a good job of local caching
> 
> alkisg:  mhall119: that persists across reboots?
> 
> mhall119:  probably not, no
> 
> alkisg:  That wouldn't help then :(
> 
> dgroos:  when you say 'local image cloning + syncing' do you mean that
> the disk image would be stored on the USB flash drive, and that that
> image would be synched during each session?
> 
> alkisg: yes, but ideally it wouldn't need to be synced as a whole, but
> only the parts that the clients needs to read each time
> So it wouldn't add any boot or other overhead
> E.g. the user would say "reserve 1 Gb on that usb stick for caching",
> and that'd be all, even if the fat client image was 10 Gb.
> 
> dgroos:  So, this is LTSP with a fat client but 'X' is stored locally
> on a USB stick, with the parts of X updated as needed.  Not quite sure
> what this, "X" is, yet.  Are you saying that the USB stick would have
> 10 GB on it or 1 GB?
> 
> alkisg:  1
> dgroos:  ... So, the incrementally updated image might be about 1 gig
> only.  This 'cached' info, that's on RAM?  Thus the need for more than
> 2 GB RAM?  Or that could be on the USB stick?
> 
> alkisg:  No no it's not related to RAM, I just tried to give a similar
> example
>  The clients wouldn't need any additional RAM for that, the cache
> would be on the usb stick, stored asynchronously so that it wouldn't
> add any overhead
>  E.g. when you have an 1 Gb image, and a client boots, it might read
> just 20-50 Mb
> It would store those on the stick, so the next time it booted it would
> just have to ask the server "has this part changed? no? then I'll read
> it from the stick, don't send it to me over the network"
> 
> dgroos:  Right.  And stick access is pretty quick!
> How much work/time do you see setting up something like this would
> take someone in-the-know? 
> 
> alkisg:  And scales well. And local disks could also be used (e.g.
> ntfs partitions), if available
>  A lot, implementing properly a caching file system over the network
> is no easy task. E.g. that caching nfs-client was implemented but
> abandoned, I'm sure there's a reason behind it abandonment :D
> 
> dgroos:  I wonder how important this feature would be to other
> educators?
> 
> alkisg:  A lot, it'd be useful for 100mbps networks too, and if
> implemented properly (with caching ldap) it would even allow a
> classroom to be still used when a server goes down
> (not exactly ltsp anymore...)
> 
> dgroos:  It seems there would be *lots* of overlap, however.
> 
> alkisg:  I think in Spain they chose to sync the image from the server
> on each boot instead of using ltsp, I imagine if such a thing was
> implemented they would use it too (thousands of installations there)
> 
> dgroos:  There site is powered by plone...
> http://www.guadalinex.org/que-es-guadalinex
> 
> vmlintu:  Maybe the ltsp image could be sync'ed in initramfs to local
> hard drive
> That might be worth a try.. it'd take quite a long time to transfer a
> 10 gig fat client image, though..
> 
> dgroos:  How often would this have to happen?
> 
> vmlintu:  every time the image changes, I guess
> Using rsync would probably shorten the time quite a bit, though
> 
> dgroos:  could it be only the part that had changed--incremental I'm
> trying to say, somehow?
> 
> vmlintu:  rsync transfers only the parts that have changed - we use
> that now to transfer ltsp images to our servers
> 
> dgroos:  OK.  Could one use USB sticks instead of HD to increase
> speed, significantly?
> 
> vmlintu:  most usb sticks I have tried have been slower than hard
> drives
> 
> alkisg:  dgroos: are you mainly talking about thin or fat clients?
> 
> alkisg:  Because if you have enough bandwidth for thin clients
> (sending videos, X traffic etc) it would more than cover the
> networked-disk part... not much need for caching there
> 
> dgroos:  Well, I'm very big into recycling older Pentium 3 and 4
> machines so I would say for the near future thin clients using lots of
> localapps, but if it were just pentium 4's with a gig of RAM I'd say
> fat clients for sure.
> 
> alkisg:  dgroos: nice, but as in the local ministry proposal, I'd
> prefer a little larger tables, with an ltsp server on the bottom of
> each table ;)
> This way the netbooks/pcs/tablets/whatever there could have wired
> connections to the ltsp server, and the server be wirelessly connected
> to the internet
> 
> dgroos:  Excellent idea with the local ltsp server!
>  I could make that work, maybe...
> Would a pentium 4 with 1 gig ram be enough for a 3-computer ltsp
> server?  Would sch-scripts still work on them?
> would it need a gig NIC?
> 
> alkisg:  That server could have 3x100mbps network cards, I think
> that'd be cheaper than gigabit+switch+whatever
>  sch-scripts would work, sure
> About the pentium 4 with 1 gb ram... well it would work, but I don't
> know if you'd be satisfied with the performance
> 
> dgroos:  How about the performance if the other 3 were running as fat
> clients?  as localapps? if the server had 2 gigs ram?  I know you
> don't know from experience--just asking your best guess.
> 
> alkisg:  For fat clients, you can have a very old ltsp server with
> just 512 MB RAM and a fast disk
> No cpu/much ram is needed there
> Of course if you have 2 Gb, it'll be used for caching...
> 
> dgroos:  regular 7200 fast *enough*?
> 
> alkisg:  Sure
> 
> dgroos
> :  I'll be doing tests on this in the next couple of months and report
> back :)
> dgroos: I'll post related parts of this to my question on the list
> serve as well.
> 
> alkisg:  dgroos: have you ever checked multiseat?
> It allows a single pc to have lots of screens + mice + keyboards
> Check the video there:
> http://www2.userful.com/products/userful-multiseat-linux
> There are multiple implementations, I just gave the link for the nice
> video
> 
> dgroos: Thanks!  I'll be checking that out as well, and adding some
> notes to my blog...
> [4:58PM] dgroos: Thanks alkisg, vmlintu and mhall119!