- context-switch stress test?
- computation / loop with easily verifiable results
- register coverage
- use subroutine, recursion (to a limit)
- trigger frequent timer interrupt
- randomized timeout
- interrupt handler (kernel): perform similar computation
- clobber as much state as possible

- test with and without optimization

- area of Mechanics (and thus Physics)
- studies "motion of objects without reference to the forces which cause the motion."

- distance / time
- automatic measurement, as discussed earlier in class

- measurement error: start & end times uniformly distributed
- use average and std-dev?
- but velocity is non-linear in time!
- estimate velocity distribution with statistical methods?

- use min and max?
- use experiment mean/variance to estimate distribution min/max
- compute estimated min/max velocity
- compute estimated mean as midpoint: (min + max) / 2
- keep it simple!

- objective?
- hit exact location → use average
- no overshoot/undershoot → use max/min bounds

- use average and std-dev?
- real-world variations (wear and tear): difficult to model
- repeated or continuous recalibration
- data import/export - better than terminal copy-and-paste?

- using an average to characterize or estimate latencies is often not a good idea
- latency utility curves usually have an S-shape
- when using an average, outliers can offset many values close to the mean
- however, outliers do
**not**increase or decrease aggregate utility significantly! - how
*often*a train enters a critical section of the track without permission matters more than how*much*it overshoots

- model trains emulate real-world trains
- we model the model trains...
- most likely: time-dependent acceleration
- approximate as constant acceleration!

- measure similar to velocity
- measure time between two sensors
- change speed level at first sensor
- compute acceleration based on known estimates for velocities
- first detect whether train has reached target velocity at 2nd sensor?
- constant acceleration → average velocity during acceleration =
(v
_{1}+ v_{2}) / 2

- manual experiment
- send stop command when sensor is triggered
- manually measure stop distance

- compute using acceleration model
- experiment by trying to stop right after sensor
- use search algorithm to find right time: could be automated
- stop time + velocity → compute stop distance?
- search algorithm (e.g., binary search) might be brittle and need many experiments

- based on known estimate for stop time/distance
- stop at known location, then start
- measure time to sensor
- can compute acceleration
- similar caveat as acceleration measurement: did train reach target velocity?

- stop before reaching target velocity
- manual experiments with different (short) times between start and stop

- how many speed levels to investigate?
- pairs of levels for acceleration/deceleration

- determine minimum speed (per segment?) to avoid getting stuck
- stop from lower speed is more accurate
- how much data can you feasibly collect?
- document and justify decisions!