[Tilesathome] My quad-core tiles at home setup

[Dirk-Lüder Kreie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ævar Arnfjörð Bjarmason schrieb:
| I thought I'd share with the list my t at h setup which I'm quite happy
| with, it's mostly based on steve's setup[1] with some auxiliary
| scripts. It's working for me on a quad-core machine so it might work
| for someone else:
|
| This is what my ~tah/ directory looks like:
|
| avar at t:~/src/tah$ ls -l . work/
| .:
| total 3004
| drwxr-xr-x 3 avar avar    4096 2008-08-22 15:05 script
| drwxr-xr-x 8 avar avar    4096 2008-08-22 15:24 tah-1
| drwxr-xr-x 8 avar avar    4096 2008-08-22 15:34 tah-2
| drwxr-xr-x 7 avar avar    4096 2008-08-22 15:24 tah-3
| drwxr-xr-x 7 avar avar    4096 2008-08-22 15:24 tah-4
| drwxr-xr-x 8 avar avar    4096 2008-08-22 15:25 tah-upload
| drwxr-xr-x 2 avar avar 3043328 2008-08-22 15:34 uploadable
| drwxr-xr-x 8 avar avar    4096 2008-08-22 02:42 work
|
| The tah-{?,upload} directories are SVN checkouts of the t at h repo[2].
| The tah-[1-4] directories house clients which all upload to the
| `uploadable' directory which tah-upload then picks up. This is the
| relevant tilesAtHome.conf for all of them:
|
| avar at t:~/src/tah$ head -n3 tah-{?,upload}/tilesAtHome.conf
| ==> tah-1/tilesAtHome.conf <==
| WorkingDirectory = /home/avar/src/tah/work/tah-1
| UploadToDirectory = 1
| UploadTargetDirectory = /home/avar/src/tah/uploadable
|
| ==> tah-2/tilesAtHome.conf <==
| WorkingDirectory = /home/avar/src/tah/work/tah-2
| UploadToDirectory = 1
| UploadTargetDirectory = /home/avar/src/tah/uploadable
|
| ==> tah-3/tilesAtHome.conf <==
| WorkingDirectory = /home/avar/src/tah/work/tah-3
| UploadToDirectory = 1
| UploadTargetDirectory = /home/avar/src/tah/uploadable
|
| ==> tah-4/tilesAtHome.conf <==
| WorkingDirectory = /home/avar/src/tah/work/tah-4
| UploadToDirectory = 1
| UploadTargetDirectory = /home/avar/src/tah/uploadable
|
| ==> tah-upload/tilesAtHome.conf <==
| WorkingDirectory = /home/avar/src/tah/work/tah-upload
| UploadToDirectory = 0
| ForkForUpload = 0
|
| The tah-upload client then has its uploadable directory symlinked to
| ../uploadable. I guess I could make the tah-[1-4] clients upload
| directly to tah-upload's work directory instead but I like to have the
| uploads in the main dir:
|
| avar at t:~/src/tah$ file work/tah-upload/uploadable
| work/tah-upload/uploadable: symbolic link to
| `/home/avar/src/tah/tah-upload/../uploadable'
|
| To run it all I open several windows in GNU screen, one of them is the
| upload client which always runs in an upload loop:
|
| avar at t:~/src/tah/tah-upload$ perl tilesGen.pl upload_loop
| - Using working directory /home/avar/src/tah/work/tah-upload
| - Keeping ZIP files after upload
| This is version 10049 (Rapperswil) of tilesgen running on linux, ID:
84105960
| [#0   0% uploadloop] waiting for new ZIP files to upload   0:00...
|
| In the rest of the tah-[1-4] directories I'm running t at h jobs to
| reneder areas I care about, usually something I've just mapped. Most
| of the time I only have 1-2 out of the 4 possible clients active.

| To render the area I've just mapped I download the area from the API
| I've been mapping, aggregate all its coordinates and use a custom
| script (osm-to-tilenumbers.pl) to get a list of all the applicable
| tiles that have changed in say the last 6 hours. I then run
| tilesGen.pl through a monitoring script which takes care of rendering
| the list of tiles given on STDIN and restarting (with appropriate
| calls to sleep()) tilesGen.pl if it were to exit uncleanly for some
| reason, usually due to the t at h api being down or network troubles:

You are aware that every 4 hours (currently) there runs a autorequester
on the t at h server that requests every tile with a node edit (moved,
tagged, deleted or added) so your script is somewhat redundant?

For the entire Project it would make more sense to run those clients in
loop mode, but I can understand if you keep doing it your way,
especially if you are the only really active mapper in a quite large
area, and want to ensure your area is rendered by a homogenous client
structure.

However I would not recommend this behaviour for many other t at h clients,
especially in areas where there are many mappers active, where the
central queue has definitive advantages with respect to both render
speed and resource conservation (API and t at h serverside)

- --

Dirk-Lüder "Deelkar" Kreie
Bremen - 53.0952°N 8.8652°E

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIsACWFUbODdpRVDwRAoccAJ4zFaVa49Z5kuqZW5eUEXmyhfuezwCdFshD
faypzdBRGL0sEICLRTolJ+o=
=5q98
-----END PGP SIGNATURE-----