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 [email protected] 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! -- edubuntu-users mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/edubuntu-users
