Is there a way to speed up download from RHN ?

Latest response

Hi everybody,

 

I'm becoming mad with the slow downloads I have to do from RHN.

When I'm doing a "yum update", or ever worse, downloading an ISO, I download at 6K/s.

 

For RHEL 6.1 BETA, for example, I get an eta of ... 7 days.

As the download link for ISOs are valid a limited period, I have to start again the download again and again...

Very time consuming, in fact.

 

I already tried by night, but I couldn't get better speeds.

Is there any way to speed up the downloads, or to switch (ever manually) to another mirror ?

 

Thanks in advance for your help :-)

Responses

I don't see speeds like that. ISOs typically take less than an hour to grab and `yum` operations typically take only a few tens of seconds to run (for simple, one or two packages/dependencies operations). Are you sure you aren't having networking issues (or NIC misconfiguration problems)?

 

Most frequent cause I've seen on our networks with network speeds has been due to NIC misconfiguration for the switches the hosts are attached to (e.g., relying on auto-negotiation when the switch ports are statically-configured; wrong bonding options, etc.).

As I administer both the network and the servers, I started by thinking to that, too.

But I quickly excluded this possibility, for two reasons :

  • Downloads from other sites oppers at a much higher speed (4 M/s)
  • I tried to download the RHEL ISO from two other sites (one in Belgium, one in France), and got the same problem

Only thing left to ask would be "are the files from the other sites of a similar nature". That is, might you be running into storage or networking problems associated with the size or composition of the data stream?

I compared the bandwith with DVD ISOs from other vendors.
That was, for me, the best way to compare things that can be compared.

Hi Sebastien,

All of our packages and ISOs from the Customer Portal and Red Hat Network (RHN) are served out via a Content Distribution Network (CDN), which means there are servers local to your region that host the content.  However, in cases where you are the first to download a piece of content in your region, the download may be slower than usual because that file has not yet been seeded in your area.  The next time it gets downloaded, it should be cached by the CDN and your download should be much faster.

 

So, could you try downloading something small (like an rpm package, with yum), then try it again and see if its faster the second time?  If so, then the cause is likely what I described above. 

 

If however you don't see an increase in speed, then there may be something in your environment causing the performance issues.  As noted by others on this thread, slow access from RHN is not a common symptom we see, so we'll want to rule out anything local to your system.

 

Regards,

John Ruemker, RHCA
Red Hat Technical Account Manager

Online User Groups Moderator

Hi John,

 

I were just able to test your suggestion, with a quite used package I think : mysql.

Unfortunately, we can exclude this cause.

The first 300 kB downloaded quite quickly, but the download felt after at 6K/s.

 

Thanks for your suggestion,

 

Sebastien Baguette.

Have you tried using `tcpdump` to see which specific host/address is acting as the source for your problematic downloads? It might be worth seeing if you're getting a consistent CDN-source and then seeing what the network between you and that CDN-source is like. Dunno how to solve your problem, but isolating a source/cause moves us in the right direction.

I just got the time to follow your suggestion.

 

It seems that I got everytime one of these hosts.

All of them seems to point to Akamai Technologies servers.

 

2.20.116.218

95.100.164.218
95.101.0.218

 

 

All hops to the 10th one included are probably OK.
I can download other ISOs without problem, and they share the same first 10 hops.

 

traceroute to 2.20.116.218 (2.20.116.218), 30 hops max, 40 byte packets
 1  10.0.0.11 (10.0.0.11)  0.123 ms  0.115 ms  0.129 ms
 2  cisco.20.172.in-addr.arpa (172.20.0.1)  2.764 ms  2.900 ms  3.018 ms
 3  belgacom1.sav-dnv.be (192.168.0.2)  1.949 ms  2.053 ms  2.136 ms
 4  172.22.148.185 (172.22.148.185)  5.016 ms  5.625 ms  5.718 ms
 5  2.5-13-195.static.isp.belgacom.be (195.13.5.2)  6.185 ms  6.274 ms  6.523 ms
 6  1.5-13-195.static.isp.belgacom.be (195.13.5.1)  6.631 ms  6.574 ms  6.622 ms
 7  dialup4.brussel.belbone.be (195.13.4.4)  6.724 ms  5.869 ms  5.671 ms
 8  dialup3.brussel.belbone.be (195.13.4.3)  6.128 ms  6.286 ms  6.351 ms
 9  be2.intlstr2.isp.belgacom.be (194.78.0.140)  5.968 ms be1.intlstr2.isp.belgacom.be (194.78.0.40)  6.146 ms  6.116 ms
10  bru-11-r7-t3-3.car.belbone.be (80.84.21.98)  6.458 ms  6.150 ms  6.563 ms
11  amsix-ams6.netarch.akamai.com (195.69.145.208)  13.684 ms  12.990 ms  12.610 ms
12 * * *

I'm getting a solid 98kB/s as I download the RHEL 6 Client DVD, which is nowhere near what I should be seeing. Is there a way to try a different mirror?

 

[edit] Downloading much faster on campus. Maybe it was a routing issue?

Hi,

 

Very, very slow from here too. Download speed from RHN under 90 K/s. More than one hour to download: rhel-server-5.6-i386-disc1.iso

 

While at same time the download speed for the file

 

ftp://fedora.c3sl.ufpr.br/kurumin-ng/ISO/kurumin-ng_8.06.iso

 

is 1.67M/s.

 

1 - Is it possible to download ISO files using other protocol than https?

 

2 - Is there a CDN "mirror" in Brazil? How can I download from it?

 

Thank you!

Well, the answer is coming wayyyy after, and I usually never "up" a post like this.

But as other people complained about the same problem, I'll do it for once, for the.

 

It was well our network which were in cause.

The problem was caused by a CISCO router, which was configured by a third party.

As I got access on it, I could see the following inspect rule : ip inspect name inspectName https

 

Removing the rule solved immediately our problem.

This rule usually cause no problem, but on some sites, it can become problematic.

Hi Sebastien, I'm glad you got your issue resolved. Thanks for following up!