Subject: RE: epoll_wait() performance

From: David Laight <[email-masked]>
Date: Thu, 28 Nov 2019 16:37:01 +0000

From: Jesper Dangaard Brouer
> Sent: 28 November 2019 11:12
...
> > Can you test recv() as well?
> 
> Sure: https://github.com/netoptimizer/network-testing/commit/9e3c8b86a2d662
> 
> $ sudo taskset -c 1 ./udp_sink --port 9  --count $((10**6*2))
>           	run      count   	ns/pkt	pps		cycles	payload
> recvMmsg/32  	run:  0	 2000000	653.29	1530704.29	2351	18	 demux:1
> recvmsg   	run:  0	 2000000	631.01	1584760.06	2271	18	 demux:1
> read      	run:  0	 2000000	582.24	1717518.16	2096	18	 demux:1
> recvfrom  	run:  0	 2000000	547.26	1827269.12	1970	18	 demux:1
> recv      	run:  0	 2000000	547.37	1826930.39	1970	18	 demux:1
> 
> > I think it might be faster than read().
> 
> Slightly, but same speed as recvfrom.

I notice that you recvfrom() code doesn't request the source address.
So is probably identical to recv().

My test system tends to increase its clock rate when busy.
(The fans speed up immediately, the cpu has a passive heatsink and all the
case fans are connected (via buffers) to the motherboard 'cpu fan' header.)
I could probably work out how to lock the frequency, but for some tests I run:
$ while :; do :; done
Putting 1 cpu into a userspace infinite loop make them all run flat out
(until thermally throttled).

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)