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

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

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

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

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;

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

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

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; }

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

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

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

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.