Ubuntu One is very slow

Update5: Day 4 and it looks like this: laptop 18078 items (5.5Gb), desktop 17803 items (5.5Gb). I wonder why the file-count differs?

Update4: Day 3 of this experiment. Machines have been online for more than 72 hours. In total 50Mb have been uploaded from laptop today (since reboot in the morning). That might be a good sign. All the files should now be in the "cloud". But are they synced to my other machines? Laptop still shows 18800+ files, desktop now shows 17800 files. Getting close...

Update3: Here's another observation, when the laptop, which still has about 11000 un-synced files in the One-folder, boots up, ubuntuone-syncdaemon can take 1-3 minutes of 100% cpu and about 300Mb RAM. After that it settles down, but 100% cpu means the machine is slow and unresponsive for a while 🙁

Update2: Someone at canonical asked for my log-files (they are in ~/.cache/ubuntuone/log/), and I've sent them. Hope they find what is going wrong!

Update1: the sync does seem coupled to a reboot. This morning it appears about 400Mb more was synced after a reboot of the machine. I still have about 11000 files un-synced after 48 hours.

These days data wants to be distributed and in the cloud. This image shows my Ubuntu One folders on three machines. They are supposed to be in sync, but are far from that after being connected to a high-speed network for more than 24 hours 🙁

OK, so let's go buy 20Gb of space on Ubuntu One, and transfer my working-set of work/hobbies/etc files there and see how it goes. I use about three computers regularly, a new laptop at work, and a  desktop and an old laptop at home. The work machine is on the university network where bandwidth shouldn't be a problem, and I have 40Mbit broadband from welho at home. What could possibly go wrong?

Ubunutu One is very very slow. I didn't just dump all my files and pictures into the shared-folder at once, I thought I'd start with a subset which happened to be 18064 files taking up 5.5Gb. It appears that in the first 24 hours roughly 700 Mb of data was synced. Now I have rebooted the primary laptop and it has very rapidly sent out another 500 Mb - but then slowed down to a creep. Is there a bandwidth-cap? For paying users?

Does anyone use Dropbox for lots (10s of thousands) of files? Does it work? Fast?

Cutsim driven by g-code

Based on Mark Pictor's cam-occ work I've been able to use the emc2 g-code interpreter 'rs274' binary that gets built during an emc2-build. It reads g-code files and outputs 'canonical' motion commands (see e.g. "The NIST RS274/NGC Interpreter - Version 3"). I'm positioning the tool at densely sampled points along each move, and subtracting it from the stock (see Yau and Yau) . The stock model is a distance field stored in an adaptive octree (see Frisken and Frisken).

This is very experimental: There's one kind of stock and one kind of tool, namely spherical!, The stock and tool sizes and colors are hard-coded, There's only one thread which means the UI becomes unresponsive and greyed-out during about 57s of processing. It's slow, 57s for a fairly simple 20-line g-code file. We assume hard-coded paths for the 'rs274' binary and the emc2 tooltable-file.

Octree operations

I've looked at set-operations (union, difference, intersection) for octrees again. Previously I tried it with linear-octrees and visualization with python and VTK. Now I'm using a traditional pointer-based octree data-structure, and drawing with OpenGL VBOs. With the addition of a g-code interpreter, a user-interface, and an isosurface extraction algorithm (such as marching-cubes) this should converge towards a milling/turning/3d-printing cutting-simulation sometime soon...

References: Frisken2000 and Frisken2006.

Quassel notes

To keep myself "forever" logged onto IRC, I wanted to run quassel-core on my isp shell-account, and quassel-client on whatever computer I am using at the moment (home/work/laptop, etc).

I first downloaded the statically linked core quasselcore-static-0.7.3.bz2 and unzipped it onto the server.

To use SSL, a certificate on the server is needed, made by copy/pasting from the quassel-wiki:

openssl req -x509 -nodes -days 365 -newkey rsa:1024 -keyout ~/.config/quassel-irc.org/quasselCert.pem -out ~/.config/quassel-irc.org/quasselCert.pem

Then, my ISP doesn't have the port open that quassel uses (4242), so the connection needs to be tunneled through SSH. For testing a 'local port forwarding' tunnel can be opened like this (this is run on the client machine):

ssh -lmy_user -L 4242:localhost:4242 my.remote.server

If I understand correctly this redirects traffic trying to connect to 4242:localhost through SSH (port 22), and actually connects to 4242:my.remote.server. However it isn't convenient to always have to type in the password when opening the tunnel, so I set up SSH login without password.

Now we can go ahead and start the server, under screen, so that it stays alive when I log out of the server shell. The server-side (quasselcore) needs no further configuration through the server shell.

screen
./quasselcore-static-0.7.3
CTRL-A - d (to detach screen)
logout

Now we can connect with quassel-client, specifying 4242:localhost as the server. When doing this for the first time quassel-client will ask for some set-up data. It's possible to use an SQL server backend on the server-side, but I'm using SQLite.

Then I started googling for advice on how to automatically start and keep alive an SSH tunnel on Ubuntu. There seems to be no consensus on how this is best done, and two or three attempts I tried failed. Most seem to use autossh. Ry4an's blog suggests an upstart script (but I couln't get that to work, and it requires a special user with no password). Or should it be done with a script in /etc/network/if-up.d ? Since I only use the this SSH-tunnel with quassel-client, maybe the easiest solution is to create a launcher-script that first opens the SSH-tunnel, and then launches quassel-client (how do I kill the tunnel when quassel-client exits?). Suggestions? sshuttle?

For now quassel-core has been running OK on the server for a few hours, and everything seems to work. I'll be able to test connecting with more clients from home later... stay tuned.

Drumsö Runt

19k long slow run around lauttasaari on Saturday. Since the shoreline of an island is supposed to have a fractal dimension greater than one, it's possible to lengthen the run by following the shoreline more closely. Here the lap around the island is about 16-3 = 13km.

Between 6-7km and slightly after 7km it's probably possible to run on the cliffs and in the woods to get a bit more distance. I'm not sure about the area around 10km, seems private with no path around the shoreline. At 12km and slightly after 14km I don't think there's a shoreline-path either.

Two Million Meters

About 95k biked this week, which brings the grand total for 2011 up to 2000 km, or two million meters. Yay!

Here's a graph:

This shows that I have been riding about 85k per week from week 13 until now (week 37). The three >100k rides to/from Tammisaari show up as peaks, as well as the 2-day Luumäki trip. Week 29 is the only one with zero km's, because of the 24h rogaining trip/event. Extrapolating until the end of the year a 85k/week rate will bring the total over 3000 km, but we'll see how tough it gets with ice, snow, and winter-tires...

On the running side of things it would be nice to get up to 1000 km again, but I'm now about 50-70k behind last years schedule.

Critical Mass, 2011 September

Some 260 riders and a route along länsiväylä, the main motorway in to Helsinki from the west. Bikes on the motorway has prompted a number of news-stories:

Yle: http://www.yle.fi/alueet/helsinki/2011/09/lansivayla_halutaan_muuttaa_kaupunkibulevardiksi_2866429.html and http://yle.fi/uutiset/kotimaa/2011/09/pyorailijat_valtasivat_moottoritien_helsingissa_2869090.html

HS: http://sange.fi/~otso/stuff/hs110913-kriittinen-l%C3%A4n%C3%A4ri.jpg or http://omakaupunki.hs.fi/paakaupunkiseutu/uutiset/pyorailykulkue_tukkii_moottoritien_kaistoja_illalla/

Some history and views: http://vesirajassa.blogspot.com/2011/09/lansimuuri.html

See also June11 and Aug11.