Hi James,
[I am putting [EMAIL PROTECTED] in the thread again...]
You can try any of the following (to set the NIC duplex/speed
properties or get more statistics):
* dmesg etc. should tell you what speed the NIC is on when
the kernel detects it.
* modinfo <module>, to get options and parameters when insmodding, eg.
sloth:~# modinfo eepro100
filename: /lib/modules/2.4.18-pre3/kernel/drivers/net/eepro100.o
description: "Intel i82557/i82558/i82559 PCI EtherExpressPro driver"
author: "Maintainer: Andrey V. Savochkin <[EMAIL PROTECTED]>"
license: "GPL"
parm: debug int, description "eepro100 debug level (0-6)"
parm: options int array (min = 1, max = 8), description "eepro100: Bits 0-3: tranceiver type, bit 4: full duplex, bit 5: 100Mbps"
parm: full_duplex int array (min = 1, max = 8), description "eepro100 full duplex setting(s) (1)"
parm: congenb int, description "eepro100 Enable congestion control (1)"
parm: txfifo int, description "eepro100 Tx FIFO threshold in 4 byte units, (0-15)"
parm: rxfifo int, description "eepro100 Rx FIFO threshold in 4 byte units, (0-15)"
parm: txdmacount int
parm: rxdmacount int
parm: rx_copybreak int, description "eepro100 copy breakpoint for copy-only-tiny-frames"
parm: max_interrupt_work int, description "eepro100 maximum events handled per interrupt"
parm: multicast_filter_limit int, description "eepro100 maximum number of filtered multicast addresses"
You may want to increase the debugging level, if at all possible...
* "ip link" from the iproute2 package, for more stats:
sloth:~# ip -s -s link list
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
RX: bytes packets errors dropped overrun mcast
1840 12 0 0 0 0
RX errors: length crc frame fifo missed
0 0 0 0 0
TX: bytes packets errors dropped carrier collsns
1840 12 0 0 0 0
TX errors: aborted fifo window heartbeat
0 0 0 0
2: eth0: <BROADCAST,MULTICAST,ALLMULTI,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:20:18:b8:1d:d0 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
20389 320 0 0 0 9
RX errors: length crc frame fifo missed
0 0 0 0 0
TX: bytes packets errors dropped carrier collsns
402 2 0 0 0 0
TX errors: aborted fifo window heartbeat
0 0 0 0
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:50:ba:b3:1a:e4 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
16883065 12585 0 0 0 1085
RX errors: length crc frame fifo missed
0 0 0 0 0
TX: bytes packets errors dropped carrier collsns
862193 11355 0 0 0 1091
TX errors: aborted fifo window heartbeat
0 0 0 0
* Then there is some software to set NIC properties. I am
on Debian Woody, and the following packages are available:
mii-tool
mii-diag
nictools-pci
nictools-nopci
I hope this helps. If you are not getting any closer with this
info, may I suggest that you replace the NICs with something
completely different, ie. NICs from a different vendor. If
this yields any significant difference in speed, you should
probably take it up with the maintainer(s) of the 3c905 code...
Regards,
Filip
-----Original Message-----
From: James A. Pattie [mailto:[EMAIL PROTECTED]]
Sent: wo 27/02/2002 16:27
To: Sneppe Filip
Cc:
Subject: Re: Update on Firewall Speed Question
Sneppe,
Thanks. I found ipTraf last night, just haven't had a chance to play
with it yet. From what I can tell all my cards are running at 100 and
are in full duplex mode (according to the led's on the back and the
switches). And of course the box has a load average of 0. :)
Do you know of any way to tell, via software, if the card(s) are really
running at 100? I've looked for HOWTO's, software, etc. and haven't
found anything yet that covers the 2.4 kernel.
Thanks,
Sneppe Filip wrote:
> James,
>
> I feel your pain.
>
> Given your CPU power and available memory, I would not look
> into the generic kernel networking code/netfilter/iptables
> for performance issues. You should have plenty of CPU cycles
> to spare. "top" should report a CPU that's almost idle.
> I have boxes 500 Mhz machines with 600+ iptables rules doing
> HTTP proxying and not having any load problems.
>
> The first (and pretty much the only) thing that springs to
> mind, is a misconfigured cable speed or duplex setting
> on the NIC. Look for info on the web on how to enable
> full duplex 100 Mbps on your NICs (they may be running
> half duplex and/or at 10 Mbps). If your machine is on
> a switch, you may be able to get some port stats from
> the switch like alignment/CRC errors, etc. that could
> point to issues with the driver.
>
> Oh, and for traffic meanurement, take a look at iptraf.
>
> Good luck,
> Filip
>
> -----Original Message-----
> From: James A. Pattie [mailto:[EMAIL PROTECTED]]
> Sent: Tue 26/02/2002 20:13
> To: [EMAIL PROTECTED]
> Cc:
> Subject: Update on Firewall Speed Question
>
> Here's whats happened sofar:
>
> I've run 'vmstat 1' while doing the transfers and verified that
> there is
> no swapping taking place. This is on a dual capable PIII 600 system
> (with only 1 cpu). Buffer and Cache memory went up/down by about 1 MB
> during the file transfer (workstation to dmz) but only a couple thousand
> bytes when doing the download (dmz to workstation).
>
> He installed a 3Com 3c905B or C card in the DMZ server, which
> cuts down
> the transfer time from 2 minutes to 90 seconds when doing a straight
> windows to windows transfer, but the time didn't change when going
> through the firewall.
>
> I've optimized my firewall rules to make the ESTABLISHED,RELATED
> check be
> at the top rather than about 5 rules down and removed the marking of
> packets and matching on those marks, but without any performance change.
> The incoming packets are diverted into chains based upon the protocol
> in use. If doing chains based upon interface first would increase
> performance, I'd be willing to try that. I haven't seen a definitive
> document that says doing user chains in this order, etc. is more
> efficient than this scenario, etc.
>
> The only time he noticed a performance change was when I
> realized I was
> running iptables 1.2.2a and then updated to 1.2.4. He said it shaved
> about 30 seconds to 1 minute off the time. I don't see how changing
> iptables would improve what the kernel is doing, but...
>
> Is there any way to see the rate of packets coming into, through
> and out
> of the firewall? I'm thinking now that the bottleneck is either when
> packets enter the firewall (internal nic - 3c905C) or when they are
> leaving the firewall into the DMZ (3c905B).
>
> I'm not seeing any dropped packets that are related to the file
> transfer
> connection and there are no collisions, etc. being reported. If anyone
> has any further ideas, suggestions, etc. please let me know.
>
> Thanks,
>
> James A. Pattie wrote:
> > Hi,
> >
> > I've got a compaq box setup with 3 3Com nics (10/100 - 3C905[ABC])
> > using 3Com's network driver for the B & C cards. I'm running linux
> > 2.4.17 and iptables 1.2.4. The firewall rules are based off of
> > PCXFirewall 2.11 and PCXFirewall Rules 1.4 (http://pcxfirewall.sf.net).
> > The box has 128 MB memory, 4 9GB SCSI drives doing softwared raid 5, and
> > over 2 GB of swap space.
> >
> > The problem I'm having is my client is trying to do SMB file
> > transfers from an internal machine to a Windows 2K box in the DMZ. When
> > downloading from the DMZ server to their Windows 2K workstation, the
> > transfer takes about 2 - 2.5 minutes (which is what it takes if you have
> > the 2 machines in the same network without going through the firewall).
> > But pushing files from his workstation to the DMZ server takes 5 - 8
> > minutes. Inititally it was taking over 20 minutes, but I stopped using
> > the onboard ThunderLan nic and switched to a 3Com and also re-ordered
> > the SMB rules to be right after my DNS rules.
> >
> > Does anyone have any ideas as to how to make the upload go quicker?
> > I've played with changing the txqueuelen value but that has always made
> > it go slower. I'm not seeing collisions, etc. and he has switched to
> > using a 3Com card in the DMZ server from the onboard ThunderLan nic.
> > This actually made the upload time be longer. :(
> >
> > The client is threatening to move to CISCO because the outside
> > programmer that the DMZ server is for, thinks that CISCO is more secure,
> > etc. than Linux, and also because he doesn't like Linux. The sysadmin
> > I'm working with wants to keep linux because of the cost difference and
> > he hasn't seen any major issues, other than this speed problem.
> >
> > The only thing I can see to improve in my firewall rules is to not
> > mark every incoming packet, which is the mechanism I'm using to know
> > which interface a packet came in when I'm working with the POSTROUTING
> > chain. I'm working on making a version that does everything by user
> > chains (more so than I currently am), but it won't be ready for several
> > days. The client wants a solution by Thursday.
> >
> > I've also tried just doing routing from the internal network to the
> > dmz, no firewalling, and it is slower by several seconds, so not doing
> > firewalling isn't the solution. (This firewall is behind another
> > firewall which is acting as the choke point for their network.)
> >
> > Any suggestions, pointers, etc. would be very much appreciated.
> >
> > Thanks,
> >
>
>
> --
> James A. Pattie
> [EMAIL PROTECTED]
>
> Linux -- SysAdmin / Programmer
> PC & Web Xperience, Inc.
> http://www.pcxperience.com/
>
>
>
>
--
James A. Pattie
[EMAIL PROTECTED]
Linux -- SysAdmin / Programmer
PC & Web Xperience, Inc.
http://www.pcxperience.com/
Title: RE: Update on Firewall Speed Question
- RE: Update on Firewall Speed Question Sneppe Filip
- RE: Update on Firewall Speed Question Sneppe Filip
- Sneppe Filip
