[Reproducible-builds] Performance of armhf boards

[Steven Chamberlain]

Hi!

I was wondering what is the performance of various armhf boards, for
package building.  Of course, the reproducible-builds team have a lot of
stats already.  Below I'm sharing the query I used and the results in
case anyone else is interested in this.

Using https://tests.reproducible-builds.org/reproducible.db
(warning: >300MiB)

$ DATE=$(date -u -d "1 day ago" '+%Y-%m-%d')
$ TIMESPAN_RAW=21
$ sqlite3 -column -header reproducible.db \
   "SELECT r.node1 AS buildd, COUNT(r.id) AS pkgs_built, CAST(AVG(r.build_duration) AS INTEGER) AS avg_duration FROM results AS r WHERE r.build_duration!='' AND r.build_duration!='0' AND r.build_date > datetime('$DATE', '-$TIMESPAN_RAW days') GROUP BY r.node1 ORDER BY pkgs_built DESC"

Figures will vary based on which packages were assigned to which
node, as some are easier to build than others, but I hope over 21
days that variance is smoothed out.

Assuming the nodes had no downtime, we can compare pkgs_built over
the 21-day period to assess performance.

Also avg_duration is meaningful, but will increase where the
reproducible-builds network scheduled more concurrent build jobs on a
node.  (Low avg_duration does not always mean high package throughput,
it may just be doing fewer jobs in parallel.)

Finally, the nodes' performance will depend on other factors such as
storage device used, kernel, etc.

Rows are annotated with number of cores, amount of RAM, and board.

buildd                                pkgs_built  avg_duration
------------------------------------  ----------  ------------
profitbricks-build5-amd64.debian.net  17415       514         # 18x,48G
profitbricks-build1-amd64.debian.net  16720       531         # 17x,48G
profitbricks-build6-i386.debian.net   15348       727         # 18x,48G
profitbricks-build2-i386.debian.net   15214       739         # 17x,48G
wbq0-armhf-rb.debian.net              2170        2359        # 4x,2G; Wandboard-Quad?
cbxi4b-armhf-rb.debian.net            2077        2582        # 4x,4G; CuBox-i4x4
odxu4-armhf-rb.debian.net             2007        2255        # 8x,2G; Odroid-XU4 (USB3 SATA SSD)
cbxi4a-armhf-rb.debian.net            1996        2365        # 4x,4G; Cubox-i4x4
cbxi4pro0-armhf-rb.debian.net         1973        2743        # 4x,2G; CuBox-i4Pro
opi2a-armhf-rb.debian.net             1767        2922        # 4x,2G; OrangePi Plus2 (USB2 SATA SSD)
odxu4c-armhf-rb.debian.net            1742        2180        # 8x,2G; Odroid-XU4
odxu4b-armhf-rb.debian.net            1627        2295        # 8x,2G; Odroid-XU4
ff2b-armhf-rb.debian.net              1529        2745        # 4x,2G; Firefly-RK3288 (USB2 SATA SSD)
opi2b-armhf-rb.debian.net             1460        2738        # 4x,2G; OrangePi Plus2 (USB2 SATA SSD)
ff2a-armhf-rb.debian.net              1435        2570        # 4x,2G; Firefly-RK3288 (USB3 SATA SSD)
bbx15-armhf-rb.debian.net             1151        1827        # 2x,2G; BeagleBoard X15 - cool!
rpi2c-armhf-rb.debian.net             1137        1986        # 4x,1G; Raspberry PI 2
hb0-armhf-rb.debian.net               1134        2143        # 2x,1G; HummingBoard Pro i2?
bpi0-armhf-rb.debian.net              773         3433        # 2x,1G; Banana Pi?
ff4a-armhf-rb.debian.net              630         1728        # 4x,4G; Firefly-RK3288
rpi2b-armhf-rb.debian.net             626         1972        # 4x,1G; Raspberry PI 2 Model B
wbd0-armhf-rb.debian.net              403         3176        # 2x,1G; Wandboard-Dual (USB2 SATA HDD)

I don't know whether to believe these figures yet!

  * wbq0 is impossibly fast for just 4x1GHz cores, 2GB RAM...
  * odxu4 looks slightly faster than the other two.
  * cbxi4a/b seem no faster than cbxi4pro0 despite twice the RAM?
  * ff2a/b show USB3 SSD to be no faster than USB2?
  * bbx15 may be able to handle more build jobs (low avg_duration).
  * bpi0 may be overloaded (high avg_duration).
  * ff4a maybe had downtime, and seems to be under-utilised.
  * rpi2b maybe had downtime, or has a slower disk than rpi2c.
  * wbd0 slowness is likely due to the magnetic hard drive.

Corrections/suggestions are welcome.

Many thanks to Vagrant for hosting all these armhf nodes!

Regards,
-- 
Steven Chamberlain
steven at pyro.eu.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20160418/cdb3020c/attachment.sig>