Michael S. Tsirkin wrote: > On Tue, Jan 18, 2011 at 11:41:22AM -0800, Rick Jones wrote: > >>PS - the enhanced latency statistics from -j are only available in >>the "omni" version of the TCP_RR test. To get that add a >>--enable-omni to the ./configure - and in this case both netperf and >>netserver have to be recompiled. > > Is this TCP only? I would love to get latency data from UDP as well. I believe it will work with UDP request response as well. The omni test code strives to be protocol agnostic. (I'm sure there are bugs of course, there always are.) There is though the added complication of there being no specific matching of requests to responses. The code as written takes advantage of TCP's in-order semantics and recovery from packet loss. In a "plain" UDP_RR test, with one at a time transactions, if either the request or response are lost, data flow effectively stops there until the timer expires. So, one has "reasonable" RTT numbers from before that point. In a burst UDP RR test, the code doesn't know which request/response was lost and so the matching being done to get RTTs will be off by each lost datagram. And if something were re-ordered the timstamps would be off even without a datagram loss event. To "fix" that would require netperf do something it has not yet done in 18-odd years :) That is actually echo something back from the netserver on the RR test - either an id, or a timestamp. That means "dirtying" the buffers which means still more cache misses, from places other than the actual stack. Not beyond the realm of the possible, but it would be a bit of departure for "normal" operation (*) and could enforce a minimum request/response size beyond the present single byte (ok, perhaps only two or four bytes :). But that, perhaps, is a discussion best left to netperf-talk at netperf.org. happy benchmarking, rick jones (*) netperf does have the concept of reading from and/or dirtying buffers, put-in back in the days of COW/page-remapping in HP-UX 9.0, but that was mainly to force COW and/or show the effect of the required data cache purges/flushes. As such it was made conditional on DIRTY being defined. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
