Measure API clock speed overhead

[EvanKirshenbaum]

Corey presented measurements of the Wombat exerciser tool's "path" task at clock speeds of 1, 10, 25, 50, 100, 300, 400, and 500 ms and noted that it seemed to plateau under 100 ms. Presumably, some of this is due to Python overhead not allowing my software to run any faster, some is due to overhead from the monitor display, and some is due to the OpenDrop hardware and software.

I'd like to characterize how much of it is in my code, so I'm going to write a wombat exerciser task (probably as a subclass of WalkPath) that reports

• the amount of time taken from after the drop appears until after the last move
• the total path length
• whether or not the display was on

This should be written to stdout and also appended to a CSV file.

I'll also need to write a wrapper script that uses os.system() to go through all of the times and display settings, repeating each a number of times. Note that I'll want to start from scratch each time to avoid hysteresis due to garbage collection.

Migrated from internal repository. Originally created by @EvanKirshenbaum on Jul 29, 2021 at 9:23 AM PDT. Closed on Jul 30, 2021 at 12:31 PM PDT.

[EvanKirshenbaum]

This issue was referenced by the following commits before migration:

• 09f37de1cb7cd54b39032977353a3042eabccd8d by @EvanKirshenbaum on Jul 29, 2021 at 11:36 AM PDT
• ec0c366b99e87bec82f7ae98526978f59575e7ca by @EvanKirshenbaum on Jul 30, 2021 at 2:16 PM PDT

[EvanKirshenbaum]

WalkPath now takes command-line arguments to print

• path length
• clock speed
• display status
• total time
• average time

either to the display (--time-motion) or appending to a CSV file (--csv-file).

There's also an wrapper script (tools/time_motion.py) that runs for a set of clock speeds (--speeds) along a given path, for a given number of repetitions (--reps), either both with and without the display (default), only with the display (--only-display) or only without the display (--no-display). The configurations are run in a random order (to reduce hysteresis effects).

In doing this, I discovered that running a task with --no-display didn't actually work. I'm not sure what the actual problem was, but it had to do with attempting to run the task from within the timer thread (i.e., it was spawned by call_after() waiting on the initial delay). I fixed this by having the main thread wait on an Event and triggered the event from the call_after().

Migrated from internal repository. Originally created by @EvanKirshenbaum on Jul 30, 2021 at 12:27 PM PDT.

[EvanKirshenbaum]

To get it on the record, here's what I found when I ran this on a path of length ten:

Migrated from internal repository. Originally created by @EvanKirshenbaum on Jul 30, 2021 at 12:31 PM PDT.