vsftpd fast for binary files, slow for text files

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.

From serverfault Robert Gamble

• 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?

  Robert Gamble : 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.

  tomlogic : Is it tied to file extension? Could a virus scanner or firewall on the server or client be adding overhead to certain extensions?

  Robert Gamble : 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.

  tomlogic : Time to install Wireshark (or use `tcpdump`) and do some packet captures. Compare the two transfers (binary file, text file) looking for differences.

  Robert Gamble : Yeah, that is among the things on my list now.
  From tomlogic