other tests with dragonfly
sepherosa at gmail.com
Sun May 4 00:41:45 PDT 2014
On Sun, May 4, 2014 at 3:26 PM, Wojciech Puchar
<wojtek at wojtek.tensor.gdynia.pl> wrote:
>> For what it's worth, Sepherosa Ziehau has been putting a lot of work into
>> reducing CPU use on high-bandwidth connections:
> if i understand correctly it would reduce CPU usage greatly on highly loaded
> server doing lots of TCP transfers.
There is another commit to reduce port token contention. Recent TCP
connect(2)+kqueue(2) using 8 processes could do ~300Kconns/s; compared
w/ ~275Kconns/s before the port token splitting work. The TCP
connect(2)+kqueue(2) is cpu bound on Dfly now (~0% idle time on all
HTs). Admittedly, I still can't max out 1000M network w/ connect(2)
on my testing hardware (the theoretical TCP connect rate for 1000M
network should be ~335Kconns/s).
However, on the other hand, the TCP accept(2)+kqueue(2) is quite good
w/ SO_REUSEPORT, sink @~335Kconns/s w/ pretty much idle time on each
> looks like core i7 with 4 cores and 8 threads can saturate completely 2
> 10Gbit/s ethernet interfaces with both directions.
> better than FreeBSD, but anyway - it's still over 3 CPU cycles per byte
> transmitted. still very high CPU usage
>> On Sat, May 3, 2014 at 6:54 AM, Wojciech Puchar
>> <wojtek at wojtek.tensor.gdynia.pl> wrote:
>> as my friend advised me, i did flood test - generated lots of random
>> UDP packets with size between 52 and 100 bytes.
>> Actually low end ethernet card in my laptop was a limit (rl), but
>> compared FreeBSD 10 with custom kernel and dragonfly 3.6 with generic kernel
>> (that have diagnostics check
>> compiled by default).
>> dragonfly used about 3 times less CPU.
>> no tests on gigabit or 10 gigabit ethernet and multicore machine for
>> quite good.
>> CPU load on more normal cases (like transfering files using rcp) is
>> lower too, but difference is smaller like 1.5-2 times.
Tomorrow Will Never Die
More information about the Users