1. Individual Sampling Process averagevalue(t+timeframe) Averaging interval timeframeQuery: 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 Low passSample value(t) value(t-1/rate) value(t-2/rate) …. bandwidthsample rate timeframeQuery: 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 Low passSample value(time 0 ) value(time -1 ) value(time -2 ) …. bandwidthsample times timeframeQuery: 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 Remos Collector Remos Modeler Network FlowBWSensor RPS Predictor Remos Modeler Application HostLoadSensor RPS Predictor Hosts HostLoadSensor RPS Predictor HostLoadSensor RPS Predictor FlowBWSensor RPS Predictor Remos Modeler RPS Predictor Remos Modeler FlowBWSensor

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

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

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.