Intel Pro100+(82559) Polling Driver Problems (More Data)
Pramod John
pramod at oration.com
Fri Mar 1 19:38:55 EST 2002
Here is an update after some more investigation....
Today I re-compiled click (from today's cvs) and linux version 2.2.20
and 2.4.9.
The test setup:
RTR - Two intel 82559 Interfaces, Pentium (yes the original) 200, SIS
5597 Chipset
CLT1 - Linux box/ Intel 82559
CLT2 - Cisco PIX FW w/Intel 82559 ( No wonder Intel is doing so well.:)
CLT1 is directly cabled to RTR, while RTR connects to CLT2 through a
10Mb/HUB and a 100Mb/Switch.
I am running a ping -f from CLT1 to RTR and a second ping -f to CLT2
This was just to be able to see gross variances, not precise ones...
Devices
Kernel Click Interrupts Polling Results (ping time/pps)
CLT1-RTR 2.2.20 X 150us/6K
CLT1-RTR 2.4.9 X 80us/8K
CLT1-RTR 2.2.20 X X 200us/5K(Erratic)
CLT1-RTR 2.2.20 X X 300us/200(Very Erratic)
CLT1-RTR 2.4.9 X X 150us/7K(Slightly Erratic)
CLT1-RTR 2.4.9 X X 200us/300(Very Erratic)
CLT1-CL2 2.2.20 X 450us
CLT1-CL2 2.4.9 X 400us
CLT1-CL2 2.2.20 X X 500us
CLT1-CL2 2.2.20 X X 600us
CLT1-CL2 2.4.9 X X 400us
CLT1-CL2 2.4.9 X X 250us
Please note that the pps totals are for all traffic, I was too lazy
to break it apart. As you can see polling being turned on suggests
that something is fundamentally wrong, it really isn't an issue of
some type of uniform performance degradation. I also verified by
looking at the interrupt counters etc, to guarantee that interrupts
had been disabled for poll mode. In addition, none of the
error/lost/dropped packet counters had any values above 0. I am
attaching my conf, in case anyone wants to peruse it and see if I
screwed up anything on it.
I am really curious if anyone has had a good experience with this Card
and if so what the peformance and hardware specs were.
thanks,
Pramod
The Polling configuration, is identical the conf below with the
FromDev..changed to PollDev...
// Generated by make-ip-conf.pl
// eth0 192.168.10.254 00:90:27:91:1E:6D
// eth1 192.168.11.1 00:90:27:91:1C:9C
tol :: ToLinux;
t :: Tee(3);
t[2] -> tol;
c0 :: Classifier(12/0806 20/0001,
12/0806 20/0002,
12/0800,
-);
FromDevice(eth0) -> [0]c0;
out0 :: Queue(200) -> todevice0 :: ToDevice(eth0);
arpq0 :: ARPQuerier(192.168.10.254, 00:90:27:91:1E:6D);
c0 [1] -> t;
t[0] -> [1]arpq0;
arpq0 -> out0;
ar0 :: ARPResponder(192.168.10.254 00:90:27:91:1E:6D);
c0 [0] -> ar0 -> out0;
c1 :: Classifier(12/0806 20/0001,
12/0806 20/0002,
12/0800,
-);
FromDevice(eth1) -> [0]c1;
out1 :: Queue(200) -> todevice1 :: ToDevice(eth1);
arpq1 :: ARPQuerier(192.168.11.1, 00:90:27:91:1C:9C);
c1 [1] -> t;
t[1] -> [1]arpq1;
arpq1 -> out1;
ar1 :: ARPResponder(192.168.11.1 00:90:27:91:1C:9C);
c1 [0] -> ar1 -> out1;
rt :: StaticIPLookup(
192.168.10.254/32 0,
192.168.10.255/32 0,
192.168.10.0/32 0,
192.168.11.1/32 0,
192.168.11.255/32 0,
192.168.11.0/32 0,
192.168.10.0/255.255.255.0 1,
192.168.11.0/255.255.255.0 2,
255.255.255.255/32 0.0.0.0 0,
0.0.0.0/32 0,
0.0.0.0/0 192.168.10.1 1);
rt[0] -> EtherEncap(0x0800, 1:1:1:1:1:1, 2:2:2:2:2:2) -> tol;
ip :: Strip(14)
-> CheckIPHeader(192.168.10.255 192.168.11.255 )
-> [0]rt;
c0 [2] -> Paint(1) -> ip;
c1 [2] -> Paint(2) -> ip;
rt[1] -> DropBroadcasts
-> cp0 :: PaintTee(1)
-> gio0 :: IPGWOptions(192.168.10.254)
-> FixIPSrc(192.168.10.254)
-> dt0 :: DecIPTTL
-> fr0 :: IPFragmenter(1500)
-> [0]arpq0;
dt0 [1] -> ICMPError(192.168.10.254, 11, 0) -> [0]rt;
fr0 [1] -> ICMPError(192.168.10.254, 3, 4) -> [0]rt;
gio0 [1] -> ICMPError(192.168.10.254, 12, 1) -> [0]rt;
cp0 [1] -> ICMPError(192.168.10.254, 5, 1) -> [0]rt;
c0 [3] -> Print(xx0) -> Discard;
rt[2] -> DropBroadcasts
-> cp1 :: PaintTee(2)
-> gio1 :: IPGWOptions(192.168.11.1)
-> FixIPSrc(192.168.11.1)
-> dt1 :: DecIPTTL
-> fr1 :: IPFragmenter(1500)
-> [0]arpq1;
dt1 [1] -> ICMPError(192.168.11.1, 11, 0) -> [0]rt;
fr1 [1] -> ICMPError(192.168.11.1, 3, 4) -> [0]rt;
gio1 [1] -> ICMPError(192.168.11.1, 12, 1) -> [0]rt;
cp1 [1] -> ICMPError(192.168.11.1, 5, 1) -> [0]rt;
c1 [3] -> Print(xx1) -> Discard;
Brecht Vermeulen wrote:
>>The .19 patch actually installs without any major complaints... But to be
>>honest
>>I don't know if this is the source of the problems. The changes from
>>.19 ->.20
>>were pretty minor. I could try the .19, is that currently what you use ?
>>
>
> without any major complaints : does this mean, no complaints ? :-)
>
> we use indeed 2.2.19, but I've never used the eepro100 driver, so can't
> help you on this.
>
> We had also a problem with the polling of tulip cards on the 2.4.9
> kernel while it works perfectly on 2.2.19, but this is not the same of
> course.
>
>
> sorry that I cannot be of more help,
> Brecht
>
>
>>>Or are you using userlevel mode ?
>>>
>>>I think polling doesn't work in userlevel mode. (but I don't know how it
>>>comes that your configuration works then)
>>>
>>Kernel Module.
>>
>>The changes to the eepro100.c driver were made while back in the 82258 days
>>I don't know whether Benjie and those guys tested with 82558 or 9...
>>
>>thanks,
>>
>>Pramod
>>
>>
>>>regards,
>>>Brecht
>>>
>>>
>>>>Pramod John wrote:
>>>>
>>>>Hi,
>>>>
>>>> I am having some problems with the Intel 82259 polling drivers.
>>>>Does anyone have any experience with them ?
>>>>My system particulars are as follows:
>>>>
>>>> Click: 1.2.3a
>>>> Linux: 2.2.20
>>>>
>>>> I have created a generic router configuration using the
>>>>make-ip-conf.pl script. I have two interfaces and am pinging
>>>>through the router with click. I see about about a factor of 100X
>>>>drop in performance when I switch the config from
>>>>interrupt to polling.
>>>>
>>>>Any ideas why this might be occurring ? Any suggestions on how to
>>>>debug this further ?
>>>>
>>>>thanks,
>>>>
>>>>Pramod
>>>>
>>>>
>>>>
More information about the click
mailing list