1 / 76

UML and SPE Part II: The UML Performance Profile

UML and SPE Part II: The UML Performance Profile. Dr. Dorina Petriu Carleton University Department of Systems and Computer Engineering Ottawa, Canada, K1S 5B6 http://www.sce.carleton.ca/faculty/petriu.html. Outline. UML Profile for Schedulability, Performance and Time

arion
Download Presentation

UML and SPE Part II: The UML Performance Profile

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. UML and SPEPart II: The UML Performance Profile Dr. Dorina Petriu Carleton University Department of Systems and Computer Engineering Ottawa, Canada, K1S 5B6 http://www.sce.carleton.ca/faculty/petriu.html WOSP’2004

  2. Outline • UML Profile for Schedulability, Performance and Time • General Resource Model • General Time Modeling • General Concurrency Model • Schedulability Profile • Performance Profile • Applying the Performance Profile • Generation of performance models from UML specs • Validation • Directions for future work WOSP’2004 tutorial

  3. UML Profile for Schedulability, Performance and Time WOSP’2004 tutorial

  4. Standard UML Semantics Profile X Profile Y UML Profiles • A package of related specializations of general UML concepts that capture domain-specific variations and usage patterns • A domain-specific interpretation of UML • Fully conformant with the UML standard • does not extend the UML metamodel • uses only standard extension mechanisms: stereotypes, tagged values, constraints • additional semantic constraints cannot contradict the general UML semantics • within the “semantic envelope” defined by the standard WOSP’2004 tutorial

  5. Guiding Principles for the SPT Profile • Adopted as OMG standard, Version 1 - OMG document formal/03-09-01.pdf http://www.omg.org/docs/formal/03-09-01.pdf • Ability to specify quantitative information directly in UML models • key to quantitative analysis and predictive modeling • Flexibility: • users can model their real-time systems using modeling approaches and styles of their own choosing • open to existing and new analysis techniques • Facilitate the use of analysis methods • eliminate the need for a deep understanding of analysis methods • as much as possible, automate the generation of analysis models and the analysis process itself • Using analysis results for: • predicting system characteristics (detect problems early) • analyze existing system (sizing, capacity planning) WOSP’2004 tutorial

  6. UML Profile Mechanism • The UML profile mechanism provides a way of specializing the concepts defined in the UML standard according to a specific domain model. • a stereotype can be viewed as a subclass of an existing UML concept • a tagged value associated with the stereotype can be viewed as an attribute • The domain model often shows associations between domain concepts, but the UML extension mechanisms do not provide a convenient way for specifying new associations in the metamodel. The following general techniques are used: • some domain associations map directly to existing associations in the metamodel. • some domain composition associations map to tags associated with the stereotype. • in some cases, a domain association is represented by using the <<taggedValue>> relationship provided by the UML profile mechanisms. WOSP’2004 tutorial

  7. UML metaclass Node «PAhost» Stereotype of Node with added semantics: a processing resource with a scheduling policy, processing rate, context switching time, utilization, throughput, etc. «PAhost» MyProcessor Tagged value associatedwith the «PAhost» stereotype {PAschdPolicy= ‘FIFO’} Specializing UML: Stereotypes • Possible to add semantics to any standard UML concept • Must not violate standard UML semantics WOSP’2004 tutorial

  8. Software Domain Schedulability/ Performance Domain General Process for Model Analysis WOSP’2004 tutorial

  9. «profile» RTresourceModeling «profile» «profile» RTconcurrencyModeling RTtimeModeling «import» «import» «import» «profile» «profile» «modelLibrary» SAProfile PAprofile RealTimeCORBAModel «import» «profile» RSAprofile UML SPT Profile Structure General Resource Modeling Framework «import» «import» Analysis Models Infrastructure Models WOSP’2004 tutorial

  10. SPT Profile:General Resource Model WOSP’2004 tutorial

  11. Quality of Service Concepts • Quality of Service (QoS): a specification (usually quantitative) of how well a particular service is (to be) performed • e.g. throughput, capacity, response time, jitter • Resource: an element whose service capacity is limited, directly or indirectly, by the finite capacities of the underlying physical elements • The specification of a resource can include: • offered QoS: the QoS that it provides to its clients • required QoS: the QoS it requires from other components to support its QoS obligations • key analysis question:(requiredQoS  offeredQoS) • why is difficult to answer: the QoS offered by a resource depends not only on the resource capacity itself, but also on the load (i.e., on the competition from other clients for the same resource). WOSP’2004 tutorial

  12. The General Resource Model RealizationModel ResourceUsageModel DynamicUsageModel StaticUsageModel (from ResourceUsageModel) (from ResourceUsageModel) ResourceManagement CausalityModel ResourceTypes CoreResourceModel WOSP’2004 tutorial

  13. +type Instance Descriptor 0..n 0..n 1..n 1..n +instance +type ResourceInstance Resource 0..n 0..n 0..n 0..n 1..n 1..n l +offeredService 1..n 1..n 1..n 1..n +type ResourceServiceInstance ResourceService +instance 0..n 0..n 1 1 0..n 0..n 0..n 0..n / / +offeredQoS 0..n 0..n 0..n 0..n QoSvalue QoScharacteristic +instance +type 0..n 0..n 1 1 0..n 0..n +offeredQoS 0..n 0..n Core Resource Model (Domain Model) • Parallel hierarchy of instances and descriptors. WOSP’2004 tutorial

  14. Basic Resource Usage Model • Resource usage describes how a set of clients uses a set of resources and their instances. • static usage: who uses what • dynamic usage: who uses what and how (order, timing, etc.) EventOccurence (from CausalityModel) AnalysisContext 1 1 0..n 0..n 1 1 1..n 1..n 1..n 1..n 1..n 1..n +usedResources ResourceInstance 0..1 0..1 1 1 ResourceUsage 0..n 0..n 1..n 1..n (from CoreResourceModel) UsageDemand +workload 1..n 1..n +usedServices ResourceServiceInstance 0..n 0..n (from CoreResourceModel) StaticUsage DynamicUsage WOSP’2004 tutorial

  15. StaticUsage Instance (from ResourceUsageModel) (from CoreResourceModel) +usedResources ResourceInstance Client (from CoreResourceModel) 1..n 1..n 1..n 1..n 0..n 0..n 0..n 0..n +requiredQoS 1..n 1..n / QoSvalue +offeredQoS (from CoreResourceModel) 0..n 0..n +instance 0..n 0..n 1 1 +type QoScharacteristic (from CoreResourceModel) Static Usage Model • Static usage: who uses what (order does not matter) WOSP’2004 tutorial

  16. EventOccurence +cause +effect Stimulus 1 1 1..n 1..n StimulusGeneration +receiver Instance 0..n 0..n 0..1 0..1 (from CoreResourceModel) 1 1 +cause 0..n 0..n +effect 1..n 1..n +executionHost +cause 0..n 0..n +methodExecution 1 1 Scenario +cause +effect StimulusReception 1 1 0..n 0..n +effect 0..1 0..1 Basic Causality Loop • Used in modeling dynamic scenarios – it captures the essential of the cause-effect chain in the behaviour of run-time instances. WOSP’2004 tutorial

  17. Dynamic Usage Model • dynamic usage: who uses what and how (order, timing, etc.) DynamicUsage (from ResourceUsageModel) +usedResources ResourceInstance Scenario / 1..n 1..n 1..n 1..n (from CoreResourceModel) (from CausalityModel) 1..n 1..n {ordered} / +step 1..n 1..n 1..n 1..n ActionExecution +successor +usedServices ResourceServiceInstance 0..n (from CoreResourceModel) 1..n 1..n 0..n 0..n +predecessor 0..n 0..n 0..n 0..n 0..n 0..n +requiredQoS +offeredQoS 0..n 0..n ActionExecution: the only modification to the UML metamodel proposed in the profile QoSvalue (from CoreResourceModel) WOSP’2004 tutorial

  18. Proposed Changes to the UML Metamodel • The change is reflected in version UML 1.5. • Addition of a new metamodel element called ActionExecution • Replacement of the association between Action and Stimulus by a semantically similar association between Stimulus and ActionExecution • addition of two new associations between Action and ActionExecution, and ActionExecution and Instance, respectively. WOSP’2004 tutorial

  19. ResourceInstance (from CoreResourceModel) protectionKind activenessKind ProtectedResource UnprotectedResource PassiveResource ActiveResource purposeKind Device Processor CommunicationResource Categories of Resources • Categorization of resources: a given resource instance may belong to more than one type. WOSP’2004 tutorial

  20. ResourceServiceInstance ActionExecution (from CoreResourceModel) (from DynamicUsageModel) 1 1 AccessControlPolicy 0..n 0..n 0..1 0..1 ExclusiveService AcquireService ReleaseService / / isBlocking : Boolean 0..n 0..n 1 1 0..n 0..n 0..n 0..n 1..n 1..n / ProtectedResource / 1 1 Exclusive Use Resources and Actions • To use an exclusive service of a protected resource the following actions must be executed before and after: • acquire service action (according to an access control policy) • release service action WOSP’2004 tutorial

  21. Instance (from CoreResourceModel) ResourceBroker ResourceManager 1 1 0..n 0..n 0..n 0..n 0..n 0..n 1 1 ResourceControlPolicy 1..n 1..n 1..n 1..n 1..n 1..n +managedResource AccessControlPolicy ResourceInstance (from ResourceTypes) (from CoreResourceModel) Resource Management Model • Utility package for modeling resource management services: • resource broker: administers the access control policy • resource manager: creates and keeps track of resources according to a resource control policy. WOSP’2004 tutorial

  22. SPT Profile: General Time Modeling WOSP’2004 tutorial

  23. TimingServices TimedEvents TimeModel TimingMechanisms General Time Model • Concepts for modeling time and time values • Concepts for modeling events in time and time-related stimuli • Concepts for modeling timing mechanisms (clocks, timers) • Concepts for modeling timing services, such as those found in real-time operating systems. WOSP’2004 tutorial

  24. Physical and Measured Time • dense time: corresponds to the continuous model of physical time (represented by real numbers) • discrete time: time broken into quanta (represented by integers) WOSP’2004 tutorial

  25. Timing Mechanisms: Clock and Timer ResourceInstance (from CoreResourceModel) +currentValue 0..n 0..n TimingMechanism TimeValue 1 1 stability (from TimeModel) +origin TimedEvent +maximalValue 0..n 0..n drift (from TimedEvents) 1 1 skew 1 1 set(time : TimeValue) 0..n 0..n get() : TimeValue reset() start() pause() 0..n 0..n 1 1 +resolution TimeInterval (from TimeModel) 1 1 +offset 1 1 +timestamp +accuracy 1..n 1..n 1 1 +referenceClock 0..n 0..n TimeValue +duration Clock Timer (from TimeModel) 0..n 0..n isPeriodic : Boolean 1 1 0..n 0..n 1 1 1 1 0..n 0..n +generatedInterrupts +generatedTimeouts 0..n 0..n ClockInterrupt Timeout (from TimedEvents) (from TimedEvents) WOSP’2004 tutorial

  26. 0..n StimulusGeneration Stimulus +cause +effect (from CausalityModel) (from CausalityModel) 1..n 1 1 1 1 0..n +cause +time +cause 1 1 +start 0..n TimeValue TimedStimulus 1..n (from TimeModel) +end 0..n 0..n / 1..n Timeout / 0..n ClockInterrupt These two associations are derived from the general association between EventOccurrence and Stimulus Timed Stimuli • In UML events are assumed to occur instantaneously. WOSP’2004 tutorial

  27. EventOccurence Scenario (from CausalityModel) (from CausalityModel) TimedAction TimedEvent 0..n 0..n Delay 1..n 1..n +timestamp 1 1 +end +start +duration 1..n 1..n 1..n 1..n TimeValue TimeInterval (from TimeModel) (from TimeModel) Timed Events and Timed Actions • Timed event: has one or more timestamps (according to different clocks) • Timed action: an action that takes a certain time to complete (with known start time, end time and duration) WOSP’2004 tutorial

  28. Caller Operator call ack Notation: Timing Marks and Constraints • A timing mark identifies the time of an event occurrence • On messages: • sendTime() • receiveTime() • On action blocks: • startTime() • endTime() call.receiveTime() callHandler.startTime() callHandler.endTime() ack.sendTime() Timing constraint {call.sendTime() - ack.receiveTime < 10 sec} WOSP’2004 tutorial

  29. P=0.44 P=0.28 P=0.28 0 ms 1 ms 2 ms 3 ms Specifying Time Values • Time values can be represented by a special stereotype of Value («RTtimeValue») in different formats; e.g. • 12:04 (time of day) • 5.3, ‘ms’ (time interval) • 2000/10/27 (date) • Wed (day of week) • $param, ‘ms’ (parameterized value) • ‘poisson’, 5.4, ‘sec’ (time value with a Poisson distribution) • ‘histogram’ 0, 0.28 1, 0.44 2, 0.28, 3, ‘ms’ WOSP’2004 tutorial

  30. Specifying Arrival Patterns • Method for specifying standard arrival pattern values • Bounded: ‘bounded’, <min-interval>, <max-interval> • Bursty: ‘bursty’, <burst-interval> <max.no.events> • Irregular: ‘irregular’, <interarrival-time>, [<interarrival-time>]* • Periodic: ‘periodic’, <period> [, <max-deviation>] • Unbounded: ‘unbounded’, <probability-distribution> • Probability distributions supported: • Bernoulli, Binomial, Exponential, Gamma, Geometric, Histogram, Normal, Poisson, Uniform WOSP’2004 tutorial

  31. General Concurrency Model • Rich enough domain model of concurrently executing and com-municating objects - used in applications, operating systems, etc. WOSP’2004 tutorial

  32. Schedulability Profile WOSP’2004 tutorial

  33. Background • Schedulability analysis: applied to hard real-time systems to find a schedule that will allow the system to meet all its deadlines. • Schedulable entities: granular parts of an application that contend for use of the execution resource that executes the schedule. • Schedule: an assignment of all the schedulable entities in the system on available processors, produced by the scheduler. • Scheduler: implements scheduling algorithms and resource arbitration policies. • Schedulingpolicy: a methodology used to establish the order of schedulable entity (e.g. process, or thread) execution. • E.g., rate monotonic, earliest deadline first, minimum laxity first, maximize accrued utility, and minimum slack time. • Schedulingmechanism: an implementation technique used by a scheduler to make decisions about the order to choose threads for execution. • E.g.,fixed priority schedulers, and earliest deadline schedulers. WOSP’2004 tutorial

  34. Schedulability core domain model WOSP’2004 tutorial

  35. Example: Telemetry System Specification WOSP’2004 tutorial

  36. Real-time Situation Modeled as SD WOSP’2004 tutorial

  37. Result Real-time Situation Modeled as CD «SAAction» «SASituation» {SAPriority=2, SAWorstCase=(93,'ms'), «SATrigger» Result RTduration=(33.5,'ms')} {SASchedulable=$R1, A.1.1:main ( ) RTat=('periodic',100,'ms')} «SAResponse» {SAAbsDeadline=(100,'ms')} A.1:gatherData ( ) «SASchedulable» Sensors TelemetryGatherer TGClock : Clock :SensorInterface :DataGatherer «SAAction» {RTstart=(16.5,'ms'), RTend=(33.5,'ms')} TGClock : Clock A.1.1.1: writeStorage ( ) «SAResource» «SATrigger» {SACapacity=1, {SASchedulable=$R2, SAAccessControl=PriorityInheritance} RTat=('periodic',60,'ms')} «SAResponse» SensorData «SAResponse» {SAPriority=3, {SAAbsDeadline=(60,'ms')} :RawDataStorage SAWorstCase=(177,'ms'), C.1:displayData ( ) RTduration=(46.5,'ms')} B.1.1 : main ( ) «SAAction» «SAAction» {RTstart=(3,'ms'), {RTstart=(10,'ms'), RTend=(5,'ms')} RTend=(31.5,'ms')} C.1.1.1: readStorage ( ) B.1.1.1: readStorage ( ) «SASchedulable» «SASchedulable» TelemetryDisplayer TelemetryProcessor : DataDisplayer :DataProcessor «SATrigger» Result {SASchedulable=$R3, «SAResponse» RTat=('periodic',200,'ms')} Display {SAPriority=1, «SAResponse» :DisplayInterface SAWorstCase=(50.5,'ms'), {SAAbsDeadline=(200,'ms')} RTduration=(12.5,'ms')} B.1:filterData ( ) C.1.1 : main ( ) TGClock : Clock WOSP’2004 tutorial

  38. Performance Profile WOSP’2004 tutorial

  39. Background • Scenariosdefine execution paths whose end points are externally visible. QoS requirements can be placed on scenarios. • Each scenario is executed by a workload: • open workload: requests arriving at in some predetermined pattern • closed workload: a fixed number of active or potential users or jobs • Scenario steps: the elements of scenarios joined with predecessor-successor relationships which may include forks, joins and loops. • a step may be an elementary operation or a whole sub-scenario • Resourcesare used by scenario steps. Quantitative resource demands for each step must be given by performance annotations. Important note: the main reason we build and solve performance models is to compute the additional delays due to the competition for resources by different concurrent users! • Performance results for a system include resource utilizations, waiting times, response times, throughputs. • Performance analysis applied to real-time systems with stochastic characteristics and soft deadlines (use mean value analysis methods). WOSP’2004 tutorial

  40. Performance Domain Model PerformanceContext 0..n 0..n 1 1 1 1 1..n 1..n 1..n 1..n 1..n 1..n +resource Workload PResource PScenario responseTime 0..n 0..n 0..n 0..n utilization 1..n 1..n hostExecutionDemand 1 1 priority schedulingPolicy responseTime throughput 0..n 0..n 1 1 <<deploys>> {ordered} +root +host 0..1 0..1 ClosedWorkload 1..n 1..n OpenWorkload 1 1 population occurrencePattern PStep PProcessingResource PPassiveResource externalDelay probabilty processingRate waitingTime repetition contextSwitchTime responseTime +successor delay priorityRange capacity operations isPreemptible 0..n 0..n accessTime interval executionTime +predecessor 0..n 0..n WOSP’2004 tutorial

  41. Specifying Performance Values • A complex structured string with the following format <performance-value> ::=“(“<kind-of-value> “,“ <modifier> “,“ <time-value>”)” where: <kind-of-value> ::= ‘req’ | ‘assm’ | ‘pred’ | ‘msr’ required, assumed, predicted, measured <modifier> ::= ‘mean’ | ‘sigma’ | ‘kth-mom’ , <Integer> | ‘max’ | ‘percentile’ <Real> | ‘dist’ <time-value>is a time value described by theRTtimeValue type • A single characteristic may combine more than one performance values: <PA-characteristic> ::= <performance-value> [<performance-Value>]* • Example: {PAdemand = (‘pred’, ‘mean’, (20, ‘ms’)) } {PArespTime = (‘req’, mean, (1, ‘sec’)) (‘pred’, mean, $RespT) } predicted - analysis result required WOSP’2004 tutorial

  42. Performance Stereotypes(1) WOSP’2004 tutorial

  43. Performance Stereotypes (2) WOSP’2004 tutorial

  44. Applying the Performance Profile WOSP’2004 tutorial

  45. What is represented in the UML model? • A UML model should represent the following aspects in order to support early performance analysis: : • key use cases described by representative scenarios • frequently executed scenarios with performance constraints • performance requirements for each scenario can be defined by the user • examples: end to end response time, throughput, jitter, etc. • resources used by each scenario • reason why needed: contention for resources has a strong performance impact • resources may be active or passive, physical or logical, hardware or software • examples: processor, disk, process, software server, lock, buffer • quantitative resource demands must be given for each scenario step • how much? • how many times? • workload intensity for each scenario (scenario set) • open workload: arrival rate of requests for the scenario • closed workload: number of simultaneous users executing the scenario WOSP’2004 tutorial

  46. Building Security System: selected Use Cases WOSP’2004 tutorial

  47. <<PAresource>> Buffer {PAcapacity=$Nbuf} Access Controller Access Controller Deployment Diagram <<PAresource>> <<PAresource>> <<PAresource>> <<PAresource>> DoorLock SecurityCard Video Disk Actuator Reader Camera {PAcapacity=2} LAN <<PA resource>> <<PAhost>> <<PAhost>> VideoAcquisition DB_CPU ApplicCPU Database AccessControl AquireProc Buffer Manager StoreProc WOSP’2004 tutorial

  48. <<PAclosedLoad>> { PApopulation = 1 , PAinterval =((‘req’,’percentile’,95, (1, ‘s’)), (‘pred’,’percentile’, 95, $Cycle)) } Requirement o <<PAstep>> {PAdemand=(‘asmd’, ‘mean’, (1.8, ‘ms))} Acquire/Store Video Scenario <<PAcontext>> <<PAresource>> <<PAresource>> <<PAresource>> <<PAresource>> <<PAresource>> BufferManager AcquireProc Video StoreProc Database Controller {PAcapacity= $Bufs} {PAcapacity= 2} <<PAstep>> <<PAstep>> {PAdemand =(‘asmd’, {PArep = $N } ‘mean’, (1.5, ‘ms’)} *[$N] procOneImage(i) getBuffer() o <<GRMacquire>> allocBuf (b) <<PAstep>> {PAdemand=(‘asmd’, o ‘mean’, (0.5, ‘ms’))} Result <<PAstep>> {PAdemand=(‘asmd’, ‘mean’, ($P * 1.5, ‘ms’)), PAextOp = (network, $P)} getImage (i, b) <<PAstep>> {PAdeman d=(‘asmd’, <<PAstep>> ‘mean’, (0.9, ‘ms’))} <<PAstep>> {PAdemand=(‘asmd’, passImage (i, b) {PAdemand=(‘asmd’, ‘mean ’, (1.1, ‘ms’))} ‘mean’, (2, ‘ms’))} storeImage (i, b) store (i, b) <<PAstep>> {PAdemand=(‘asmd’, ‘mean’, ($B * 0.9, ‘ms’)),, PAextOp=(writeBlock, $B)} <<PAstep>> {PAdemand=(‘asmd’, writeImg (i, b) ‘mean’, (0.2,’ms’))} freeBuf (b) <<GRMrelease>> <<PAstep>> releaseBuf (b) {PAdemand=(‘asmd’, ‘mean’, (0.5, ‘ms’))} o WOSP’2004 tutorial

  49. Requirement o Access Control Scenario <<PAopenLoad>> {PAoccurencePattern = (‘poisson’, 30, ‘s’), <<PAcontext>> PArespTime =((‘req’,’percentile’,95, (1, ‘s’)), Result (‘pred’,’percentile’, 95, $UserR))} <<PAresource>> <<PAresource>> <<PAresource>> <<PAresource>> <<PAresource>> <<PAresource>> Alarm Disk CardReader DoorLock Database Access Controller User o <<PAstep>> {PAextOp=(read, 1)} <<PAstep>> <<PAstep>> {PAdemand=(‘asmd’, readCard {PAdemand =(‘asmd’, ‘mean’, (1.8, ‘ms’))} ‘mean’, (1.8, ‘ms’))} admit (cardInfo) getRights() <<PAstep>> {PAdemand=(‘asmd’, ‘mean’, (1.5, ‘ms’)), PAprob = 0.4} readRights() [not_in_cache] readData() o <<PAstep>> {PAdemand=(‘asmd’, ‘mean’, (1.8, ‘ms’))} <<PAstep>> <<PAstep>> {PAdemand=(‘asmd’, {PAdelay=(‘asmd’, ‘mean’, ‘mean’, (0.3, ‘ms’))} (500, ‘ms’)), PAprob = 1} checkRights() [OK] openDoor() enterBuilding <<PAstep>> {PAdemand=(‘asmd’, ‘mean’, <<PAstep>> (0.2, ‘ms’), PAprob=0.2} {PAprob = 0} [need to log?] logEvent() [not OK] alarm() <<PAstep>> {PAdemand=(‘asmd’, ‘mean’, (3, ‘ms’))} writeEvent() <<PAstep>> o writeRec() {PAdemand=(‘asmd’, ‘mean’, (1.8, ‘ms’))} WOSP’2004 tutorial

  50. Acquire/Store Video Scenario: top-level AD <<PAcontext>> VideoController <<PAclosedLoad>> N *[ ] {PApopulation = 1, <<PAstep>> PAinterval= {PArep = $N} procOneImage ((‘req’,’percentile’, 95, (1,’s’)), (‘pred ’,’percentile’, $Cycle))} <<PAstep>> {PAdemand= (‘asmd’, ‘mean’, cycleOverhead (1.8, ‘ms))} composite activity detailed on the next slide WOSP’2004 tutorial

More Related