Re: GNUnet build failure on mips64el
On 02/22/2014 08:44 AM, Mark H Weaver wrote: PASS: test_local_revocation.py Feb 22 07:17:50-660583 testbed-api-topology-16547 WARNING Error while establishing a link: 0x4: Timeout while connecting to CORE of peer with id: 0 -- Retrying Feb 22 07:17:51-098510 testbed-api-topology-16547 WARNING Error while establishing a link: 0x5: Timeout while connecting to CORE of peer with id: 1 -- Retrying Feb 22 07:17:56-127624 testbed-api-topology-16547 WARNING Error while establishing a link: 0x7: Timeout while acquiring HELLO of peer 6ULB -- Retrying Feb 22 07:17:56-134033 testbed-api-topology-16547 WARNING Error while establishing a link: 0x6: Timeout while acquiring HELLO of peer 6DER -- Retrying Feb 22 07:18:01-142761 testbed-api-topology-16547 WARNING Error while establishing a link: 0x9: Timeout while acquiring HELLO of peer 6DER -- Retrying Feb 22 07:18:01-143920 testbed-api-topology-16547 WARNING Error while establishing a link: 0x8: Timeout while acquiring HELLO of peer 6ULB -- Retrying --8---cut here---end---8--- These warnings are likely caused due to the system getting overloaded. The testcase has a test ramp-up part which starts 2 peers and then connects them. This part is failing as peers are unable to connect. After printing the text above, it gets stuck in 'src/revocation/.libs/test_revocation', with the two 'gnunet-service-nse' subprocesses both running continuously and all other gnunet processes sleeping. This is likely to cause the load on the system. 'gnunet-service-nse' tries to find a proof-of-work to participate in the size estimation application of GNUnet. This proof-of-work involves find a value whose hash matches its first n digits; this is required to avoid Sybil attacks and can be computationally expensive and can be taxing on the loongson you have. I am not sure if the NSE service is needed for this testcase. If not it should be easy to fix. In any case, the testcase should not run for more than ~1 minute. I'd like to debug this. Would it be possible to provide me access to this machine? Sree
Re: GNUnet build failure on mips64el
On 02/22/2014 09:46 AM, Sree Harsha Totakura wrote: This is likely to cause the load on the system. 'gnunet-service-nse' tries to find a proof-of-work to participate in the size estimation application of GNUnet. This proof-of-work involves find a value whose hash matches its first n digits; this is required to avoid Sybil attacks and can be computationally expensive and can be taxing on the loongson you have. I am not sure if the NSE service is needed for this testcase. If not it should be easy to fix. I've disabled the POW calculation in SVN 32456, so the CPU load issue should be fixed now. 0x48426C7E.asc Description: application/pgp-keys
Re: GNUnet build failure on mips64el
On Fri, Feb 21, 2014 at 06:49:43PM +0100, Ludovic Courtès wrote: The same holds for Qt - its build times out after 2 hours, when it is simply not finished. Could we raise the timeout on hydra? IIUC the code, there’s not absolute timeout by default, only a timeout-on-silence. Which one do we hit here? Things seem to stop after exactly two hours, and the last line of the log looks as if this happens in the middle of compilation. Another thing: We have four cores (I suppose actually two hyperthreaded ones) on hydra. On my machine, top shows four times 100%. On hydra, I get the impression that only one core is working. Is this normal (due to outside load, maybe), or do we need to tweak something? It’s supposed to use all the cores. What makes you think only one core is used? top does not reach the 4 times 100%, but is usually rather below 100%. Andreas
Re: GNUnet build failure on mips64el
Sree Harsha Totakura sreehar...@totakura.in writes: On 02/21/2014 07:22 AM, Mark H Weaver wrote: Any idea what's going on here? In case it's helpful, I've also attached the entire build log. Can you go into the build directory '/tmp/nix-build-gnunet-0.10.0.drv-1/gnunet-0.10.0/src/revocation' and run 'make check' and see if you get the same output? That failed immediately. The reason is that apparently GNUnet's test suite only works if GNUnet has already been installed. In this case, since the build failed, the guix-daemon deleted the /nix/store/* directory where it had been installed :-( I think it's going to hard to reproduce the build environment outside of guix-daemon. I think it would be better to try a modified recipe that only runs a subset of the tests. Mark
Re: GNUnet build failure on mips64el
On 02/21/2014 04:31 PM, Ludovic Courtès wrote: On the GNUnet side, it would be great if the tests were less timing sensitive. We faced these problems earlier when we added Sheevaplug and RasberryPi into our buildbots. Unfortunately, since we are having a network application, the timeouts are necessary. We can try increasing the timeouts but that makes the test runs long if a testcase were to fail genuinely. Guess we'll have to come up with some automated measurement for timeouts depending on the host configuration. I just don't know how; any ideas? Sree
