Closed gperciva closed 1 year ago
Please retest with linux on a t3 instance; t2 is Xen-based and may have performance anomalies if Linux uses page-flipping.
It would also be good to check FreeBSD 13.2 (not 12.4) and on a comparable EC2 instance. I'm guessing FreeBSD isn't really 2x faster than Linux.
Interesting results! t3.small, 5 warmup runs, N=101 recorded data
sudo yum install clang
)Two visualizations of the same data:
My take-aways:
pipe()
has the variability, while socket()
doesn't. That's the opposite of my bare-metal 12.4 system (intel core i3-71000U).setsockopt()
stuff makes no difference, so there's no point committing it.I didn't play any games with cpu pinning or sysctl kern.timecounter.alloweddeviation
or the like.
I think that the pipe()
vs. socketpair()
test is interesting enough to be worth adding to git master (as part of standalone-enc
).
This is for investigating the variability in the existing
standalone_pipe_socketpair_one.c
test, which usesproto_pipe()
. I took that test, replace theproto_pipe
with aread(); write();
loop, and then made the communication endpoints either pipes, socketpairs, or socketpairs with the same socket options that are used inproto_conn.c
.Here's two visualizations of the same benchmarks, with N=31. Freebsd is 12.4 on bare metal; Linux is aws linux on a t2.
setsockopt()
variant seems to be the same as the plain socketpairs, so I don't think it's worth including that as a separate test. (Unless I'm missing something some options thatproto_conn.c
used?)I didn't play games with cpu pinning, because pipes vs. sockets seemed to be an interesting enough comparison as it is.
So my proposal is to omit the
setsockopt()
test, and and only merge the first two commits in this PR.