On Thu, 8 Apr 2021 23:01:53 +0200 Viktor Rosendahl <viktor.rosendahl@xxxxxxxxx> wrote: > > Hmm, sounds more like "--various" would be better than "--random". Just > > because it appears you wont to try different timings. Having a --random > > option just doesn't sound like it's what you expect it to be. > > > > I guess that you are right that with --random many people may assume the > sleep time to be random. Perhaps --dizzy-sleep or --arbitrary-sleep > would be better? I think "--various-sleep" may be better. Note, I'm currently doing my income taxes, and when you sell a bunch of stocks that you bought at different times, for the date, you enter "various". Which is why that word is in my head ;-) > > For the latency-collector, I used the name --random because the behavior > is based on the lrand48_r() call, seeded by /dev/urandom. In my thinking > it's the sleeping behavior that is random, not the sleep time. > > I guess that a mathematical purist may say that the behavior is > arbitrary rather than random, because if the value N is different from > two, then there are unequal probabilities between the two choices. > > At first when I developed the latency-collector, I thought that using a > random sleep time would be the right approach but I came to the > conclusion that it is not a good idea. > > If we have the case with a burst of two latencies, where the first one > is 5 ms, , then if we for example sleep randomly between 0 and 500 ms, > we will only have a 1% chance to get the first latency. If we use the > random algorithm from the latency-collector, with N=2, then we have 50% > chance, which is much better. Even if we would have been paranoid to > initialize with N=5, in order to prepare for bursts sizes of up to 5, > then we would still have a 20% chance. > > If we have a random sleep time then we would need to make assumptions on > how long the latencies are and how much time there is between them, and > there is no way to guess that beforehand. > > With the random behavior, we only need to make an assumption about how > many latencies there are going to be in a burst, which is the value N. > This is also impossible to know with certainty but we can make some > educated guess about it. Also, as I already mentioned, if the > latency-collector ever encounters N latencies in a burst, then it will > automatically increment N. > > > There's already a "-s" option that takes a sleep interval between > wakeups, > > which sounds similar to what you have. Perhaps we can make "-1" a special > > value to do the "random" wakeup thing. "0" is already special to make it > > wake up when it detects data in the buffer. > > > > To me "-s -1" feels a bit too cryptic and non-descriptive. Also, I > wonder how many would read the description of the -s option carefully > enough to notice it. It really comes to how well we make our documentation, and I want to create a tutorial for most common operations. When there's good documentation (and a simple and quick tutorial) cryptic solutions like the above can be useful. > > On the other hand, trace-cmd record seems to already use most of the > alphabet as short options. Yeah, it has suffered that :-/ > > Do you think it could be acceptable to add a new long option, such as > --dizzy-sleep? I'm not really sure what you mean by "dizzy-sleep". To me, that means it is unbalanced and not stable. Where as --various-sleep is pretty much exactly what it is. It sleeps for various amounts of time. -- Steve
|