F12: Yum - network disconnects spins it's wheels.
Daniel B. Thurman
dant at cdkkt.com
Sat Feb 27 00:50:47 UTC 2010
On 02/26/2010 03:59 PM, Ed Greshko wrote:
> Daniel B. Thurman wrote:
>
>> On 02/25/2010 09:34 PM, Ed Greshko wrote:
>>
>>
>>> Tony Nelson wrote:
>>>
>>>
>>>
>>>> On 10-02-25 21:37:58, Ed Greshko wrote:
>>>> ...
>>>>
>>>>
>>>>
>>>>
>>>>> I can't conceive of a situation where usage of http or ftp protocol
>>>>> would interact to "smack" an imap connection.
>>>>>
>>>>> To me, based on your observations, I'm getting the feeling you may
>>>>> have a strange network problem that may be local to you or within
>>>>> your ISP close to you. As I said, I'd be dragging out wireshark.
>>>>>
>>>>>
>>>>>
>>>>>
>>>> It's not FastestMirror, it's the mirror it's choosing to use. If he
>>>> figures out which one, he can blacklist it.
>>>>
>>>>
>>>>
>>>>
>>>>
>>> That is what the case was in my situation although maybe I didn't spell
>>> it out. However, I did say that Singapore was causing an issue for me
>>> and I added the line "exclude=.gov, .sg" to my fastestmirror.conf.
>>>
>>> But, when he says that his IMAP connection is *also* being affected then
>>> I can't conjure a situation where yum would have an impact on IMAP
>>>
>>>
>> I can try to find out if it is a mirror problem, but then again, I thought
>> that mirrors were randomly chosen and if a mirror is not responding
>> properly or whatever it is, the offending mirror should have been dropped
>> and another mirror tried. From past Yum versions, I have seen this to
>> be the case, and I have not seen any such thing with F12's Yum version
>> which lead me to question if mirror testing/switching code was
>> dropped? I hope I am wrong in my assumptions.
>>
> AFAIK, haven't done any research, without FM mirrors are chosen more or
> less at random. With FM a list is generated and the fastest mirror
> found. Then every time yum is run the list is used.
>
>> Is it possible that the network is somehow using maximum bandwidth
>> preventing network access to other apps? The IMAP network break
>> seemed to prevent IMAP client connectivity temporarily and once yum
>> stopped, IMAP client connections quickly resumed.
>>
>> I have a pretty quiet network and it seems to me, that somehow running
>> yum with FM causes problems. Removing FM seems to work but it is
>> not maxing out the bandwidth. For example, with FM, it is hitting hard
>> at around 300-320KB/s but without it, it is hitting around 200-290KB/s
>> which is notably slower as you watch the downloads.
>>
> First, the only thing that FM does is determine what mirror it feels
> will get your the best download speed. That is all that is does.
> Period, end of story. If you use FM and you get higher speed downloads
> on updates then it is doing its job.
>
> If high download speeds are really causing problems, not just hogging
> your connection and slowing down other types of downloads, then a
> network problem could exist.
>
> What kind of connection do you have? I've got DSL with advertised
> speeds of 2MB/515Kb. I run "slingplayer" on my Vista system and viewing
> is crisp and clear and no noticeable impact on browsing. That is, until
> I start downloading a torrent or two while simultaneously doing
> updates. Then the browsing is slower, the TV isn't as clear. But that
> is to be expected. But, nothing dies.
>
I have 3-5MB/1Mb. Interestingly, as I said before, using the same
system, I do not have a problem at all using F9 and F11! Must
have installed *something* that might be getting in the way?
Beats me!
Nothing dies on F12, but Yum hangs using FM. That is the
only thing I am seeing. Ahh, well... I can live without FM.
> If you are getting a situation where a high speed download results in
> everything degrading into being unusable then a hardware problem in your
> path could exist. This was years ago, but I once had a problem where a
> router suffered from buffer overruns when traffic was extremely high.
> It would throttle connections and start throwing away data resulting in
> many retransmissions. To make a long story short, it couldn't
> gracefully recover and caused high packet loss in spikes. Made finding
> the problem hard.
>
Ugh.
More information about the users
mailing list