dcapwell commented on code in PR #28:
URL: https://github.com/apache/cassandra-accord/pull/28#discussion_r1089568046
##########
accord-core/src/test/java/accord/impl/basic/DelayedExecutorService.java:
##########
@@ -0,0 +1,80 @@
+package accord.impl.basic;
+
+import org.apache.cassandra.concurrent.FutureTask;
+
+import java.util.Collections;
+import java.util.List;
+import java.util.Random;
+import java.util.concurrent.AbstractExecutorService;
+import java.util.concurrent.Callable;
+import java.util.concurrent.Executors;
+import java.util.concurrent.TimeUnit;
+
+public class DelayedExecutorService extends AbstractExecutorService
+{
+ private static final int THREAD_SCHEDULING_OVERHEAD_MILLIS = 5;
+
+ private final PendingQueue pending;
+ private final Random random;
+
+ public DelayedExecutorService(PendingQueue pending, Random random)
+ {
+ this.pending = pending;
+ this.random = random;
+ }
+
+ @Override
+ protected <T> Task<T> newTaskFor(Runnable runnable, T value) {
+ return newTaskFor(Executors.callable(runnable, value));
+ }
+
+ @Override
+ protected <T> Task<T> newTaskFor(Callable<T> callable) {
+ return new Task<>(callable);
+ }
+
+ private Task<?> newTaskFor(Runnable command) {
+ return command instanceof Task ? (Task<?>) command :
newTaskFor(command, null);
+ }
+
+ @Override
+ public void execute(Runnable command) {
+ Task<?> task = newTaskFor(command);
+ int jitterMillis = THREAD_SCHEDULING_OVERHEAD_MILLIS +
random.nextInt(1000);
Review Comment:
What I see is `org.apache.cassandra.simulator.Action#schedule` which adds
the following jitter
```
@Override
public long schedulerDelayNanos()
{
return (scheduler.delayChance.get(random) ? scheduler.longDelayNanos
: scheduler.delayNanos).select(random);
}
```
with these config values
```
// long delay chance
schedulerDelayChance = new ChanceRange(randomSource ->
randomSource.qlog2uniformFloat(4), 0.01f, 0.1f),
schedulerDelayNanos = new LongRange(0, 50, MICROSECONDS, NANOSECONDS),
schedulerLongDelayNanos = new LongRange(50, 5000, MICROSECONDS, NANOSECONDS),
KindOfSequence kind = UNIFORM or UNIFORM_STEP or RANDOMWALK
```
So what I see is we randomly select the probability for the run between 1%
and 10% and use that as a constant as the input into the `Decision` to select
if we use "large" or not.
Large is 50 micro to 5ms.
I can def add similar logic to BurnTest, I didn't see an existing bias
select function so went lazy with uniform; would be good to so the "large"
range is rare.
Now, about the numbers I went with, these were pulled from a prod cluster
for a different application where CFS avg 5ms to start a thread that had its
condition met and max of 1s... these numbers were thread starting, but we are
not, so the overhead really is just how long it takes for the thread to see the
state... So... lets test that!
On M1 Mac this is what I saw (in micro)
```
Summary of 10000000 Samples
Min: 6
Median: 4102
Avg: 4241
Max: 25729
Counts in Millis
0 910225 9.10%
1 982552 9.83%
2 977544 9.78%
3 1850840 18.51%
4 2811417 28.11%
5 1179405 11.79%
6 369632 3.70%
7 252550 2.53%
8 183516 1.84%
9 154046 1.54%
10 66330 0.66%
11 43829 0.44%
12 41320 0.41%
13 23590 0.24%
14 16804 0.17%
15 7367 0.07%
16 10912 0.11%
17 14986 0.15%
18 20019 0.20%
19 11307 0.11%
20 10720 0.11%
21 14148 0.14%
22 11867 0.12%
23 11820 0.12%
24 12201 0.12%
25 11053 0.11%
```
So yeah, I can work on similar logic, but I might tweak the ranges
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
