I've been trying to get UFTP to successfully send large files for a few
months now and am ready to give up on this tool.
I've tweaked every possible setting and run hundreds of attempts at this
point, but large files always seem to accumulate more and more errors as
they grow. And after multiple passes it seems like the NAKs are really far
behind. I really don't see anything that indicates the receiver is under
pressure. I've rate limited it down. But it seems like this tool really
can't handle files of a few hundred GBs.
Restarts would save the day, but it seems like they are broken in
implementation.
If I'm reading the documentation correctly, you can have either: Restarts or full/multiple destination paths. That's not a rational compromise.
I'd like to be able to restart and tell it where I want my file to go.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just released version 4.9.7 which addresses a timout issue when sending large files. There was a delay in looping through the list of blocks to send which has been fixed.
This fix, in addition to increasing the UDP buffer size and cache size on the client (-B and -c respectively) should address the performance issues you've been having.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've been trying to get UFTP to successfully send large files for a few
months now and am ready to give up on this tool.
I've tweaked every possible setting and run hundreds of attempts at this
point, but large files always seem to accumulate more and more errors as
they grow. And after multiple passes it seems like the NAKs are really far
behind. I really don't see anything that indicates the receiver is under
pressure. I've rate limited it down. But it seems like this tool really
can't handle files of a few hundred GBs.
Restarts would save the day, but it seems like they are broken in
implementation.
If I'm reading the documentation correctly, you can have either: Restarts
or full/multiple destination paths. That's not a rational compromise.
I'd like to be able to restart and tell it where I want my file to go.
I just released version 4.9.7 which addresses a timout issue when sending large files. There was a delay in looping through the list of blocks to send which has been fixed.
This fix, in addition to increasing the UDP buffer size and cache size on the client (-B and -c respectively) should address the performance issues you've been having.