Individual Sampling Process

1. Individual Sampling Process Query: timeframe average value(t+timeframe) Averaging interval Query Result: value(t+timeframe), averaging interval, stats Averaging interval is needed to interpret value timeframe is relative to *client* clock, “t+timeframe” result is relative to *server* clock

2. Periodic Sampling Process Query: timeframe value(t) value(t-1/rate) value(t-2/rate) …. Low pass Sample bandwidth sample rate Query Result: value, bandwidth, sample rate, stats Bandwidth and rate are needed to interpret value Bandwidth ~= “averaging interval” timeframe is relative to *client* clock, “-1” is relative to *server* clock

3. Non-periodic Sampling Process Query: timeframe value(time0) value(time-1) value(time-2) …. Low pass Sample bandwidth sample times Query Result: time-1, value(time-1), bandwidth, stats Bandwidth and rate are needed to interpret value Bandwidth ~= “averaging interval” timeframe is relative to *client* clock, time-1 is time on *server* clock

4. Proposed API Extensions struct SamplingProperties { enum {Individual, PeriodicStream, NonperiodicStream} sample_type; TimeStamp timestamp; double nominal_sample_rate_in_hz double signal_bandwidth_in_hz; }

5. Proposed API Extensions typedef struct{ double max; double min; double expected; // for the expectation value SamplingProperties sampling_properties; /* index of dispersion */ double q1, q3; int confidence; } remos_stat_s;

6. Importance of Time Stamps • Applications: Enables meaningful comparisons of measurements from different sources • Prediction: Enables non-periodic to periodic sampling • Prediction schemes generally assume periodic samples

7. Clock Synchronization • Even for simplest query, two clocks are involved • timeframe is in client time • sampling is in server time • Skewed clocks can result in invalid comparisons • host1_load(t+2) vs host2_load(t+2) assumes that “t” is the same for both samples • Avoid adding clock synch now, but include it in the API, and warn users they might want to use ntp or other tool

8. Proposed API Extensions struct TimeStamp { enum { RemosGlobalTime, // possible future Remos clocksync ModelerLocalTime, // modeler library supplied timestamp CollectorLocalTime,// collector supplied timestamp } timestamptype; double time_in_seconds_since_epoch; // precision of clock double precision_in_seconds; // only valid for RemosGlobalTime double skew_in_seconds; }

9. Current Integration of Predictors Application Remos Modeler RPS Predictor RPS Predictor RPS Predictor RPS Predictor RPS Predictor RPS Predictor FlowBWSensor HostLoadSensor FlowBWSensor HostLoadSensor FlowBWSensor HostLoadSensor Hosts Remos Modeler Remos Modeler Remos Modeler Remos Collector Network

10. Partial “Value Add” Approach Application Remos Modeler RPS Predictor RPS Predictor RPS Predictor RPS Predictor RPS Predictor RPS Predictor FlowBWSensor HostLoadSensor FlowBWSensor HostLoadSensor FlowBWSensor HostLoadSensor Hosts Remos Modeler Remos Modeler Remos Modeler Remos Collector Network

11. A Full “Value Add” Approach Application Remos Modeler RPS Predictor RPS Predictor RPS Predictor RPS Predictor RPS Predictor RPS Predictor FlowBWSensor HostLoadSensor FlowBWSensor HostLoadSensor FlowBWSensor HostLoadSensor Remos Modeler Remos Modeler Remos Modeler Remos Modeler Remos Modeler Remos Modeler Remos Collector RawHostLoadSensor RawHostLoadSensor RawHostLoadSensor

12. Prediction Requirements • Continuous measurement stream or history • lower latency with measurement stream • potentially lower overhead with history • Periodic samples or nonperiodic samples with timestamps • Configuration management • Startup/shutdown, etc.