Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am running vsftpd 2.2.1 on an Ubuntu 8.04 machine with a pretty straight-forward configuration and am experiencing a strange issue regarding uploads to the machine via FTP. If I upload text files the transfer speed is about 70 KB/s, if I upload binary data (zip file, etc.) the transfer speed is about 50 times as fast. I have used several different clients on different operating systems, different file sizes, etc. I have tried in both binary and ASCII modes for the text file transfer and nothing seems to make a difference. Has anybody seen this before or have any idea what might be causing this behavior?

Update: The FTP server is on a different subnet as the client machines that I previously tested with and have a Linux gateway in between, it appears that the issue is only occurring when machines on a different subnet connect through the gateway to the FTP server. When machines on the same subnet as the FTP server upload text files the issues doesn't seem to occur. This still doesn't make much sense but maybe there is an issue with the ip_conntrack_ftp module used on the gateway.

Update: It turns out that someone had set up Snort IDS on one side of the gateway which was breaking up FTP packets on approximately newline barriers which caused the lag for text files.

share|improve this question
    
Thanks for providing the answer here. I ran into something similar a long time ago and solved it in the end, but even reading your question I had forgotten what the deal was. –  Caleb Oct 5 '10 at 7:11
    
Please mark this as accepted. –  Konrads Nov 2 '10 at 8:30
    
@Konrads: Done, thanks. –  Robert Gamble Nov 2 '10 at 12:04

1 Answer 1

up vote 1 down vote accepted

Maybe the line-ending conversions in vsftpd were written inefficiently, and since binary mode is most commonly used, no one has bothered to improve the algorithm used in vsftpd.

Or, it could just be that passing data from a tcp socket out to disk really is a lot faster than having to check every character for CR and LF. The check could introduce enough latency in the connection to reduce your transfer speed.

Are you running tests locally on Ethernet (low latency, would be affected greatly by additional latency) or across the Internet?

share|improve this answer
    
I tried both ASCII and binary mode and for text files it makes no difference. In binary mode, text files are still much slower so I don't think that the CR/CRLF conversions should even come into the picture. I am testing locally on a 100 Mbit local network. –  Robert Gamble Jul 16 '10 at 17:28
    
Is it tied to file extension? Could a virus scanner or firewall on the server or client be adding overhead to certain extensions? –  tomlogic Jul 16 '10 at 20:34
    
It doesn't appear to be, I tried with and without extensions, there is not virus scanner or anything else involved, I have reproduced this between a linux client machine, linux server, and linux firewall, all without AV or anything else that should be affecting anything. The gateway is just forwarding traffic between the subnets. –  Robert Gamble Jul 16 '10 at 22:02
    
Time to install Wireshark (or use tcpdump) and do some packet captures. Compare the two transfers (binary file, text file) looking for differences. –  tomlogic Jul 16 '10 at 22:33
    
Yeah, that is among the things on my list now. –  Robert Gamble Jul 17 '10 at 5:06

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.