I guess that is a limitation on the part of the MS TCP stack. Even in NT
4.0?
> with large delays or a WAN link, so I need something like 150K windows.
> I opted for multiple sessions for my measurements. This turned out to be
> useful enough for my purposes. Adding the throughput #'s give you a good
> idea of what's what.
Just make sure you have reasonably close start and stop times with the
independent streams. This is an area that relies heavily on the due
dilligence of the person running the benchmark since there is no
explicit synchronization in netperf2. You need to give yourself decent
run times, and make sure the skew in start and stop is minimized.
I generally sit there watching the output manually.
One technique that others have used is to have three netperf tests in a
row from each driving system/window. In shell talk that would be
$ netperf; netperf; netperf
they then only take the results from the middle of each threesome - the
idea is that one is sure that the middle of each threesome has all
concurrent streams going in parallel, regardless of startup/shutdown
skew. Of course, if the system is completely thrashed, that might not
hold.
rick jones
-- these opinions are mine, all mine; HP might not want them anyway... :) feel free to email, or post, but please do not do both... my email address is raj in the cup.hp.com domain...