* major network performance difference between 2.4 and 2.6.2-rc2
@ 2004-01-31 3:06 Jim Faulkner
2004-01-31 14:28 ` Felipe Alfaro Solana
2004-02-04 20:42 ` Jim Faulkner
0 siblings, 2 replies; 11+ messages in thread
From: Jim Faulkner @ 2004-01-31 3:06 UTC (permalink / raw)
To: linux-kernel; +Cc: akpm
There is a major networking performance problem on my machine under recent
2.6 kernels. I have a dual Athlon-MP machine with an onboard Intel
Ethernet Pro 100 device, which can use either the e100 or eepro100 driver.
I ran some tests under 2.4 and recent 2.6 kernels to see what kind of
performance I could get. I tested using both ftp and samba, the client
machine is a windows box with an onboard 3com 3c920b controller. They
are connected through a D-Link 100 megabit full duplex switch.
Under both 2.6.2-rc2 and 2.6.2-rc2-mm2, the performance is pretty bad.
Copying 4.3 gigabytes of data from the linux machine to the windows box
via samba takes about 35 minutes. LFTP shows FTP transfers from the linux
box to the windows box to go at about 2 megabytes per second. The
performance is even worse in the opposite direction, LFTP shows transfers
from the linux box to the windows box to be around 1.5 megabytes per
second.
I repeated the above tests with both the e100 driver and the eepro100
driver and got the same results. Running ifconfig shows "errors:0
dropped:0 overruns:0 frame:0" and "errors:0 dropped:0 overruns:0
carrier:0 collisions:0" for the device.
Unfortunately my OS (unstable Gentoo) does not appear to support 2.4
kernels anymore, so I had to use a Knoppix CD to test 2.4 kernels. I am
using Knoppix nov 19 2003 version, which I believe uses a 2.4.21 or 2.4.22
kernel. It uses the eepro100 driver.
Under the Knoppix 2.4 kernel, using the exact same samba configuration
file, I was able to copy 4.3 gigabytes of data from the linux machine to
the windows machine in about 8 minutes. Copying in the opposite direction
takes about 10 minutes. Unfortunately Knoppix doesn't include an FTP
server so I wasn't able to test that.
It appears that my network device is capable of 4 times the throughput
under 2.4 kernels versus recent 2.6 kernels. I believe this problem arose
recently, probably sometime since 2.6.0, since I only recently noticed
this performance issue.
I don't know if this problem is specific to my configuration or not, so
included below is lots of configuration information. Please note that the
funky modules like nvidia, vmware and cbm were not loaded when I ran my
tests.
thanks,
Jim Faulkner
delta-9 linux # cat /proc/version
Linux version 2.6.2-rc2-mm2 (root@delta-9) (gcc version 3.3.2 20031218
(Gentoo Linux 3.3.2-r5, propolice-3.3-7)) #1 SMP Fri Jan 30 16:07:03 EST
2004
delta-9 linux # scripts/ver_linux
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux delta-9 2.6.2-rc2-mm2 #1 SMP Fri Jan 30 16:07:03 EST 2004 i686 AMD
Athlon(tm) MP 2200+ AuthenticAMD GNU/Linux
Gnu C 3.3.2
Gnu make 3.80
util-linux 2.12
mount 2.12
module-init-tools 3.0-pre8
e2fsprogs 1.34
PPP 2.4.2
nfs-utils 1.0.6
Linux C Library 2.3.3
Dynamic linker (ldd) 2.3.3
Procps 3.1.15
Net-tools 1.60
Kbd 1.12
Sh-utils 5.0.91
Modules Loaded nvidia vmnet vmmon btaudio amd_k7_agp agpgart
8139too e100 parport_pc cbm parport
delta-9 linux # cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 8
model name : AMD Athlon(tm) MP 2200+
stepping : 1
cpu MHz : 1800.573
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow
bogomips : 3538.94
processor : 1
vendor_id : AuthenticAMD
cpu family : 6
model : 8
model name : AMD Athlon(tm) MP
stepping : 1
cpu MHz : 1800.573
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow
bogomips : 3596.28
delta-9 linux # cat /proc/modules
nvidia 2071816 12 - Live 0xf92e1000
vmnet 32784 2 - Live 0xf8e07000
vmmon 81192 0 - Live 0xf8f55000
btaudio 17488 1 - Live 0xf8ded000
amd_k7_agp 7820 1 - Live 0xf8d93000
agpgart 32748 2 amd_k7_agp, Live 0xf8d9a000
8139too 25728 0 - Live 0xf8ad2000
e100 34816 0 - Live 0xf8ac8000
parport_pc 40000 1 - Live 0xf8abd000
cbm 8812 0 - Live 0xf8a98000
parport 45096 2 parport_pc,cbm, Live 0xf8aa2000
delta-9 linux # cat /proc/ioports
0000-001f : dma1
0020-0021 : pic1
0040-005f : timer
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
02f8-02ff : serial
0376-0376 : ide1
0378-037a : parport0
037b-037f : parport0
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial
0778-077a : parport0
0cf8-0cff : PCI conf1
a000-cfff : PCI Bus #02
a000-a01f : 0000:02:04.0
a000-a01f : EMU10K1
a400-a407 : 0000:02:04.1
a400-a407 : emu10k1-gp
a800-a8ff : 0000:02:05.0
a800-a8ff : 8139too
ac00-ac3f : 0000:02:07.0
ac00-ac3f : e100
b000-b007 : 0000:02:08.0
b000-b007 : ide2
b400-b403 : 0000:02:08.0
b402-b402 : ide2
b800-b807 : 0000:02:08.0
b800-b807 : ide3
bc00-bc03 : 0000:02:08.0
bc02-bc02 : ide3
c000-c00f : 0000:02:08.0
c000-c007 : ide2
c008-c00f : ide3
e000-e0ff : 0000:00:09.0
e400-e4ff : 0000:00:09.1
e800-e803 : 0000:00:00.0
f000-f00f : 0000:00:07.1
f000-f007 : ide0
f008-f00f : ide1
delta-9 linux # cat /proc/iomem
00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000d0000-000d55ff : Extension ROM
000d6000-000d87ff : Extension ROM
000f0000-000fffff : System ROM
00100000-3ffeffff : System RAM
00100000-00411bbb : Kernel code
00411bbc-0052993f : Kernel data
3fff0000-3fff2fff : ACPI Non-volatile Storage
3fff3000-3fffffff : ACPI Tables
e0000000-e7ffffff : 0000:00:00.0
e8000000-efffffff : PCI Bus #01
e8000000-efffffff : 0000:01:05.0
f0000000-f1ffffff : PCI Bus #01
f0000000-f0ffffff : 0000:01:05.0
f3000000-f4ffffff : PCI Bus #02
f4000000-f401ffff : 0000:02:07.0
f4000000-f401ffff : e100
f4020000-f4023fff : 0000:02:08.0
f4024000-f4024fff : 0000:02:00.0
f4024000-f4024fff : ohci_hcd
f4025000-f40250ff : 0000:02:05.0
f4025000-f40250ff : 8139too
f4026000-f4026fff : 0000:02:07.0
f4026000-f4026fff : e100
f5000000-f50fffff : PCI Bus #02
f5000000-f5000fff : 0000:02:06.0
f5000000-f5000fff : bttv0
f5001000-f5001fff : 0000:02:06.1
f5001000-f5001fff : btaudio
f5100000-f5100fff : 0000:00:09.1
f5100000-f5100fff : aic7xxx
f5101000-f5101fff : 0000:00:09.0
f5101000-f5101fff : aic7xxx
f5102000-f5102fff : 0000:00:00.0
fec00000-ffffffff : reserved
delta-9 linux # lspci -vvv
0000:00:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-760 MP
[IGD4-2P] System Controller (rev 11)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort+ >SERR- <PERR-
Latency: 32
Region 0: Memory at e0000000 (32-bit, prefetchable)
Region 1: Memory at f5102000 (32-bit, prefetchable) [size=4K]
Region 2: I/O ports at e800 [disabled] [size=4]
Capabilities: [a0] AGP version 2.0
Status: RQ=16 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64-
HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4
Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP+ GART64- 64bit- FW+
Rate=x4
0000:00:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P]
AGP Bridge (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32
Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: f0000000-f1ffffff
Prefetchable memory behind bridge: e8000000-efffffff
BridgeCtl: Parity- SERR+ NoISA+ VGA+ MAbort- >Reset- FastB2B-
0000:00:07.0 ISA bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] ISA
(rev 05)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
0000:00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-768 [Opus]
IDE (rev 04) (prog-if 8a [Master SecP PriP])
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32
Region 4: I/O ports at f000 [size=16]
0000:00:07.3 Bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] ACPI (rev
03)
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
0000:00:09.0 SCSI storage controller: Adaptec AHA-3960D / AIC-7899A U160/m
(rev 01)
Subsystem: Adaptec AHA-3960D U160/m
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (10000ns min, 6250ns max), cache line size 08
Interrupt: pin A routed to IRQ 177
BIST result: 00
Region 0: I/O ports at e000 [disabled]
Region 1: Memory at f5101000 (64-bit, non-prefetchable) [size=4K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:09.1 SCSI storage controller: Adaptec AHA-3960D / AIC-7899A U160/m
(rev 01)
Subsystem: Adaptec AHA-3960D U160/m
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (10000ns min, 6250ns max), cache line size 08
Interrupt: pin B routed to IRQ 185
BIST result: 00
Region 0: I/O ports at e400 [disabled]
Region 1: Memory at f5100000 (64-bit, non-prefetchable) [size=4K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:10.0 PCI bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] PCI
(rev 05) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort+ >SERR- <PERR-
Latency: 32
Bus: primary=00, secondary=02, subordinate=02, sec-latency=32
I/O behind bridge: 0000a000-0000cfff
Memory behind bridge: f3000000-f4ffffff
Prefetchable memory behind bridge: f5000000-f50fffff
Expansion ROM at 0000a000 [disabled] [size=12K]
BridgeCtl: Parity- SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
0000:01:05.0 VGA compatible controller: nVidia Corporation NV15GL [Quadro2
Pro] (rev a4) (prog-if 00 [VGA])
Subsystem: nVidia Corporation: Unknown device 006d
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 248 (1250ns min, 250ns max)
Interrupt: pin A routed to IRQ 177
Region 0: Memory at f0000000 (32-bit, non-prefetchable)
Region 1: Memory at e8000000 (32-bit, prefetchable) [size=128M]
Capabilities: [60] Power Management version 1
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [44] AGP version 2.0
Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA- ITACoh- GART64-
HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4
Command: RQ=16 ArqSz=0 Cal=0 SBA- AGP+ GART64- 64bit- FW+
Rate=x4
0000:02:00.0 USB Controller: Advanced Micro Devices [AMD] AMD-768 [Opus]
USB (rev 07) (prog-if 10 [OHCI])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR+
Latency: 32 (20000ns max), cache line size 08
Interrupt: pin D routed to IRQ 193
Region 0: Memory at f4024000 (32-bit, non-prefetchable)
0000:02:04.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1
(rev 07)
Subsystem: Creative Labs CT4832 SBLive! Value
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (500ns min, 5000ns max)
Interrupt: pin A routed to IRQ 169
Region 0: I/O ports at a000
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:02:04.1 Input device controller: Creative Labs SB Live! MIDI/Game
Port (rev 07)
Subsystem: Creative Labs Gameport Joystick
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32
Region 0: I/O ports at a400
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:02:05.0 Ethernet controller: D-Link System Inc RTL8139 Ethernet (rev
10)
Subsystem: D-Link System Inc DFE-530TX+ 10/100 Ethernet Adapter
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (8000ns min, 16000ns max)
Interrupt: pin A routed to IRQ 177
Region 0: I/O ports at a800
Region 1: Memory at f4025000 (32-bit, non-prefetchable) [size=256]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
PME(D0-,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:02:06.0 Multimedia video controller: Brooktree Corporation Bt878
Video Capture (rev 11)
Subsystem: Hauppauge computer works Inc. WinTV Series
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (4000ns min, 10000ns max)
Interrupt: pin A routed to IRQ 185
Region 0: Memory at f5000000 (32-bit, prefetchable)
Capabilities: [44] Vital Product Data
Capabilities: [4c] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:02:06.1 Multimedia controller: Brooktree Corporation Bt878 Audio
Capture (rev 11)
Subsystem: Hauppauge computer works Inc. WinTV Series
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (1000ns min, 63750ns max)
Interrupt: pin A routed to IRQ 185
Region 0: Memory at f5001000 (32-bit, prefetchable)
Capabilities: [44] Vital Product Data
Capabilities: [4c] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:02:07.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100]
(rev 0d)
Subsystem: Intel Corp. EtherExpress PRO/100 Server Adapter
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (2000ns min, 14000ns max), cache line size 08
Interrupt: pin A routed to IRQ 169
Region 0: Memory at f4026000 (32-bit, non-prefetchable)
Region 1: I/O ports at ac00 [size=64]
Region 2: Memory at f4000000 (32-bit, non-prefetchable)
[size=128K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable+ DSel=0 DScale=2 PME-
0000:02:08.0 RAID bus controller: Promise Technology, Inc. PDC20276 IDE
(rev 01) (prog-if 85)
Subsystem: Giga-byte Technology: Unknown device b001
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=slow >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (1000ns min, 4500ns max), cache line size 08
Interrupt: pin A routed to IRQ 185
Region 0: I/O ports at b000
Region 1: I/O ports at b400 [size=4]
Region 2: I/O ports at b800 [size=8]
Region 3: I/O ports at bc00 [size=4]
Region 4: I/O ports at c000 [size=16]
Region 5: Memory at f4020000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [60] Power Management version 1
Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: major network performance difference between 2.4 and 2.6.2-rc2
2004-01-31 3:06 major network performance difference between 2.4 and 2.6.2-rc2 Jim Faulkner
@ 2004-01-31 14:28 ` Felipe Alfaro Solana
2004-02-04 20:42 ` Jim Faulkner
1 sibling, 0 replies; 11+ messages in thread
From: Felipe Alfaro Solana @ 2004-01-31 14:28 UTC (permalink / raw)
To: Jim Faulkner; +Cc: Linux Kernel Mailinglist, Andrew Morton
On Sat, 2004-01-31 at 04:06, Jim Faulkner wrote:
> There is a major networking performance problem on my machine under recent
> 2.6 kernels. I have a dual Athlon-MP machine with an onboard Intel
> Ethernet Pro 100 device, which can use either the e100 or eepro100 driver.
>
> I ran some tests under 2.4 and recent 2.6 kernels to see what kind of
> performance I could get. I tested using both ftp and samba, the client
> machine is a windows box with an onboard 3com 3c920b controller. They
> are connected through a D-Link 100 megabit full duplex switch.
>
> Under both 2.6.2-rc2 and 2.6.2-rc2-mm2, the performance is pretty bad.
> Copying 4.3 gigabytes of data from the linux machine to the windows box
> via samba takes about 35 minutes. LFTP shows FTP transfers from the linux
> box to the windows box to go at about 2 megabytes per second. The
> performance is even worse in the opposite direction, LFTP shows transfers
> from the linux box to the windows box to be around 1.5 megabytes per
> second.
>
> I repeated the above tests with both the e100 driver and the eepro100
> driver and got the same results. Running ifconfig shows "errors:0
> dropped:0 overruns:0 frame:0" and "errors:0 dropped:0 overruns:0
> carrier:0 collisions:0" for the device.
>
> Unfortunately my OS (unstable Gentoo) does not appear to support 2.4
> kernels anymore, so I had to use a Knoppix CD to test 2.4 kernels. I am
> using Knoppix nov 19 2003 version, which I believe uses a 2.4.21 or 2.4.22
> kernel. It uses the eepro100 driver.
>
> Under the Knoppix 2.4 kernel, using the exact same samba configuration
> file, I was able to copy 4.3 gigabytes of data from the linux machine to
> the windows machine in about 8 minutes. Copying in the opposite direction
> takes about 10 minutes. Unfortunately Knoppix doesn't include an FTP
> server so I wasn't able to test that.
>
> It appears that my network device is capable of 4 times the throughput
> under 2.4 kernels versus recent 2.6 kernels. I believe this problem arose
> recently, probably sometime since 2.6.0, since I only recently noticed
> this performance issue.
>
> I don't know if this problem is specific to my configuration or not, so
> included below is lots of configuration information. Please note that the
> funky modules like nvidia, vmware and cbm were not loaded when I ran my
> tests.
I have experienced lower network performance with 2.6 kernels and 3Com
cards. On my laptop, downstream traffic (download) seems to get nearly
full throughput (~10MB/s) but upstream traffic never rises from 3MB/s.
On other computers, the throughput is more symmetric, but not as good as
it was with 2.4 kernels. The problem seems to be related with a possible
hardware bug on my 3Com card, but I have been unable to confirm.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: major network performance difference between 2.4 and 2.6.2-rc2
2004-01-31 3:06 major network performance difference between 2.4 and 2.6.2-rc2 Jim Faulkner
2004-01-31 14:28 ` Felipe Alfaro Solana
@ 2004-02-04 20:42 ` Jim Faulkner
2004-02-04 20:54 ` Andrew Morton
2004-02-04 21:28 ` Gerd Knorr
1 sibling, 2 replies; 11+ messages in thread
From: Jim Faulkner @ 2004-02-04 20:42 UTC (permalink / raw)
To: linux-kernel; +Cc: akpm, kraxel
On Fri, 30 Jan 2004, Jim Faulkner wrote:
>
> There is a major networking performance problem on my machine under recent
> 2.6 kernels. I have a dual Athlon-MP machine with an onboard Intel
> Ethernet Pro 100 device, which can use either the e100 or eepro100 driver.
>
> I ran some tests under 2.4 and recent 2.6 kernels to see what kind of
> performance I could get. I tested using both ftp and samba, the client
> machine is a windows box with an onboard 3com 3c920b controller. They
> are connected through a D-Link 100 megabit full duplex switch.
...
> It appears that my network device is capable of 4 times the throughput
> under 2.4 kernels versus recent 2.6 kernels. I believe this problem arose
> recently, probably sometime since 2.6.0, since I only recently noticed
> this performance issue.
I am still experiencing severely degraded network performance under
2.6.2-rc3 and 2.6.2-rc3-mm1. Based on some kernel output, I think this
problem may be related to Gerd Knorr's input patches, so I am CCing him on
this e-mail. You can view my entire original e-mail, which includes
system configuration information, right here:
http://groups.google.com/groups?selm=1jTPU-2ee-1%40gated-at.bofh.it&rnum=1
While doing a large network transfer, and not at any other time, I get
tons of messages like this from the kernel:
Feb 4 15:13:50 delta-9 i2c IR (Hauppauge): unknown key: key=0x3f raw=0x3fff down=1
Feb 4 15:13:55 delta-9 i2c IR (Hauppauge): unknown key: key=0x3f raw=0x3fff down=0
Feb 4 15:13:57 delta-9 i2c IR (Hauppauge): unknown key: key=0x3f raw=0x3fff down=1
Feb 4 15:14:00 delta-9 i2c IR (Hauppauge): unknown key: key=0x3f raw=0x3fff down=0
Feb 4 15:14:01 delta-9 i2c IR (Hauppauge): unknown key: key=0x3f raw=0x3fff down=1
Feb 4 15:14:03 delta-9 i2c IR (Hauppauge): unknown key: key=0x3f raw=0x3fff down=0
Feb 4 15:14:03 delta-9 i2c IR (Hauppauge): unknown key: key=0x3f raw=0x3fff down=1
Feb 4 15:14:05 delta-9 i2c IR (Hauppauge): unknown key: key=0x3f raw=0x3fff down=0
Feb 4 15:14:06 delta-9 i2c IR (Hauppauge): unknown key: key=0x3f raw=0x3fff down=1
I do have a hauppauge remote which works great under the 2.6 kernels
(thanks Gerd), but I am not pressing any keys while this is happening.
Additionally, while large network transfers are going on, both ksoftirqd/0
and events/0 start going crazy, putting a huge load on my system:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3 root 35 19 0 0 0 S 45.9 0.0 0:46.98 ksoftirqd/0
6 root 5 -10 0 0 0 S 43.3 0.0 1:56.63 events/0
12008 dogshu 15 0 4800 2356 3828 S 5.3 0.2 0:05.98 proftpd
12 root 15 0 0 0 0 S 0.3 0.0 0:00.41 pdflush
9778 root 16 0 5888 1724 5516 R 0.3 0.2 0:00.12 sshd
the load before that network transfer was 0.01, and the load after the
network transfer was 1.45.
I'd really like to have my network performance back, so it would be great
if someone could take a look at this. :)
thanks for any help,
Jim Faulkner
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: major network performance difference between 2.4 and 2.6.2-rc2
2004-02-04 20:42 ` Jim Faulkner
@ 2004-02-04 20:54 ` Andrew Morton
2004-02-04 21:08 ` David S. Miller
2004-02-05 4:57 ` Jim Faulkner
2004-02-04 21:28 ` Gerd Knorr
1 sibling, 2 replies; 11+ messages in thread
From: Andrew Morton @ 2004-02-04 20:54 UTC (permalink / raw)
To: Jim Faulkner; +Cc: linux-kernel, kraxel
Jim Faulkner <jfaulkne@ccs.neu.edu> wrote:
>
>
> I am still experiencing severely degraded network performance under
> 2.6.2-rc3 and 2.6.2-rc3-mm1.
A kernel profile is needed.
> Based on some kernel output, I think this
> problem may be related to Gerd Knorr's input patches, so I am CCing him on
> this e-mail.
Sounds unlikely.
> Additionally, while large network transfers are going on, both ksoftirqd/0
> and events/0 start going crazy, putting a huge load on my system:
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 3 root 35 19 0 0 0 S 45.9 0.0 0:46.98 ksoftirqd/0
> 6 root 5 -10 0 0 0 S 43.3 0.0 1:56.63 events/0
> 12008 dogshu 15 0 4800 2356 3828 S 5.3 0.2 0:05.98 proftpd
> 12 root 15 0 0 0 0 S 0.3 0.0 0:00.41 pdflush
> 9778 root 16 0 5888 1724 5516 R 0.3 0.2 0:00.12 sshd
>
> the load before that network transfer was 0.01, and the load after the
> network transfer was 1.45.
Could be a networking problem, but boy that's a lot of CPU time.
Please, do this:
- Boot with `profile=1' on the kernel command line
sudo readprofile -r
sudo readprofile -M10
time <whatever command it is that is causing the problem>
readprofile -n -v -m /boot/System.map | sort -n +2 | tail -40 | tee ~/log
Making very sure that /boot/System.map is the correct map file for the
currently-running kernel.
Thanks.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: major network performance difference between 2.4 and 2.6.2-rc2
2004-02-04 20:54 ` Andrew Morton
@ 2004-02-04 21:08 ` David S. Miller
2004-02-04 21:22 ` Andrew Morton
2004-02-05 4:57 ` Jim Faulkner
1 sibling, 1 reply; 11+ messages in thread
From: David S. Miller @ 2004-02-04 21:08 UTC (permalink / raw)
To: Andrew Morton; +Cc: jfaulkne, linux-kernel, kraxel
On Wed, 4 Feb 2004 12:54:44 -0800
Andrew Morton <akpm@osdl.org> wrote:
> Jim Faulkner <jfaulkne@ccs.neu.edu> wrote:
> > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> > 3 root 35 19 0 0 0 S 45.9 0.0 0:46.98 ksoftirqd/0
> > 6 root 5 -10 0 0 0 S 43.3 0.0 1:56.63 events/0
> > 12008 dogshu 15 0 4800 2356 3828 S 5.3 0.2 0:05.98 proftpd
> > 12 root 15 0 0 0 0 S 0.3 0.0 0:00.41 pdflush
> > 9778 root 16 0 5888 1724 5516 R 0.3 0.2 0:00.12 sshd
> >
> > the load before that network transfer was 0.01, and the load after the
> > network transfer was 1.45.
>
> Could be a networking problem, but boy that's a lot of CPU time.
Andrew maybe something bolixed in the MAX_SOFTIRQ_RESTART stuff
we put into kernel/softirq.c? Just a guess...
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: major network performance difference between 2.4 and 2.6.2-rc2
2004-02-04 21:08 ` David S. Miller
@ 2004-02-04 21:22 ` Andrew Morton
0 siblings, 0 replies; 11+ messages in thread
From: Andrew Morton @ 2004-02-04 21:22 UTC (permalink / raw)
To: David S. Miller; +Cc: jfaulkne, linux-kernel, kraxel
"David S. Miller" <davem@redhat.com> wrote:
>
> On Wed, 4 Feb 2004 12:54:44 -0800
> Andrew Morton <akpm@osdl.org> wrote:
>
> > Jim Faulkner <jfaulkne@ccs.neu.edu> wrote:
> > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> > > 3 root 35 19 0 0 0 S 45.9 0.0 0:46.98 ksoftirqd/0
> > > 6 root 5 -10 0 0 0 S 43.3 0.0 1:56.63 events/0
> > > 12008 dogshu 15 0 4800 2356 3828 S 5.3 0.2 0:05.98 proftpd
> > > 12 root 15 0 0 0 0 S 0.3 0.0 0:00.41 pdflush
> > > 9778 root 16 0 5888 1724 5516 R 0.3 0.2 0:00.12 sshd
> > >
> > > the load before that network transfer was 0.01, and the load after the
> > > network transfer was 1.45.
> >
> > Could be a networking problem, but boy that's a lot of CPU time.
>
> Andrew maybe something bolixed in the MAX_SOFTIRQ_RESTART stuff
> we put into kernel/softirq.c? Just a guess...
Might be. Jim, does a `patch -p1 -R' of the below help things?
diff -Nru a/kernel/softirq.c b/kernel/softirq.c
--- a/kernel/softirq.c Wed Feb 4 13:20:39 2004
+++ b/kernel/softirq.c Wed Feb 4 13:20:39 2004
@@ -57,11 +57,22 @@
wake_up_process(tsk);
}
+/*
+ * We restart softirq processing MAX_SOFTIRQ_RESTART times,
+ * and we fall back to softirqd after that.
+ *
+ * This number has been established via experimentation.
+ * The two things to balance is latency against fairness -
+ * we want to handle softirqs as soon as possible, but they
+ * should not be able to lock up the box.
+ */
+#define MAX_SOFTIRQ_RESTART 10
+
asmlinkage void do_softirq(void)
{
+ int max_restart = MAX_SOFTIRQ_RESTART;
__u32 pending;
unsigned long flags;
- __u32 mask;
if (in_interrupt())
return;
@@ -73,7 +84,6 @@
if (pending) {
struct softirq_action *h;
- mask = ~pending;
local_bh_disable();
restart:
/* Reset the pending bitmask before enabling irqs */
@@ -93,10 +103,8 @@
local_irq_disable();
pending = local_softirq_pending();
- if (pending & mask) {
- mask &= ~pending;
+ if (pending && --max_restart)
goto restart;
- }
if (pending)
wakeup_softirqd();
__local_bh_enable();
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: major network performance difference between 2.4 and 2.6.2-rc2
2004-02-04 20:42 ` Jim Faulkner
2004-02-04 20:54 ` Andrew Morton
@ 2004-02-04 21:28 ` Gerd Knorr
1 sibling, 0 replies; 11+ messages in thread
From: Gerd Knorr @ 2004-02-04 21:28 UTC (permalink / raw)
To: Jim Faulkner; +Cc: linux-kernel, akpm
> While doing a large network transfer, and not at any other time, I get
> tons of messages like this from the kernel:
>
> Feb 4 15:14:05 delta-9 i2c IR (Hauppauge): unknown key: key=0x3f raw=0x3fff down=0
> Feb 4 15:14:06 delta-9 i2c IR (Hauppauge): unknown key: key=0x3f raw=0x3fff down=1
>
> I do have a hauppauge remote which works great under the 2.6 kernels
> (thanks Gerd), but I am not pressing any keys while this is happening.
Hmm, what happens if you rmmod the ir-kbd-i2c module? Any difference?
> 3 root 35 19 0 0 0 S 45.9 0.0 0:46.98 ksoftirqd/0
> 6 root 5 -10 0 0 0 S 43.3 0.0 1:56.63 events/0
One of the two could be ir-kbd-i2c, it polls the i2c IR chip using tasklets.
Not sure which of the kernel threads runs the tasklets ...
Gerd
--
"... und auch das ganze Wochenende oll" -- Wetterbericht auf RadioEins
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: major network performance difference between 2.4 and 2.6.2-rc2
2004-02-04 20:54 ` Andrew Morton
2004-02-04 21:08 ` David S. Miller
@ 2004-02-05 4:57 ` Jim Faulkner
2004-02-06 21:14 ` Bill Davidsen
1 sibling, 1 reply; 11+ messages in thread
From: Jim Faulkner @ 2004-02-05 4:57 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, kraxel, davem, manmower
On Wed, 4 Feb 2004, Andrew Morton wrote:
> Jim Faulkner <jfaulkne@ccs.neu.edu> wrote:
> >
> >
> > I am still experiencing severely degraded network performance under
> > 2.6.2-rc3 and 2.6.2-rc3-mm1.
>
> A kernel profile is needed.
>
> > Based on some kernel output, I think this
> > problem may be related to Gerd Knorr's input patches, so I am CCing him on
> > this e-mail.
>
> Sounds unlikely.
>
> > Additionally, while large network transfers are going on, both ksoftirqd/0
> > and events/0 start going crazy, putting a huge load on my system:
> >
> > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> > 3 root 35 19 0 0 0 S 45.9 0.0 0:46.98 ksoftirqd/0
> > 6 root 5 -10 0 0 0 S 43.3 0.0 1:56.63 events/0
> > 12008 dogshu 15 0 4800 2356 3828 S 5.3 0.2 0:05.98 proftpd
> > 12 root 15 0 0 0 0 S 0.3 0.0 0:00.41 pdflush
> > 9778 root 16 0 5888 1724 5516 R 0.3 0.2 0:00.12 sshd
> >
> > the load before that network transfer was 0.01, and the load after the
> > network transfer was 1.45.
>
> Could be a networking problem, but boy that's a lot of CPU time.
>
Thanks to Andrew's suggestion of profiling my kernel, I've figured out
what is happening here. It is my fault, it is not a bug.
I use this iptables script generator:
http://ftp.berlios.de/pub/mldonkey/pango/goodies/ipblacklist_convert
in combination with this blacklist:
http://www.peerguardian.net/pgipdb/guarding.p2p
I had already modified the script so everything on my LAN interface was
accepted, however I didn't realize that the scipt was using "-I INPUT 1"
for all of its blacklist rules. iptables was going through around 5300
rules for each and every packet that came in through my LAN interface,
which is definately not what I intended.
I fixed my firewall script, and my LAN throughput is back up at 10
megabytes per second, with nowhere near the load.
Sorry about that. I'm not sure what the hauppauge messages are about, but
they're not the cause of my problem.
> > > Could be a networking problem, but boy that's a lot of CPU time.
> >
> > Andrew maybe something bolixed in the MAX_SOFTIRQ_RESTART stuff
> > we put into kernel/softirq.c? Just a guess...
>
> Might be. Jim, does a `patch -p1 -R' of the below help things?
I did try the patch before fixing my firewall rules. ksoftirqd/0 was no
longer using alot of CPU time, however events/0 still was using alot of
CPU time, and of course my performance was still bad.
> Please, do this:
>
> - Boot with `profile=1' on the kernel command line
>
> sudo readprofile -r
> sudo readprofile -M10
> time <whatever command it is that is causing the problem>
> readprofile -n -v -m /boot/System.map | sort -n +2 | tail -40 | tee ~/log
If you're still curious, here is the output while I had my bad firewall
enabled:
c037a340 sock_def_readable 1933 10.9830
c0149180 kmem_cache_free 1954 20.3542
c03b3810 tcp_recvmsg 2032 1.0672
c0174b20 do_select 2049 2.6680
c037aa30 skb_release_data 2098 13.1125
c037a8e0 alloc_skb 2129 9.5045
c03ac190 ip_queue_xmit 2181 1.6829
c01b62b0 is_leaf 2230 4.8060
c0174e50 sys_select 2274 1.7991
c03b1f70 tcp_sendmsg 2679 0.5419
c037fb60 process_backlog 2797 8.7406
c04110ff sysenter_past_esp 2978 29.4851
c037f9b0 netif_receive_skb 3115 7.2106
c03a61c0 ip_route_input 3130 5.9280
c03b0810 tcp_poll 3208 8.3542
c012ca50 del_timer_sync 3356 11.6528
c03a8700 ip_rcv 3429 2.6458
c03baf00 tcp_rcv_established 3589 1.8538
c012c620 __mod_timer 3835 6.3076
c037ab00 __kfree_skb 3864 15.0938
c012c990 del_timer 3894 20.2812
c03a8c10 ip_local_deliver_finish 4009 7.5928
c038a570 nf_iterate 4049 23.0057
c03bc6a0 tcp_transmit_skb 4078 2.7114
c01491e0 kfree 4135 36.9196
c03e1b20 tcp_packet 4514 9.4042
c0163200 __find_get_block 4607 22.1490
c0163b80 __block_prepare_write 4860 4.5336
c0121640 __preempt_spin_lock 4996 52.0417
c01b6590 search_by_key 7268 1.9750
c02148f4 csum_partial 8790 30.5208
c0215440 __copy_from_user_ll 10875 84.9609
c03c4910 tcp_v4_rcv 12975 5.4793
c011f760 __wake_up 15757 140.6875
c02153d0 __copy_to_user_ll 17531 156.5268
c011efb0 schedule 18536 10.5318
c0116730 delay_tsc 25865 808.2812
c03e3730 ipt_do_table 3933402 4552.5486
c0108c70 default_idle 5633092 88017.0625
00000000 total 9915575 3.1080
sorry about the false alarm,
Jim Faulkner
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: major network performance difference between 2.4 and 2.6.2-rc2
2004-02-05 4:57 ` Jim Faulkner
@ 2004-02-06 21:14 ` Bill Davidsen
2004-02-07 17:56 ` Hilko Bengen
0 siblings, 1 reply; 11+ messages in thread
From: Bill Davidsen @ 2004-02-06 21:14 UTC (permalink / raw)
To: Jim Faulkner; +Cc: Andrew Morton, linux-kernel, kraxel, davem, manmower
Jim Faulkner wrote:
> Thanks to Andrew's suggestion of profiling my kernel, I've figured out
> what is happening here. It is my fault, it is not a bug.
>
> I use this iptables script generator:
> http://ftp.berlios.de/pub/mldonkey/pango/goodies/ipblacklist_convert
> in combination with this blacklist:
> http://www.peerguardian.net/pgipdb/guarding.p2p
>
> I had already modified the script so everything on my LAN interface was
> accepted, however I didn't realize that the scipt was using "-I INPUT 1"
> for all of its blacklist rules. iptables was going through around 5300
> rules for each and every packet that came in through my LAN interface,
> which is definately not what I intended.
>
> I fixed my firewall script, and my LAN throughput is back up at 10
> megabytes per second, with nowhere near the load.
This does point out an issue, as a 2.7 enhancement it would be really
useful to have a better way to handle a large number of rules, when what
you want is one rule applied to many IP values. I ran into this when
fighting a DDoS attack, and by the time I got the attack stopped, even
only dropping or rejecting --syn packets I had most of a CPU in system
time running ~10k rules.
I wrote a perl script to break it into multiple level tables, but it was
still pretty slow and uglier than a hedgehog's rectum.
What would be nice is some kind of table approach, hash or tree, which
allows operations to be matches against all of the IPs in a group, and
obviously to add/delete entries. I think for simplicity individual IPs
rather than CIDR blocks are desirable.
In any case, if a network person is looking for something really neat
for 2.7, blactlists of various types are getting more common, and an
efficient solution would be good.
--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: major network performance difference between 2.4 and 2.6.2-rc2
2004-02-06 21:14 ` Bill Davidsen
@ 2004-02-07 17:56 ` Hilko Bengen
2004-02-18 3:33 ` Bill Davidsen
0 siblings, 1 reply; 11+ messages in thread
From: Hilko Bengen @ 2004-02-07 17:56 UTC (permalink / raw)
To: linux-kernel
Bill Davidsen <davidsen@tmr.com> writes:
> What would be nice is some kind of table approach, hash or tree,
> which allows operations to be matches against all of the IPs in a
> group, and obviously to add/delete entries. I think for simplicity
> individual IPs rather than CIDR blocks are desirable.
Do you mean something like <http://www.hipac.org/>?
-Hilko
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: major network performance difference between 2.4 and 2.6.2-rc2
2004-02-07 17:56 ` Hilko Bengen
@ 2004-02-18 3:33 ` Bill Davidsen
0 siblings, 0 replies; 11+ messages in thread
From: Bill Davidsen @ 2004-02-18 3:33 UTC (permalink / raw)
To: Hilko Bengen; +Cc: linux-kernel
Hilko Bengen wrote:
> Bill Davidsen <davidsen@tmr.com> writes:
>
>
>>What would be nice is some kind of table approach, hash or tree,
>>which allows operations to be matches against all of the IPs in a
>>group, and obviously to add/delete entries. I think for simplicity
>>individual IPs rather than CIDR blocks are desirable.
>
>
> Do you mean something like <http://www.hipac.org/>?
Thank you for the pointer, it's not what I meant but probably will be
highly useful anyway.
What I had in mind was a single rule which would apply against a table
of IP addresses and CIDR blocks instead of one. Somewhat like the access
table in sendmail, but perhaps more like a database in that I could add
and delete to/from the table at runtime while always leaving the table
valid (pseudo-atomic operations).
Perhaps the example of what I would like to do is better than what I
wrote. Think of tables in iproute2.
iptables -A INPUT -p tcp --stable badguys --dport smtp -j REJECT
then as I detect...
iptables -T badguys add 270.1.2.3
iptables -T badguys add 270.4.5.16/4
So I could add and delete to a table, and it's use would not be limited
to a single rule. It would be an independent in-memory table of some
(hash?) organization.
I think the link you kindly provided is a viable solution, it's just not
quite what I had in mind, allowing me to use an IP set in multiple or
changing ways without redefinition for each IP.
Didn't mean to get this going in this list, it grew from a chance comment.
--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2004-02-18 3:51 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-01-31 3:06 major network performance difference between 2.4 and 2.6.2-rc2 Jim Faulkner
2004-01-31 14:28 ` Felipe Alfaro Solana
2004-02-04 20:42 ` Jim Faulkner
2004-02-04 20:54 ` Andrew Morton
2004-02-04 21:08 ` David S. Miller
2004-02-04 21:22 ` Andrew Morton
2004-02-05 4:57 ` Jim Faulkner
2004-02-06 21:14 ` Bill Davidsen
2004-02-07 17:56 ` Hilko Bengen
2004-02-18 3:33 ` Bill Davidsen
2004-02-04 21:28 ` Gerd Knorr
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).