SEO

Maybe somebody else has experienced similar problems and can make
suggestions that pertain to what is happening to me.

I was running Mandrake 9. The system basically performed flawlessly.
I was able to PPP with a modem from the linux box, ftp over that
connection, as well as set up the linux box to be an IPTABLES NAT so
that workstations on the network could have Internet connectivity as
well. The modem line was a backup to the Cable Modem interface, which
also worked well under Mandrake.

I recently installed RH9 on this pc. I did this because I bought a
new RAID5 controller (S150SX4) from promise and it has specific kernel
requirements- one of them being 2.4.20-8 or 2.4.20-8smp. The
controller card is working fine and performance is acceptable.

Here is the problem:
PPP is performing poorly. There are 10 - 20% RX errors as well as 10
- 20% packet loss with simple pings.

This very same modem and phoneline when plugged into a system running
Windows XP performs fine.

This very same modem and phoneline also performed fine with the
previous Mandrake configuration .

Regardless of connect speeds which are either 28800 or 49333,
depending on whether or not I enable V90, I get 1.4 - 1.6KB/sec avg
speed over FTP. Note: this is a USR Courier V.everything modem.

I used to get over 4k on average with bursts of 5-6KB/sec.

With the packet loss and RX errors, needless to say, this PPP
interface is worthless as a NAT.

Here is my system:
Dual P2 400's. (Not a powerhouse, but it has been reliable for a
couple years now)
1GB pc-133 RAM
400GB RAID5
Intel Gigabit Ethernet
3Com 10/100 Ethernet
Adaptec 2940 w/Tandberg SLR5 tapedrive and NEC Cd-Rom
Panasonic IDE Cd-Rom
USR Courier v.everything modem

RH9
kernel-2.4.20-8smp
iptables v1.2.7a

So far I have tried:
connecting to a different ISP
using a different modem
lowering baud rates and line speeds
verified correct modem init string
asyncmap 0

None of this made much of a difference if at all.

During FTP transfers, both CPUs are virtually idle. 2-3% intermittent
utilization and yet the ftp performance is poor.

I tried using mru 576 and mtu 576 and there was a slight throughput
improvement. 1.9KB/sec, but nothing great. Packet loss and RX errors
still were at 10-20%.

Also, with mru and mtu at 576, workstations fail to transfer through
the NAT. It seems that the minimum that works over the NAT is 1500.

Can somebody suggest some things to test to help narrow down this
problem?

Thanks in advance,
Charles

2boxers_at_comcast_dot_net wrote:
> Maybe somebody else has experienced similar problems and can make
> suggestions that pertain to what is happening to me.
>
> I was running Mandrake 9. The system basically performed flawlessly.
> I was able to PPP with a modem from the linux box, ftp over that
> connection, as well as set up the linux box to be an IPTABLES NAT so
> that workstations on the network could have Internet connectivity as
> well. The modem line was a backup to the Cable Modem interface, which
> also worked well under Mandrake.
>
> I recently installed RH9 on this pc. I did this because I bought a
> new RAID5 controller (S150SX4) from promise and it has specific kernel
> requirements- one of them being 2.4.20-8 or 2.4.20-8smp. The
> controller card is working fine and performance is acceptable.
>
> Here is the problem:
> PPP is performing poorly. There are 10 - 20% RX errors as well as 10
> - 20% packet loss with simple pings.
>
> This very same modem and phoneline when plugged into a system running
> Windows XP performs fine.
>
> This very same modem and phoneline also performed fine with the
> previous Mandrake configuration .
>
> Regardless of connect speeds which are either 28800 or 49333,
> depending on whether or not I enable V90, I get 1.4 - 1.6KB/sec avg
> speed over FTP. Note: this is a USR Courier V.everything modem.
>
> I used to get over 4k on average with bursts of 5-6KB/sec.
>
> With the packet loss and RX errors, needless to say, this PPP
> interface is worthless as a NAT.
>
> Here is my system:
> Dual P2 400's. (Not a powerhouse, but it has been reliable for a
> couple years now)
> 1GB pc-133 RAM
> 400GB RAID5
> Intel Gigabit Ethernet
> 3Com 10/100 Ethernet
> Adaptec 2940 w/Tandberg SLR5 tapedrive and NEC Cd-Rom
> Panasonic IDE Cd-Rom
> USR Courier v.everything modem
>
> RH9
> kernel-2.4.20-8smp
> iptables v1.2.7a
>
> So far I have tried:
> connecting to a different ISP
> using a different modem
> lowering baud rates and line speeds
> verified correct modem init string
> asyncmap 0
>
> None of this made much of a difference if at all.
>
> During FTP transfers, both CPUs are virtually idle. 2-3% intermittent
> utilization and yet the ftp performance is poor.
>
> I tried using mru 576 and mtu 576 and there was a slight throughput
> improvement. 1.9KB/sec, but nothing great. Packet loss and RX errors
> still were at 10-20%.
>
> Also, with mru and mtu at 576, workstations fail to transfer through
> the NAT. It seems that the minimum that works over the NAT is 1500.
>
> Can somebody suggest some things to test to help narrow down this
> problem?
>
> Thanks in advance,
> Charles

Here are some comments / suggestions:

*) Various people have reported poor performance issues with various FTP
programs (clients and/or servers) on various releases of <pick your
favorite Linux distro>. So you might want to run some "Google Groups"
searches on the Linux/Redhat newsgroups using keywords like "poor ftp
performance" to see if you can locate some of these message threads.
(
http://www.google.com/advanced_group_search
Newsgroups: *linux* *redhat*
)

*) Even though the manufacturer of your RAID5 controller states that the
"required" kernel version as '2.4.20-8', chances are that other kernel
versions - and particularly later kernel versions - will work as good
as, or even better than, the 2.4.20-8 release.

*) Multiple RH9 Linux 'kernel' RPMs can be installed on a single system
at the same time, giving you the option to boot the computer into one of
several different kernel versions. So you might consider downloading and
installing the latest 'update' release of the RH9 'kernel' RPM.
(ftp://ftp.redhat.com/pub/redhat/linux/updates/9/en/os)

*) The Linux kernels that Red Hat provides contain Red Hat-specific
"fixes" in the kernel code. So you might want to try downloading,
building, and installing a stock Linux 2.4.20 (or later) kernel - i.e.,
a kernel that hasn't been "fixed" by Red Hat - to see if a stock kernel
works better. (http://www.kernel.org)

*) The 'netfilter' firewall software (in the Linux kernel) has some
kernel modules that provide protocol-specific support for connection
tracking (ip_conntrack_*) and NAT (ip_nat_*). FTP is one of the
protocols that requires these special connection tracking and NAT kernel
modules - i.e., 'ip_conntrack_ftp' and 'ip_nat_ftp', respectively.

[root]# modprobe ip_conntrack_ftp
[root]# modprobe ip_nat_ftp
[root]# lsmod | grep ^ip | sort
[root]# find /lib/modules/ -name "ip_conntrack*"
[root]# find /lib/modules/ -name "ip_nat_*"

*) Are you using the latest-and-greatest release of the 'ppp' RPM? FWIW,
here's the version that's currently installed on my RH9 Linux box:

[root]# rpm -q ppp
ppp-2.4.1-10

(n.b. I don't use PPP. So I can't offer any advice as to whether this is
a stable/good release of the 'ppp' RPM or not.)

FWIW, if the 'Fedora Core 1' distro has a newer version/release of the
'ppp' RPM, you might consider downloading and then building the *SOURCE*
RPM (SRPM) (.src.rpm) for the new release. You should be able to find
the 'ppp' SRPM on Red Hat's FTP site (which seems to be off line today,
along with Red Hat's web server <?>).

--
Jim

To reply by email, remove "link" and change "now.here" to "yahoo"
jfischer_link5809{at}now.here.com

On Fri, 14 Nov 2003 12:55:00 -0600, Jim Fischer
<jfischer_link5809@now.here.com> wrote:

>
>Here are some comments / suggestions:
>
>*) Various people have reported poor performance issues with various FTP
>programs (clients and/or servers) on various releases of <pick your
>favorite Linux distro>. So you might want to run some "Google Groups"
>searches on the Linux/Redhat newsgroups using keywords like "poor ftp
>performance" to see if you can locate some of these message threads.
>(
>http://www.google.com/advanced_group_search
>Newsgroups: *linux* *redhat*
>)

I have been doing this for the past few days. My problem is most
noticeable using FTP since FTP uses all available bandwidth, but a
simple ping also reveals the 10-20% packet loss, so an FTP specific
solution may not be in order. I could have picked a better subject
header, but it seems that many people are having this problem with
redhat 9.

>
>*) Even though the manufacturer of your RAID5 controller states that the
>"required" kernel version as '2.4.20-8', chances are that other kernel
>versions - and particularly later kernel versions - will work as good
>as, or even better than, the 2.4.20-8 release.

You would think so.

Actually, this device has very specific kernel support, unfortunately.
There has been talk of a partial source release of the driver which
would allow building the driver as a module or as part of a kernel,
but as of now, the driver is installed, prebuilt for specific kernels
only. This is a growing concern as there may be reasons that require
building a new kernel.

http://www.promise.com/support/downl...y=All&os=10 0

Promise really needs to get on the ball with Linux support.

>
>*) Multiple RH9 Linux 'kernel' RPMs can be installed on a single system
>at the same time, giving you the option to boot the computer into one of
>several different kernel versions. So you might consider downloading and
>installing the latest 'update' release of the RH9 'kernel' RPM.
>(ftp://ftp.redhat.com/pub/redhat/linux/updates/9/en/os)

Yes I know, I had 8 or 9 or so on my Mandrake system, Long live
lilo... but this doesnt help me in this case unless there are options
that I need to add or remove from my existing kernel version to fix
ppp.

>
>*) The Linux kernels that Red Hat provides contain Red Hat-specific
>"fixes" in the kernel code. So you might want to try downloading,
>building, and installing a stock Linux 2.4.20 (or later) kernel - i.e.,
>a kernel that hasn't been "fixed" by Red Hat - to see if a stock kernel
>works better. (http://www.kernel.org)
>

I would much rather use a plain vanilla kernel, but as of right now I
don't have the choice as explained above.

This is liable to be the fix, but unfortunately I cannot employ this
since the controller driver is forcing me to use a specific kernel.

I know better than to buy another one of these controllers for this
reason, but for now, all seems to be working well with the controller
itself and I need the storage capacity it is providing.

>*) The 'netfilter' firewall software (in the Linux kernel) has some
>kernel modules that provide protocol-specific support for connection
>tracking (ip_conntrack_*) and NAT (ip_nat_*). FTP is one of the
>protocols that requires these special connection tracking and NAT kernel
>modules - i.e., 'ip_conntrack_ftp' and 'ip_nat_ftp', respectively.
>
> [root]# modprobe ip_conntrack_ftp
> [root]# modprobe ip_nat_ftp
> [root]# lsmod | grep ^ip | sort
> [root]# find /lib/modules/ -name "ip_conntrack*"
> [root]# find /lib/modules/ -name "ip_nat_*"
>

I have never had to use the protocol specific modules before, but I do
not question you. I know they are there for a reason.

Additionally, I have the problem without iptables loaded. In other
words, PPP only from the linux box, ftp client from the linux box over
that ppp connection produces the poor performance.

>*) Are you using the latest-and-greatest release of the 'ppp' RPM? FWIW,
>here's the version that's currently installed on my RH9 Linux box:
>
> [root]# rpm -q ppp
> ppp-2.4.1-10
>

This is what I have installed.

>(n.b. I don't use PPP. So I can't offer any advice as to whether this is
>a stable/good release of the 'ppp' RPM or not.)
>
>FWIW, if the 'Fedora Core 1' distro has a newer version/release of the
>'ppp' RPM, you might consider downloading and then building the *SOURCE*
>RPM (SRPM) (.src.rpm) for the new release. You should be able to find
>the 'ppp' SRPM on Red Hat's FTP site (which seems to be off line today,
>along with Red Hat's web server <?>).

Building the latest PPP may not be a bad idea. It wouldnt be the
first time I have fixed smp related problems by building new binaries.

Any idea if pppd has any smp specific support or properties?

If this were a kernel specific problem, what methods are there for
diagnosing poor ppp performance aside from replacing the kernel?

How can I check if the IRQ's are being serviced properly?

How can I check if the pppd process is being serviced properly?

Charles

no name wrote:

> Maybe somebody else has experienced similar problems and can make
> suggestions that pertain to what is happening to me.
>
> I was running Mandrake 9. The system basically performed flawlessly.
> I was able to PPP with a modem from the linux box, ftp over that
> connection, as well as set up the linux box to be an IPTABLES NAT so
> that workstations on the network could have Internet connectivity as
> well. The modem line was a backup to the Cable Modem interface, which
> also worked well under Mandrake.
>
> I recently installed RH9 on this pc. I did this because I bought a
> new RAID5 controller (S150SX4) from promise and it has specific kernel
> requirements- one of them being 2.4.20-8 or 2.4.20-8smp. The
> controller card is working fine and performance is acceptable.
>
> Here is the problem:
> PPP is performing poorly. There are 10 - 20% RX errors as well as 10
> - 20% packet loss with simple pings.

Maybe your com port is getting serial overruns because the new card is
causing lots of higher priority interrupts.

I used to be able to make any ppp on com grind to a halt by scp-ing
from/flood pinging my gateway - doesn't happen now I've got a PCI DSL modem
on the same set up. I didn't fix it, but assumed it was because the IRQ on
the com was too low.

You can change this with irqtune.

Andy.

>Maybe your com port is getting serial overruns because the new card is
>causing lots of higher priority interrupts.
>
>I used to be able to make any ppp on com grind to a halt by scp-ing
>from/flood pinging my gateway - doesn't happen now I've got a PCI DSL modem
>on the same set up. I didn't fix it, but assumed it was because the IRQ on
>the com was too low.
>
>You can change this with irqtune.
Does this even work with 2.4.x SMP kernels with APIC enabled?
Charles

no name wrote:

> >Maybe your com port is getting serial overruns because the new card is
> >causing lots of higher priority interrupts.
> >
> >I used to be able to make any ppp on com grind to a halt by scp-ing
> >from/flood pinging my gateway - doesn't happen now I've got a PCI DSL
> >modem on the same set up. I didn't fix it, but assumed it was because the
> >IRQ on the com was too low.
> >
> >You can change this with irqtune.
> Does this even work with 2.4.x SMP kernels with APIC enabled?
> Charles

I haven't got a clue, if it were me I would just try and see - but then you
may have more to loose if it all goes pear shaped :-)

Andy.

Problem Solved !!!

I shut off the irqbalance service.

I adjusted the IRQ affinity for the serial port that the PPP modem was
connected to.

echo 2 > /proc/irq/4/smp_affinity

more about it here:
http://www.spoonix.com/howtos/smp_affinity.txt

When I did this, I immediately noticed a dramatic change for the
better.

By moving IRQ 4 to the second CPU, the performance was restored to
PPP.

I really dont know if it was IRQ contention or load on CPU 1, but even
with all the nics and controllers on CPU 2 with the serial port, the
performance increase was noticeable.

For good measure, I put everything but that serial port on CPU 1. Of
course individual processes can still interrupt either processor, but
it seems like it is fixed now.

RX errors are down to about 2% from 20%.
Downloads are up to 5.8 KB/sec from 1.5 KB/sec.

I notice in this configuration about 10% more CPU load to the second
processor and I take that as a good thing.

Additionally, something I didn't even have in my old configuration was
disabling MNP5 compression. This was a minor gain, but nevertheless
when we are talking kilobytes, I'll take what I can get.

Charles