FTP slows to a crawl and then quits

FTP slows to a crawl and then quits

Post by Daniel Rud » Mon, 05 Nov 2001 05:02:42



Hello,

        I am expiriancing a problem with FTP.  I have read the thread
"ftp-transfer runs with 16kb/s on a 100mbit lan" and I have implemented
the fix as described by setting all network adapters on the internal lan
to half duplex.  It does work, but now here is the problem.  Has
full-duplex transfers been broken in FBSD4.4?  There is NO mismatch
between half duplex and full duplex because the switch states that all
connected ports are running 100mbps at full duplex.  I never had this
problem under 4.2 using 100mbps at full duplex.  This just started with
4.4.  Even the two Winblows machines where having trouble with it
FreeBSD machines although between themselves, the file transfers IS
close to 100mbps because the transfers are happening at roughly at 10-12
MegaBytes/sec using the same NICs as the FreeBSD machines.  Gee, it
looks like Microshaft actually did something right for a change.  Any
suggestions as to what is causing this and how to fix it? Has a bug
report been submitted to GNATS?
--
Daniel Rudy
Reply to dcrudy at aol dot com.

*!*!* DO NOT HIT REPLY *!*!*
ALL EMAIL SENT TO REPLY ADDRESS WILL BE DELETED!

 
 
 

FTP slows to a crawl and then quits

Post by Jim Levi » Mon, 05 Nov 2001 06:26:25




> Hello,

>    I am expiriancing a problem with FTP.  I have read the thread
> "ftp-transfer runs with 16kb/s on a 100mbit lan" and I have implemented
> the fix as described by setting all network adapters on the internal lan
> to half duplex.  It does work, but now here is the problem.  Has
> full-duplex transfers been broken in FBSD4.4?  There is NO mismatch
> between half duplex and full duplex because the switch states that all
> connected ports are running 100mbps at full duplex.

If your switch claims that it's ports are 100Mbps/FDX, then you need to
force the FreeBSD boxes to the same setting, not to force them to
half-duplex. By forcing them to half-duplex you are just enforcing a link
mis-match. Both ends of the link have to be in the same mode or there'll
be problems with data transfers.

Note that not all switches seem to be 'created equal'. I've seen some of
the cheaper hubs claim to be in 100Mbps/FDX, when they couldn't really
handle that. Changing both ends of each link to 100Mbps/HDX solved the
data transfer problems.

Quote:> I never had this
> problem under 4.2 using 100mbps at full duplex.  This just started with
> 4.4.  Even the two Winblows machines where having trouble with it
> FreeBSD machines although between themselves, the file transfers IS
> close to 100mbps because the transfers are happening at roughly at 10-12
> MegaBytes/sec using the same NICs as the FreeBSD machines.  Gee, it
> looks like Microshaft actually did something right for a change.  Any
> suggestions as to what is causing this and how to fix it? Has a bug
> report been submitted to GNATS?

If there's a problem I don't have any evidence to suggest that it's
generic to 4.4. I'm running that on neworks that have Cisco and Netgear
switches and have no problems getting ~8MB/sec sustained. There could be
a problem with specific NIC's (mine are all Intel ExpressPro 10/100 and
3Com 905's), but the OS seems to handle it fine.

--
The instructions said to use Windows 98 or better, so I installed FreeBSD.

 
 
 

FTP slows to a crawl and then quits

Post by simon l » Mon, 05 Nov 2001 08:33:37





>> Hello,

>>        I am expiriancing a problem with FTP.  I have read the thread
>> "ftp-transfer runs with 16kb/s on a 100mbit lan" and I have implemented
>> the fix as described by setting all network adapters on the internal lan
>> to half duplex.  It does work, but now here is the problem.  Has
>> full-duplex transfers been broken in FBSD4.4?  There is NO mismatch
>> between half duplex and full duplex because the switch states that all
>> connected ports are running 100mbps at full duplex.

>If your switch claims that it's ports are 100Mbps/FDX, then you need to
>force the FreeBSD boxes to the same setting, not to force them to
>half-duplex. By forcing them to half-duplex you are just enforcing a link
>mis-match. Both ends of the link have to be in the same mode or there'll
>be problems with data transfers.

>Note that not all switches seem to be 'created equal'. I've seen some of
>the cheaper hubs claim to be in 100Mbps/FDX, when they couldn't really
>handle that. Changing both ends of each link to 100Mbps/HDX solved the
>data transfer problems.

In many cases the problems lie with the cards being used.  I have
an el cheapo 8 port switch, that does full duplex fine with Intel
cards but will not talk to Realtek based cards using full duplex.  I force
the Realtek cards to half duplex and everything works fine.

In my case the switch will only negoitiate half duplex with the
Realtek cards.

- Show quoted text -

Quote:

>> I never had this
>> problem under 4.2 using 100mbps at full duplex.  This just started with
>> 4.4.  Even the two Winblows machines where having trouble with it
>> FreeBSD machines although between themselves, the file transfers IS
>> close to 100mbps because the transfers are happening at roughly at 10-12
>> MegaBytes/sec using the same NICs as the FreeBSD machines.  Gee, it
>> looks like Microshaft actually did something right for a change.  Any
>> suggestions as to what is causing this and how to fix it? Has a bug
>> report been submitted to GNATS?

>If there's a problem I don't have any evidence to suggest that it's
>generic to 4.4. I'm running that on neworks that have Cisco and Netgear
>switches and have no problems getting ~8MB/sec sustained. There could be
>a problem with specific NIC's (mine are all Intel ExpressPro 10/100 and
>3Com 905's), but the OS seems to handle it fine.

>--
>The instructions said to use Windows 98 or better, so I installed FreeBSD.

Simon

--
----------------
Simon Lai
Synatech Pty Ltd
newsjl.at.synatech.com.au

 
 
 

FTP slows to a crawl and then quits

Post by Merli » Mon, 05 Nov 2001 10:41:06


How do I force a card into HalfDuplex on the FreeBSD box - or at least 10Mb
instead of 100. I may have a similar problem. I have an Accton 8 Port 10MB
Hub, but the card in the new FreeBSD box does the old - slow then stop for
ages then start again thing. Lots of collissions on the collission led. So I
figure a card mismatch somewhere. Maybe I'll just dump the card and try a
different one.

ah ha. dmesg reveals all

rlphy0: <RealTek internal media interface> on miibus0
rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto

Is this telling me that it's trying to run at 100, when the hub is only a 10
???

hmmmmmm
Bob

Quote:> In many cases the problems lie with the cards being used.  I have
> an el cheapo 8 port switch, that does full duplex fine with Intel
> cards but will not talk to Realtek based cards using full duplex.  I force
> the Realtek cards to half duplex and everything works fine.

> ----------------
> Simon Lai
> Synatech Pty Ltd
> newsjl.at.synatech.com.au

 
 
 

FTP slows to a crawl and then quits

Post by Merli » Mon, 05 Nov 2001 11:05:22



Quote:

> How do I force a card into HalfDuplex on the FreeBSD box - or at least
10Mb
> instead of 100. I may have a similar problem. I have an Accton 8 Port 10MB
> Hub, but the card in the new FreeBSD box does the old - slow then stop for
> ages then start again thing. Lots of collissions on the collission led. So
I
> figure a card mismatch somewhere. Maybe I'll just dump the card and try a
> different one.

> ah ha. dmesg reveals all

rl0: <Accton MPX 5030/5038 10/100BaseTX> port 0xd800-0xd8ff mem
0xf5800000-0xf58000ff irq 9 at device 10.0 on pci2

who knows what this is?????

Quote:> rlphy0: <RealTek internal media interface> on miibus0
> rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto

> Is this telling me that it's trying to run at 100, when the hub is only a
10
> ???

> hmmmmmm
> Bob

> > In many cases the problems lie with the cards being used.  I have
> > an el cheapo 8 port switch, that does full duplex fine with Intel
> > cards but will not talk to Realtek based cards using full duplex.  I
force
> > the Realtek cards to half duplex and everything works fine.

> > ----------------
> > Simon Lai
> > Synatech Pty Ltd
> > newsjl.at.synatech.com.au

 
 
 

FTP slows to a crawl and then quits

Post by Daniel Rud » Mon, 05 Nov 2001 15:07:22



> How do I force a card into HalfDuplex on the FreeBSD box - or at least 10Mb
> instead of 100. I may have a similar problem. I have an Accton 8 Port 10MB
> Hub, but the card in the new FreeBSD box does the old - slow then stop for
> ages then start again thing. Lots of collissions on the collission led. So I
> figure a card mismatch somewhere. Maybe I'll just dump the card and try a
> different one.

> ah ha. dmesg reveals all

> rlphy0: <RealTek internal media interface> on miibus0
> rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto

> Is this telling me that it's trying to run at 100, when the hub is only a 10
> ???

> hmmmmmm
> Bob

> > In many cases the problems lie with the cards being used.  I have
> > an el cheapo 8 port switch, that does full duplex fine with Intel
> > cards but will not talk to Realtek based cards using full duplex.  I force
> > the Realtek cards to half duplex and everything works fine.

> > ----------------
> > Simon Lai
> > Synatech Pty Ltd
> > newsjl.at.synatech.com.au

It's telling you that the NIC supports those medias.  ifconfig <NIC id>
media 10BaseTX mediaopt half-duplex should do the trick.
--
Daniel Rudy
Reply to dcrudy at aol dot com.

*!*!* DO NOT HIT REPLY *!*!*
ALL EMAIL SENT TO REPLY ADDRESS WILL BE DELETED!

 
 
 

FTP slows to a crawl and then quits

Post by Merli » Mon, 05 Nov 2001 17:01:49


No worries. It's running full-duplex now, but 10Mb. I suspect it didn't know
what it was soupposed to do, but now it does.

thanks
Bob

Quote:

> It's telling you that the NIC supports those medias.  ifconfig <NIC id>
> media 10BaseTX mediaopt half-duplex should do the trick.
> --
> Daniel Rudy
> Reply to dcrudy at aol dot com.

> *!*!* DO NOT HIT REPLY *!*!*
> ALL EMAIL SENT TO REPLY ADDRESS WILL BE DELETED!

 
 
 

FTP slows to a crawl and then quits

Post by Daniel Rud » Wed, 07 Nov 2001 19:18:58



> Hello,

>         I am expiriancing a problem with FTP.  I have read the thread
> "ftp-transfer runs with 16kb/s on a 100mbit lan" and I have implemented
> the fix as described by setting all network adapters on the internal lan
> to half duplex.  It does work, but now here is the problem.  Has
> full-duplex transfers been broken in FBSD4.4?  There is NO mismatch
> between half duplex and full duplex because the switch states that all
> connected ports are running 100mbps at full duplex.  I never had this
> problem under 4.2 using 100mbps at full duplex.  This just started with
> 4.4.  Even the two Winblows machines where having trouble with it
> FreeBSD machines although between themselves, the file transfers IS
> close to 100mbps because the transfers are happening at roughly at 10-12
> MegaBytes/sec using the same NICs as the FreeBSD machines.  Gee, it
> looks like Microshaft actually did something right for a change.  Any
> suggestions as to what is causing this and how to fix it? Has a bug
> report been submitted to GNATS?
> --
> Daniel Rudy
> Reply to dcrudy at aol dot com.

> *!*!* DO NOT HIT REPLY *!*!*
> ALL EMAIL SENT TO REPLY ADDRESS WILL BE DELETED!

Here's an update as to what the problem is.  I have confirmed that it IS
a bug in the sis device driver.  When I comment out a secion of the code
that resets the NIC, the transfers become blazingly fast.  Here's the
info:

static void sis_reset(sc)
        struct sis_softc        *sc;
{
        register int            i;

        SIS_SETBIT(sc, SIS_CSR, SIS_CSR_RESET);

        for (i = 0; i < SIS_TIMEOUT; i++) {
                if (!(CSR_READ_4(sc, SIS_CSR) & SIS_CSR_RESET))
                        break;
        }

        if (i == SIS_TIMEOUT)
                printf("sis%d: reset never completed\n", sc->sis_unit);

        /* Wait a little while for the chip to get its brains in order.
*/
        DELAY(1000);

        /*
         * If this is a NetSemi chip, make sure to clear
         * PME mode.
         */
/*      if (sc->sis_type == SIS_TYPE_83815) {
                CSR_WRITE_4(sc, NS_CLKRUN, NS_CLKRUN_PMESTS);
                CSR_WRITE_4(sc, NS_CLKRUN, 0);
        }

commented out due for testing pourposes */

        return;

Quote:}

That peice that I commented out seems to be the cause of the slow to a
crawl and quit problem.  Now I can transfer files 40MB or more at full
speed (I used a 46MB tar file for test pourposes.)  It also has fixed
the NFS problem that I was having as well.  PME mode is Power Management
Event as per the National Semiconductor datasheet.  Credit goes to some
helpfull soul on the freebsd-questions list for pointing out this little
bit of code.
--
Daniel Rudy
Reply to dcrudy at aol dot com.

*!*!* DO NOT HIT REPLY *!*!*
ALL EMAIL SENT TO REPLY ADDRESS WILL BE DELETED!

 
 
 

1. FTP slows down to a crawl

I just setup Apache 1.3.0 on a FreeBSD 2.2.6 server.  I have it
connected to the Internet by a 33.6 modem on a regular analog
telephone line. I can see the server from local machines on the
same network and can also see it across the Internet if I enter
the "dynamic" IP address assigned by by ISP.

So last night we were testing it for speed. Since the pages are
loading pretty quickly across the Internet, I figured, great the
FTP should go fast too.  So a friend of mine who has an ISDN
dial-up with his ISP logged into my Apache server from his house
many miles away.  He then tried to transfer a file of about 2 MB to
the server.  It took off likity-split, but then slowed down to an aboslute
crawl.  Another transfer I tried earlier in the day did the same thing
to me from my computer at the office.  Does this sound like some
setting I have wrong in the conf files?

Please help, we need fast FTP.

2. ATI 32MB RAGE FURY video card and Redhat

3. Slow-Crawling-FTP Connect Time

4. wuftpd and Guest Users...- again?

5. xdr nfs highmem deadlock fix [Re: filesystem access slowing system to a crawl]

6. Opinion on Linux Wireless home networking

7. RH 2.4.7-2 kernel slows to a crawl under heavy i/o

8. Sun F77 compiler on x86

9. Diald + SLIP slows down to a crawl

10. Streams problem - systems slows to a crawl

11. kppp--slows normal users to a crawl?

12. Why does my SLIP slow to a crawl

13. filesystem access slowing system to a crawl