can I rsync on UDP?
Jagadeesh
I have task of downloading files sized little over 1GB using rsync. It
is taking lot of time because of my lousy network speed. Just to test
I want to try rsync over UDP if possible, I am sure someone should
have done this trial, Can you share ideas about how to do it.
Thanks
Benjamin Rampe
> I have task of downloading files sized little over 1GB using rsync. It
> is taking lot of time because of my lousy network speed. Just to test
> I want to try rsync over UDP if possible, I am sure someone should
> have done this trial, Can you share ideas about how to do it.
Most important question: why do you have lousy network speed? Or what do
you consider to be "lousy speed"?
There are protocols that you want to use over TCP because you can use
jumbo frames (e.g. NFS). Albeit TCPs overhead for small packets has to
be considered, overall it allows for much more throughput when you (are
able to) use the right parameters. Simplified: file size over 1GB
screams for TCP.
I could be wrong. But I think you got hooked up at the wrong side of the
problem.
Regards,
Benjamin
P.S. do you really have to use rsync? Only access via a rsync server?
There are cases were rsync really s*cks!
Joe Pfeiffer
Of course, 1GB files will take a long time with pretty darn good
network speed (I for one would regard 5Mbit/sec as pretty good. 1GB
at 5Mb/sec = 2000 seconds = half an hour). Why do you suspect network
speed that would be improved by using UDP? Slow is slow, after
all... FWIW, if there's a UDP-based protocol that rsync can use, I
don't know of it.
Unruh
>Jagadeesh <mnjag...@gmail.com> writes:
Well, I would say that it depends on the connection. If he has Gb network
between the machines, rsync over ssh should give about 30MB/s. with the
encryption probably being the bottleneck.
If it is over 100Mb link, 10MB/s is achievable.
If it is a long distance transfer then an hour would not be out of place.
Why he thinks UDP will change his "lousy network speed" I have no idea.
Joe Pfeiffer
All good points -- I was starting from the assumption that when he
said "lousy network speed" he was on something slower than LAN speeds,
and pointing out that pretty good long distance transfer will still be
taking quite a while.
> Why he thinks UDP will change his "lousy network speed" I have no idea.
I was wondering that too.
Allen Kistler
> Joe Pfeiffer <pfei...@cs.nmsu.edu> writes:
>
>> Jagadeesh <mnjag...@gmail.com> writes:
>
>>> its a lame question, but let me ask you Gurus,
>>>
>>> I have task of downloading files sized little over 1GB using rsync. It
>>> is taking lot of time because of my lousy network speed. Just to test
>>> I want to try rsync over UDP if possible, I am sure someone should
>>> have done this trial, Can you share ideas about how to do it.
>
>> Of course, 1GB files will take a long time with pretty darn good
>> network speed (I for one would regard 5Mbit/sec as pretty good. 1GB
>> at 5Mb/sec = 2000 seconds = half an hour). Why do you suspect network
>> speed that would be improved by using UDP? Slow is slow, after
>> all... FWIW, if there's a UDP-based protocol that rsync can use, I
>> don't know of it.
>
> Well, I would say that it depends on the connection. If he has Gb network
> between the machines, rsync over ssh should give about 30MB/s. with the
> encryption probably being the bottleneck.
FWIW, I've found that rsync over ssh over a 1 Gbit link has a bottleneck
at the platter, not the cpu. Of course, that's with
electrically-connected drives (SAS, SATA).
It would be interesting to do the same experiment with a good
fiber-attached SAN (I'm thinking HP StorageWorks, e.g.), but I can only
dream about what *that* answer might be, since I haven't got the
hardware to actually do the experiment.
Unruh
>Unruh wrote:
>> Joe Pfeiffer <pfei...@cs.nmsu.edu> writes:
>>
>>> Jagadeesh <mnjag...@gmail.com> writes:
>>
>>>> its a lame question, but let me ask you Gurus,
>>>>
>>>> I have task of downloading files sized little over 1GB using rsync. It
>>>> is taking lot of time because of my lousy network speed. Just to test
>>>> I want to try rsync over UDP if possible, I am sure someone should
>>>> have done this trial, Can you share ideas about how to do it.
>>
>>> Of course, 1GB files will take a long time with pretty darn good
>>> network speed (I for one would regard 5Mbit/sec as pretty good. 1GB
>>> at 5Mb/sec = 2000 seconds = half an hour). Why do you suspect network
>>> speed that would be improved by using UDP? Slow is slow, after
>>> all... FWIW, if there's a UDP-based protocol that rsync can use, I
>>> don't know of it.
>>
>> Well, I would say that it depends on the connection. If he has Gb network
>> between the machines, rsync over ssh should give about 30MB/s. with the
>> encryption probably being the bottleneck.
>FWIW, I've found that rsync over ssh over a 1 Gbit link has a bottleneck
>at the platter, not the cpu. Of course, that's with
>electrically-connected drives (SAS, SATA).
It depends on the computer. I ran tests with a SATA drive on a 2GH machine
and Gb ethernet, and it was ssh that was the bottleneck. With a faster
machine
it is possible that disk access would be the bottleneck. ( If I ran rsync
straight-- ie rsync->rsync daemon which does not go through ssh) I got
about 50-80% higher throughput.
Maxwell Lol
> I have task of downloading files sized little over 1GB using rsync. It
> is taking lot of time because of my lousy network speed. Just to test
> I want to try rsync over UDP if possible, I am sure someone should
> have done this trial, Can you share ideas about how to do it.
So you prefer a faster unreliable backup over a slower reliable one?
Excuse me, but that sounds crazy.
AZ Nomad
rsync has error checking. It works perfectly over unreliable networks.
Maxwell Lol
*ALL* networks are unreliable. That's why TCP was developed - to
provide reliable transfer of data over a network.
If rsync works over UDP, what is the command option? I don't see one.
Rsync runs over rsh/ssh, which uses TCP.
If there is a remote shell that is reliable and uses UDP as a
transport, that could be specified. But I don't know of any.
So please explain how rsync works over UDP......
Rick Jones
> *ALL* networks are unreliable. That's why TCP was developed - to
> provide reliable transfer of data over a network.
Might it be more accurate to say that all IP networks are unreliable?
rick jones
--
The glass is neither half-empty nor half-full. The glass has a leak.
The real question is "Can it be patched?"
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
AZ Nomad
>AZ Nomad <azno...@PremoveOBthisOX.COM> writes:
>> On Wed, 22 Oct 2008 07:43:08 -0400, Maxwell Lol <nos...@com.invalid> wrote:
>>>Jagadeesh <mnjag...@gmail.com> writes:
>>
>>>> I have task of downloading files sized little over 1GB using rsync. It
>>>> is taking lot of time because of my lousy network speed. Just to test
>>>> I want to try rsync over UDP if possible, I am sure someone should
>>>> have done this trial, Can you share ideas about how to do it.
>>
>>>So you prefer a faster unreliable backup over a slower reliable one?
>> rsync has error checking. It works perfectly over unreliable networks.
>*ALL* networks are unreliable. That's why TCP was developed - to
>provide reliable transfer of data over a network.
rsync has it's own error checking protocol
Unruh
>AZ Nomad <azno...@PremoveOBthisOX.COM> writes:
rsync has two modes-- one is over ssh (or rsh.) in that mode the local
rsync makes an ssh connection to the remote machine and starts up a version
of rsync on that remote machine to connect the two together.
In the other mode, when the local rsync contacts the remote machines on
port 873, the remote (x)inted starts up a version of rsync and intiates the
transfer. That can be either tcp or udp.(Not sure how it decides which to
use). That mode is NOT encrypted ( as rsync over ssh is) and can be about
50% faster depending on your CPU , network,...
It means that the remote machine MUST set up rsync to run as an (x)inetd
daemon. In the first case all that is needed is that the user be able to
log on with ssh, and run rsync. In the second the remote sysadmin must set
up rsync to run as a daemon. This is obviously somewhat more risky since it
potentially opens up the system to remote attacks. That can be mitigated
with hosts.allow and /etc/rsync.conf
Maxwell Lol
> Maxwell Lol <nos...@com.invalid> wrote:
>> *ALL* networks are unreliable. That's why TCP was developed - to
>> provide reliable transfer of data over a network.
>
> Might it be more accurate to say that all IP networks are unreliable?
Sure. Also XNS, DECNET, SMB/NETBIOS and many others.
I'm not sure if you are implying that other networks are reliable.
But I suppose you can have a network of two machines in a bomb
shelter, with a UPS that can be powered by a aux. generator. But that
could be an IP network. So some IP networks could be 99.99999999%
reliable.
Maxwell Lol
>>*ALL* networks are unreliable. That's why TCP was developed - to
>>provide reliable transfer of data over a network.
>
> rsync has it's own error checking protocol
It will have a hard time syncing two directories if it can't transfer
any files reliably. How many times will it try to transfer a file
before it gives up?
I suppose IF you had a UDP-based shell, and IF you let it run long
enough, and IF rsync never stopped trying, eventually it would be able
to transfer a few GB's reliably. Eventually.
But I would bet that it would take a lot longer than a TCP-based shell.
If someone has a RSH equiv that uses UDP, it's easy enough to try.
I don't know of any, however....
Maxwell Lol
> rsync has two modes-- one is over ssh (or rsh.) in that mode the local
> rsync makes an ssh connection to the remote machine and starts up a version
> of rsync on that remote machine to connect the two together.
> In the other mode, when the local rsync contacts the remote machines on
> port 873, the remote (x)inted starts up a version of rsync and intiates the
> transfer. That can be either tcp or udp.(Not sure how it decides which to
> use). That mode is NOT encrypted ( as rsync over ssh is) and can be about
> 50% faster depending on your CPU , network,...
Thanks. This is new to me. But I didn't see anything about rsync
using UDP in the man page. And does it use it to initiate a TCP
connection? Or is EVERYTHING done with UDP?
And are you use the speedup is due to UDP, or is the speedup duee to
using RSH versus SSH (no encyprion vs. encryption)
>
> It means that the remote machine MUST set up rsync to run as an (x)inetd
> daemon. In the first case all that is needed is that the user be able to
> log on with ssh, and run rsync. In the second the remote sysadmin must set
> up rsync to run as a daemon. This is obviously somewhat more risky since it
> potentially opens up the system to remote attacks. That can be mitigated
> with hosts.allow and /etc/rsync.conf
I still don't see any config option that says to use UDP versus TCP.
I'm not on a system where I can monitor a rsync session, but I still doubt
file transfers can be done using UDP. They could be INITIATED using UDP.
I suppose you can change/etc/initd.conf so it reads
rsync stream udp nowait root /usr/bin/rsync rsyncd --daemon
and try it out. Try it both ways and see if there is any difference.
If UDP is not supported, it ought to generate an error.
Anyone willling to try?
Unruh
>Unruh <unruh...@physics.ubc.ca> writes:
>> rsync has two modes-- one is over ssh (or rsh.) in that mode the local
>> rsync makes an ssh connection to the remote machine and starts up a version
>> of rsync on that remote machine to connect the two together.
>> In the other mode, when the local rsync contacts the remote machines on
>> port 873, the remote (x)inted starts up a version of rsync and intiates the
>> transfer. That can be either tcp or udp.(Not sure how it decides which to
>> use). That mode is NOT encrypted ( as rsync over ssh is) and can be about
>> 50% faster depending on your CPU , network,...
>Thanks. This is new to me. But I didn't see anything about rsync
>using UDP in the man page. And does it use it to initiate a TCP
>connection? Or is EVERYTHING done with UDP?
No idea. All I know is that port 873 is defined as rsync for both TCP and
UDP. I have no idea if and how it uses it.
>And are you use the speedup is due to UDP, or is the speedup duee to
>using RSH versus SSH (no encyprion vs. encryption)
It does not use rsh in the daemon mode. It connects directly to the daemon
running on the other machine.
>>
>> It means that the remote machine MUST set up rsync to run as an (x)inetd
>> daemon. In the first case all that is needed is that the user be able to
>> log on with ssh, and run rsync. In the second the remote sysadmin must set
>> up rsync to run as a daemon. This is obviously somewhat more risky since it
>> potentially opens up the system to remote attacks. That can be mitigated
>> with hosts.allow and /etc/rsync.conf
>I still don't see any config option that says to use UDP versus TCP.
>I'm not on a system where I can monitor a rsync session, but I still doubt
>file transfers can be done using UDP. They could be INITIATED using UDP.
>I suppose you can change/etc/initd.conf so it reads
> rsync stream udp nowait root /usr/bin/rsync rsyncd --daemon
Most modern systems use xinetd, and there is an rsync file in
/etc/xinetd.d/ which you have to enable (disable=no)
Chris Davies
> If rsync works over UDP, what is the command option? I don't see one.
You could try something like this, I suppose:
RSYNC_RSH='ssh -f %h nc -u -l 60873; nc -u %h 60873'
rsync -avHP local/files remotehost:/remote/path
Chris
Chris Davies
> No idea. All I know is that port 873 is defined as rsync for both TCP and
> UDP. I have no idea if and how it uses it.
That's an IANA issue. When someone registers a port it's assigned for
both UDP and TCP. Many protocols use only one mechanism.
Chris
Chris Davies
> *ALL* networks are unreliable [...]
Rick Jones <rick....@hp.com> wrote:
> Might it be more accurate to say that all IP networks are unreliable?
Consider two computers linked by {whatever}. I can't see a situation where
you couldn't (theoretically) break the linkage described by {whatever}
by some means.
Chris
Maxwell Lol
> Maxwell Lol <nos...@com.invalid> writes:
>
>>Unruh <unruh...@physics.ubc.ca> writes:
>
>>> rsync has two modes-- one is over ssh (or rsh.) in that mode the local
>>> rsync makes an ssh connection to the remote machine and starts up a version
>>> of rsync on that remote machine to connect the two together.
>>> In the other mode, when the local rsync contacts the remote machines on
>>> port 873, the remote (x)inted starts up a version of rsync and intiates the
>>> transfer. That can be either tcp or udp.(Not sure how it decides which to
>>> use). That mode is NOT encrypted ( as rsync over ssh is) and can be about
>>> 50% faster depending on your CPU , network,...
>
>>Thanks. This is new to me. But I didn't see anything about rsync
>>using UDP in the man page. And does it use it to initiate a TCP
>>connection? Or is EVERYTHING done with UDP?
>
> No idea. All I know is that port 873 is defined as rsync for both TCP and
> UDP. I have no idea if and how it uses it.
I looked into it a bit more.
I only saw this reference to UDP/DGRAM in rsync 3.0.4:
lib/addrinfo.h:#ifndef NI_DGRAM
lib/addrinfo.h:#define NI_DGRAM 16
lib/getaddrinfo.c: (flags & NI_DGRAM) ? "udp" : "tcp");
This is just some utility code copied from another program.
In other words, I see no way that UDP can be used.
>>And are you use the speedup is due to UDP, or is the speedup duee to
>>using RSH versus SSH (no encyprion vs. encryption)
>
> It does not use rsh in the daemon mode. It connects directly to the daemon
> running on the other machine.
I will have to set this up and test it.
Jagadeesh
> Unruh <unruh-s...@physics.ubc.ca> writes:
> > Joe Pfeiffer <pfeif...@cs.nmsu.edu> writes:
Well. I was talking about slow wan
But good helpful replies.
Thanks
Joe Pfeiffer
>
> No idea. All I know is that port 873 is defined as rsync for both TCP and
> UDP. I have no idea if and how it uses it.
Near as I can tell from reading rsync's man page, it doesn't. It only
actually uses tcp.
Unruh
That of course tells me absolutely no more than did "lousy network speeds".
And I still do not know why UDP would make a difference.
Rick Jones
> Rick Jones <rick....@hp.com> writes:
> > Maxwell Lol <nos...@com.invalid> wrote:
> >> *ALL* networks are unreliable. That's why TCP was developed - to
> >> provide reliable transfer of data over a network.
> >
> > Might it be more accurate to say that all IP networks are unreliable?
> Sure. Also XNS, DECNET, SMB/NETBIOS and many others.
> I'm not sure if you are implying that other networks are reliable.
I cannot recall the specifics, but IIRC X.25 has some degree of
"reliability" along the lines of retransmission and whatnot.
rick jones
--
oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates
Rick Jones
Sure, the question is whether or not there is a network-layer (ish)
protocol that provides reliability a la TCP or what not - ie one with
retransmissions and flow control etc, such that a ULP (Upper Layer
Protocol) sitting on top of it might presume reliability the way an
application using TCP does.
One can "break" a TCP connection but we still refer to TCP as a
"reliable" protocol - even though the only "guarantee" that TCP makes
is that it will tell you that it was _probably_ unable to get some of
your data to the remote destination.
Jagadeesh
I can get high speed connection. That's my limitation.
But all your replies saved my time that I would have spent on R&D
without getting much success.
Thank you again.
Jagadeesh
Unruh
>Thank you very much all for you time and helping me.
>I can get high speed connection. That's my limitation.
I think something went wrong witht he last two sentences.
What doe you define as "high speed".
Maxwell Lol
>>> rsync makes an ssh connection to the remote machine and starts up a version
>>> of rsync on that remote machine to connect the two together.
>>> In the other mode, when the local rsync contacts the remote machines on
>>> port 873, the remote (x)inted starts up a version of rsync and intiates the
>>> transfer. That can be either tcp or udp.(Not sure how it decides which to
>>> use).
I have confirmed that UDP is NEVER used.
As as extra validation, the manual page says
>There are two different ways for rsync to contact a remote system:
>using a remote-shell program as the transport (such as ssh or rsh) or
>contacting an rsync daemon directly via TCP.
>>>That mode is NOT encrypted ( as rsync over ssh is) and can be about
>>> 50% faster depending on your CPU , network,...
I suspect it's because encryption isn't used.
Maxwell Lol
Since nc sends a one-way stream, I don't see how anything can be
negotiated between the two systems. Which is the point of
rsync......
Nevertheless, I tried
RSYNC_RSH='ssh -f 192.168.1.50 nc -u -l -p 60873; nc -u 192.168.1.50 -p 60873'
export RSYNC_RSH
and was not able to get it to work.
>
> Chris
Maxwell Lol
> Thank you very much all for you time and helping me.
> I can get high speed connection. That's my limitation.
Assuming you mean you cannot get a high speed connection,
there may be other problems.
Encryption does slow things down. Do you want security or speed?
Is rsync being done over a wide area network? There are ways to tune this.
Do you have to use rsync? (instead of compressing a tar file).
Chris Davies
> You could try something like this, I suppose:
> RSYNC_RSH='ssh -f %h nc -u -l 60873; nc -u %h 60873'
Maxwell Lol <nos...@com.invalid> wrote:
> Since nc sends a one-way stream, I don't see how anything can be
> negotiated between the two systems. Which is the point of
> rsync......
thishost$ nc -u otherhost 60873
otherhost$ nc -u -l -p 60873
The two terminal sessions in which I ran these command can now send
packets between each other. Bidirectionally. (Granted, I missed a
"-p". Or perhaps there are different versions of nc. I can't remember.)
> RSYNC_RSH='ssh -f 192.168.1.50 nc -u -l -p 60873; nc -u 192.168.1.50 -p 60873'
> and was not able to get it to work.
It probably needs some more work, and since it was an illustration of
futility (rsync over udp? bletch!) I hope you don't mind if I don't
spend any more time on it.
Chris
Unruh
>Jagadeesh <mnjag...@gmail.com> writes:
He refuses to tell us anything about his system. "Doctor I am sick". "What
appears to be the problem" "Doctor I am sick, do you thing a lobotomy would
help?"
Michael Zawrotny
> Allen Kistler <acki...@oohay.moc> writes:
>
> >Unruh wrote:
> >> Joe Pfeiffer <pfei...@cs.nmsu.edu> writes:
>
> >FWIW, I've found that rsync over ssh over a 1 Gbit link has a bottleneck
> >at the platter, not the cpu. Of course, that's with
> >electrically-connected drives (SAS, SATA).
>
> It depends on the computer. I ran tests with a SATA drive on a 2GH machine
> and Gb ethernet, and it was ssh that was the bottleneck. With a faster
> machine
> it is possible that disk access would be the bottleneck. ( If I ran rsync
> straight-- ie rsync->rsync daemon which does not go through ssh) I got
> about 50-80% higher throughput.
As another data point, when I've compared sending a large file (e.g.
knoppix iso image) via rsync/ssh and netcat, netcat usually took half
as long. That was done on pata/sata attached drives in my office on
either 100M or gig ethernet.
Mike
--
Michael Zawrotny
Institute of Molecular Biophysics
Florida State University | email: zawr...@sb.fsu.edu
Tallahassee, FL 32306-4380 | phone: (850) 644-0069