I have set up a test environment for URBACKUP 1.4.7 with a windows 7 laptop
client connected via a netgear fs108 switch to a desktop opensuse 13.2.
A folder which contains the iso of opensuse with 4.3 GB is
the test data to be backed up.
On full file backup the client indicates that the task would
take 21 hours. The transmission was about 560Kbit/s.
I fired up a windows system on the same hardware as the
linux and found that Windows moves the file to another pc in 6 minutes 40
seconds.
Paragon does it in 12 minutes.
I took a tcpdump of the urbackup process and found that I
was getting several checksum errors. In
the 1.25 minute sample there were 17 checksum error packets. In four of these cases the server had to send
the complaint to the client twice. In
these cases the wait was in total 1.097 seconds, meaning that the delay was
caused by the client.
I increased the priority of the client in the Windows Task
Manager to “High”. This had no effect.
It seems as though the client was doing something else at
this time, but what is beyond me. I can
imagine that it took a long time to get the data back into storage that it had
already sent. Perhaps keeping old data
in buffers for a bit might be the way.
Sorry, I need to update that. The sample was for 1.25 seconds, not minutes, so that the delay of 1.09 seconds during the 4 particular checksum error packets was quite considerable.
Also to note: the linux system hosted the server and the windows 7 laptop hosted the client.
If those are TCP resends, this is an operating system/driver issue. UrBackup just uses the operating system API. Could be that it fills buffers faster than the other software, but that should not cause checksum errors.
Internet research leads to the following analysis:
The delay on the Windows 7 side is due to the implementation
of delayed ACK and Nagle’s Algorithm as re-defined
in RFC1122. This implementation is not
uniform leading to the following mess:
Client (Nagle’s Algorithm) won’t send remaining data until
an ACK is received
Server won’t send an ACK until a response arrives (Delayed
ACK )
TCP does not release the response to the application until ACKs
are in
Wait for Time-out (in Windows 7 this is 200ms or 1 fifth of
a second) .
When this happens four times a second, the transfer is
slowed down by a factor of at least five.
Hopeful Ideas:
a. Turn off Nagle’s algorithm. Used to be possible by altering the
registry. In Windows7 this no longer
works.
b. On the Client Software specify: TCP_NODELAY
c. Use UDP instead of TCP (probably the best
solution as TCP was not designed with data streaming in mind)
Is there any chance of the Developing Team doing either b or c?