[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4F05F969.7090608@hp.com>
Date: Thu, 05 Jan 2012 11:26:33 -0800
From: Rick Jones <rick.jones2@...com>
To: Eric Dumazet <eric.dumazet@...il.com>
CC: Jean-Michel Hautbois <jhautbois@...il.com>, netdev@...r.kernel.org
Subject: Re: TCP communication for raw image transmission
On 01/05/2012 10:53 AM, Eric Dumazet wrote:
> Le jeudi 05 janvier 2012 à 10:41 -0800, Rick Jones a écrit :
>
>> Why? A netperf UDP_STREAM test is "purely" unidirectional (*). I
>> suspect the numbers look funny thanks to the 32-bit compilation bugs
>> (format statement issues).
>
> Unidirectional, but the receiver must send some status notifications ?
>
> My reasonning (before you explained the compat problem between sender
> and receiver) was that since we flooded the link, we were blocking
> output from receiver (because of collisions), and
Well, the flow goes something like
*) netperf establishes control connection
*) netserver accepts and forks
*) netperf sends initial test request and configuration
*) netserver sends final test setup information
*) netserver starts timer (with padding)
*) netperf starts timer
*) netperf's timer expires, netperf stops sending, starts waiting for
results from netserver (in a select with a one or two minute timeout)
*) netserver's timer expires, sends its part of the test results
*) netperf comes out of select and receives netservers information
*) netperf displays results
If the netserver's results were blocked by some massive backlog of data
in queues somewhere, the results will either simply be delayed, or
netperf's select() will timeout and errors will be reported. It would
not result in netperf reporting results without netserver's input.
happy benchmarking,
rick jones
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists