Report on membershipmeeting Feb2016

This months membership meetup was more cozy than usual. Also a lot more productive, judging on what happened the days after ;-)

The highlights:

  • Easterhegg 2016. Originally we wanted to help out with cool lighting and take part as a big realraum delegation from Graz. Unfortunately tickets were quite suddenly and unexpectadly sold out. So there will be no realraum @ Easterhegg 2016 Salzburg. Too bad. Very sad. Some of us are going to Revision16 instead though.
  • Lasercutter exhaustvent and OLGA vents. Is finally going to be built. See upcoming post with pictures.
  • Curtain: Will finally happen. New curtain rod installation was finished on Wednsday and Curtain is scheduled for hanging on Friday.
  • mur.at: The future of our internet uplink is in flux. Interessting stuff will happen 2016/2017.
  • Finances: Over the next months we will test and then maybe introduce a new formal system for financing stuff in realraum.

Light in realraum is now faster

licht.realraum.at, went FTLw today. That is… it became much Faster Than Last week. :-)

Since the Raspbian image upgrade and move to a bigger (but slower) SDcard, licht.realraum.at had become truly sluggish. To the point that pressing a button to turn on the light or change the stereo volume could take up to 6 seconds until something happened. (Obviously we disabled the swap-file long ago.)

The problem was quickly identified. Processes don’t load quickly enough.
The fact that the whole systems was a dunghill of bashscript cgi-scripts and python helper scripts also did not help. At all.

First attempt to rectify this: rewrite the python helper rf433ctl.py. Formerly it was a simple script that would be called by the cgi-script and send the appropriate bytes down to the teensy.
Each call to it, however now took forever. So. I rewrote it as a daemon that would constantly stay in memory and be nudged by other instances of it via RPC. The idea being, if it’s already completely in memory, loading a second instance should be faster. Right? Wrong!. Unfortunately that did not work out at all.

Second attempt to rectify this: Remove the kiosk functionality and thus memory-hog midori from licht. Thankfully a very nice person gifted us a RaspberryPi per (almost) anonymous letter, so we had the necessary hardware on-hand to split the functionality onto two separate boxes: licht.realraum.at and smallkiosk.realraum.at
Unfortunately, even freeing up 60% of memory did not even put a dent into the problem.

So.. third and last attempt. Hit it with go ;-> In a 3 hour session, I rewrote the whole dunghill as a monolithic golang daemon/webserver/tty-handler which, once loaded, always stays in memory. Then I got rid of lighthttpd and the python scripts. Result… Speedup from 6s to <=0.05s !! Should have done this right away really...