Bandwidth problems at beta time (apt-get is slow)

Chow Loong Jin hyperair at
Sun Oct 4 17:49:05 BST 2009

On Sunday 04,October,2009 05:52 PM, Martin Olsson wrote:
> Jono Bacon wrote:
>> On 10/02/2009 09:05 PM, Jorge O. Castro wrote:
>>> Ken asked me to help him test some empathy stuff today and grabbing
>>> the build-deps took over 10 minutes for a few hundred k's worth of
>>> packages. I have a caching proxy at home so normally it's not so bad
>>> but I am starting to wonder if there should be an ACLable mirror
>>> available to people in core-dev/MOTU/bugcontrol/whatever so people can
>>> get the important stuff done. In the past I've gotten emails from the
>>> ISO tracker before my original rsync is even close to done so the pain
>>> just multiplies over the course of the end of the cycle..
>>> I think it's great that we have so much enthusiam for a release but
>>> surely we can set aside a certain percentage of bandwidth for people
>>> to get their testing done.
>> I agree. I think we need to find a better solution for this problem. 
>> What does everyone else think?
> I was also frustrated by this yesterday while doing upstream
> development I needed some -dbgsym packages to hunt down a bug.
> Any solution that treats core-dev/MOTU like a special case would
> be a big mistake because A) lots of upstream devs use Ubuntu, and
> B) the bandwidth issues are also a _huge_ turn off for normal users
> installing or upgrading Ubuntu.
I won't say you're wrong, but I don't really agree that it is a 'big mistake'.
Upstream devs don't generally have as wide a scope to cover as Ubuntu
core-dev/MOTU do, though, especially when you consider that the Ubuntu
developers have to be the ones sponsoring packaging contributions from the
universe-contributors and the general public who happen to submit patches and
such. They will have to test-build the packages, hence requiring all kinds of
dependencies to be downloaded.

> The real solutions include:
> A) use bittorrent to download .DEBs - this is not very hard to do
> when you think of it; we got many high quality bittorrent client
> libraries available already. If this is hard for some reason, I'd
> love to hear why; maybe we can think of some way to simply the
> problem?
Bittorrent is slow if not set up properly, and it is a pain to set up properly.
At least, I don't think the average user should have to know how to forward
ports just to get Ubuntu up to date. After that, there are a whole bunch of
issues with Bittorrent being blocked by ISPs and university/company networks.
And even if you do get past that, there's the whole issue where Bittorrent
transfers take quite some time to start up (find seeds/peers, establish
connections, etc).
> B) dont send full DEB's all the time, send a bsdiff on upgrade,
> like how Google Chrome distributes their updates.
I believe there is ongoing work to do with debdeltas.
> C) create more mirrors and make sure each user can download
> for multiple mirrors at once (i.e. do load balancing between
> mirrors, dont "hardcode" a specific mirror in preferences).
It's actually quite hard to load-balance multiple mirrors that aren't on the
same local network, because of how fast the mirrors update, and how hard it is
to keep the mirrors in sync with each other.
> D) upgrade the servers and their internet connections
Or get more mirrors, etc. Fun.

Kind regards,
Chow Loong Jin (GPG: 0x8F02A411)
Ubuntu Contributing Developer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : 

More information about the ubuntu-devel mailing list