IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 19 March 2020 (all times are UTC)
| 00:00 | <markit> don't know hat algorithm alkis is using, wondering if could be used a better compression algorithm slow in the compression phase but very fast in decompression
| |
| 00:00 | <map7> yes that could be it.
| |
| 00:00 | I'm going to reboot my client and watch the clients CPU as I start libreoffice
| |
| 00:02 | <markit> Compressors available: gzip (default), lzo, xz.
| |
| 00:02 | I've tried and no core was saturated, but try you too
| |
| 00:06 | I could try to compress with lzo and see what happens
| |
| 00:08 | <map7> no core was saturdated for me either
| |
| 00:10 | <markit> ltsp image -m "-comp lzo" /
| |
| 00:11 | seems much slower to create...
| |
| 00:15 | <map7> I'm testing lzo also
| |
| 00:17 | 28seconds blank screen
| |
| 00:17 | no real difference
| |
| 00:21 | just testing xz now for completeness
| |
| 00:23 | <markit> I'm still at 69% of image creation :(
| |
| 00:24 | <map7> 45seconds with xz
| |
| 00:25 | I've got 32threads for compression on the server that's why it's compressing fast
| |
| 00:28 | <markit> me 4 inside a vm :)
| |
| 00:28 | LoBo loads still in 15"
| |
| 00:31 | with iftop -ni bond0 I see that during libo load, the speed of the interface is between 30 and 80Mb/s, so very slow
| |
| 00:32 | that's why for a 80MB file it takes 10 seconds, I suppose
| |
| 00:32 | <map7> is that the NFS link or IMG uncompression speed affecting that?
| |
| 00:33 | Changing the compression between gzip, lzo and xz seems to change the timings
| |
| 00:33 | so maybe there is something to the compression
| |
| 00:35 | <markit> map7: what do you mean? Seams that nfs is not processing fast as it should
| |
| 00:36 | <map7> I mean what is being accessed over the NFS share? Is it just a straight copy or is it trying to access the image in which it might not be the NFS share
| |
| 00:37 | <markit> the server "exports" the image with nfs
| |
| 00:38 | the client does not seem to "mount" in a normal way like for homes, since I think has to be considered a block device like an hard disk
| |
| 00:38 | <map7> ok
| |
| 00:38 | <markit> so probably is some /dev/loop0 that you see with df -h in the client
| |
| 00:39 | like /dev/loop0 4,3G 4,3G 0 100% /run/initramfs/ltsp/0/looproot
| |
| 00:41 | <map7> ok, so it uses squashfs could squashfs itself be slowing this down?
| |
| 00:43 | <markit> from mount on the client: /run/initramfs/ltsp on / type overlay (rw,relatime,lowerdir=/run/initramfs/ltsp/0/looproot,upperdir=/run/initramfs/ltsp/0/up,workdir=/run/initramfs/ltsp/0/work)
| |
| 00:44 | I would love just to change "relatime" to "noatime" for better performances but dubt is the real issue here
| |
| 00:45 | I've the feeling that everything is ok (no error, timeouts, retransmissions, slow disk I/O) but never the less things don't go as fast as they could
| |
| 00:45 | <map7> I'm using two NVMe drives with 5GB/s read/write (Corsair MP600) there shouldn't be an IO problem here
| |
| 00:46 | I'm going to try zstd for compression
| |
| 00:46 | <markit> map7: I'm GMT+1 timezone, 1.45 am here
| |
| 00:46 | <map7> markit: Thanks for your help
| |
| 00:46 | looks like we are on the same path.
| |
| 00:46 | <markit> map7: I wolud love to improve speed myself
| |
| 00:46 | <map7> It's 11:46am here
| |
| 00:47 | I'll let you know if I find anything
| |
| 00:47 | <markit> but I think that without alkisg we can't find any solution, or maybe he did a lot of test and there is NO solution
| |
| 00:47 | <map7> yeah when he comes online I'll share what we have tested today
| |
| 00:48 | <markit> I'm depressed by my lack of troubleshooting abilities :(
| |
| 00:48 | I've no deep knowledge of what is going on, so is just a "try and guess" aproach
| |
| 00:48 | <map7> I feel your pain
| |
| 00:55 | markit: When I do my dd to RAM the blank screen goes down to 5seconds
| |
| 00:55 | PRE_INITRD_BOTTOM_IMAGE_TO_RAM="dd if=/root/images/x86_64.img of=/dev/null"
| |
| 00:55 | | |
| 00:57 | with zstd compressed image
| |
| 00:57 | Libreoffice is down to 4s cold and 1.5s warm
| |
| 00:57 | not bad
| |
| 01:02 | <markit> map7: incredible! Is zstd is supported by mksquashfs?
| |
| 01:03 | man says "Compressors available: gzip (default), lzo, xz."
| |
| 01:03 | maybe is a PRE_INITRD_BOTTOM_IMAGE_TO_RAM effect instead?
| |
| 01:04 | * markit trying zsdt, seems supported | |
| 01:05 | <vagrantc> the manpage sometimes lags ... look at "mksquashfs --help" to see what compressions are supported, but you'll also need kernel support as well
| |
| 01:15 | <markit> vagrantc: thanks
| |
| 01:18 | map7: here with zstd libo loads in 11" instead of 15"
| |
| 01:21 | mmm found that at startup client is contacting some Amazon IP :(
| |
| 01:21 | maybe checking for updates, but everything should have been disabled sigh
| |
| 01:25 | <map7> yes it supports zstd on my machine
| |
| 01:27 | <markit> map7: your performance is almost due only by PRE_INITRD_BOTTOM_IMAGE_TO_RAM
| |
| 01:27 | you are doing a sort of "pre-warm-boot"
| |
| 01:28 | but I'm surprised that boot time doesn't increase dramatically since you are tranferring the whole image, some GB
| |
| 01:28 | <map7> overall boot time does increase
| |
| 01:28 | but I'm only timing the 'blank' screen
| |
| 01:29 | I'm not so worried adding time to the boot as we don't really reboot fat-clients here
| |
| 01:29 | it's more the time to start applications I'm worried about
| |
| 01:29 | ultimately I would like both the boot and apps to load fast
| |
| 01:29 | <markit> and you are comparing new ltsp with old ltsp5, still fat clients?
| |
| 01:30 | <map7> our old ltsp5 system is currently using thin-clients
| |
| 01:30 | and it's on debian 8
| |
| 01:30 | <markit> with ltsp5 I was faster in boot time, but just because i.e. 16.04 kernel was 50MB while now is around 100MB in size
| |
| 01:31 | <map7> you could manually compile the kernel and get it back down to that size
| |
| 01:31 | <markit> oh, I see... nothing can be faster than thin clients
| |
| 01:31 | map7: I don't care do it at every upgrade, fat was never fast
| |
| 01:31 | but I'm wondering if it could be much faster
| |
| 01:32 | I don't see bandwidth saturation, cpu saturation, disk I/O saturation BUT is slow... how is that?
| |
| 01:33 | if you have network transfer that is 10x slower than what should be, of course less data = fater boot/load, but the main problem is "why 10x slower?"
| |
| 01:33 | <map7> did you try zstd compression with the PRE_INITRD_BOTTOM_IMAGE_TO_RAM line?
| |
| 01:33 | <markit> I've 3.8GB image and 2GB client :)
| |
| 01:34 | and is pointless, since of course "local access" (to ram) is fast
| |
| 01:34 | I want to discover and improve the .img access by the clients
| |
| 01:35 | <map7> yeah just thinking we have two problems here, the decompression of the image on the client and the NFS transfer over the squashfs loop mount thing
| |
| 01:39 | zstd image over NFS the blank screen went for 25secs
| |
| 01:39 | zstd in local RAM the blank screen went for 5secs
| |
| 01:39 | only difference was I copied the img into RAM
| |
| 01:46 | <markit> with wireshark I've a lot of warnings regarding nfs "there is some bitmap data left undissected", but don't understand if is a wireshark problem while capturing
| |
| 01:46 | in any case there are a lot of calls as GETATTR or LOOKUP
| |
| 01:47 | <map7> right I've only got a basic understanding of wireshark
| |
| 01:47 | I put an '&' on the end of my 'dd' and it didn't hold up the boot and it's still fast
| |
| 01:47 | <markit> seems that even if the "raw data" transfer is not high, libo does tons of file system requests
| |
| 01:48 | and nfs is slow for that... that remainds me an old, unresolved problem about NFS and Kde with regards to /home
| |
| 01:48 | <map7> could we use a samba mount instead?
| |
| 01:50 | <markit> I've no idea
| |
| 01:53 | <map7> Are you using NFSv4?
| |
| 01:53 | does NFSv4 overcome this limitation?
| |
| 01:53 | <markit> mount says so, but wireshark says V3
| |
| 01:54 | <map7> cat /proc/fs/nfsd/versions
| |
| 01:54 | <markit> in any case, libo load was a matter of 46.000 packets exchanged
| |
| 01:54 | <map7> It shows me that version 3 is enabled, but you can force v4
| |
| 01:54 | <markit> -2 +3 +4 +4.1 +4.2
| |
| 01:54 | <map7> same
| |
| 01:54 | does it choose the lowest when connecting?
| |
| 01:55 | maybe disabling 3,4 & 4.1 will force it to use the latest protocol
| |
| 01:55 | which might be worth testing
| |
| 01:55 | https://wiki.debian.org/NFSServerSetup
| |
| 01:55 | <markit> client "mount" shows vers=4.2 for homes, dont' know how the access is done for the .img
| |
| 02:00 | in general the performance of NFS versions 3, 4 and 4.1 are fairly similar, at least in these tests
| |
| 02:00 | (googling about nfs differences of performance)
| |
| 02:06 | <map7> hmmm, I disabled nfsv3 and now it doesn't boot
| |
| 02:09 | <markit> restarted the nfs server?
| |
| 02:09 | <map7> yes i did
| |
| 02:09 | i've just set it back to v3 and restarted nfs server and it boots again
| |
| 02:10 | so maybe it's forcing a v3 mount for the image
| |
| 02:10 | <markit> also if you change exports, AFAIR you have to issue this command exportfs -a don't know if you change other parameters
| |
| 02:10 | maybe, I've the feeling that without alkisg we are just wasting time
| |
| 02:15 | gdi2k_ has left IRC (gdi2k_!~gdi2k@203.177.136.19, Ping timeout: 264 seconds) | |
| 02:17 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 246 seconds) | |
| 02:18 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 02:29 | gdi2k_ has joined IRC (gdi2k_!~gdi2k@203.177.136.18) | |
| 02:31 | <markit> 3.30 am here, sleep time :) bye map7, let me know if you find anything useful
| |
| 02:31 | markit has left IRC (markit!~marco@mail.ammdomus.it, ) | |
| 04:11 | gdi2k_ has left IRC (gdi2k_!~gdi2k@203.177.136.18, Ping timeout: 250 seconds) | |
| 04:18 | <alkisg> map7: install an OS locally on a client to be able to compare local OS vs LTSP
| |
| 04:19 | Comparing "launching on a quad core client for the first time" with "launching on a 32 core server while home is already cached" isn't really meaningful
| |
| 04:20 | LTSP should be similar to a local installation on a rotational disk
| |
| 04:22 | And of course thins may load apps a few times faster when the server is faster, but the screen updates are thousand of times slower than fats
| |
| 04:22 | !thin-client-deprecation
| |
| 04:22 | <ltspbot> thin-client-deprecation: The new LTSP doesn't support thin clients (remote Xorg), but it does support low-spec netbooted clients with remote desktop (xfreerdp, x2go etc). Read more in https://github.com/ltsp/community/issues/32
| |
| 04:23 | <alkisg> 4 gbps per client isn't really feasible at this point; thin clients will become a good option again when we'll have server hardware that will be able to compress one vp9 stream per client real time
| |
| 04:24 | ...possibly in 10 years or so :)
| |
| 04:24 | <map7> alkisg: Yeah. I managed to get the boot blank screen down from 33seconds to 5 seconds by using the 'dd' command + zstd compression
| |
| 04:24 | <alkisg> map7: is that boot blank screen, or login blank screen?
| |
| 04:25 | <map7> just before the login screen appears
| |
| 04:25 | <alkisg> When you say login, I assume you mean lightdm, right?
| |
| 04:25 | <map7> and instead of 15 seconds to start libreoffice it's now 4seconds
| |
| 04:25 | <alkisg> At that point, you're supposed to be seeing systemd console messages
| |
| 04:25 | <map7> lightdm yes
| |
| 04:25 | <alkisg> Services starting etc, not black
| |
| 04:26 | <map7> I see the services start, then a blank screen, then lightdm
| |
| 04:26 | <alkisg> Which desktop environment are you using?
| |
| 04:26 | Maybe your client is trying to use wayland and fails
| |
| 04:26 | And then falls back to xorg
| |
| 04:26 | <map7> xfce4
| |
| 04:26 | <alkisg> Do you have gdm3 installed? Or just lightdm?
| |
| 04:27 | <map7> just lightdm
| |
| 04:28 | <alkisg> And that's on buster?
| |
| 04:28 | <map7> no that's on bullseye "testing"
| |
| 04:28 | <alkisg> Maybe they switched lightdm to wayland too there
| |
| 04:29 | <map7> I'm about to test buster with the PPA ltsp 20.3 and build a chroot image
| |
| 04:29 | <alkisg> I think you should test local OS
| |
| 04:29 | This will have useful results
| |
| 04:29 | It's a different thing to "try to optimize debian" than "trying to optimize ltsp"
| |
| 04:29 | <map7> with debian 11 bullseye?
| |
| 04:30 | <alkisg> With the same OS that you're trying with LTSP, so yeah
| |
| 04:30 | To compare the same version, not different versions
| |
| 04:30 | If you see that local OS is also slow, then you can have the goal of "optimizing debian", which is unrelated to ltsp
| |
| 04:30 | <map7> on an SSD or rotational disk?
| |
| 04:30 | <alkisg> The best test would be rotational
| |
| 04:31 | SSD would also be useful too, but LTSP is more close to the rotational speed, which is still a valid installation option, debianites would care to optimize it
| |
| 04:31 | E.g. Ubuntu 12.04 booted in 12 secs, while Ubuntu 20.04 boots in 50 secs, in local OS
| |
| 04:31 | So this reflects in LTSP too
| |
| 04:31 | <map7> ok fair enough
| |
| 04:32 | is that recorded from grub menu to login?
| |
| 04:32 | <alkisg> Yes
| |
| 04:34 | zstd should indeed be specified as the default compression, wherever it's supported, but it's only available in the latest OSes like 20.04 and bullseye
| |
| 04:34 | <map7> is there any downside to doing the 'dd to ram' trick?
| |
| 04:34 | <alkisg> Fortnately we can set that in ltsp.conf
| |
| 04:34 | Apart from transferring a lot of GB while the client boots, no
| |
| 04:35 | 33 seconds blank screen sounds like a real problem though, I have a 2 seconds blank screen here before lightdm shows, without using caching
| |
| 04:36 | A local OS installation will prove if that delay is a debian issue or a networking/ltsp issue
| |
| 04:36 | <map7> yes, 'markit' was also having the same problem
| |
| 04:36 | <alkisg> Nah
| |
| 04:36 | I saw marking boot screen, there were no 33 sec delays
| |
| 04:37 | <map7> ok, maybe it was just the delay on starting libreoffice which was the same
| |
| 04:37 | <alkisg> Markit was also trying to optimize, and with my help he got it from 1.40 down to 40 or something, but there were no 33 sec delays involved
| |
| 04:38 | LO needs around 15 secs for first launch here, around the same as local installations
| |
| 04:38 | The second launch is a lot faster, like 2 secs, as it's cached
| |
| 04:39 | (including caching /home*
| |
| 04:39 | echo 3 > /proc/sys/vm/drop_caches both on the server and client can help in some tests
| |
| 04:39 | * alkisg waves, later... :) | |
| 04:40 | <map7> cool thanks
| |
| 05:27 | gdi2k_ has joined IRC (gdi2k_!~gdi2k@203.177.136.19) | |
| 05:41 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 06:11 | gdi2k_ has left IRC (gdi2k_!~gdi2k@203.177.136.19, Ping timeout: 250 seconds) | |
| 06:16 | gdi2k_ has joined IRC (gdi2k_!~gdi2k@203.177.136.18) | |
| 06:17 | <alkisg> Back
| |
| 06:39 | woernie has joined IRC (woernie!~werner@pD9E8BE9E.dip0.t-ipconnect.de) | |
| 07:08 | gdi2k_ has left IRC (gdi2k_!~gdi2k@203.177.136.18, Ping timeout: 246 seconds) | |
| 07:36 | gdi2k_ has joined IRC (gdi2k_!~gdi2k@203.177.136.19) | |
| 08:06 | <Klimm> https://egw.lohn24.de/intern/?page_name=NachrichtenLG&category_id=99&item=1342769
| |
| 10:23 | statler has joined IRC (statler!~Georg@gwrz.lohn24.de) | |
| 10:31 | gdi2k_ has left IRC (gdi2k_!~gdi2k@203.177.136.19, Remote host closed the connection) | |
| 10:42 | shored has left IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi, Read error: Connection reset by peer) | |
| 10:42 | shored has joined IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi) | |
| 10:52 | markit has joined IRC (markit!~marco@mail.ammdomus.it) | |
| 10:54 | <markit> hi map7 :)
| |
| 10:57 | Teridon has joined IRC (Teridon!~Teridon@dragon.teridon.com) | |
| 11:02 | <markit> hi alkisg, yesterday me and map7 have tried to understand the ltsp bottlenecks, but we have a lot of dubs and found no solution :)
| |
| 11:02 | <alkisg> markit: see irclogs, I already commented a bit
| |
| 11:02 | irclogs.ltsp.org
| |
| 11:02 | <markit> thanks
| |
| 11:11 | alkisg: libo starts in 5 seconds in my virtual server (on ssd), but 15" in the client
| |
| 11:11 | but what surprises me is that there seem not to be any "saturation" during the process
| |
| 11:11 | i.e. if I reboot client and re-load libo, server has cached it so no disk I/O, CPU on server and client side don't reach 100% (none of the 4 cores)
| |
| 11:11 | and seems that bandwidth (iftop) peackes at 70Mb/s, while connection is at 1Gb
| |
| 11:11 | seems like nfs is really "lazy" in sending the image
| |
| 11:11 | markit has left IRC (markit!~marco@mail.ammdomus.it, Remote host closed the connection) | |
| 11:11 | markit_2 has joined IRC (markit_2!~marco@mail.ammdomus.it) | |
| 11:11 | markit_2 is now known as markit | |
| 11:11 | <alkisg> markit: it's request/receive/process loops
| |
| 11:12 | If it's cached locally, e.g. on the second run, then it's faster
| |
| 11:12 | <markit> sorry, disconnected... don't know what was sent in this channel
| |
| 11:12 | <alkisg> Since it involves both net AND cpu, and they don't run in parallel, then none of them is maxed out
| |
| 11:12 | It's normal, it also happens with ssd and rotational
| |
| 11:13 | In your server sdd, it's already cached as well, so you're using ram, not disk
| |
| 11:13 | And of course ssd is faster than gigabit lan, while rotational is about the same
| |
| 11:13 | So to compare apples with apples, and not oranges, try to compare libreoffice speed in local installation with rotational disk with ltsp
| |
| 11:14 | That's what we expect to have the same speed. If it doesn't, then that needs solving
| |
| 11:14 | But if LO needs 15 locally on rotational disk (which it does here), then there's not much to optimize
| |
| 11:14 | To reach SSD speeds with LAN, you'd need 10 gbps cards, not 1 gbps...
| |
| 11:15 | <markit> I don't get the reasoning, sorry. If I've 1Gb/s lan I have around 80MB/s, since libo file is 80MB, should take 1 second to "travel" from server to client
| |
| 11:15 | <alkisg> Only if there's no CPU involved
| |
| 11:15 | You're thinking "cp"
| |
| 11:15 | It's not
| |
| 11:15 | <markit> let's say that is a little slower... 5 seconds? not 15!
| |
| 11:16 | but cpu is not saturated at all in both sides
| |
| 11:16 | <alkisg> "fetch me that file. OK, waiting. Now i'll process it and make a dbus call. OK now fetch me that other file. Now I want that little sector there"
| |
| 11:16 | All processes EXCEPT benchmarks/cp etc work that way
| |
| 11:17 | They ask a few things from disk, then they do some CPU tasks, so they don't max out either the disk or the cpu
| |
| 11:17 | Because they don't work in parallel. They wait for result from disk, then use cpu, and disk just waits until cpu is finished processing
| |
| 11:17 | That's why "readahead" was developed, to try to predict what the next disk call will be, and fetch it while CPU is processing
| |
| 11:18 | And of course readahead only succeeds in 10% of the cases, it can't predict the future disk requests properly
| |
| 11:18 | You need example?
| |
| 11:18 | loop: (read icon from disk, draw icon to screen)
| |
| 11:19 | This doesn't max out neither disk nor CPU
| |
| 11:20 | IF the libreoffice programmers did that though:
| |
| 11:20 | loop: (read icon from disk, receive it *asynchronously* and *then* draw it), that would max out one of them
| |
| 11:20 | This is very usual in network programming, doing CPU tasks WHEN disk/net data is received, but it's not very usual in normal programming, as it's more difficult
| |
| 11:24 | <markit> I see, but in local disk I see "spikes" and high load of cpu or I/O when I run big programs, while with LTSP I see only slow load, that is surprising
| |
| 11:25 | <alkisg> One net/cpu loop needs e.g. 1 msec. For the spike to register, you need e.g. 10 msec. So, they'll never show up as net will stop the cpu from maxing out for 10 msec
| |
| 11:25 | This is the same even if you use SSD but you clear the cache
| |
| 11:25 | Remember, you are not clearing the cache, so you're not using SSD, you're measuring RAM cache speed, which needs only CPU
| |
| 11:26 | Boot without VM, in a local disk, even SSD
| |
| 11:26 | Then run echo 3 > /proc/sys/vm/drop_caches
| |
| 11:26 | Then run libreoffice
| |
| 11:26 | <markit> here is fast
| |
| 11:26 | <alkisg> And compare with that :)
| |
| 11:26 | <markit> 5 seconds as well, on ssd
| |
| 11:26 | <alkisg> With VM?
| |
| 11:26 | Because VM caches the data
| |
| 11:26 | <markit> no, my computer
| |
| 11:27 | <alkisg> OK do vnc for me to see
| |
| 11:27 | !vnc-edide
| |
| 11:27 | <ltspbot> vnc-edide: To share your screen with me, open Epoptes → Help menu → Remote support → Host: srv1-dide.ioa.sch.gr, and click the Connect button
| |
| 11:27 | <alkisg> or:
| |
| 11:27 | !vnc-dide
| |
| 11:27 | <ltspbot> vnc-dide: To share your screen with me, run this: sudo apt-get --yes install x11vnc; x11vnc -connect srv1-dide.ioa.sch.gr - this is a reverse connection, it doesn't need port forwarding etc.
| |
| 11:27 | <markit> splash screen after 1 second, and libo after 3
| |
| 11:27 | <alkisg> OK, let's see it together
| |
| 11:27 | <markit> I've a 4K screen
| |
| 11:27 | <alkisg> I don't mnid
| |
| 11:28 | *mind
| |
| 11:28 | <markit> I'm on debian sid, do I have to install epoptes then?
| |
| 11:28 | <alkisg> No do the second variant, with just x11vnc
| |
| 11:28 | !vnc-dide
| |
| 11:28 | <ltspbot> vnc-dide: To share your screen with me, run this: sudo apt-get --yes install x11vnc; x11vnc -connect srv1-dide.ioa.sch.gr - this is a reverse connection, it doesn't need port forwarding etc.
| |
| 11:29 | <alkisg> markit: it disconnected
| |
| 11:29 | run it again
| |
| 11:30 | <markit> ok
| |
| 11:31 | <alkisg> Meh you have the broken old x11vnc
| |
| 11:31 | No
| |
| 11:31 | Hrm
| |
| 11:32 | markit: 9 seconds
| |
| 11:32 | And didn't max out anything
| |
| 11:33 | What you were counting is the RAM/cache speed
| |
| 11:33 | Not disk speed. As it was already cached in RAM
| |
| 11:34 | 9 sec without cache, 2 sec with cache
| |
| 11:35 | When only cache is used, then only CPU is used, that's why it maxes out CPU
| |
| 11:35 | This is the same in LTSP too, if you cache everything, it maxes CPU and loads in 2 secs
| |
| 11:35 | <markit> I dropped the cache, maybe I missed the "sync"
| |
| 11:36 | yes, but if SERVER caches LiBo, and then client runs it, seems to me that should run much faster
| |
| 11:36 | <alkisg> Nope. It's the network that's "slow", we don't care at all if the server has cached it or not
| |
| 11:36 | Server disk speed = 500 MB/sec = 5 gbps. Network speed = 1 gbps, much less than the disk speed
| |
| 11:37 | <markit> ok, and no better protocol or whatever to make it run faster?
| |
| 11:37 | <alkisg> To cache it in the client
| |
| 11:37 | <markit> let me test lan speed of the VM, just to be sure
| |
| 11:37 | of course :)
| |
| 11:37 | <alkisg> That's what map7 does, it caches everything with "dd" when the client boots
| |
| 11:38 | So if everything is in RAM, then everything is fast, except for /home
| |
| 11:38 | And if one wants to be even faster, he can cache (read) /home/username as well
| |
| 11:38 | <markit> I've a 4GB image and we boot clients every lesson
| |
| 11:38 | btw, epoptes says speed is 2Gb/s since I've 2 lan bounded
| |
| 11:39 | (round robin)
| |
| 11:39 | but sure, if local is 9 seconds, client 15 sounds good
| |
| 11:40 | <alkisg> local with rotational is more than 15 ;)
| |
| 11:40 | It's only ssd that's 9
| |
| 11:40 | <markit> ok, btw default 8 nfs daemond are enough for 25 clients?
| |
| 11:40 | <alkisg> 2 gb to many clients, not one client, right?
| |
| 11:41 | <markit> 2.5 to the single client, the "nic" is virtual
| |
| 11:41 | <alkisg> The clients use bonds too?
| |
| 11:41 | Ah, virtual client, ok
| |
| 11:41 | Faith has joined IRC (Faith!~Paty_@unaffiliated/faith) | |
| 11:41 | <markit> to be fair, should "virtually" run at 10Gbs, but maybe there is some setup to do
| |
| 11:42 | <alkisg> In any case, waiting for 1 min for the pc to boot, and 10 sec for soffice or firefox to run, sound rather acceptable to me
| |
| 11:42 | So I don't give it more thought than that
| |
| 11:42 | <markit> btw, I've always considered vnc a very slow, laggish protocol, how can you work in my 4K screen without issues?
| |
| 11:42 | <alkisg> IRC and terminal needs minimal bandwidth. I'm not trying to browse or watch youtube :)
| |
| 11:43 | I see one frame per 3 seconds :)
| |
| 11:43 | And that's only because it's a small window there
| |
| 11:43 | Full screen, I'd see one frame per minute :D
| |
| 11:44 | <markit> I see, sure
| |
| 11:44 | ok, I had big hopes that we could have made ltsp run much faster just discovering a simple bottleneck :( Maybe next time ;P
| |
| 11:45 | <alkisg> Haha, you'll need to make libreoffice launch in 5 seconds in rotational (which means a whole lot of optimizations in the libreoffice, kernel, libc code) and then ltsp will get them too :)
| |
| 11:46 | OK lunch time, see you later guys
| |
| 11:46 | <markit> also "decompressing" inidrd.img takes 10 seconds
| |
| 11:46 | ok, thanks a lot, see you :)
| |
| 11:46 | <alkisg> Decompression time is the same with or without ltsp; hopefully they'll switch to zstd which is better
| |
| 11:47 | <markit> I'll have a loot at ltsp.conf to put zstd as default for ltsp imgage
| |
| 12:02 | markit has left IRC (markit!~marco@mail.ammdomus.it, ) | |
| 12:16 | Mikaela has left IRC (Mikaela!~Mikaela@unaffiliated/mikaela, Quit: Mikaela) | |
| 12:17 | Mikaela has joined IRC (Mikaela!~Mikaela@unaffiliated/mikaela) | |
| 12:52 | Teridon1 has joined IRC (Teridon1!~Teridon@dragon.teridon.com) | |
| 12:56 | Teridon has left IRC (Teridon!~Teridon@dragon.teridon.com, Ping timeout: 250 seconds) | |
| 13:28 | sunweaver has joined IRC (sunweaver!~sunweaver@fylgja.das-netzwerkteam.de) | |
| 13:28 | <sunweaver> alkisg: I have a question regarding LTSP
| |
| 13:29 | but first question: are you and your loved ones well?
| |
| 13:29 | Here comes the question... Everyone is crazy about homeoffice these days.
| |
| 13:29 | I have a running LTSP next generation installation running and one customer that boots over PXE.
| |
| 13:30 | Now they ask for conversion of the netboot images into ISO images to be booted from a USB stick.
| |
| 13:30 | Is that something that has been done before with an LTSP image?
| |
| 13:30 | If no, do you have some concept in mind to make that happen?
| |
| 13:31 | The customer is willing to pay upstream development (me contributing to LTSP) for that.
| |
| 13:34 | <MWALTERS> would remoting into the LTSP server be a viable alternative?
| |
| 13:34 | (x2go)
| |
| 13:34 | <sunweaver> MWALTERS: nope. The user shall RDP into a Windows Terminal Server.
| |
| 13:35 | MWALTERS: I modified the LTSP image in a way that it acts as a X2Go Thinclient, running X2Go, but only with DirectRDP sessions configured in X2Go Client
| |
| 13:35 | * sunweaver is from X2Go upstream btw. | |
| 13:35 | <MWALTERS> So you're using LTSP as a launchpad to have them RDP intoa windows client? Why not ask them to RDP straight into the Terminal server?
| |
| 13:36 | RDP gateway seems like the correct answer in this situation, doesn't it?
| |
| 13:36 | s/windows client/windows server
| |
| 13:37 | <sunweaver> basically yes, but the customer does not want to have their own devices in the company's network.
| |
| 13:38 | basically, what you say is what I told the customer, too.
| |
| 13:38 | <MWALTERS> Gotcha ;)
| |
| 13:38 | <sunweaver> But they don't want to see the employees' Windows machines on their network.
| |
| 13:38 | so, this is where the LTSP boot stick comes into play.
| |
| 13:38 | <MWALTERS> I mean... they don't have to. I'm sure you also explained that.
| |
| 13:38 | <sunweaver> sure, I did.
| |
| 13:39 | <MWALTERS> It seems like you already thought of reasonable alternatives. I'll defer to the LTSP folks from here :)
| |
| 13:39 | <sunweaver> thanks!
| |
| 13:39 | <MWALTERS> Handing out USB drives and trying to explain how to boot from them to end-users sounds... tiring. ;)
| |
| 13:40 | <sunweaver> MWALTERS: that won't be my job. And many of them are used to that, but with IGEL tc images on USB stick. They are to be replaced now.
| |
| 13:40 | (it will be the site admin's job...)
| |
| 13:40 | <MWALTERS> Give that person a raise :)
| |
| 13:40 | <sunweaver> not my call ;-)
| |
| 13:47 | alkisg: ^^^ my question is still open... Hope to hear from you soon.
| |
| 14:16 | shored has left IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi, Read error: Connection reset by peer) | |
| 14:18 | shored has joined IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi) | |
| 14:22 | <alkisg> Back, reading...
| |
| 14:24 | !local-boot
| |
| 14:24 | <ltspbot> local-boot: If you want LTSP fat clients on a low-speed network, you can put i386.img on e.g. C:\Boot\LTSP\i386.img and use this command line in pxelinux.cfg: APPEND ro initrd=ltsp/i386/initrd.img init=/sbin/init-ltsp root=/dev/sda1 rootflags=ro loop=/Boot/LTSP/i386.img; IPAPPEND 3
| |
| 14:24 | <alkisg> !liveusb
| |
| 14:24 | <ltspbot> Error: "liveusb" is not a valid command.
| |
| 14:25 | <alkisg> !learn liveusb as My attempt at a multiboot USB stick: https://github.com/alkisg/liveusb
| |
| 14:25 | <ltspbot> The operation succeeded.
| |
| 14:25 | <alkisg> sunweaver: you can tell grub to boot from inside a squashfs, and you can use liveusb in order to have a USB drive based on grub that is bootable under BIOS or UEFI
| |
| 14:26 | Since you don't need any server connections for /home or users or authentication, I don't think any changes to LTSP are needed at all...
| |
| 14:27 | Btw, I'm currently working on booting ltsp.img + windows.vmdk from a USB stick, for a client ;)
| |
| 14:28 | (i.e. VM windows on a stick)
| |
| 14:38 | (btw I hope you and yours are fine too; but from what I'm hearing, Germany is so organized that's not afraid from any viruses :))
| |
| 15:31 | <sunweaver> alkisg: thanks a lot for feedback!
| |
| 15:32 | <alkisg> np, ping me if anything's needed
| |
| 15:32 | <sunweaver> Nice! Will look into this tonight.
| |
| 15:33 | German government seems very organized, but many people here are reluctant to "obey". Other than in China, the German approach is a democratic approach. But many people here seem resistant against good advice.
| |
| 15:33 | We (family) have self-quarantined ourselves and only leave home for the absolute necessary.
| |
| 15:34 | I am looking forward to playing with liveusb.
| |
| 15:34 | (is it something that should go to Debian?)
| |
| 15:34 | <alkisg> Nah
| |
| 15:34 | Just an image with both grub-pc and grub-efi, and an easy method to dd it
| |
| 15:35 | so that it works under secure boot, plain uefi, or bios
| |
| 15:35 | ...by just dropping .iso in a folder... and also supports windows setup... I give it to teachers here to make it easier for them to format standalone PCs
| |
| 16:02 | shored has left IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi, Read error: Connection reset by peer) | |
| 16:03 | shored has joined IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi) | |
| 16:14 | shored has left IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi, Read error: Connection reset by peer) | |
| 16:15 | shored has joined IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi) | |
| 16:18 | shored has left IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi, Read error: Connection reset by peer) | |
| 16:18 | shored has joined IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi) | |
| 16:18 | shored has left IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi, Read error: Connection reset by peer) | |
| 16:19 | shored has joined IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi) | |
| 16:20 | shored has left IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi, Max SendQ exceeded) | |
| 16:21 | shored has joined IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi) | |
| 16:41 | statler has left IRC (statler!~Georg@gwrz.lohn24.de) | |
| 16:43 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 18:03 | Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Remote host closed the connection) | |
| 18:04 | Faith has joined IRC (Faith!~Paty_@2001:12d0:2080::231:49) | |
| 18:23 | Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Remote host closed the connection) | |
| 18:25 | Faith has joined IRC (Faith!~Paty_@unaffiliated/faith) | |
| 19:04 | Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Remote host closed the connection) | |
| 19:05 | Faith has joined IRC (Faith!~Paty_@2001:12d0:2080::231:49) | |
| 19:36 | woernie has left IRC (woernie!~werner@pD9E8BE9E.dip0.t-ipconnect.de, Ping timeout: 250 seconds) | |
| 19:36 | woernie has joined IRC (woernie!~werner@pD9E8BE9E.dip0.t-ipconnect.de) | |
| 19:59 | quinox has left IRC (quinox!~quinox@ghost.qtea.nl, Quit: WeeChat 2.6) | |
| 20:02 | quinox has joined IRC (quinox!~quinox@ghost.qtea.nl) | |
| 20:41 | shored has left IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi, Read error: Connection reset by peer) | |
| 20:41 | Teridon1 has left IRC (Teridon1!~Teridon@dragon.teridon.com, Remote host closed the connection) | |
| 20:43 | shored has joined IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi) | |
| 20:48 | shored has left IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi, Read error: Connection reset by peer) | |
| 20:48 | shored has joined IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi) | |
| 20:54 | woernie has left IRC (woernie!~werner@pD9E8BE9E.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 21:30 | GodFather has joined IRC (GodFather!~rcc@d53-64-7-141.nap.wideopenwest.com) | |
| 21:34 | GodFather has left IRC (GodFather!~rcc@d53-64-7-141.nap.wideopenwest.com, Ping timeout: 240 seconds) | |
| 21:47 | shored has left IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi, Read error: Connection reset by peer) | |
| 21:48 | shored has joined IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi) | |
| 22:00 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 246 seconds) | |
| 22:12 | Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving) | |
| 22:34 | GodFather has joined IRC (GodFather!~rcc@d53-64-7-141.nap.wideopenwest.com) | |
| 22:57 | GodFather has left IRC (GodFather!~rcc@d53-64-7-141.nap.wideopenwest.com, Ping timeout: 240 seconds) | |
| 22:59 | markit has joined IRC (markit!~marco@mail.ammdomus.it) | |
| 23:41 | GodFather has joined IRC (GodFather!~rcc@d53-64-7-141.nap.wideopenwest.com) | |