public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Dave Oxley <dave@daveoxley.co.uk>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user]  Re: Network collisions
Date: Wed, 05 Oct 2005 20:59:09 +1000	[thread overview]
Message-ID: <4343B1FD.6010908@daveoxley.co.uk> (raw)
In-Reply-To: <loom.20051004T154250-885@post.gmane.org>

Ok, I've fixed the problem. I've plugged both systems into my router 
(which is a switch) and they are working fine now. There is obviously a 
bug in the 8139too driver. I'll have to live with the long cables going 
to the switch for the time being though!!

Cheers for everyones help.
Dave.

James wrote:

>Dave Oxley <dave <at> daveoxley.co.uk> writes:
>
>
>  
>
>>Yeah, its a hub. I'll stop trying to set it to full duplex now.
>>    
>>
>
>  
>
>>It is 40 times quicker in one direction than the other. Can you 
>>give me a hint where to go from here.
>>    
>>
>
>Try connecting the 2 systems  with only a 'cross-over cable' run the applications
>and make measurements. If this results in an increase in the bandwidth 
>in either direction, you may want to put systems back on the hub, and 
>have a third system run ethereal. Look at your data traffic and see 
>if anythingelse is using the bandwidth from either of these 2 system 
>or what else is plug into the hub/switch.
>
>Is the hub a 10Mbps only hub/switch, check that. On 10 Mbps ethernet 
>hubs,you can never reach the full 10 Mbps, in fact with many systems 
>chattering,the practical throughput is marginally around 33%.
>
>If when you are on the cross over cable and you get similar poor 
>results,then the problem may be in the ethernet driver code, 
>kernel, irq settings or
>some other low level part of the kernel/modules, especially if 
>you get the same skewed results with several different 
>applications moving data between the systems. But, if when
> you move data between these 2 isolated system, and 
>get different bandwidth performance semantics, then the problem 
>is most likely between the applications or a bottleneck in the 
>application code (poor data structure for example).
>
>Make sure you computers are not resource limited, thus blocking 
>the processthat you are running to move the data. Top and ntop 
>are just a few toolsto help track down these sort of issues.
>
>Sadly, you may have a complex mix of part or all of these 
>aforementioned issues... 
>
>hth,
>James
>
>  
>
-- 
gentoo-user@gentoo.org mailing list



  reply	other threads:[~2005-10-05 11:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-04  5:28 [gentoo-user] Network collisions Dave Oxley
2005-10-04  9:46 ` Mark Knecht
2005-10-04 10:00   ` Dave Oxley
2005-10-04 10:16     ` kashani
2005-10-04 11:22       ` Dave Oxley
2005-10-04 11:40         ` Jonathan Wright
2005-10-04 14:04         ` [gentoo-user] " James
2005-10-05 10:59           ` Dave Oxley [this message]
2005-10-04  9:53 ` [gentoo-user] " Uwe Thiem
2005-10-05  1:31   ` Dave Oxley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4343B1FD.6010908@daveoxley.co.uk \
    --to=dave@daveoxley.co.uk \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox