Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: Fetch time optimization (svn : gcc/eglibc - git : linux-yocto)
Date: Fri, 30 Mar 2012 16:12:44 +0100	[thread overview]
Message-ID: <1333120364.18082.77.camel@ted> (raw)
In-Reply-To: <20120330105006.00955b5d@eb-e6520>

On Fri, 2012-03-30 at 10:50 +0200, Eric Bénard wrote:
> Le Thu, 29 Mar 2012 23:03:13 +0100,
> Richard Purdie <richard.purdie@linuxfoundation.org> a écrit :
> 
> > On Thu, 2012-03-29 at 22:53 +0200, Eric Bénard wrote:
> > > I noticed in from scratch builds for qemuarm that the longest time is
> > > taken in fetching sources, especially those fetched using git
> > > (linux-yocto for example) & svn (gcc, eglibc & co).
> > 
> > Are you timing these as fetches from the source control systems or from
> > the mirror tarballs of the repositories. The tarballs should be
> > faster...
> > 
> the default configuration seems to fetch from source control systems
> as I always see very long time to fetch gcc/eglibc/linux-yocto
> (despite having a 2.2 MBytes/s downlink DSL line).

If you're hitting the SCMs I can understand the frustration.

> I don't think that's a size problem but that fetching through svn or
> git is far less efficient than http or ftp especially from gnu's svn
> which may be overloaded.

Agreed.

> Morover in a pure OE context we have no interest of all the source
> history provided by svn or git and that makes a very big volume to
> download.

The fetcher will deal with this well in the svn case. In the git case,
we made a decision to include history since its not that more expensive.
Both these assumptions are based on a working up to date mirror.

> . ./openembedded-core/oe-init-build-env 
> edit local.conf to select qemuarm & BBTHREAD to 8
> bitbake core-image-minimal -c fetchall
> 
> and then I see bitbake stops at around 209 or 214 tasks waiting and
> I see that in ps :
> /home/ebenard/OE-CORE/build/tmp-eglibc/sysroots/x86_64-linux/usr/bin/git.real
> clone --bare --mirror
> git://git.yoctoproject.org/linux-yocto-3.2 /home/ebenard/OE-CORE/build/downloads/git2/git.yoctoproject.org.linux-yocto-3.2
> and
> svn co -r 184847
> http://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch@184847
> 
> ... and both are actually fetching at only around 200 KiB/s which last
> for quite a long time as (from an other downloads dir) the final
> tree size are huge :
> du -s git.yoctoproject.org.linux-yocto-3.2/
> 610824	git.yoctoproject.org.linux-yocto-3.2/
> du -s gcc.gnu.org/
> 1602496	gcc.gnu.org/
> du -s www.eglibc.org/
> 625048	www.eglibc.org
> If I launch at the same time :
> wget ftp://ftp.gnu.org/gnu/gcc/gcc-4.6.3/gcc-4.6.3.tar.bz2
> I get a download speed close to 1MB/s and the file to download is only
> 64MB which would save bandwidth.

Try adding this to your configuration:

PREMIRRORS = "\
git://.*/.*   http://downloads.yoctoproject.org/mirror/sources/ \n \
svn://.*/.*   http://downloads.yoctoproject.org/mirror/sources/ \n"

and see if that helps the performance. It might be we consider making
this the default for OE-Core although some people are nervous about
doing this...

Cheers,

Richard




  reply	other threads:[~2012-03-30 15:21 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-29 20:53 Fetch time optimization (svn : gcc/eglibc - git : linux-yocto) Eric Bénard
2012-03-29 22:03 ` Richard Purdie
2012-03-30  1:03   ` Bruce Ashfield
2012-03-30  6:44     ` Samuel Stirtzel
2012-03-30  9:21       ` Paul Eggleton
2012-03-30  9:32       ` Richard Purdie
2012-03-30 10:07         ` Samuel Stirtzel
2012-03-30 10:45           ` Richard Purdie
2012-04-02  8:15             ` Samuel Stirtzel
2012-03-30  7:00     ` Martin Jansa
2012-03-30 10:06       ` Richard Purdie
2012-03-30  8:50   ` Eric Bénard
2012-03-30 15:12     ` Richard Purdie [this message]
2012-03-30 15:24       ` Eric Bénard
2012-03-30 15:49         ` Bruce Ashfield
2012-03-30 15:55           ` Eric Bénard
2012-03-30 16:02         ` Richard Purdie
2012-03-30 16:17           ` Eric Bénard
2012-03-30 17:33             ` Bruce Ashfield
2012-03-30 18:36               ` Eric Bénard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1333120364.18082.77.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox