fix: sleep for 100ms between benchmarks

[bajtos]

• Check the assumption that there may be a bug in setTimeout implementation when it's called with no timeout value.

• Bring back the console log statement printed after a benchmark is finished but before we schedule the next one. This should give us visibility into the question whether Voyager gets stuck inside the benchmark code or in the main loop logic.

Links:

• https://filecoinproject.slack.com/archives/C03S6LXSRB8/p1712820650418649?thread_ts=1712766423.069179&cid=C03S6LXSRB8

[bajtos]

@juliangruber I don't know the ramifications of introducing a 100ms delay between benchmarks. Will it reduce the number of checks performed by our network too much?

We can choose a smaller delay, but OTOH, I think the timer precision is around 50ms, so using a value smaller than 50ms may not make sense.

[juliangruber]

@juliangruber I don't know the ramifications of introducing a 100ms delay between benchmarks. Will it reduce the number of checks performed by our network too much?

Yes, unfortunately this will negatively affect the amount of tests Voyager schedules.

What about instead we return runSaturnBenchmarkInterval()?

[bajtos]

https://github.com/filecoin-station/spark/blob/e78405179c0e49a2ae56b13c0d035372690a106b/lib/spark.js#L213-L230

@juliangruber I don't know the ramifications of introducing a 100ms delay between benchmarks. Will it reduce the number of checks performed by our network too much?

Yes, unfortunately this will negatively affect the amount of tests Voyager schedules.

Yeah, I was worried that could be the case.

What about instead we return runSaturnBenchmarkInterval()?

That should work.

Is there any particular reason why we cannot run a while(true) loop instead? We are using that in Spark.

https://github.com/filecoin-station/spark/blob/e78405179c0e49a2ae56b13c0d035372690a106b/lib/spark.js#L213-L230

  async run () {
    while (true) {
      const started = Date.now()
      try {
        await this.nextRetrieval()
        this.#activity.onHealthy()
      } catch (err) {
        this.handleRunError(err)
      }
      const duration = Date.now() - started
      const baseDelay = APPROX_ROUND_LENGTH_IN_MS / this.#maxTasksPerNode
      const delay = baseDelay - duration
      if (delay > 0) {
        console.log('Sleeping for %s seconds before starting the next task...', Math.round(delay / 1000))
        await sleep(delay)
      }
    }
  }

[juliangruber]

No particular reason, just that we wanted to keep the module code as close to the original service worker as possible

[juliangruber]

as you suggested, a while (true) would be great

[bajtos]

as you suggested, a while (true) would be great

Opened #6

I also realised that runBenchmark always prints a message at the end, so there is no need to print another message in the main loop (as long as there is no delay between runs).