From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Wed, 16 Jun 2010 18:31:17 -0400 To: nemo@lsub.org, 9fans@9fans.net Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: Re: [9fans] Inducing artificial latency Topicbox-Message-UUID: 3478d080-ead6-11e9-9d60-3106f5b1d025 On Wed Jun 16 18:17:45 EDT 2010, nemo@lsub.org wrote: > On programs where I control the client and the server, I simulated > it by spawning a process that did sleep and then do the write. > > That is, you could send many things at once (i.e., same bandwidth) > but you could pretend the thing was delayed. > One tricky point was to be sure that sends were still in order, but that > was a non-issue in my case. > > Perhaps being able to trigger delays on ip for testing/measuring > with a ctl would be a lot better, in the line of what you've done. the ethernet, or shim ethernet, device seems like a better place for this. ip is not the only protocol! that's what loopback(3) does, but without the real network. it would be good to plug loopback or similar into a real ethernet. it's also worth looking at loopback's implementation strategy, which allows for µs delays. sleep is just too course-grained for my testing. dialing up random reordering would seem to me to be a feature at this level. - erik