Hi Laurentiu, Do you have any comment on the performance question Richard asked? I know your team is using a machine with different configuration from the one used by the Shanghai team. The performance figure from the Shanghai team has been hovering around 110 mins. That's the case for 1.2 release and 1.3 M2 milestone report. 1.3 M1 milestone report has the build time as 95 minutes, which I believe is from your team. So my question is whether you used the same machine for M3 performance testing as for M1. Another factor that might have caused the difference (between 95 and 83 minutes) is your testing procedure/environment such as other processes running at the same time, memory usage, sstate cache, etc. If you used the same machine and same testing procedure/environment, then we have some improvement in M3 compared with M1. Please let me know your thoughts.
Thanks, Song -----Original Message----- From: Serban, Laurentiu Sent: Friday, August 24, 2012 6:34 AM To: Purdie, Richard Cc: yocto@yoctoproject.org; Liu, Song; Stewart, David C; Wold, Saul Subject: RE: 1.3 M3 Full Pass test results Hello Richard, Even if the installer is used in the default mode, issues still occur (see comment 7). I think the root cause for these is the same, so I did not submit a new bug. Thank you, Laurentiu -----Original Message----- From: Purdie, Richard Sent: Friday, August 24, 2012 1:22 PM To: Serban, Laurentiu Cc: yocto@yoctoproject.org; Liu, Song; Stewart, David C; Wold, Saul Subject: Re: 1.3 M3 Full Pass test results On Thu, 2012-08-23 at 20:13 +0100, Serban, Laurentiu wrote: > Here are the results for the full pas tests on 1.3 M3 RC2. The commit > used for testing is 8b8748c8f963900b83dc0fdd7757556f917fe4fd. > > Some details about the encountered issues below: > > BSP – Sudoku-savant project build issue (2878) > > ADT – the relocatable sdk issue (2980) causes 13 test cases to be on > faile/blocked state I thought it worked as long as you didn't have to relocate it so no tests should have been blocked, we just have the relocation issue? > , also the Clutter C template issue is unsolved (2577) > > Core Build System – x32 is still an issue (2888), cleaning sstate > issue is still not solved (2897), incremental RPM image generation > (2969), source archiving (2619), the kvm issue was reproduced by > another colleague (2790) Yocto BSP creation via JSON (2693) or for > qemu (2991) fails, multilib issue (2918 – this requires a little more > investigation from QA), > > HOB - all seems ok for RC2 > > Self-hosted-image - cannot start on Virtual Box (X issue), it is very > slow on qemu and it has a m4 package build (3005) issue on VMWare. If > the self-hosted-image is used on machine with internet connectivity > via proxy there will be an initial sanity check failure, but this is > not a blocking issue. > > A mention for the performance testing: on a Ubbuntu 12.04 i7 machine > using 8 threads the build time was 83 minutes (with prior fetching). How does this compare with our other performance numbers. From what I remember, we used to hover around the 105-115 minute mark. Did we have some significant speed gains or is this just an artefact of changing the test machine? Cheers, Richard _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
