Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

FTP very slow download rate

Status
Not open for further replies.

NIEDAX

Programmer
Mar 24, 2005
7
0
0
DE
Hi,
When I download a file with Win98 from my Server (SCO UNIX Release 5 FTp-Server:ftpd), then I have a good download rate between 1000 and 2000 KByes/s. When I download a file with WinXP or Ubuntu Linux from the Server, I have a very slow download rate between 50 and 200 KBytes/s!!! I have no idea to solve this problem!

I have a second SCO Unix mashine without this Problems. I'm new in SCO UNIX so please describe your answer a little bit detailed.

Server:
SCO UNIX Release 5

FTP-Server:
ftpd

FTP-Clients:
gFTP
TotalCommander
SmartFTP

Thx Olli
 
Are all the machines (SCOs,Win98,WinXP and Linux) on the same subnet ?
What is the ouptput of the uname -a command on both SCO ?

Hope This Helps, PH.
FAQ219-2884
FAQ181-2886
 
I ran into that same symptom just yesterday on a Client's system.
Run "netstat -m". If you see errors listed, it's time to reboot the box. That doesn't really address the cause, but it might remove the symptoms for awhile.

"Proof that there is intelligent life in Oregon. Well, Life anyway.
 

We had to select FTP's PASV mode with some combinations of XP and installed patches.

 
Hi

PHV (MIS):
All mashines are on the same subnet.
uname -a :
First SCO mashine: SCO_SV cook 3.2 5.0.5 i386
Second SCO mashine: SCO_SV sni 3.2 5.0.6 i386

motoslide (MIS):
netstat -m have no errors listed.

M577A2 (TechnicalUser):
I have tested PASV mode but it isn't faster :-(

Thanks at all.

Any other idea?

Greats Olli
 
are the xp and linux systems "resolvable" from the sco system.

i.e. can the sco system resolve the names of these systems from their ip address.

try adding them to the hosts file and set hostresorder in /etc/resolv.conf to :

hostresorder local bind
 
From the Clients I can resolve the sco system and from the sco system I can resolve all clients via DNS-Server without problems.
 
just to make sure....
from the SCO system you can resolve the clients name from its ip...
not the ip from its name.

If that is ok then the next thing to look at is "sar" while a transfer is taking place.
sar 5 5

and what is the output of ifconfig (particularly looking at buffer sizes).
 
Maybe you can find something on de SCO system using:
llistat -l

Is the slow system a HP server? If it is, what driver did you use for the NIC? There is a problem with the HP 10/100 driver. Had the same problem with a HP server and changed the NIC with a 3Com and the problem was solved.
 
Hi

stanhubble (MIS):
the sco system can resolve from name->ip and ip->name.
Result from sar 5 5:
Average usr 36, sys 8, wio 48, idle 7

ifconfig:

net1: flags=4043<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet <IP-ADRESS> netmask <NETMASK> broadcast <BORADCAST-IP>
perf. params: recv size: 24576; send size: 24576; full-size frames: 1
ether <MAC-ADDRESS>



Hidsjer (TechnicalUser):

With the command "hw" I can see that the sco system have a "Intel Ether Express PRO/100B LAN Adapter REV 1" but in the last lines from the output I have found the following line:

%hptx0 0xDCE0-0xDD1F 16 - type=HP 10/100

I think this means that I use the Intel Card with the HP driver? So I must only change the HP driver with an Intel and it will work!?
 
Yes I have a HP Server: HP Netserver LH3
 
It's definitly worth trying. In our case we just replaced the card by a 3com (money doesn't matter) So, I can't tell you if replacing the driver is sufficiant.
But this is the combination (card & driver) I was refering to yes. You don't have problems with telnet or other small packets but when trying to put serious data over the line it's very slow.
Good Luck.
 
I recall having the same issue with that same combination as Hidsjer. That was about 8 years ago and only occured in some Client environments. Perhaps it's related to other equipment on the network, but switching to 3COM solved the issue. I *think* installing the Intel drivers also helped, but it's been too long for me to remember with much accuracy.

"Proof that there is intelligent life in Oregon. Well, Life anyway.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top