<div dir="ltr"><div><br><br>On Wed, Mar 15, 2017 at 6:03 PM, Nikos Alexandris <<a href="mailto:nik@nikosalexandris.net">nik@nikosalexandris.net</a>> wrote:<br>><br>[...]<br>><br>> Nikos:<br>><br>>>> Some messy rough timings:<br>>>><br>>>> 1) i7, 8 cores, 32GB RAM, Base OS: CentOS -> Three r.in.gdal processes<br>>>> for "p2.tif", each stuck at 3% for almost 14h<br>>>><br>>>> 2) Xeon, 24 Cores, 32GB RAM, Base OS: Windows -> Three gdal_translate<br>>>> processes with -projwin, the VRT file as an input and GeoTIFF as output,<br>>>> at 40% since yesterday afternoon<br>>>><br>>>> 3) Xeon, 12 Cores, ? RAM, Base OS: CentOS.jpg -> Same processes as in<br>>>> 1), stuck at 0% of progress for more than 16h.<br>>>><br>>>> SSD can be seen as a "necessity".<br>>><br>>><br>> Markus Metz:<br>><br>>> Hmm, not really.<br>><br>><br>> In a laptop (i7-4600U CPU @ 2.10GHz with 8GB of RAM with SSD) it was<br>> progressing, in a quite acceptable manner.<br></div> What is the gdal version you used? I use gdal 2.1.3.<br><div><br>>  I had to break the process,<br>> unfortunately, because I don't have a lot of free space :-/<br><br></div><div>maybe because you forgot the enable compression ;-)<br></div><div><br>><br>>> With the p1 tif and GRASS db on the same spinning HDD, and<br>>> 6 other heavy processes constantly reading from and writing to that same<br>>> HDD, r.in.gdal took 2h 13min to import the p1 tif. 360 MB as input and 1.5<br>>> GB as output is not that heavy on disk IO. Most of the time is spent<br>>> decompressing input and compressing output.<br>><br>><br>> p2 is a harder one!<br><br>export GDAL_CACHEMAX=10000<br>gdal_translate -co "COMPRESS=LZW" GHS_BUILT_LDS1990_GLOBE_R2016A_3857_38_v1_0_p2.tif p2_test.tif<br><br></div><div>finishes in 28 minutes.<br></div><div><br></div><div>you could try gdal 2.1.3, maybe 2.1.3 has a more efficient cache regarding block-wise reading than gdal 1.11.4 <br><br></div><div>Best,<br><br></div><div>Markus M<br></div></div>