Closed Bug 608182 Opened 15 years ago Closed 15 years ago

Slow updates for some users

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 INVALID

People

(Reporter: cilias, Unassigned)

Details

There are some users in the Firefox newsgroup complaining about constantly slow update downloads, under 100KB/s. Here are the threads: http://groups.google.com/group/mozilla.support.firefox/browse_frm/thread/ebb703e41874ff86 http://groups.google.com/group/mozilla.support.firefox/browse_frm/thread/51a247a10764c891 I asked for traceroute info from releases.mozilla.org, and they gave me this: 10/27/10 16:49:17 Fast traceroute releases.mozilla.org Trace releases.mozilla.org (64.50.236.214) ... 1 192.168.1.1 0ms 3ms 0ms TTL: 29 (No rDNS) 2 10.110.240.1 9ms 12ms 16ms TTL:254 (No rDNS) 3 96.34.112.53 16ms 9ms 9ms TTL:253 (acr01nrictx-gbe-9-3.ftwo.tx.charter.com bogus rDNS: host not found [authoritative]) 4 96.34.113.47 13ms 26ms 11ms TTL:252 (96-34-113-47.static.unas.tx.charter.com ok) 5 96.34.113.8 13ms 10ms 9ms TTL:251 (dtr01ftwotx-tge-4-2.ftwo.tx.charter.com bogus rDNS: host not found [authoritative]) 6 96.34.113.20 13ms 10ms 10ms TTL:250 (dtr01ftwotx-gbe-9-12.ftwo.tx.charter.com bogus rDNS: host not found [authoritative]) 7 96.34.2.32 11ms 10ms 9ms TTL:249 (bbr01ftwotx-tge-0-0-5-0.ftwo.tx.charter.com bogus rDNS: host not found [authoritative]) 8 4.71.216.5 12ms 14ms 16ms TTL:247 (so-6-0-0.edge4.Dallas1.Level3.net ok) 9 4.69.145.180 17ms 14ms 20ms TTL:247 (ae-83-80.ebr3.Dallas1.Level3.net ok) 10 4.69.134.22 32ms 47ms * TTL:246 (ae-7-7.ebr3.Atlanta2.Level3.net ok) 11 4.68.103.44 32ms 44ms 30ms TTL:245 (ae-27-52.car1.Atlanta4.Level3.net ok) 12 4.53.233.142 34ms 31ms 32ms TTL: 53 (TDS-TELECOM.car1.Atlanta4.Level3.net ok) 13 64.50.238.217 57ms 56ms 55ms TTL:242 (mtjltndst52-tg0-7-4-0.network.tds.net ok) 14 64.50.234.65 70ms 63ms 65ms TTL:241 (mtjltndst51-tg0-0-4-0.network.tds.net ok) 15 64.50.224.233 62ms 59ms 62ms TTL:242 (chcgildtcor52-tg0-0-2-0.network.tds.net ok) 16 64.50.224.210 64ms 74ms 62ms TTL:241 (chcgildtcor53-giten9-1.network.tds.net ok) 17 64.50.236.214 64ms 62ms 61ms TTL: 50 (mirror2.mirrors.tds.net ok) Tracing route to releases.geo.mozilla.com [155.98.64.83] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms homeportal [192.168.1.254] 2 21 ms 20 ms 20 ms 99-100-0-2.lightspeed.irvnca.sbcglobal.net [99.1 00.0.2] 3 25 ms 21 ms 20 ms 75.20.13.204 4 * * * Request timed out. 5 * * * Request timed out. 6 21 ms 21 ms 22 ms 151.164.102.64 7 21 ms 21 ms 21 ms ex2-p14-0.eqlaca.sbcglobal.net [151.164.39.189] 8 21 ms 21 ms 21 ms te4-5.mpd01.lax05.atlas.cogentco.com [154.54.12. 53] 9 21 ms 22 ms 21 ms te0-1-0-1.mpd22.lax01.atlas.cogentco.com [154.54 .6.189] 10 34 ms 34 ms 34 ms te0-1-0-6.mpd22.sfo01.atlas.cogentco.com [154.54 .3.134] 11 34 ms 34 ms 35 ms te4-1.ccr01.oak01.atlas.cogentco.com [154.54.24. 114] 12 37 ms 37 ms 37 ms te4-1.ccr01.smf01.atlas.cogentco.com [154.54.26. 229] 13 50 ms 50 ms 50 ms te3-3.ccr01.slc01.atlas.cogentco.com [66.28.4.19 3] 14 51 ms 50 ms 50 ms te3-4.ccr01.slc02.atlas.cogentco.com [154.54.28. 38] 15 59 ms 59 ms 59 ms 38.104.174.66 16 60 ms 59 ms 59 ms ebc-p-a-170.uen.net [140.197.252.81] 17 59 ms 59 ms 59 ms ebc-pe-a-178.uen.net [140.197.252.71] 18 60 ms 59 ms 59 ms 205.124.249.118 19 60 ms 60 ms 61 ms 199.104.93.17 20 60 ms 60 ms 60 ms crpark-wr1ebc.net.utah.edu [155.99.132.102] 21 * * * Request timed out. 22 60 ms 60 ms 60 ms gw-soc-r2-eng.cs.utah.edu [155.98.127.22] 23 * * * Request timed out. 24 * * * Request timed out. 25 * * * Request timed out. 26 * * * Request timed out. 27 * * * Request timed out. 28 * * * Request timed out. 29 * * * Request timed out. 30 * * * Request timed out. Trace complete. Does that info help at all?
OS: Mac OS X → All
Hardware: x86 → All
Assignee: server-ops → network-operations
Component: Server Operations → Server Operations: Netops
Unfortunately not. releases.mozilla.org isn't the right place to test (and is a DNS pool anyways). The right place to check depends on the update channel the user is on, which can be found at app.update.channel in about:config. If they're on 'release' then download.m.o will redirect to a mirror that's close based on geo-ip. That's obviously going to vary based on the user's location, the mirrors, the time of day, other software releases, phase of the moon, etc. You can sometimes figure mirror which by running netstat in a terminal/cmd window. Hopefully we will backport bug 597664 to 3.6. If they're on 'beta' then they go to ftp.m.o, which is also used for nightly updates. I could believe that ftp.m.o wasn't keeping up all of the time but it's unlikely many of those people will be on the beta channel, since that requires installing a beta version and installing final or point release later. IMO it's not reasonable that people expect their 5+ Mbps lines will be saturated; nor are comparisons to Google useful, since they have a 3 times smaller user base and much larger infrastructure. I do agree that only a few KB/s is poor experience, but bear in mind that the majority of users are doing background updates, grabbing 300KB every 10 minutes.
Punting back. Its not really a network issue netops can handle (it's external to Mozilla).
Assignee: network-operations → server-ops
Component: Server Operations: Netops → Server Operations
I'm not really sure what the next step is. Is there anything I can ask those users to do that would help you? Is this invalid?
You could ask these users to provide this info * where they live (roughly) * what mirror they are hitting when get slow updates (see comment above about netstat) * does the problem persist if they shut down Firefox while the download is running, wait a few seconds then restart. They should get another mirror
Doesn't feel like there's any IT fix here. We monitor performance from San Jose but it's difficult to catch performance issues from all parts of the globe on networks we don't directly manage. Some of the posts mention ftp.mozilla.org which we do manage. I'll followup in the newsgroups on that.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → INVALID
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.