<?xml version="1.0" encoding="utf-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: File Transfer Woes</title>
	<atom:link href="http://gentlenews.com/2005/10/31/file-transfer-woes/feed/" rel="self" type="application/rss+xml" />
	<link>http://gentlenews.com/2005/10/31/file-transfer-woes/</link>
	<description>Invalidating people's opinions and personal sentiments since 1981.</description>
	<pubDate>Thu, 04 Dec 2008 22:14:40 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.3</generator>
		<item>
		<title>By: Frenchy</title>
		<link>http://gentlenews.com/2005/10/31/file-transfer-woes/#comment-1811</link>
		<dc:creator>Frenchy</dc:creator>
		<pubDate>Sun, 29 Jan 2006 15:30:43 +0000</pubDate>
		<guid isPermaLink="false">http://gentlenews.com/archives/2005/10/31/file-transfer-woes/#comment-1811</guid>
		<description>Hi Farris, did you find a solution to why the transfers are slow when using SFTP through Nautilus?  I have the same problem and I, like you, am also an Ubuntu convert.  I wonder if it's something in Ubuntu.

I've read through the responses and thought that you got a pretty raw deal.  Firstly, the ACK is done at the TCP/IP stack level, not by client software.  Happy to be corrected on this.

Also, rule out CPU overhead because the command line version is fast and therefore SSH (i.e. the CPU time required for compression) isn't a problem.  Also, to backup my claim, when I transferred a 600 MB file, the idle time on both client and server remained above 90%.  CPU time is not the problem.

Just as a comparison, my 600 MB file took 10 minutes to transfer which , by my calculations, is 1 MB/sec which is 8 Mbits/sec, very slow.

The last piece to the puzzle is that all network communications to the box slow down when I'm transferring the file through Nautilus using SSH/SFTP.  I think that I'm going to run a packet sniffer on the network to see what's being sent, more to the point, what's taking up the bandwidth.</description>
		<content:encoded><![CDATA[<p>Hi Farris, did you find a solution to why the transfers are slow when using SFTP through Nautilus?  I have the same problem and I, like you, am also an Ubuntu convert.  I wonder if it&#8217;s something in Ubuntu.</p>
<p>I&#8217;ve read through the responses and thought that you got a pretty raw deal.  Firstly, the ACK is done at the TCP/IP stack level, not by client software.  Happy to be corrected on this.</p>
<p>Also, rule out CPU overhead because the command line version is fast and therefore SSH (i.e. the CPU time required for compression) isn&#8217;t a problem.  Also, to backup my claim, when I transferred a 600 <acronym title="Megabyte">MB</acronym> file, the idle time on both client and server remained above 90%.  CPU time is not the problem.</p>
<p>Just as a comparison, my 600 <acronym title="Megabyte">MB</acronym> file took 10 minutes to transfer which , by my calculations, is 1 <acronym title="Megabyte">MB</acronym>/sec which is 8 Mbits/sec, very slow.</p>
<p>The last piece to the puzzle is that all network communications to the box slow down when I&#8217;m transferring the file through Nautilus using SSH/SFTP.  I think that I&#8217;m going to run a packet sniffer on the network to see what&#8217;s being sent, more to the point, what&#8217;s taking up the bandwidth.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Farris</title>
		<link>http://gentlenews.com/2005/10/31/file-transfer-woes/#comment-1753</link>
		<dc:creator>Farris</dc:creator>
		<pubDate>Tue, 01 Nov 2005 15:37:49 +0000</pubDate>
		<guid isPermaLink="false">http://gentlenews.com/archives/2005/10/31/file-transfer-woes/#comment-1753</guid>
		<description>The next time I need to move data securely, I'll probably go with FTP/TLS. Thanks, dude.

It's GOTTA be the acks that are slowing this thing down. No amount of CPU overhead on a P4 2GHz (I forget the bus speed) can account for an almost 90% performance loss.</description>
		<content:encoded><![CDATA[<p>The next time I need to move data securely, I&#8217;ll probably go with FTP/TLS. Thanks, dude.</p>
<p>It&#8217;s GOTTA be the acks that are slowing this thing down. No amount of CPU overhead on a P4 2GHz (I forget the bus speed) can account for an almost 90% performance loss.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Josh-Daniel Davis</title>
		<link>http://gentlenews.com/2005/10/31/file-transfer-woes/#comment-1751</link>
		<dc:creator>Josh-Daniel Davis</dc:creator>
		<pubDate>Tue, 01 Nov 2005 13:26:13 +0000</pubDate>
		<guid isPermaLink="false">http://gentlenews.com/archives/2005/10/31/file-transfer-woes/#comment-1751</guid>
		<description>That doesn't account for the SMB slowdown.

Network tuning (send and receive buffers) would help SMB.

SFTP is poorly implemented in many places.

TLS/FTP is pretty good, all things considered.</description>
		<content:encoded><![CDATA[<p>That doesn&#8217;t account for the SMB slowdown.</p>
<p>Network tuning (send and receive buffers) would help SMB.</p>
<p>SFTP is poorly implemented in many places.</p>
<p>TLS/FTP is pretty good, all things considered.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Josh-Daniel Davis</title>
		<link>http://gentlenews.com/2005/10/31/file-transfer-woes/#comment-1750</link>
		<dc:creator>Josh-Daniel Davis</dc:creator>
		<pubDate>Tue, 01 Nov 2005 13:22:38 +0000</pubDate>
		<guid isPermaLink="false">http://gentlenews.com/archives/2005/10/31/file-transfer-woes/#comment-1750</guid>
		<description>Most SFTP clients still run synchronously.  They wait for ACK before sending another packet.  This is a huge perf loss.  SCP doesn't do that, but there's still alot more protocol overhead.

I recommend TLS over FTP.  It's still not as fast as ftp, but it's as close as you can get with encryption.

vsftpd supports TLS.  I use filezilla (from sourceforge) for winders client. 
</description>
		<content:encoded><![CDATA[<p>Most SFTP clients still run synchronously.  They wait for ACK before sending another packet.  This is a huge perf loss.  SCP doesn&#8217;t do that, but there&#8217;s still alot more protocol overhead.</p>
<p>I recommend TLS over <a href="http://FTP" rel="nofollow">http://FTP</a>.  It&#8217;s still not as fast as ftp, but it&#8217;s as close as you can get with encryption.</p>
<p>vsftpd supports TLS.  I use filezilla (from sourceforge) for winders client.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jim</title>
		<link>http://gentlenews.com/2005/10/31/file-transfer-woes/#comment-1748</link>
		<dc:creator>Jim</dc:creator>
		<pubDate>Tue, 01 Nov 2005 10:56:08 +0000</pubDate>
		<guid isPermaLink="false">http://gentlenews.com/archives/2005/10/31/file-transfer-woes/#comment-1748</guid>
		<description>I think by overhead... JustinM means CPU overhead.

With FTP, for instance, the CPU has very little to do. The data is not converted in anyway. It's simply crammed into packets and shipped across the network. With SSH it has to be encrypted on one end and then decrypted on the other, and, unfortunately, that's a lot of math. So, your CPU will be VERY involved with an SSH transaction. Now, if you use SFTP over SSH, you have to deal with an SSH subsystem and any of the sillyness involved there.... and it just gets dirtier and dirtier.

As far as why nautilus SSH would be slower than command line SSH more than likely has to do with packet size and any extra CPU being sucked out by whatever fancy dialog box the GUI is trying to show you. Nautilus isn't know for speed.

What I'm trying to say is, your network and your disks are probably NOT your bottleneck. CPU is playing a large role here.

At work about a year ago they pushed out a requirement to use encryption for all data travelling over the intranet, even if it isn't destined to leave our network. We saw a HUGE slow down from almost EVERY application... even though they are all written in different languages, on different platforms, with different purposes. 
</description>
		<content:encoded><![CDATA[<p>I think by overhead&#8230; JustinM means CPU overhead.</p>
<p>With FTP, for instance, the CPU has very little to do. The data is not converted in anyway. It&#8217;s simply crammed into packets and shipped across the network. With SSH it has to be encrypted on one end and then decrypted on the other, and, unfortunately, that&#8217;s a lot of math. So, your CPU will be VERY involved with an SSH transaction. Now, if you use SFTP over SSH, you have to deal with an SSH subsystem and any of the sillyness involved there&#8230;. and it just gets dirtier and dirtier.</p>
<p>As far as why nautilus SSH would be slower than command line SSH more than likely has to do with packet size and any extra CPU being sucked out by whatever fancy dialog box the <acronym title="Graphical User Interface">GUI</acronym> is trying to show you. Nautilus isn&#8217;t know for speed.</p>
<p>What I&#8217;m trying to say is, your network and your disks are probably NOT your bottleneck. CPU is playing a large role here.</p>
<p>At work about a year ago they pushed out a requirement to use encryption for all data travelling over the intranet, even if it isn&#8217;t destined to leave our network. We saw a HUGE slow down from almost EVERY application&#8230; even though they are all written in different languages, on different platforms, with different purposes.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Farris</title>
		<link>http://gentlenews.com/2005/10/31/file-transfer-woes/#comment-1746</link>
		<dc:creator>Farris</dc:creator>
		<pubDate>Tue, 01 Nov 2005 04:49:16 +0000</pubDate>
		<guid isPermaLink="false">http://gentlenews.com/archives/2005/10/31/file-transfer-woes/#comment-1746</guid>
		<description>It can't be overhead, because the numbers I'm giving are actual throughput on the interface, as measured by iptraf. I sorta misspoke when I said "effective throughput".

Oh, and... um... Yeah. Your mama.</description>
		<content:encoded><![CDATA[<p>It can&#8217;t be overhead, because the numbers I&#8217;m giving are actual throughput on the interface, as measured by iptraf. I sorta misspoke when I said &#8220;effective throughput&#8221;.</p>
<p>Oh, and&#8230; um&#8230; Yeah. Your mama.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Justinm</title>
		<link>http://gentlenews.com/2005/10/31/file-transfer-woes/#comment-1744</link>
		<dc:creator>Justinm</dc:creator>
		<pubDate>Tue, 01 Nov 2005 04:19:41 +0000</pubDate>
		<guid isPermaLink="false">http://gentlenews.com/archives/2005/10/31/file-transfer-woes/#comment-1744</guid>
		<description>Not being anywhere near an expert on the subject, I would assume that the basic difference between sftp and plain ol' ftp is the overhead that is going into the encryption/decryption.  Normally this overhead doesn't bug you, but, at the data quantity you're talking about, that overhead adds up quickly. As far as why the interface versions are slower than their command-line counterparts, I'll leave that to more knowledgeable folk.

And, as far as my mother is concerned, she did usually have a shot or two before walking out the door of The Plantation, but, who can discredit her for that?</description>
		<content:encoded><![CDATA[<p>Not being anywhere near an expert on the subject, I would assume that the basic difference between sftp and plain ol&#8217; ftp is the overhead that is going into the encryption/decryption.  Normally this overhead doesn&#8217;t bug you, but, at the data quantity you&#8217;re talking about, that overhead adds up quickly. As far as why the interface versions are slower than their command-line counterparts, I&#8217;ll leave that to more knowledgeable folk.</p>
<p>And, as far as my mother is concerned, she did usually have a shot or two before walking out the door of The Plantation, but, who can discredit her for that?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
