Hi all
Rick Jones wrote:
2) use the aforementioned burst TCP_RR test. This is then a single
netperf with data flowing both ways on a single connection so no issue
of skew, but perhaps an issue of being one connection and so one process
on each end.
Since our major gaol is to establish a
Good morning (my TZ),
I'll try to answer all questions, hoewver if I miss something big,
please point my nose to it again.
Rick Jones wrote:
As asked in LKML thread, please post the exact netperf command used to
start the client/server, whether or not you're using irqbalanced (aka
Hi all, slowly crawling through the mails.
Brandeburg, Jesse wrote:
The test was done with various mtu sizes ranging from 1500 to 9000,
with ethernet flow control switched on and off, and using reno and
cubic as a TCP congestion control.
As asked in LKML thread, please post the exact netperf
Brief question I forgot to ask:
Right now we are using the old version 7.3.20-k2. To save some effort
on your end, shall we upgrade this to 7.6.15 or should our version be
good enough?
Thanks
Carsten
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message
Hi Andi,
Andi Kleen wrote:
Another issue with full duplex TCP not mentioned yet is that if TSO is used
the output will be somewhat bursty and might cause problems with the
TCP ACK clock of the other direction because the ACKs would need
to squeeze in between full TSO bursts.
You could try
Hi all,
Brandeburg, Jesse wrote:
I would suggest you try TCP_RR with a command line something like
this: netperf -t TCP_RR -H hostname -C -c -- -b 4 -r 64K
I did that and the results can be found here:
https://n0.aei.uni-hannover.de/wiki/index.php/NetworkTest
seems something went wrong and
