Ethernet Errors - One Direction Only

[John]

Dan,

Here are some items...

(a) Replaced D-Link in Linux with Linksys 10/100 that uses the tulip
driver.  Good & bad.
Now, transfer rates have not changed Linux --> Win.  Win --> Linux I still
have a bunch of overrun errors in the RX side, BUT it doesn't bring the
network down and will complete transfers with reliable data.  Shuffled my
50 Meg winzip file back and forth many times and it always checked good in
either direction.  Linux --> Win, 2.3Mbps, Win --> Linux 900Kbps.

(b) A friend of mine and I were talking about MTUSpeed and we searched the
registry for mtu with  no results.  So decided to use MTUSpeed and set an
mtu anyway, even if it said it was for the dial up.  Hummm...  Had a little
luck there.  Apparently it set the mtu for the tcp/ip everything.  Setting
the 1500 MTU, no difference.  Setting 576 MTU reduced the errors by about
50% and increased Win --> Linux to about 1.3Mbps.

(c) I looked in my /proc/sys/net/ipv4 and couldn't find anything related
(in english) to mtu.

Does anybody know how to correctly tweak the variables in the tulip driver?
 There are some comments about user settings and I have tweaked a couple,
but have now put them back to the defaults where they were.


/* Maximum events (Rx packets, etc.) to handle at each interrupt. */
static int max_interrupt_work = 25;
Went from 10 --> 30.  No apparent change.

#define RX_RING_SIZE	32  Went to 64, no apparent change

I'm really afraid to go very far in the source code <G>  Maybe somebody out
there can point me in the right direction.

BTW, the tulip driver that came with 2.2.13 Kernel (From kernel.org, not a
distro) etc, did not work.  Used the tulip from the install disk provided
by Linksys.

Tomorrow or Friday, my video card for my new machine should be here.  From
there, unless somebody comes up with a resolution, I will put the linksys
in the new WinBlows and a D-Link in the Penguin and try it that way and see
what happens.

For what it's worth, I am running an AMD K2-450 on a Shuttle 591P with a
Via MP3  Chipset, 100Mhz FSB, and 64 Meg Ram.

Lend me your thoughts on the above <G>

Have a good evening...

At 07:25 PM 1/4/2000 -0800, Dan Kaminsky wrote:
>OK, I'm game for solving this one...

>MTU
>===
>1)  Go to www.nonags.com and find a tool to change your MTU(Maximum
>Transmission Unit) value.  You've got a range from 522 to 1500 bytes per
>packet.  If either extreme "just works", oscillate by halves(10 fails, 5
>works, 8 fails, 7 works--7 is highest value that works) until you find the
>"limiting value"
>2)  There's a MTU value within /proc/sys/net/ipv4 on the Linux box.  Fudge
>that too.
>
>NIC
>===
>1)  Change the NIC on the Windows machine--use the following commands to
>save your registry before you futz w/ your drivers, and you'll be able to
>go back painlessly.  (I always do this before I blast apart people's
>systems.)

>2)  Change the NIC on the Linux machine.  This is my prime culprit--I'm
>betting the drivers on the Linux side aren't coping with some signal
>they're getting from the Windows side.  (We operate on a higher standard
>in Linux--this instability has a DoS Security Breach
>Flipside.)  Preferably, toss in a tulip and after the system boots, just
>run insmod tulip.


John Jaeger - Billings, Montana

EMail To	: <mailto:john at jjgb.com>
Home Page	: <http://www.jjgb.com>

PGP:
RSA Key ID: 0xAAEC7751  <http://www.jjgb.com/public_files/RSA_Key.zip>
DSS Key ID: 0x5E90BEC7   <http://www.jjgb.com/public_files/DSS_Key.zip>

"Our liberty is protected by four boxes... 
    The ballot box, the jury box, the soap box, and the cartridge box."
                                   - Anonymous