Slow FTP Client

When using the FTP client to FTP to a Windows Server 2008 R2 server we get extremely slow transfers. It appears to hang at times. I have tested this to a QNX box and there is no problem. However FTPing to a Solaris box also shows extremely slow transfers. Below are some statistics. FTPing from the Solaris box to the Windows Server box does not show any problems at all. I adjusted send and receive buffers and it looks as if it completes immediate but it hangs at the end and even states that is is stalled then it finishes at about the same transfer rates

To Window Server 2008 R2
226 File received ok.Transfer bytes:4196352Bytes;Average speed is:77.321KB/s
4196352 bytes sent in 01:14 (54.87 KB/s)

To Solaris
226 Transfer complete.
4196352 bytes sent in 00:33 (121.34 KB/s)

To Qnx
226 Transfer complete.
4196352 bytes sent in 00:00 (9.71 MB/s)

Djryan77,

I don’t quite understand what you posted. Are those time from QNX->Windows/Solarais/QNX or are then from Windows->QNX,Solaris->QNX, RNX->QNX. I am not quite sure which way you are having problems.

Are you transferring across a network (ie through a router to another subnet) or directly connected machine on the same LAN?

I wonder if the network card is running in 10 Mbit mode or Half Duplex. Use the command ‘nicinfo’ to see what speed/duplex the card is running at under QNX.

Tim

The times are from QNX to Windows Server 2008 R2, and from QNX to Solaris and from QNX to QNX. Uploading from windows and solaris to QNX is fast. The problem is using the QNX FTP Client to upload a 4mb file to an FTP Server running on Windows or Solaris. The maximum speed is 55 KBs. It is always from QNX.

The transfers are all on the same subnet, directly connected machines.

Speed is 1000.00 Mb/s full-duplex. Wireshark captures show large delays (several second delays) immediately after the remote host sends ACK(s) in ftp-data mode. It is taking 65 seconds to upload a 4mb file when it should take < a second.

wm0:
INTEL 82544 Gigabit (Copper) Ethernet Controller

Physical Node ID … 00106F 05C459
Current Physical Node ID … 00106F 05C459
Current Operation Rate … 1000.00 Mb/s full-duplex
Active Interface Type … MII
Active PHY address … 0
Maximum Transmittable data Unit … 1500
Maximum Receivable data Unit … 0
Hardware Interrupt … 0xa
Memory Aperture … 0xfe6e0000 - 0xfe6fffff
Promiscuous Mode … Off
Multicast Support … Enabled

Packets Transmitted OK … 18030
Bytes Transmitted OK … 19759829
Broadcast Packets Transmitted OK … 11
Multicast Packets Transmitted OK … 0
Memory Allocation Failures on Transmit … 0

Packets Received OK … 30485
Bytes Received OK … 2953937
Broadcast Packets Received OK … 18078
Multicast Packets Received OK … 0
Memory Allocation Failures on Receive … 0

Single Collisions on Transmit … 0
Multiple Collisions on Transmit … 0
Deferred Transmits … 0
Late Collision on Transmit errors … 0
Transmits aborted (excessive collisions) … 0
Jabber detected … 0
Receive Alignment errors … 0
Received packets with CRC errors … 1
Packets Dropped on receive … 0
Oversized Packets received … 0
Short packets … 0
Squelch Test errors … 0
Invalid Symbol Errors … 0

The bad received packet with a CRC is very suspicous given the low amount of data transfered. I wouldn’t worry if it’s 1 out a billion packet but 1 out of 30500 is cause for concerned. Check the hardware.

This might sound unrelated, but when ftp’ing from a Windows system to QNX, make sure you are in binary mode, which is absurdly not the default.

ftp> bin

I’ve seen windows ftp do strange things in text mode.

We are having driver problems with the INTEL 82544 Gigabit (Copper) Ethernet Controller on our QNX boxes running QNX 6.4.0. These drivers are causing excessive Symbol Frame Errors on our Cisco WS-C2960S-24TS-L L2 switch. We can monitor the ports on the switch and we continue to receive these errors non-stop. We have installed new CAT6 tested cables also. When we FTP from these nodes our transfer rate is limited to 60 Kbytes/sec because of these Symbol Frame Errors.

We have tested by dropping the speed to 100 MB/s and using Half Duplex and the speed approaches 4,000+Kbytes/sec. This is not an acceptable solution to the problem and we need this fixed as soon as possible.
I notice that in QNX 6.3.1 that io-net was running and the MTU size was 1514 however we do not see io-net running on QNX 6.4.0 and there is no io-net in /sbin/.

We need to be able to run at Gigabit speed.and we need to know how to control the driver.

The network driver structure was changed from QNX 6.3 to QNX 6.4, so io-net was changed to io-pkt.

I believe there was a meta driver written so that io-net drivers would work under io-pkt.
I wonder if you are using the 6.3 driver using this meta-driver for your card?
If so, it might work better with a native io-pkt driver if there is one.

6.4.0 was very quickly replaced with 6.4.1, so you might want to consider it a beta and move on. 6.4.1 was superseded by 6.5 which you might want to think of as 6.4.2. It’s not all that different. I suspect that a 6.5 io-pkt driver would will work with 6.4.0 if you are stuck at that version.

We are having driver problems with the INTEL 82544 Gigabit (Copper) Ethernet Controller on our QNX boxes running QNX 6.4.0. These drivers are causing excessive Symbol Frame Errors on our Cisco WS-C2960S-24TS-L L2 switch. We can monitor the ports on the switch and we continue to receive these errors non-stop. We have installed new CAT6 tested cables also. When we FTP from these nodes our transfer rate is limited to 60 Kbytes/sec because of these Symbol Frame Errors.

We have tested by dropping the speed to 100 MB/s and using Half Duplex and the speed approaches 4,000+Kbytes/sec.