ave outstanding
before it does a read? And does it take care to build-up to that number
of writes to avoid batching during slowstart, even with TCP_NODELAY set?
rick jones
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozla
On 07/16/2012 12:06 PM, Thadeu Lima de Souza Cascardo wrote:
On Mon, Jul 16, 2012 at 10:27:57AM -0700, Rick Jones wrote:
What is the effect on packet-per-second performance? (eg aggregate,
burst-mode netperf TCP_RR with TCP_NODELAY set or perhaps UDP_RR)
I used uperf with TCP_NODELAY and 16
Anton Vorontsov wrote:
On Tue, Jul 07, 2009 at 11:47:38AM -0700, Rick Jones wrote:
Admittedly, all the world is not TCP, but a big chunk is, so are you
likely to have reference counts go to zero on the tx queue for
anything other than small standalone TCP ACK segments?
That's a ge
o are you likely to
have reference counts go to zero on the tx queue for anything other than small
standalone TCP ACK segments?
rick jones
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
y to act as a receiver, you
might give that a try - it would be interesting to see the effect of
their ACK avoidance heuristics on TCP throughput. One non-trivial
difference I keep forgetting to mention is that TCP will have that
returning ACK stream that UDP will not.
rick jones
__
Anton Vorontsov wrote:
Hi all,
Down here few question regarding networking throughput, I would
appreciate any thoughts or ideas.
On the MPC8315E-RDB board (CPU at 400MHz, CSB at 133 MHz) I'm observing
relatively low TCP throughput using gianfar driver...
What is the "target" of the test - is
ny number of other
benchmarks. The "send a request, wait for reply, send next request, etc etc
etc" is a rather common application behaviour afterall.
rick jones
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
