Re: bin/60443: ftp ASCII transfers are too slow

The following reply was made to PR bin/60443; it has been noted by GNATS.

From: [email protected] (Michael van Elst)
To: [email protected]
Cc: 
Subject: Re: bin/60443: ftp ASCII transfers are too slow
Date: Sun, 12 Jul 2026 11:53:39 -0000 (UTC)

 [email protected] ("[email protected] via gnats") writes:
 
 >FTP ASCII transfers seem to interact badly with Nagle's algorithm
 >because ASCII xfers rely on libc's BUFSIZ (1KB) internal buffer.
 
 I doubt that Nagle's algorithm has any effect here. After all,
 it would just improve throughput at the cost of latency.
 
 What you see is the higher overhead from stdio.
 
 E.g.:
 
 ftp> get in.txt
 local: in.txt remote: in.txt
 229 Entering Extended Passive Mode (|||62337|)
 150 Opening ASCII mode data connection for 'in.txt' (306788817 bytes).
 226 Transfer complete.
 312122680 bytes received in 00:08 (34.99 MiB/s)
 
 vs.
 
 ftp> get in.txt
 local: in.txt remote: in.txt
 229 Entering Extended Passive Mode (|||62335|)
 150 Opening BINARY mode data connection for 'in.txt' (306788817 bytes).
 226 Transfer complete.
 306788817 bytes received in 00:08 (33.36 MiB/s)
 
 and (with kern.sofixedbuf=0 to keep TCP autoscaling enabled):
 
 ftp> get in.txt
 local: in.txt remote: in.txt
 229 Entering Extended Passive Mode (|||62332|)
 150 Opening ASCII mode data connection for 'in.txt' (306788817 bytes).
 226 Transfer complete.
 312122680 bytes received in 00:08 (33.22 MiB/s)
 
 vs.
 
 ftp> get in.txt
 local: in.txt remote: in.txt
 229 Entering Extended Passive Mode (|||62331|)
 150 Opening BINARY mode data connection for 'in.txt' (306788817 bytes).
 226 Transfer complete.
 306788817 bytes received in 00:05 (53.21 MiB/s)
 
 
 
 In all cases the ftpd was CPU limited (on a 1.6GHz Atom N3150).
 
 For ASCII transfers, about 44% of a core are spent in usermode.
 For BINARY transfers, less than 1% of a core is spent in usermode, but
 the CPU spends about twice the time in system mode.
 
 
 The client shows similar behaviour. Funneling data through stdio
 takes lots of time in usermode and time spent in system mode
 about doubles for the binary transfer.
 
 > time ftp -x 8192 -V ftp://ftp:[email protected]/pub/in.txt\;type=a
 2.370u 0.671s 0:08.63 35.2%     0+0k 0+14io 0pf+0w
 
 > time ftp -x 8192 -V ftp://ftp:[email protected]/pub/in.txt\;type=i
 0.050u 1.234s 0:08.94 14.3%     0+1k 0+16io 0pf+0w
 
 and with autoscaling:
 
 > time ftp -x 8192 -V ftp://ftp:[email protected]/pub/in.txt\;type=a
 2.352u 0.713s 0:09.42 32.4%     0+0k 0+14io 0pf+0w
 
 > time ftp -x 8192 -V ftp://ftp:[email protected]/pub/in.txt\;type=i
 0.038u 1.072s 0:05.42 20.2%     1+1k 0+10io 0pf+0w
 
 
 
 Now, why does system time increase? It should process the same
 amount of data, and the system call overhead should be larger
 for ASCII transfers. Maybe that's more lock contention in the kernel
 at higher speeds, but the lockstat numbers are not conclusive.