File transfer stuck

[Duncan]

Dotan Cohen posted on Tue, 07 Dec 2010 21:42:10 +0200 as excerpted:

> Often I notice that file transfers between machines get "stuck" when
> transfering with Dolphin. This is nothing new, I've noticed this since
> the KDE 3 days, on many different machines. For instance, at this moment
> I have two large (>1GB each) folders that I am transfering over the LAN
> to another computer. They both were transfering fine, but suddenly one
> has it's speed stuck on 0 KiB/s for quite some time. Both "threads" are
> transfering from the same local computer to the same remote computer on
> the LAN. There are no out-of-disk error or the like.
> 
> What could be the cause of this, and other than stopping and restarting
> the transfer, what can I do? This is Kubuntu 10.10 with KDE 4.6, but
> I've experienced this issue on Fedora as well, and on every version for
> the past few years.

I don't do much LAN work, but on the 'net in general, that's a classic 
sign of abnormal packet drops.

Now /some/ packet drops are normal with TCP as that's what it uses for 
congestion control -- it starts slow and speeds up until it starts losing 
packets (which get retransmitted), then backs off, as it then believes it 
has reached the maximum speed allowed by the link.

But in bad-quality link situations, the packet drops can be so bad and so 
unpredictable that the transfer ends up going slower (oh, dropping 
packets, slow down)... and slower... and slower... until it's basically 
sitting there with an open connection but doing nothing.  Apparently, this 
gets more likely once the dropped packets get so bad that it's dropping 
the acks and retransmit requests as well.  At that point, one side can get 
so confused that it gives up and sends a RST (reset) packet... which if it 
gets lost too...

The bottom line being that at a certain bad connection quality, it's 
basically impossible to complete a transmission of any size.  If you're 
lucky, you can cancel and restart the transmission without erasing the 
partial file (or set of files) transferred so far, and the second (and 
third, and...) will pick up where the previous one left off, more or less.

But a (wired) LAN shouldn't have connection issues that bad, unless 
something's wrong with the equipment or possibly the configuration.  With 
a wireless link I suppose it's somewhat possible (try wired and see if the 
problem disappears), but it shouldn't be with wired.  Assuming you /are/ 
wired, I'd be checking stuff such as the duplex settings, for loose 
connections, etc.  If you're using a switch, full duplex should be fine.  
If you're using a hub and connecting more than two devices, make sure it's 
half-duplex on all of them, because just one device set wrong will 
seriously screw that entire physical subnet!  (That's pretty basic 
networking stuff and hubs aren't so common any more, but who knows?)

At one point I had a NIC going out that I didn't recognize as a local 
issue since the problem /appeared/ to be on the other side of the modem/
router, between me and the ISP (I didn't have a LAN at that time, just the 
single computer connected to the DSL modem/router).  It wasn't just me it 
stumped, either, it stumped the guys at the ISP for awhile as well, as the 
pings, etc, really did seem to show a good local connection and a bad 
remote, but when that NIC was ultimately replaced, the issue disappeared.  
We only found out tho after they'd physically switched me to a new port on 
the DSLAM, and I'd gone as far as a full reinstall (back in the MS days), 
without any luck, because all the traces really /did/ appear to put it on 
the ISP side of the modem.  In that case, the issue was heat related -- 
the NIC had a bad component that worked fine when it was hot, but 
terrible, otherwise.  If I kept the room at 85F/30C plus, it worked just 
fine!  It was just this sort of issues that I'd see as it cooled down!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.