PS. Thanks for writing flent and making it available. I'm a novice w/flent but do plan to learn it. Bob On Fri, Oct 13, 2017 at 11:47 AM, Bob McMahon wrote: > Hi Toke, > > The other thing that will cause the server thread(s) and listener thread > to stop is -t when applied to the *server*, i.e. iperf -s -u -t 10 will > cause a 10 second timeout for the server/listener thread(s) life. Some > people don't want the Listener to stop so when -D (daemon) is applied, the > -t will only terminate server trafffic threads. Many people asked for > this because they wanted a way to time bound these threads, specifically > over the life of many tests. > > Yeah, summing is a bit of a mess. I've some proto code I've been playing > with but still not sure what is going to be released. > > For UDP, the source port must be unique per the quintuple (ip proto/src > ip/ src port/ dst ip/ dst port). Since the UDP server is merely waiting > for packets it doesn't have an knowledge about how to group. So it groups > based upon time, i.e. when a new traffic shows up it's put an existing > active group for summing. > > I'm not sure a good way to fix this. I think the client would have to > modify the payload, and per a -P tell the server the udp src ports that > belong in the same group. Then the server could assign groups based upon a > key in the payload. > > Thoughts and comments welcome, > Bob > > On Fri, Oct 13, 2017 at 2:28 AM, Toke Høiland-Jørgensen > wrote: > >> Bob McMahon writes: >> >> > Thanks Toke. Let me look into this. Is there packet loss during your >> > tests? Can you share the output of the client and server per the error >> > scenario? >> >> Yeah, there's definitely packet loss. >> >> > With iperf 2 there is no TCP test exchange rather UDP test information >> > is derived from packets in flight. The server determines a UDP test is >> > finished by detecting a negative sequence number in the payload. In >> > theory, this should separate UDP tests. The server detects a new UDP >> > stream is by receiving a packet from a new source socket. If the >> > packet carrying the negative sequence number is lost then summing >> > across "tests" would be expected (even though not desired) per the >> > current design and implementation. We intentionally left this as is as >> > we didn't want to change the startup behavior nor require the network >> > support TCP connections in order to run a UDP test. >> >> Ah, so basically, if the last packet from the client is dropped, the >> server is not going to notice that the test ended and just keep >> counting? That would definitely explain the behaviour I'm seeing. >> >> So if another test starts from a different source port, the server is >> still going to count the same totals? That seems kinda odd :) >> >> > Since we know UDP is unreliable, we do control both client and server >> over >> > ssh pipes, and perform summing in flight per the interval reporting. >> > Operating system signals are used to kill the server. The iperf sum >> and >> > final reports are ignored. Unfortunately, I can't publish this package >> > with iperf 2 for both technical and licensing reasons. There is some >> skeleton >> > code in Python 3.5 with asyncio >> > >> that >> > may be of use. A next step here is to add support for pandas >> > , and possibly some control chart >> > techniques (both single >> and >> > multivariate >> > ) for >> both >> > regressions and outlier detection. >> >> No worries, I already have the setup scripts to handle restarting the >> server, and I parse the output with Flent. Just wanted to point out this >> behaviour as it was giving me some very odd results before I started >> systematically restarting the server... >> >> -Toke >> > >