Re: Longstanding networking / SMP issue? (duplextest)

[jamal <hadi@cyberus.ca>]

I got you. I think its a clever idea. You have better chances if you
make your packets larger.
Netdev is the network developers mailing list at netdev@oss.sgi.com
Linux-net is network users mailing list;

cheers,
jamal

On Wed, 19 Feb 2003, Simon Kirby wrote:

> On Wed, Feb 19, 2003 at 08:40:47PM -0500, jamal wrote:
>
> > Hi, could you please either posting or ccing netdev on network related
> > issues? There are a lot of people who could help you but are not
> > subscribed to lk.
>
> Is netdev separate from linux-net?  If so, where is it? :)
>
> > I dont have an answer for you. I think testing a different card like
> > Dave says would be a good start. I am curious about the theory of
> > operation of your program; by duplex mismatch i take it you mean one end
> > has one speed setting but the other has a conflicting one?
> > If thats so i am not sure i understand why sending a burst of packets
> > and waiting for responses catches this problem. Are you saying
> > you could successfully send but fail to receive? I dont see the connection
> > and i am curious.
>
> Here's the story...
>
> Once upon a time, Donald wrote (or helped write, I don't know) the eepro100
> driver.  Because Intel had so many variants of the eepro100, it was
> difficult to implement link autonegotiation because different cards had
> the link state detection wired to different pins.  Even today, the eepro100
> driver doesn't seem to autonegotiate with any of the switches I've tried
> it with.  (10/100 autonegotiates fine, but the duplex does not.)
>
> To get around this problem, we had to force our switch ports to 100/full
> and force the eepro100 driver to 100/full also.  This works well, but
> because we have hundreds of boxes running diferent OSs and we tend to
> move things aroud fairly often, it's easy to forget to set up the port
> properly.  When this happens, everything appears to work, but depending
> on timing, some packets are dropped due to one side believing there is a
> collision while other side sees no problem.  (This assumes you understand
> how Ethernet works -- if not, let me know!)
>
> The timing required to hit the packet loss is actually quite important.
> Web site visitors can often download at fairly high speeds over the
> Internet (600 kB/sec, for example) from a machine with a duplex mismatch,
> but internally (on the same LAN), transfer rates can be as low as 20
> kB/sec, although usually about 60 kB/sec, depending on the number of
> switches being traversed, luck, etc.
>
> The duplextest program attempts to set up a timing situation that
> exploits the half-collision scenario by sending multiple echo packets at
> once, so that the first will be on the way back while the latter are
> still being sent.  "ping -f" doesn't work for this because it always uses
> a timer and only sends one packet.
>
> I hope this explains things...
>
> Simon-
>
> [        Simon Kirby        ][        Network Operations        ]
> [     sim@netnation.com     ][     NetNation Communications     ]
> [  Opinions expressed are not necessarily those of my employer. ]
>