The slowdown wasn't due to internet,
but the listing on the pc it'self .... (As in 'building file list')
The download isn't a problem.

> I'm glad that the memory worked, but another trick we found was using 
> http instead of ftp.
> Even if the ftp and http server are just as fast at getting a file to 
> you, the python getUrl code is very different, and with ftp takes quite 
> a few more interactions with the server.
> That is the reason we switched the default yum-conf configurations from 
> ftp to http.
> Troy
> 
> Killian De Volder wrote:
>> Thank you, that solved the issue !
>> (odly enough i check for swapping issues, but it didn't seem to  use 
>> it, must have
>> overlooked it)
>>
>>> On Mon, 21 Apr 2008, Killian De Volder wrote:
>>>
>>>> Hello,
>>>>
>>>> Since a certain point in time (i'm afraid I do not recall what
>>>> triggered it),
>>>> yum is slow. Not slow as in ... lets wait, 5 or even 20 mins. But
>>>> longer...
>>>> I don't even know how long it takes ... that's how slow it is.
>>>>
>>>> I'm not sure how I can begin to debug or resolve this issue ? Any
>>>> advise ?
>>>> (64mb ram, 23MB/Sec hdparm speed, yum version 2.4.3)
>>> Try adding more memory!
>>>
>>> At some point we discovered that the sl5 installations we were doing
>>> just stalled on machines with < 768M ram.  These are kickstart installs
>>> where we were pointing at two repos:
>>>
>>>   the base sl50 repo (well our local mirror of it)
>>>
>>>   an additional repo containing *all* sl50 security updates plus our 
>>> local
>>>    packages
>>>
>>> At some point the total number of available packages causes the anaconda
>>> (using the yum code!) to need rather more memory than was available.
>>>
>>> (during install there is no swap and some memory is already taken by the
>>> initrd and tmpfs stuff).
>>>
>>> When we first started using this kickstart setup with sl50 384M was
>>> enough (though pretty slow), and since little else has changed so I
>>> assume that it is a problem with the number of available packages that
>>> the yum code has to check.
>>>
>>> Oddly enough the installer gets as far as starting the actual
>>> installation but then after a few hundered packages gets 'stuck'.
>>> Switching to a text VC shows that anaconda is swapping furiously and we
>>> have loads of disk i/o but no useful progress.
>>>
>>> A machine with ~512M ram installed at a time before there were so many
>>> updates doesn't seem to have a big problem with doing yum updates but
>>> that may simply be that it doesn't have so much memory stolen by initrd
>>> etc.
>>>
>>> We are about to globally update to sl51 which may help simply because
>>> there are (currently) fewer security updates...
>>>
> 
>