Pete Heist writes: > The `-n` and `-timeouts` parameters have been added to the client, and are documented in the usage. Quick examples: > > ``` > tron:~/src/github.com/peteheist/irtt:% ./irtt client -timeouts 250ms,500ms,1s,2s -n 127.0.0.2 > [Connecting] connecting to 127.0.0.2 > Error: no reply from server > tron:~/src/github.com/peteheist/irtt:% echo $? > 1 > tron:~/src/github.com/peteheist/irtt:% ./irtt client -timeouts 250ms,500ms,1s,2s -n 127.0.0.1 > [Connecting] connecting to 127.0.0.1 > [Connected] connected to 127.0.0.1:2112 > [NoTest] skipping test at user request > tron:~/src/github.com/peteheist/irtt:% echo $? > 0 > ``` Awesome! > I don't know how aggressive you want to go on open packet timeouts, > but I set a minimum at 200ms so users won't be as tempted to abuse > public servers. Default Linux TCP syn timeout looks to be hardcoded at > 3s,6s,12s, etc. I think our default of 1s,2s,4s,8s is fine in this day > and age. In flent, I think 250ms,500ms,1s,2s would be one way of being > pretty sure whether a server is running or not in a reasonable amount > of time (3.75s), but I don't know what actual the time constraints > are. I don't want to spend more than one second probing, so 250ms,500ms will have to do. > I took a quick look at the irtt runner in flent. Looks good, my only > comment is that `-fill rand` and `-fillall` aren't necessary because > there's no payload (whose length would be specified with `-l`). Seeing > that though made me add a micro-optimization to not call Read with an > empty slice on the Filler when there's no payload requested. So if you > want to leave those params in anticipation of using `-l` later, it's > probably fine. Yeah, was mirroring what I'm doing with netperf. Haven't thought about adding knobs yet, but setting the lengths seems useful. > That makes me think, any reason we can't use irtt for the voip tests? > There could be tests simulating some different codecs with different > intervals and payload lengths, if we wanted: That would be awesome! D-ITG is awful to setup, so having a replacement for that would be good :) -Toke -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/tohojo/flent/issues/106#issuecomment-345266203