CS 452/652 Fall 2019 - Lecture 19
October 23, 2019
- 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."
- 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!
- hit exact location → use average
- no overshoot/undershoot → use max/min bounds
- real-world variations (wear and tear): difficult to model
- repeated or continuous recalibration
- data import/export - better than terminal copy-and-paste?
Aside: Average Latency?
- 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 =
(v1 + v2) / 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
Experiments and Data
- 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!