| dgroos | Good Morning. | 15:49 |
|---|---|---|
| dgroos | ... and Good Afternoon! | 19:50 |
| alkisg | Hey dgroos | 20:13 |
| alkisg | LTSP over wireless will be kinda slow, maybe *nx would fare better | 20:13 |
| dgroos | *nx? | 20:14 |
| dgroos | (video board still working?) | 20:14 |
| dgroos | alkisg: Possible, though? How about with gigabit wireless with a ratio of 1 router to 10 clients? | 20:16 |
| alkisg | I stopped rebooting, it works if I just use suspend :D | 20:16 |
| alkisg | Sure, it's possible, as long as you have an appropriate initramfs locally, e.g. in a usb stick | 20:17 |
| alkisg | To check if the performance suffices, you can temporarily test with XDMCP, it has the same performance as ltsp | 20:17 |
| alkisg | I.e. enable xdmcp in /etc/gdm/custom.conf, and run X -query on e.g. 10 standalone clients over wireless | 20:18 |
| alkisg | I've never seen a gigabit wireless link so I don't know how that would perform | 20:18 |
| vmlintu | fat clients might perform better over wireless | 20:25 |
| dgroos | alkisg: Right, wireless N is rated at 300 MB/sec... | 20:25 |
| dgroos | 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. | 20:26 |
| dgroos | vmlintu: 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). | 20:27 |
| dgroos | brb | 20:27 |
| vmlintu | I should do some testing with fat clients over wireless some day too | 20:58 |
| alkisg | Some form of local image cloning + syncing is needed there, otherwise with regular 50mbps wireless they're slow | 21:04 |
| alkisg | 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 | 21:05 |
| mhall119 | alkisg: IIRC, samba does a good job of local caching | 21:06 |
| alkisg | mhall119: that persists across reboots? | 21:06 |
| mhall119 | probably not, no | 21:06 |
| alkisg | That wouldn't help then :( | 21:07 |
| dgroos | alkisg: 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? | 21:17 |
| alkisg | dgroos: 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 | 21:17 |
| alkisg | So it wouldn't add any boot or other overhead | 21:18 |
| alkisg | 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. | 21:19 |
| 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? | 21:25 |
| alkisg | 1 | 21:28 |
| alkisg | $ free | 21:28 |
| alkisg | total used free shared buffers cached | 21:28 |
| alkisg | Mem: 4117336 3621892 495444 0 235892 2831324 | 21:28 |
| alkisg | That "cached" column for RAM has the same meaning as disk caching | 21:29 |
| alkisg | It just speeds up the access when a slow link (in this case the network) exists | 21:29 |
| 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? | 21:31 |
| alkisg | No no it's not related to RAM, I just tried to give a similar example | 21:32 |
| alkisg | 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 | 21:33 |
| alkisg | E.g. when you have an 1 Gb image, and a client boots, it might read just 20-50 Mb | 21:34 |
| alkisg | 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" | 21:34 |
| dgroos | Right. And stick access is pretty quick! | 21:35 |
| dgroos | alkisg: How much work/time do you see setting up something like this would take someone in-the-know? | 21:35 |
| alkisg | And scales well. And local disks could also be used (e.g. ntfs partitions), if available | 21:35 |
| alkisg | 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 | 21:36 |
| dgroos | I wonder how important this feature would be to other educators? | 21:39 |
| dgroos | Other educators? | 21:39 |
| 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 | 21:41 |
| alkisg | (not exactly ltsp anymore...) | 21:42 |
| dgroos | It seems there would be *lots* of overlap, however. | 21:46 |
| 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) | 21:47 |
| dgroos | There site is powered by plone... http://www.guadalinex.org/que-es-guadalinex | 22:01 |
| vmlintu | Maybe the ltsp image could be sync'ed in initramfs to local hard drive | 22:08 |
| vmlintu | That might be worth a try.. it'd take quite a long time to transfer a 10 gig fat client image, though.. | 22:10 |
| dgroos | How often would this have to happen? | 22:10 |
| vmlintu | every time the image changes, I guess | 22:10 |
| vmlintu | Using rsync would probably shorten the time quite a bit, though | 22:11 |
| dgroos | could it be only the part that had changed--incremental I'm trying to say, somehow? | 22:11 |
| vmlintu | rsync transfers only the parts that have changed - we use that now to transfer ltsp images to our servers | 22:12 |
| dgroos | OK. Could one use USB sticks instead of HD to increase speed, significantly? | 22:13 |
| vmlintu | most usb sticks I have tried have been slower than hard drives | 22:18 |
| alkisg | dgroos: are you mainly talking about thin or fat clients? | 22:19 |
| dgroos | vmlintu: I didn't know that! | 22:19 |
| 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 | 22:19 |
| 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. | 22:21 |
| alkisg | You put wireless cards to P3/P4? Wouldn't it be more effective to just add RAM to them? | 22:22 |
| dgroos | alkisg: not sure what you mean? | 22:22 |
| dgroos | We're not currently doing wireless! | 22:22 |
| alkisg | dgroos: e.g. sending a video to a thin client requires for example 50 mbps | 22:22 |
| alkisg | If you have 50 mbps bandwidth for each client, why use usb sticks? | 22:23 |
| dgroos | I would like to do that in future setups, I've got 2 more teachers that want a classroom set of 'computer-embedded-tables' :D | 22:23 |
| alkisg | We have that use case here too, the ministry decided that it wants to ship tables with wheels and netbooks on them, connected wirelessly to the rest of the school | 22:25 |
| dgroos | alkisg: if you want to look at the table I'm talking about (not on wheels nor sold at any reputable store!) check the bottom row of images on this page--I've changed this to a public folder for a bit so you can see it :) http://gcos.mpls.k12.mn.us:8383/gcos/Members/mrg/imagess/ | 22:33 |
| dgroos | Actually, none of the students are using the computers in the tables, I use these images to show that... regular class business can go on with these tables, too! | 22:34 |
| 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 ;) | 22:34 |
| alkisg | 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 | 22:35 |
| dgroos | And I down-sized my tables to get them to fit in a room, also I like the group dynamics at this size table. | 22:39 |
| dgroos | Excellent idea with the local ltsp server! | 22:40 |
| dgroos | I could make that work, maybe... | 22:40 |
| dgroos | Would a pentium 4 with 1 gig ram be enough for a 3-computer ltsp server? Would sch-scripts still work on them? | 22:41 |
| dgroos | would it need a gig NIC? | 22:41 |
| alkisg | That server could have 3x100mbps network cards, I think that'd be cheaper than gigabit+switch+whatever | 22:44 |
| alkisg | sch-scripts would work, sure | 22:45 |
| alkisg | 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 | 22:45 |
| 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. | 22:49 |
| dgroos | just loaded a new pict at the above-mentioned link showing the table in use :) | 22:51 |
| dgroos | *as a computer-table. | 22:51 |
| alkisg | For fat clients, you can have a very old ltsp server with just 512 MB RAM and a fast disk | 22:51 |
| alkisg | No cpu/much ram is needed there | 22:52 |
| alkisg | Of course if you have 2 Gb, it'll be used for caching... | 22:52 |
| dgroos | regular 7200 fast *enough*? | 22:53 |
| alkisg | Sure | 22:53 |
| dgroos | I'll be doing tests on this in the next couple of months and report back :) | 22:54 |
| dgroos | I'll post related parts of this to my question on the list serve as well. | 22:54 |
| alkisg | dgroos: have you ever checked multiseat? | 22:55 |
| dgroos | multiseat? | 22:55 |
| alkisg | It allows a single pc to have lots of screens + mice + keyboards | 22:55 |
| alkisg | *Maybe* that's better suited to what you're trying to do | 22:55 |
| alkisg | Check the video there: http://www2.userful.com/products/userful-multiseat-linux | 22:56 |
| alkisg | There are multiple implementations, I just gave the link for the nice video | 22:56 |
| dgroos | Really! I didn't know those existed though I'd conceived of them quite a few times... | 22:57 |
| dgroos | Thanks! I'll be checking that out as well, and adding some notes to my blog... | 22:57 |
| dgroos | Thanks alkisg, vmlintu and mhall119! | 22:58 |
| === ogra is now known as Guest61100 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!