LTSP over wireless?
mhall at lakeland.net
Mon Jan 10 01:34:40 UTC 2011
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).
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.
> alkisg: LTSP over wireless will be kinda slow, maybe *nx would fare
> 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
> 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
> 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
> 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...
> 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
> 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
> : 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:
> There are multiple implementations, I just gave the link for the nice
> 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!
More information about the edubuntu-users