<kugel> what's up with qnap-jdgordon?
* bertrik finally finished reaper man
<kugel> how can it do 3 builds taking >100s each while the round was 222s ?
<bertrik> Started now with Equal rites
<bluebrother> multicore box?
<kugel> do you mean multiple clients?
<bluebrother> no, I'm wondering if the build server hands out as many builds in parallel as the box has cores.
<kugel> IIRC it doesn't
<bluebrother> thought that's only guessing -- no idea how the buildserver handles multicore machines
<kugel> also, IIUC this qnap is a NAS, unlikely that it has more than 1 core
<bluebrother> a box being NAS doesn't tell anything about the number of cores. What makes you believe it's a NAS box?
<kugel> they talked about it a while ago (petur and JdGordon )
<bertrik> qnap makes NASs
<bluebrother> well, JdGordon might shed light on the issue ...
<kugel> the home NASes all don't have multiple cores (looking at qnap's site)
<bluebrother> glasschale-Rondom also seems to run multiple builds at once.
* gevaerts suspects that something went wrong with either the database log or with the parsing
<kugel> gevaerts: the client stats table clearly shows JdGordon's 3 >100s builds. I'd say it's impossible to do those within 222s and without parallel building
<kugel> but I'm having paralell builds also sometimes, so far only when a new round starts just after the previous 
<kugel> (e.g. due to rapid committing)
<gevaerts> yes, looks like a bug in the build master
<bluebrother> it's also interesting that the graph shows 1s upload time for the bootloaders though bootloaders aren't uploaded.
<gevaerts> logs are uploaded
<gevaerts> not sure if that's meant to be counted though
<bluebrother> hmm, good point. But then I'd expect the upload speed to show something different to 0 in the build round log
<gevaerts> ok, clearly a bug in the build master. Those parallel builds seem to get two build commands
<gevaerts> and as far as I know, clients shouldn't get parallel builds at al
<kugel> I remember that too
<gevaerts> (the client supports them, but the current allocation doesn't make use of that)
<bertrik> but we do build and upload in parallel, yesno?
<gevaerts> yes
<gevaerts> see e.g. rb.hostname.be-gevaerts in the latest round
<kugel> http://rasher.dk/rockbox/buildgraphs/graph.php?r=22331&debug looks really bad
<kugel> it shows that builds are started before being queued (?)
<gevaerts> where?
<kugel> iuno-bluebrother for example
<bertrik> I got some "Connection refused" when connecting to svn.rockbox.org during that round
<kugel> either that, or I didn't understand the differences between queued and completed/cancelled
<gevaerts> kugel: I think all queueing is done at the start of the round. They seem to be started in the wrong order, but that's different
<kugel> gevaerts: is queuing what the build master expects the client to do (best-fit)
<kugel> ?
<gevaerts> kugel: yes, more or less
<kugel> ah that makes sense
<kugel> then iuno-bluebrother totally broke
<kugel> wrong order and parallel builds (maybe that's connected?)
<gevaerts> I'm pretty sure the wrong order is a symptom of the parallel builds problem
* Grahack hat die Verbindung getrennt ("Leaving.")
<kugel> gevaerts: I'm not sure it's a bug in the master, it seems to allocate correctly
* Topy44 hat die Verbindung getrennt ()
<gevaerts> I'm not sure. Let Zagor find out...
* kugel likes the Wiktionary entry for "automagically"
<bluebrother> well, that was part of one of my quesition: does the time for queued builds name the time that the client is supposed to need for the build?