IRC chat logs for #ltsp on irc.libera.chat (webchat)


Channel log from 16 June 2017   (all times are UTC)

01:03lucascastro has joined IRC (lucascastro!~lucas@170.233.149.62)
01:56mark___ has left IRC (mark___!826921d2@gateway/web/freenode/ip.130.105.33.210, Quit: Page closed)
02:07||cw has left IRC (||cw!~chrisw@unaffiliated/cw/x-1182934, Quit: Do not follow the null pointer, for therein lies ma&^%#___)
02:15||cw has joined IRC (||cw!~chrisw@97-87-138-138.dhcp.stls.mo.charter.com)
02:16||cw has joined IRC (||cw!~chrisw@unaffiliated/cw/x-1182934)
02:31lucascastro has left IRC (lucascastro!~lucas@170.233.149.62, Remote host closed the connection)
02:31lucas_ has joined IRC (lucas_!~lucas@170.233.149.60)
03:49cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
05:04alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 255 seconds)
05:14Statler has joined IRC (Statler!~Georg@p579FFF05.dip0.t-ipconnect.de)
05:22ricotz has joined IRC (ricotz!~ricotz@p5B2A85F3.dip0.t-ipconnect.de)
05:22ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
06:13Eric3 has joined IRC (Eric3!~eric@sdi.iut-valence.fr)
06:31aspd has joined IRC (aspd!02576fa3@gateway/web/freenode/ip.2.87.111.163)
06:31Mark__ has joined IRC (Mark__!826921d2@gateway/web/freenode/ip.130.105.33.210)
06:32aspd has left IRC (aspd!02576fa3@gateway/web/freenode/ip.2.87.111.163, Client Quit)
06:32
<Mark__>
Hi can I use LTSP in gaming? like in cybercafe?
06:32
is this possible?
06:37
<bcg>
Mark__: I'm running ltsp on rhel7(-ish). I have my own rpms for that (will be available soon).
06:38
<Mark__>
wow nice
06:38
<bcg>
I'm been running it on rhel6 for years.
06:39
<Mark__>
hows the performance?
06:40
<bcg>
What can I say? It depends on your server and network. I'm mostly running localapps-firefox etc on it.
06:40
<Mark__>
ok ill be waiting for the release thanks
06:42
<bcg>
I will not try to push it to epel anytime soon, but the sources and maybe prebuilt rpms will be available.
06:46Mark__ has left IRC (Mark__!826921d2@gateway/web/freenode/ip.130.105.33.210, Quit: Page closed)
06:49johnsmith has joined IRC (johnsmith!7ab0043e@gateway/web/freenode/ip.122.176.4.62)
06:52kjackal_ has joined IRC (kjackal_!~quassel@ppp-94-66-56-239.home.otenet.gr)
06:53johnsmith has left IRC (johnsmith!7ab0043e@gateway/web/freenode/ip.122.176.4.62, Ping timeout: 260 seconds)
07:01aspd has joined IRC (aspd!02576fa3@gateway/web/freenode/ip.2.87.111.163)
07:04alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
07:39Eric3 has left IRC (Eric3!~eric@sdi.iut-valence.fr, Ping timeout: 240 seconds)
07:46v4169sgr has joined IRC (v4169sgr!~andrew@235.204.187.81.in-addr.arpa)
07:47
<v4169sgr>
Hi All, just a silly question, is there a way of using LTSP with masquerading to run DHCP on a router box with chrooting, to support different thin client architectures from the server? Is this method clearly documented, step by step?
07:48
<alkisg>
v4169sgr: errm that's like 3 confused questions into 1
07:48
It's easy to support different thin client architectures, for example see the raspberrypi case:
07:49
!rasbperrypi
07:49
<ltsp>
I do not know about 'rasbperrypi', but I do know about these similar topics: 'raspberrypi'
07:49
<alkisg>
!raspberrypi
07:49
<ltsp>
raspberrypi: (#1) Ubuntu/LTSP on Pi 2: https://help.ubuntu.com/community/UbuntuLTSP/RaspberryPi, or (#2) Debian/LTSP (with raspbian chroot) on Pi: http://cascadia.debian.net/trenza/Documentation/raspberrypi-ltsp-howto/, or (#3) unofficial Ubuntu/LTSP (with raspbian chroot) on Pi: http://pinet.org.uk/
07:49
<alkisg>
#1 there supports i386 and armfh
07:49
*armhf
07:49
Now, that part is completely unrelated to masquerading, so I'm not sure why you mixed those questions...
07:49
<v4169sgr>
ok, thanks, it is just simply i686 server and i386 clients, but running DHCP on the router is mandatory
07:50
<alkisg>
Why don't you just use i386 for all of them?
07:50
That's what thousands of schools do here...
07:50
!ltsp-pnp
07:50
<ltsp>
ltsp-pnp: ltsp-pnp is an alternative (upstream) method to maintain LTSP installations for thin and fat clients that doesn't involve chroots: https://help.ubuntu.com/community/UbuntuLTSP/ltsp-pnp
07:50
<v4169sgr>
I am indeed, but wondering if i386 on the server is too high a price to pay
07:50
<alkisg>
So, if you follow that page, you get an easy ltsp setup with your router as the dhcp server, which supports both i386 and amd64
07:50
No chroots involved at all
07:51
<v4169sgr>
yes, actually that is what I am running now
07:51
and it works well
07:51
BUT
07:51
<alkisg>
OK, what price are you talking about? 64bit is wasting more ram for 10% more performance, generally not worth it
07:51
<v4169sgr>
there are significant performance IO related issues on the server, to do with how i386 handles caching
07:52
<alkisg>
Do you have any documentation on that? I've never seen it
07:52
<v4169sgr>
I have semi effective workarounds now, but they are only marginally effective
07:52
and don't deal with the issue
07:52
so am wondering about biting the bullet and reinstalling i686
07:52
but need a documented method
07:52
<alkisg>
It's strange that I haven't seen such an issue in thousands of installations. Could you elaborate?
07:52
<v4169sgr>
so I won't be left high and dry :)
07:52
<alkisg>
Some URL or some more documentation?
07:53
Are you talking about disk peformance, for example? How do you measure it?
07:54
E.g. hdparm reports the same speed for disks under 32 or 64bit installations
07:54
<v4169sgr>
https://ubuntuforums.org/showthread.php?t=2363087&highlight=
07:54
no, defo not storage perf
07:54
is caching
07:55
no easy answer AFAIK to that
07:55
basically any form of large scale file copying is affected
07:55
or indeed running any form of intensive IO task
07:55
even running a browser for a period
07:55
<alkisg>
So you're the only one that seen the issue and the only one that commented on it?
07:56
It sounds like an isolated incident then, similar to what I just reported there: https://bugs.launchpad.net/ubuntu/+source/linux-hwe/+bug/1698118
07:56
<v4169sgr>
read the thread, there are apparently others with similar issues
07:56
that's where I saw the info about work arounds
07:57
<alkisg>
Could you read my bug report, which is shorter, while I read your forum posts?
07:57
Are you talking about the same thing there?
07:59
<v4169sgr>
Symptoms are definitely similar, would say it IS related to caching, as workaround to clear the cache provides temporary relief, after operation completes
07:59
was the install you reported on 32 bit?
07:59
<alkisg>
Yes, but that's just a detail
08:00
There's math behind it, that depend on ram, bus size etc
08:00
So, it happens with 32bit + 16 ram, it doesn't happen with 32bit + 8 ram,
08:00
and it could happen with 64bit + 8 ram
08:00
<v4169sgr>
what about 64 bit + 16 GB ram?
08:00
<alkisg>
Haven't tested. It might work by luck.
08:00
Its not a solution, just a combination that happened to work
08:01
So I don't think 64 bit is superior there at all
08:01
<v4169sgr>
Do me a favour
08:02
try runningsync && echo "3" | tee /proc/sys/vm/drop_caches
08:02
sync && echo "3" | tee /proc/sys/vm/drop_caches
08:02
on the affected server
08:02
you reported
08:02
after the IO peration
08:02
operation
08:02
<alkisg>
I think I tried it many times in the past, but I'll try it again when it happens
08:02
<v4169sgr>
and see if it makes a difference
08:02
I think it should
08:02
<alkisg>
I've given access to the box, to an ubuntu-kernel developer
08:02
He got the metadata he needed and he'll debug this locally
08:03
<v4169sgr>
ok, but is worth trying
08:03
to see if we genuinely have the same issue
08:03
<alkisg>
He reports that it's a semi-known problem, that noone knows how to properly solve, so they play with little changes in the config
08:03
OK, you can test with mem=8G in the cmdline too
08:03
This bypasses the issue here
08:03
Which mobo do you have?
08:07
<v4169sgr>
Asus P8H77-V LE
08:07
not bleeding edge by any means lol
08:07
and 16 GB RAM
08:07
<alkisg>
That's the code he says is to blame: http://elixir.free-electrons.com/linux/latest/source/mm/page-writeback.c
08:07
16 GB RAM was common to all the cases I've seen it
08:07
Although, I haven't tested with more...
08:08
<v4169sgr>
What does mem=8G do? Sorry for the silly question :)
08:09
<alkisg>
It tells the kernel to limit your memory to 8GB
08:09
So your system no longer has 16G but 8
08:09
And then it runs fine
08:09
<v4169sgr>
Would 12 work too?
08:10
And is this a GRUB option we are talking about?
08:10
have to say this issue remains the major limiting factor in my install atm
08:10
it is most likely to affect user experience on a day to day basis
08:11
and I put in 16 GB RAM to avoid capacity issues when 3 users were all using their thin clients
08:11
as I was seeing previously using 12.04 64 bit and 8 GB RAM
08:11aspd has joined IRC (aspd!02576fa3@gateway/web/freenode/ip.2.87.111.163)
08:13
<v4169sgr>
According to this link
08:13
https://unix.stackexchange.com/questions/94079/massive-unpredictable-i-o-performance-drop-in-linux
08:13
<aspd>
alkisg: Καλημέρα. Έχεις χρόνο να σβήσεις το virt-manager κτλ από τον δικό μου υπολογιστή;
08:13
<v4169sgr>
Last Update: After more investigation I've found out that number of files in the cache was triggering the problem. It was trashing the disks while trying to commit many small files back to the disk. Since I was using the system for ten years, I've took the plunge and reinstalled with 64 bit Debian. Now it's working smoothly. It was probably a side effect of ten years of upgrading with finding limits of 32 bit operating system.
08:13
<alkisg>
v4169sgr: 12 worked for me for a bit more load, but after a lot of load, it happened again
08:13
aspd: είσαι στο αγγλικό κανάλι πάλι, έλα στο ελληνικό: /join #ts.sch.gr
08:15
v4169sgr: I'll test more with dropping the cache, but I dont think it made a difference in my case. I'm not sure I remember well though.
08:15
Also, I think I was able to reproduce it with plain "dd", without ltsp-update-image or copying a lot of files; just with 1 large file
08:15
Again not sure about that though, it was months ago
08:15
<v4169sgr>
yes, I was able to reproduce using file copies to a USB too
08:16
and just simply (a) running unity DE for 24 hours staying logged in, and (b) trying to use google maps on chromium
08:16
and (c) using firefox for an extended period
08:17
impact: system was still usable, just VERY slow
08:17
<alkisg>
Have you tested if 64bit fixes the issue?
08:17
<v4169sgr>
until whatever task was exited, and the cache dropped
08:17
<alkisg>
E.g. with a live cd?
08:17
<v4169sgr>
then perf was restored just as though the box was rebooted
08:18Statler has left IRC (Statler!~Georg@p579FFF05.dip0.t-ipconnect.de, Remote host closed the connection)
08:19
<v4169sgr>
I can try, probably over the weekend, as system in use right now :)
08:32aspd has left IRC (aspd!02576fa3@gateway/web/freenode/ip.2.87.111.163, Quit: Page closed)
08:38mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk)
08:51ogra_ is now known as ogra
08:51ogra has joined IRC (ogra!~ogra_@ubuntu/member/ogra)
08:56Statler has joined IRC (Statler!~Georg@mail.lohn24.de)
09:12forum has joined IRC (forum!~Thunderbi@194-96-63-21.adsl.highway.telekom.at)
09:17brendon_ has joined IRC (brendon_!c4d2ae61@gateway/web/freenode/ip.196.210.174.97)
09:19brendon_ has left IRC (brendon_!c4d2ae61@gateway/web/freenode/ip.196.210.174.97, Client Quit)
09:48
<alkisg>
v4169sgr: dropping the caches seems to help; I'll include that to the bug report. I'll also test with better methods like those mentioned in https://unix.stackexchange.com/questions/253816/restrict-size-of-buffer-cache-in-linux.
09:49
I'm also preparing a one-liner test case, to make things simpler to reproduce...
09:53Eric3 has joined IRC (Eric3!~eric@sdi.iut-valence.fr)
10:13markus_e92 has left IRC (markus_e92!~markus_e9@91-115-158-50.adsl.highway.telekom.at, Ping timeout: 255 seconds)
10:14markus_e92 has joined IRC (markus_e92!~markus_e9@80-121-120-140.adsl.highway.telekom.at)
10:22lucas_ has left IRC (lucas_!~lucas@170.233.149.60, Remote host closed the connection)
10:24
<v4169sgr>
Thanks alkisg, and well done :) I do hope that your kernel developer friend will find the additional information useful, as it would seem caching does have something to do with it. I am definitely going to test a live CD run of 64 bit 16.04 over the weekend.
10:25forum has left IRC (forum!~Thunderbi@194-96-63-21.adsl.highway.telekom.at, Ping timeout: 260 seconds)
10:25
<v4169sgr>
but of course it is better to fix the issue and remain in 32 bit with a clean well supported line to LTSP-PNP if we can :)
10:49forum has joined IRC (forum!~Thunderbi@194-96-63-21.adsl.highway.telekom.at)
10:56forum has left IRC (forum!~Thunderbi@194-96-63-21.adsl.highway.telekom.at, Ping timeout: 240 seconds)
10:58Eric3 has left IRC (Eric3!~eric@sdi.iut-valence.fr, Ping timeout: 240 seconds)
11:07forum has joined IRC (forum!~Thunderbi@194-96-63-21.adsl.highway.telekom.at)
11:10lucascastro has joined IRC (lucascastro!~lucas@131.255.227.138)
12:01forum has left IRC (forum!~Thunderbi@194-96-63-21.adsl.highway.telekom.at, Remote host closed the connection)
12:01forum has joined IRC (forum!~Thunderbi@194-96-63-21.adsl.highway.telekom.at)
12:08Eric3 has joined IRC (Eric3!~eric@sdi.iut-valence.fr)
12:30v4169sgr has left IRC (v4169sgr!~andrew@235.204.187.81.in-addr.arpa)
12:44forum has left IRC (forum!~Thunderbi@194-96-63-21.adsl.highway.telekom.at, Ping timeout: 260 seconds)
12:46
<bcg>
In ldm's src/plugins/*/Makefile.am you use "ldmplugdir = $(libdir)/ldm/". It should be libexecdir as it is in src/Makefile.am.
12:46
There are few other things too, so I'll create my own repo.
12:47
Or src/Makefile.am should use libdir, whatever you prefer?
12:48
libexecdir = /usr/libexec, libdir = /usr/lib64
12:51
I think it should be libdir.
12:58mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving)
13:54lucascastro has left IRC (lucascastro!~lucas@131.255.227.138, Read error: Connection reset by peer)
13:55lucascastro has joined IRC (lucascastro!~lucas@131.255.227.138)
14:07
<bcg>
alkisg: committed and pushed to ldm-rhel7.
14:16alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Read error: Connection reset by peer)
14:18forum has joined IRC (forum!~Thunderbi@194-96-63-21.adsl.highway.telekom.at)
14:19kjackal_ has left IRC (kjackal_!~quassel@ppp-94-66-56-239.home.otenet.gr, Read error: Connection reset by peer)
16:00forum has left IRC (forum!~Thunderbi@194-96-63-21.adsl.highway.telekom.at, Remote host closed the connection)
16:00forum has joined IRC (forum!~Thunderbi@194-96-63-21.adsl.highway.telekom.at)
16:00Freejack has left IRC (Freejack!~quassel@unaffiliated/freejack, Quit: No Ping reply in 180 seconds.)
16:02Freejack has joined IRC (Freejack!~quassel@unaffiliated/freejack)
16:22Eric3 has left IRC (Eric3!~eric@sdi.iut-valence.fr, Ping timeout: 246 seconds)
16:32Eric3 has joined IRC (Eric3!~eric@sdi.iut-valence.fr)
16:36forum has left IRC (forum!~Thunderbi@194-96-63-21.adsl.highway.telekom.at, Ping timeout: 246 seconds)
16:36Eric3 has left IRC (Eric3!~eric@sdi.iut-valence.fr, Ping timeout: 255 seconds)
16:40jgee has joined IRC (jgee!~jgee@200.118.140.142)
16:42vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
17:25forum has joined IRC (forum!~Thunderbi@194-96-63-21.adsl.highway.telekom.at)
17:26forum has joined IRC (forum!~Thunderbi@194-96-63-21.adsl.highway.telekom.at)
17:32forum has left IRC (forum!~Thunderbi@194-96-63-21.adsl.highway.telekom.at, Quit: forum)
17:47markus_e92 has left IRC (markus_e92!~markus_e9@80-121-120-140.adsl.highway.telekom.at, Ping timeout: 240 seconds)
17:51markus_e92 has joined IRC (markus_e92!~markus_e9@80-121-120-140.adsl.highway.telekom.at)
18:08vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
18:14vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
18:33gidarakos has joined IRC (gidarakos!59d2e2ad@gateway/web/freenode/ip.89.210.226.173)
18:41gidarakos has left IRC (gidarakos!59d2e2ad@gateway/web/freenode/ip.89.210.226.173, Quit: Page closed)
18:59alexxtasi[m] has left IRC (alexxtasi[m]!alexxtasim@gateway/shell/matrix.org/x-sghmszqszklenrht, Ping timeout: 264 seconds)
19:17Statler has left IRC (Statler!~Georg@mail.lohn24.de, Remote host closed the connection)
19:55Freejack has left IRC (Freejack!~quassel@unaffiliated/freejack, Ping timeout: 268 seconds)
19:56Freejack has joined IRC (Freejack!~quassel@unaffiliated/freejack)
19:57vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
20:40alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
20:50
<alkisg>
bcg: no idea about libexecdirs etc, I haven't written much .c code under linux. sbalneav is the person to ask. Better yet, file bug reports or merge requests so that they can be properly discussed and committed
20:51
14:07<bcg> alkisg: committed and pushed to ldm-rhel7. => I didn't see any merge requests yet though!
20:51
:)
20:55ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
21:32alexxtasi[m] has joined IRC (alexxtasi[m]!alexxtasim@gateway/shell/matrix.org/x-mwctwjhzahnlovgn)
22:51adrianor1 has joined IRC (adrianor1!~adrianorg@177.18.170.113)
22:54adrianorg has left IRC (adrianorg!~adrianorg@177.204.158.96.dynamic.adsl.gvt.net.br, Ping timeout: 260 seconds)
23:18ltsp` has joined IRC (ltsp`!bot@ltsp.org)
23:21elias_a_ has joined IRC (elias_a_!elias@hilla.kapsi.fi)
23:21syrius__ has joined IRC (syrius__!syrius@thunder.stormtek.net)
23:21TatankaT_ has joined IRC (TatankaT_!~tim@193.190.253.114)
23:26TatankaT has left IRC (TatankaT!~tim@193.190.253.114, *.net *.split)
23:26syrius has left IRC (syrius!syrius@thunder.stormtek.net, *.net *.split)
23:26lmds_ has left IRC (lmds_!~lmds@tui.pi-et-ro.net, *.net *.split)
23:26zamba has left IRC (zamba!marius@flage.org, *.net *.split)
23:26ltsp has left IRC (ltsp!bot@ltsp.org, *.net *.split)
23:26elias_a has left IRC (elias_a!elias@hilla.kapsi.fi, *.net *.split)
23:26zamba has joined IRC (zamba!marius@flage.org)
23:26syrius__ has left IRC (syrius__!syrius@thunder.stormtek.net, Remote host closed the connection)
23:26syrius has joined IRC (syrius!syrius@thunder.stormtek.net)
23:29lmds_ has joined IRC (lmds_!~lmds@tui.pi-et-ro.net)
23:30lucascastro has left IRC (lucascastro!~lucas@131.255.227.138, Remote host closed the connection)
23:31syrius has left IRC (syrius!syrius@thunder.stormtek.net, Ping timeout: 260 seconds)
23:32syrius has joined IRC (syrius!syrius@thunder.stormtek.net)