[eepro100] Re: urgent question about linux driver

??? conan@linuxsecurity.co.kr
Sun, 2 Jul 2000 23:40:08 +0900


I'm very sorry for my somewhat wrong infomation from my previous mail.
I've tested more options and got some different result.
2.2.14 got the similar result to 2.0.36 when I configured some options.
bi-directional test also got the similar result to uni-directional test, too.

(below is in 2.2.14 kernel:)
The default eepro100 module reported "Too much work at interrupt..." and 
"card reports no resources" and could not send or receive any packets.
After I reloaded the module with "max_interrupt_work=800 options=0x30,0x30
rx_copybreak=10 ", the driver worked well.
But It still reported "card reports no resource" and stop to work sometimes.

Now it seems to me that all problems will be solved if the driver could resolve the case
when "card reports no resources".
I still want to hear your opinion. 
Have you ever heard about the result about the test with some packet generator like smartbit2000 ?

----- Original Message ----- 
From: "???" <conan@linuxsecurity.co.kr>
To: "Donald Becker" <becker@scyld.com>
Sent: Saturday, July 01, 2000 2:03 PM
Subject: Re: urgent question about linux driver


> Thank you for your quick reply.
> I had already configured max_interrupt_work you pointed to see what happens.
> I increased it as you told, and even had removed the max_interrupt_work check in the code,
> but the result changed little.
> 
> If you don'y mind, I want to hear your opinion.
> For now, I'm not sure where the problem lies...the driver, the NIC hardware, linux networking code, or the motherboard possibly ?
> The test was basically testing the performance of a linux machine as a router (linux should have 2 NIC).
> The phenomenon is that when the packet generator increases the number of packets (upto 100M bps with various size of raw packets from 64byte to 1024byte), the number of packets routed by linux machine decrises almost to zero.
> 
> One considerable point is that when packets are sent in uni-direction 
> (smartbit slot 1 --> linux eth0 --> linux eth1 --> smartbit slot 2)
> the problem does not occur and most packets are routed well.
> But when smartbit generates packets bi-directianal,
> (smartbit slot 1 <--> linux eth0 <--> linux eth1 <--> smartbit slot 2)
> problem begins to occur and almost all packets are dropped.
> 
> Another point is that "Too much work at interrupt ..." only coms when the kernel is 2.0.36 
> and does not come when the kernel is 2.2.14.
> Interesting result is that when I tested uni-directional, 2.0.36 performed almost twice than 2.2.14.
> when tested bi-directional, 2.0.36 says "Too much work at interrupt ..." and routes 0 packets
> while 2.2.14 says nothing but routes almost 0 packets.
> 
> Do you have any ideas ?
> 
> ----- Original Message ----- 
> From: "Donald Becker" <becker@scyld.com>
> To: "@LA>1G" <conan@linuxsecurity.co.kr>
> Sent: Saturday, July 01, 2000 12:45 AM
> Subject: Re: urgent question about linux driver
> 
> 
> > On Fri, 30 Jun 2000, @LA>1G wrote:
> > 
> > > I want to get some infomations about the linux driver of eepro100 or 3c59x,
> > > but the web pages at cesdis.gsfc.nasa.gov does not seem to available.
> > 
> >  http://www.scyld.com/network/eepro100.html
> >  http://www.scyld.com/network/vortex.html
> > 
> > > By the way, I tested that driver (or a linux machine with that driver and
> > > NIC) with hard stress using a packet generater named SmartBit2000.  The
> > > driver said, "Too much work at interrupt...." and could hardly receive or
> > > send packets.  Could you explain the meaning of the error message ?
> > 
> > The driver limits the work it does at interrupt time in order to preserve
> > real-time response.
> > If you are using the driver with a configuration/machine where this causes a
> > problem, you can reduce the impact or turn off this feature with the
> > 'max_interrupt_work' driver parameter.
> > 
> >   insmod 3c59x  max_interrupt_work=200
> > 
> > or put the following into /etc/conf.modules  
> >   options 3c59x  max_interrupt_work=200
> > 
> > Donald Becker becker@scyld.com
> > Scyld Computing Corporation http://www.scyld.com
> > 410 Severn Ave. Suite 210 Beowulf Clusters / Linux Installations
> > Annapolis MD 21403
> > 
> > 
> > 
>