From: Bei Guan <gbtju85@gmail.com>
To: xen-devel <Xen-devel@lists.xen.org>
Subject: The data transfer speed between two VMs -- a comparison between Xen libvchan and SCP?
Date: Sun, 23 Mar 2014 00:28:46 +0800 [thread overview]
Message-ID: <CAEQjb-TCAsNN3_-1qwSd6AyETb4XDGnxifRKTsRGz91UEWsjyw@mail.gmail.com> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 2609 bytes --]
Hi All,
I try to make a comparison between the Xen libvchan and SCP with respect to
the data transfer speed between two co-located VMs. The following is what I
have done.
1. I modify the code tools/libvchan/node.c to transfer a file between two PV
DomUs. I set the buffer size to 2048, which is the data size writing into
the shared ring every time. (Please refer to the line 78 in node.c)
2. I use the command "time" to get the rough time of transferring a file
between two PV DomUs under the SCP and Xen libvchan. The size of the file
to transfer is 50M, 100M, 500M. The test result is posted behind.
However, I find that the data transferred time does decrease much under the
Xen libvchan when compared to the SCP. I also set the buffer size to 4096,
5000, 10000, and so on. The Xen libvchan doesn't show a better performance.
It doesn't perform "around 30-40% faster than TCP for 4KB request sizes".
(Like the paper[1] said.)
Is there any wrong with my test? How to show the advantage of the Xen
libvchan? Or say the advantage of the shared memory mechanism between Xen
PV DomUs?
[1] "The case for reconfigurable I/O channels"
http://www.freebsdlabs.com/~robert/papers/201203-resolve-reconfigurable-io.pdf
===========
The test result:
The time to transfer a file under the Xen libvchan. (BufferSize is 2048)
The files testdata_50m, testdata_100m, testdata_500m are files with size of
50M, 100M and 500M, respectively.
# time ./node testdata_50m
*real 0m2.795s*
user 0m0.243s
sys 0m0.784s
# time ./node testdata_100m
*real 0m5.707s*
user 0m0.196s
sys 0m1.943s
# time ./node testdata_500m
*real 0m28.680s*
user 0m2.057s
sys 0m8.601s
The time to transfer a file under the SCP.
# time scp testdata_50m root@192.168.160.226:/root/tmp
testdata_50m 100% 50MB 25.0MB/s 00:02
*real 0m2.326s*
user 0m1.485s
sys 0m0.409s
# time scp testdata_100m root@192.168.160.226:/root/tmp
testdata_100m 100% 100MB 20.0MB/s 00:05
*real 0m4.271s*
user 0m2.815s
sys 0m0.811s
# time scp testdata_500m root@192.168.160.226:/root/tmp
testdata_500m 100% 500MB 20.8MB/s 00:24
*real 0m24.641s*
user 0m15.354s
sys 0m4.246s
>From the time above, we can see that the time to transfer a file under Xen
libvchan is larger than that under the SCP. Why it happened? Doesn't the
Xen libvchan show a better performance?
Thank you for your time. I appreciate your any suggestions.
--
Best Regards,
Bei Guan
[-- Attachment #1.2: Type: text/html, Size: 6387 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next reply other threads:[~2014-03-22 16:28 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-22 16:28 Bei Guan [this message]
2014-03-24 12:25 ` The data transfer speed between two VMs -- a comparison between Xen libvchan and SCP? George Dunlap
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAEQjb-TCAsNN3_-1qwSd6AyETb4XDGnxifRKTsRGz91UEWsjyw@mail.gmail.com \
--to=gbtju85@gmail.com \
--cc=Xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).