Closed Bug 630541 Opened 15 years ago Closed 14 years ago

Very slow downloads of mar packages for nightly builds

Categories

(mozilla.org Graveyard :: Server Operations, task)

Product:
mozilla.org Graveyard
Component:
Server Operations
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: whimboo, Assigned: ravi)

References

Details

Updating nightly builds especially if you missed it the day before, is a real pain. Since a couple of days it takes ages to download the full mar file. I only see about 80kB/s transfer speed. Would be great if we could identify this issue and solve it.
Assignee: server-ops → justdave
More of a cantfix than a wontfix. We know what the issue is, and it'll be resolved after tomorrow's downtime on the staging server. The continuous run rsync in prep for phase 3 on bug 614786 is what's causing the slowness. That'll go away after the partitions are swapped during the outage window.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
Thanks Dave. I will re-check once bug 614786 has been marked as fixed.
Depends on: 614786
Dave, should that now be better? If yes, then I have to disappoint you. :/ It's still slow and servers with max. 300kB/s.
Nothing has been changed since bug 614786 has been fixed 5 days ago. It's still slow.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
I'm going to have to go ahead and blame network this time around. I just downloaded http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/firefox-4.0b12pre.en-US.mac.dmg in less than 20 seconds, getting around 2.0 MB/sec on the transfer, connecting to ftp.mozilla.org from Michigan. Which means it's likely network somewhere between you and the FTP server, rather than in our infrastructure, too.
Assignee: justdave → ravi
Here the last entries from the traceroute to f.m.o: 18 te7-2.mpd01.sjc03.atlas.cogentco.com (66.28.4.74) 193.909 ms 191.504 ms 193.532 ms 19 38.104.138.46 (38.104.138.46) 189.046 ms 190.397 ms 189.274 ms 20 border1.t3-1-bbnet1.sje003.pnap.net (66.151.144.27) 185.584 ms 186.454 ms 186.715 ms 21 mozilla-4.border1.sje003.pnap.net (69.25.56.86) 191.465 ms 186.915 ms 185.760 ms 22 te-8-3.core1.sjc.mozilla.net (63.245.208.102) 187.554 ms 184.507 ms 188.633 ms 23 * * * 24 * * *
Status: REOPENED → ASSIGNED
To Dave's point we don't have any ability to influence your route to us significantly. That you're nearly 200ms suggests this is just the way it is until someone can speed up 'c'.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago → 14 years ago
Resolution: --- → WONTFIX
(In reply to comment #7) > To Dave's point we don't have any ability to influence your route to us > significantly. That you're nearly 200ms suggests this is just the way it is > until someone can speed up 'c'. For real? Today I get 15KB/s for downloading the update inside of Minefield. I can't believe that this is only my connection because I'm now connected via another provider and still suffer from this issue even more. Any other hosts are serving content with over 500KB/s. Even other hosts in the U.S. allow transfer rates of about 2.5MB/s. Could that be a routing issue in general for European users? CC'ing some more folks from Europe to get this sorted out.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Can you at least provide your IP address if you've changed providers as well as th eIP address you're trying to connect to so we have something of substance to look at? Are these other US hosts geographically similar to the one of Mozilla's you're connecting to? It could be many things not the least of which are speed of light issues and provider bandwidth limitations.
If you could also provide the URI of what you're trying to download so I can test from my resources outside of North America.
(In reply to comment #9) > Can you at least provide your IP address if you've changed providers as well as > th eIP address you're trying to connect to so we have something of substance to > look at? Are these other US hosts geographically similar to the one of > Mozilla's you're connecting to? Right now I have two providers so I can even test both. I will send you the IP addresses and traceroute logs via email. Well not sure if those servers are located in CA, but I have now tested with http://www.speakeasy.net/speedtest/ and explicitly selected a server in Frisco. I get rates of 2MB/s. (In reply to comment #10) > If you could also provide the URI of what you're trying to download so I can > test from my resources outside of North America. Just download an older nightly build of Minefield on OS X, i.e. the one from Monday Feb. 14th. Open "About Minefield" and download the full update. That's all what I'm doing here.
i have no problems with downloads - also i have 2 internetlines with about +60.000 kb/s at my homeoffice - in the past this problems were as i can remember when i hit server from japan or so
(In reply to comment #13) > Henrik, do you notice any variation during the day ? So far not. Updated another machine about 6h earlier today and had the same slow download rates.
We may have to attribute your symptoms to the providers selected to get to ftp. Have you tried contacting support of your ISPs? From our Amsterdam datacenter: 2011-02-17 22:27:18 (617 KB/s) - `firefox-4.0b12pre.en-US.mac.partial.20110215030353-20110216030352.mar' saved [3509413/3509413] real 0m6.033s user 0m0.010s sys 0m0.064s 2011-02-17 22:28:48 (519 KB/s) - `firefox-4.0b12pre.en-US.mac.complete.mar' saved [33730852/33730852] real 1m3.838s user 0m0.080s sys 0m0.558s And from our Paris office (8M SDSL): 2011-02-18 07:34:01 (650 KB/s) - `firefox-4.0b12pre.en-US.mac.partial.20110215030353-20110216030352.mar' saved [3509413/3509413] real 0m5.647s user 0m0.016s sys 0m0.062s 2011-02-18 07:35:05 (593 KB/s) - `firefox-4.0b12pre.en-US.mac.complete.mar' saved [33730852/33730852] real 0m55.894s user 0m0.055s sys 0m0.265s
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → WONTFIX
Also both of the IPs you provided are 20-40ms more than to our PAR1 or AMS1 sites.
At the moment it is working perfectly. I'm also getting the speed you have mentioned above. Ravi, probably we should try to measure throughput at the same time when that slow rates appear and not with a window of one day. If I can see the issue again, I will contact you on IRC.
This has been solved now and even in heavy loading times I get quite nice fast downloads.
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.