On Using Tracer Driver for External Dynamic Process Observation

Pierre Deransart Rewerse-WP I3 1

Pierre DeransartJanuary 29, 2007REWERSE WP I3 meetingDresden

LoriaRocquencourt

Sophia Antipolis

Rhône-Alpes

Futurs

Les unités de recherche

CONTEXT, HISTORY

From DiSCiPl to OADymPPaC

•DiSCiPl (1997-2000): enhance constraint debugging: resulted in prototypes, but still ad-hoc tools for correctness and performance analysis

•OADymPPaC (2001-2004) main challenges• Interoperability of tools: make analysis tool development easier --> "standardisation"

of the CP platforms and tools parameterisation

• Scaling: increase the size of the problems which can be analysed this way (hundreds of variables or constraints) ----> enable using specialized HMI

Resulted in powerful analyzers (prototypes and products), but still prototype tools for performance analysis

Also still an approach limited to finite domains constraint solving

OADymPPaC Realizations

GENERICITY and INTEROPERABILITY PRINCIPLES

NEW PROBLEMS

OADymPPaC raised unsolved questions:

•Trace Semantics (related to its genericity): what is the exact nature of the “Observational Semantics”

•Modeling of the Interactions between Observed Process and Analysis Tools

•How to keep the whole system efficient (need to evaluate efficiency)

•Is the approach generic itself? Can it be applied to new domains (not just constraints) in particular in software engineering

Ways to ANSWER to the PROBLEMS

•Trace Semantics (related to its genericity): what is the exact nature of the “Observational Semantics”: model of trace for a family of processes

•Modeling of the Interactions between Observed Process and Analysis Tools: Introduction of Tracer Driver and Analyzer Manager

•How to keep the whole system efficient (need to evaluate efficiency): Concepts of Virtual full Trace, Actual incremental Trace extraction and rebuilding

•Is the approach generic itself? Can it be applied to new domains (not just constraints) in particular in software engineering can the approach (full trace with partial OS, interactive tracer driver) be applied in new domains

RELATIONSHIPS with REWERSE (attempt)

•Genericity of traces and trace querying

•Semantics (web) mining and observational semantics: looking for combination of traces and models “explaining” the traces

•Software Composition vs Trace Composition

•Relations action vs event: actions produce (trace) event

HISTORY

•Ducassé, Opium: versatile analyzers

•Ducassé, Noyer, 1994, JLP: independence of tracer and analyzers

•Langevine & Ducassé & Deransart, 2003, ICLP’03: Codeine, First Driven Tracer approach implementation for GNU-prolog

•Deransart & all, 2004, OADymPaC project: client/server architecture, trace standardization (XML) for interoperability

•Langevine & Deransart & Ducassé, 2004, LNAI 3010: model of « generic trace » for constraint programming

•Langevine & Ducassé, 2005, AADEBUG, WLPE: Driven Tracer for FD constraints and experimentation

•Now, 2006: « theory » of generic trace and driven tracer =

virtual full trace, actual incremental trace and observational semantics

OBJECTS OF STUDIES

•Traces

•Interactions and Tracer Driver

•Observational Semantics of traces

TRACESTRACES

« Leave traces, not proofs, only traces give dreams »

René Char

Poète

(1907-1988)

« Laisser des traces, pas des preuves, seules les traces peuvent faire rêver »

René CharPoète(1907-1988)

SOME MOTIVATIONS

Dynamic Program Analysis: typical recent works are based on trace analysis

•Ernst & al. 2001: “Dynamically discovering likely program invariants…” from data computed by dynamic execution

•Denmat & al. 2005 “Data mining and Cross-checking of Execution Traces…” from a collection of traces

•Zaidman & al. 2005 “Applying Webmining Techniques to Execution Traces…”

WHY TRACES ?Any phenomenon, any open system leaves traces

•Walking (persistent foot traces)•Sedimentation (temporally accumulated traces), fossils•Particles (light): objects only known by their physical or chemical properties•Programs (outputs, observation)•Communication (messages)•Discourse abstract•Human Memory…(persistent and reactive)

Traces are everywhere: we only know processes by their traces

OBSERVING PROCESSESEverybody watches everyones…..

Everybody receives from everyone

Everybody sends messages to …

We know and define complex objects from the traces they leave

We know complex programs behaviour by analyzing their traces

Causal analysis is not tractable likely causality

TRACE modeling is the right approach

BUT, what IS a TRACE ???

HOW to ANALYSE IT ???

I want to leave these questions open

….small demo

What IS a TRACE ???

the answer is:Any possible understandable information related to an observed phenomenon

•Any observing device will find in the trace what it needs

•If a process needs instrumentation to produce a trace, this need only to be made once

•Analysis tools may be developed independently

- it is not possible to broadcast such a huge information flow (communication slowing down)

-then the observed process always computes a huge amount of unused data (construction slowing down)

SPECIFIC ASPECTS

Needs for trace standardization

•All levels of granularity accepted

•Different kinds of information included (levels of abstraction)

•Each analyzer must be able to recognize its relevant information

•Use of XML to define possible standards

SEEMS an UNREALISTIC GOAL !!!

the answer is:Driven Tracer

•selects in the trace what the observer needs

•keeps tracer listening to the analyzers (dialog between server and clients)

•Leave the tracer to distribute and broadcast each specific trace

•Allow workload repartition between tracer and analysers

VIRTUAL FULL TRACE (VFT definition)

unbounded sequence of trace events of the form

et: (t, at, St+1) •et: unique identifier of the event •t: chrono. Time of the trace•at: kind of event, an identifier characterizing the kind of actions from which the process changed from St to St+1

•St = p1,t..., pn,t : values of parameters at chrono t. St is the full current state

ACTUAL TRACEunbounded sequence of actual events of the form e’t: (t, at, At)

such that, there exists a function f, such that for each event e’t = f( et, St).

At denotes a set of attribute values. The actual trace is the trace emitted by a tracer, which can actually be “visible”.

The virtual full trace is a particular case of actual trace where f is the identity, i.e.the attributes of At are the kind of event at and the parameter values St+1.

Different kinds of attributes

•f(p) = p, ex “CPU time”

•f(p) = (p), current parameter abstraction, ex “depth of the proof tree”

•attrt = f( pt+1, St), incremental attribute, ex “values removed from the domain of a variable”

P: parameter(s)

INCREMENTAL TRACE(full actual)

An actual trace is incremental if the attributes describe only the changes affecting the current state, i.e. for every t

et = F (e’t,subpart(St))

F is the “Observational Semantics” (OS)

It verifies also: (if all attributes incremental)

St+1 = F(At,St)

OBSERVATIONAL SEMANTICSTrace:

et: (t, at, St+1)

There exists a function f, such that for each event

e’t = (t, at, At) = f( et, St)

This is trace extraction : At = f( St, St+1)

The “Observational Semantics” (OS) is a kind of partial “explanation”):

St+1 = F(At,St) (full actual, otherwise )

(F used for rebuilding)

EXAMPLE (actual trace)

1 1 Call: '$call$'(bench(2)) 2 2 Call: bench(2) 3 3 Call: 2>0 3 3 Exit: 2>0 4 3 Call: _182 is 2-1 4 3 Exit: 1 is 2-1 5 3 Call: bench(1) ....

Gentra4CP format<post chrono="8" depth="1" cident="c2" />

<new-variable chrono="10" depth="1" vident="v3" vinternal="_#47" vname="V3">

</vardomain>

</new-variable>

<new-constraint chrono="11" depth="1" cident="c3" cinternal="fd_domain(v3,1,4)" orig="user">

<state>

</constraint>

</state>

</new-constraint>

<new-variable chrono="14" depth="1" vident="v4" vinternal="_#69" vname="V4">

</new-variable>

01 17 16:53:37 kok ker: Additional sense indicates Medium not present01 17 16:53:37 kok ker: sdb : block size assumed to be 512 bytes, disk size 1GB. 01 17 16:53:37 kok ker: /dev/scsi/host1/bus0/target0/lun0: I/O error: dev 08:10, sector 001 17 16:53:37 kok ker: I/O error: dev 08:10, sector 001 17 16:53:37 kok ker: unable to read partition table01 17 16:53:37 kok ker: usb.c: registered new driver usbdevfs01 17 16:53:37 kok ker: usb.c: registered new driver hub01 17 16:53:37 kok ker: usb-uhci.c: $Revision: 1.275 $ time 09:50:48 Aug 17 200501 17 16:53:37 kok ker: usb-uhci.c: High bandwidth mode enabled01 17 16:53:37 kok ker: usb-uhci.c: USB UHCI at I/O 0x2440, IRQ 1901 17 16:53:37 kok ker: usb-uhci.c: Detected 2 ports01 17 16:53:37 kok ker: usb.c: new USB bus registered, assigned bus number 101 17 16:53:37 kok ker: hub.c: USB hub found01 17 16:53:37 kok ker: hub.c: 2 ports detected01 17 16:53:37 kok ker: usb-uhci.c: USB UHCI at I/O 0x2460, IRQ 2301 17 16:53:37 kok ker: usb-uhci.c: Detected 2 ports01 17 16:53:37 kok ker: usb.c: new USB bus registered, assigned bus number 201 17 16:53:37 kok ker: hub.c: USB hub found01 17 16:53:37 kok ker: hub.c: 2 ports detected01 17 16:53:37 kok ker: usb-uhci.c: v1.275:USB Universal Host Controller Interface driver

Messages Linux File

Actual Trace Requirements

•The actual trace may likely be the full virtual trace (attributes are the parameters)

•It may be discontinuous, then the full current state shall be available at any time on

demand

•It should likely incorporate complex objects built from the VFT

•It should cover large application domains and many observation methods

•It should have a clear semantics (OS): the OS allows to rebuild original states from the

trace (assuming that the full current state is known at some moment from which the

trace is continuous)

INTERACTIONINTERACTIONS and S and

TRACER TRACER DRIVERDRIVER

ObservedProcess

Virtual Full Trace ActualFull Trace

Classical Approach (general broadcasting)

Tracer

Filter/Builder

ObservingProcess

ObservingProcessObserved

Process

Virtual Full Trace

TracerFilter/

BuilderActualFull Trace

Classical Approach (general broadcasting)

Driven Tracer Approach (requested trace only)

Virtual Full Trace

Process

TracerBuilder

RequestedV. Trace

ActualRequested

DriverFilter/

Manager

Workload Analysis

• Program (without connections with tracer) T_prog

• Tracer (parameters and attributes computation) T_core + T_extract

• Driver (dialog and attributes selection) T_cond

• Broadcasting (all traces encoding) T_encode-and-com

====================================================

• Trace decoding T_decode

• Trace filtering T_ filter

• Trace rebuilding T_rebuild

• Analyzer execution T_ana

Workload AnalysisProcess

---------------

T_prog + T_core1

Tracer/Driver-----------------------------------------------| |

T_core2 + T_cond + T_extract + T_encode-and-com

=========================================================

Analyzer/Builder/Manager------------------------------------------

T_decode + T_filter + T_rebuild + T_ana

Workload balanceProcess and Tracer---------------

T_prog + T_core

Analyzer---------

| |T_ana

Manager---------

| |T_filter

Driver---------

| |T_cond

Tracer---------

| |T_extract

Builder---------

| |T_rebuild

Tracer----------------- | |T_ encode-and-com

Manager---------| |T_decode

==================================================

Workload Evaluation: processesProcess and Tracer---------------

T_prog + T_core

Analyzer---------

| |T_ana

==============

•A (sophisticated) analyzer may be extremely slow

•With large virtual full traces T_core may become important but is thus balanced by T_ana (example: explanations in Gnu-Prolog and graph visualization)

•It is also possible to extend the full trace with complex objects built on demand (genericity of the VFT is not affected, only T_extract)

Workload Evaluation: Driver/ManagerManager---------

| |T_filter

Driver---------

| |T_cond

========

• This is the key point of the Driver approach: the manager filters a large broadcasted full actual trace or alternatively the driver filters the trace events (and selects few events wrt the full trace) before the actual trace is extracted.

• This makes the approach efficient because the selection consists of 2 steps:1. on the kind of events (assumes a finite relatively small number

of kind of events)2. other criteria may be considered during extraction step, but

applied on relatively few events

Workload Evaluation: extraction/rebuildingTracer

--------- | |T_extract

Builder---------

| |T_rebuild

=========

•Attributes extraction with complex criteria may be relatively slow, but only relatively few events are subject to this operation

•State reconstruction by the Builder may be slower (the virtual state may not be explicitly constructed by the process when it may be in the Builder).

•The Builder must also prepare the data for the analyzer (ex: build table models for visualization tool)

Workload Evaluation: encode/comm/decodeTracer

----------------- | |T_ encode-and-com

=========

•The actual trace may be encoded with different methods in order to optimize the broadcasted data flow: compression, binary conversion … etc. But the implies an equivalent work from the Manager.

•This is not specific to this approach. It just shows that verbose XML may be used. There are proposals to compress XML (e.g. http://www.w3.org/TR/wbxml)

Evaluation of workload balance (Ad-hoc Approach)

Process and Tracer---------------

T_prog + T_core

Analyzer---------

| |T_ana

Manager---------

| |T_filter

Driver---------

| |T_cond

Tracer---------

| |T_extract

Builder---------

| |T_rebuild

Tracer----------------- | |T_ encode-et-com

=============================================

Evaluation of workload balance (Tracer Driver Approach)

Process and Tracer---------------

T_prog + T_core

Analyzer---------

| |T_ana

Manager---------

| |T_filter

Driver---------

| |T_cond

Tracer---------

| |T_extract

Builder---------

| |T_rebuild

Tracer----------------- | |T_ encode-et-com

==================================================

Summary•Ad-hoc Approach

• The full actual trace is treated, resulting in excessive tracer extraction, coding and communication times.

• The full actual trace must be decoded and filtered by the Manager.• This imposes to reduce the size of the trace at the source, restricting

reusability of the trace by different tools.

•Tracer Driver Approach• There is no limit of the trace size (except extra computation costs due to

core computations preparing extraction of a huge virtual trace). The tracer may be designed for a large collection of potential uses.

• Additionally to the tracer a driver must be implemented. But the additional driving time can be low and extraction, coding and communication times may be very reduced (provided that, even if several analyzers are active, only a small part of the virtual full trace is used).

DRIVER/MANAGER REQUIREMENTSDriver (server)

•Analyze trace queries

•Store and manage requested trace patterns

•Manage the dialog between server (tracer) and clients (analyzers)

•Tell the tracer what to extract and to broadcast

Manager (client)

•Select the trace events for its analyzer (verify trace adequacy)

•Elaborate and send queries

•Manage the dialog between server (tracer) and clients (analyzers)

Language of Interactions

Basic instructions between driver (server) and mediator (client). A persistent set of conditions, compiled as a finite automaton, serves for the current trace event selection.

•Manager commands (sent to the driver)• current (in sync mode): request to send particular attributes• resume (start async mode)• update (sync or async mode): modifies the event selection conditions• interrupt (emergency signal to stop – may be issued by any external

process): pipe is broken and some trace events may be lost.

•Driver commands (sent to the manager in trace events)• breakpoint (start sync mode): tracer is waiting for commands• provide (in sync mode): level of the actual trace• complement (in sync mode): additional info or current state as requested by

current

OBSERVATIOOBSERVATIONALNAL

SEMANTICSSEMANTICS

OBSERVATIONAL SEMANTICSTrace:

et: (t, at, St+1)

There exists a function f, such that for each event

e’t = (t, at, At) = f( et, St)

The attributes describe only the changes affecting the current state, i.e. for every t

et = F (e’t,subpart(St))

F is the “Observational Semantics” (OS)

One may just consider the relevant elements:

Trace extraction: At = f( St, St+1)

Trace rebuiling: St+1 = F(At,St)

Trace extraction, communication and rebuilding

ObservedProcess

Virtual Full Trace

Tracer

ObservingProcess

RebuiltVirtual

Full Trace(all

related infos)

Re-building

ActualFull Trace

Filter/Builder

Extraction

Communication

A very simple example: imprecise clock

Example of trace

•Initial state (event “0”): [0, 0]•Virtual full trace (events 1 to 8):

[[1,0], [2,2], [3,3], [ 4,4], [5,5], [6,6], [7,6], [8,6] |_]•Actual full trace:

[[1,0], [2,2], [3,1], [4,1], [5,1], [6,1], [7,0], [8,0] |_]•Rebuilt virtual full trace:

[[1,0], [2,2], [3,3], [4,4], [5,5], [6,6], [7,6], [8,6] |_]

A very simple example: imprecise clocktrace( [[T1,VST1],[T2,VST2]|VTr], [[T1,AT1],[T2,AT2]|ATr] , [T1,BT1],[T2,BT2]|BTr] )

:- incrchrono(T1,T2),

impwatch(VST1,VST2,I),

extract(AT1,AT2,I),

rebuild(BT1,AT2,BT2),

trace( [[T2,VST2]|VTr], [[T2,AT2]|ATr], [[T2,BT2]|BTr] ).

incrchrono(T1,T2) :- T2 is T1+1.

impwatch(ST1,ST2,I):- random(0,3,I),ST2 is ST1+I.

extract(_,AT2,I) :- AT2 is I.

rebuild(ST1,AT1,ST2) :- ST2 is ST1+AT1.

EXAMPLE (Bird’s Prolog actual trace)

1 1 Call: '$call$'(bench(2)) 2 2 Call: bench(2) 3 3 Call: 2>0 3 3 Exit: 2>0 4 3 Call: _182 is 2-1 4 3 Exit: 1 is 2-1 5 3 Call: bench(1) ....

4 “ports” or event types: CALL / EXIT / REDO / FAIL

Example: Prolog Bird’s Trace Virtual full state S

•A program P (set of clauses)

•Proof Tree (PT): set of ordered labeled nodes n•Labels of n: ({clause(n), failed}, nondet(n))•clause is a function PT inst(P)•nondet is a function PT {true,false} (true iff non deterministic node)

•cn the current node in state SObservations: •each node labeled by a clause instance has a related predication which is the head of the clause•A node is non deterministic as long as there is some non used clause of P whose predicate p is the same as the predicate name of its related predication

SO of Bird’s Prolog TraceInitial state: a single deterministic node with label “goal” labeled by a[n instance of the] goal clause, cn is the first leaf.

•CALL pred If cn leaf(PT) and pred is the related predication of cnthen PT is expanded with clause(cn) [and cn is marked det/nondet] and cn’ is the next leaf

•EXIT pred If pred is the related predication of cn and the subtree of root cn has been successfully completed

then cn’ is the next leaf

•REDO pred

then cn’ is the closer previous non deterministic node and all complete subtrees between cn’ and cn are removed and pred is the related predication of cn’ and PT is expanded with clause(cn’)

•FAIL If cn leaf(PT) and pred is the related predication of cnthen cn’ is the next leaf, if any, root ‘goal’ otherwise

Trace explanation in proof style

1: CALL p: prove p with the theorem (clause) p:-q,r. and go to prove q and r (prove q first)

2: CALL q: prove q with the theorem q:-u1. and go to prove u1

3: CALL u1: u1 is a fact (clause: u1:-true.) then it is true.

4: EXIT u1: u1 is proven. Continue to the next unproved lemma

5: CALL r: r is a fact (clause: r:-true.) And follow subtree

4: EXIT p: the proof of p is completed.

Even simpler SO of Bird’s Prolog Trace

OS: « explicative semantics », not operational

Virtual full trace describing PT evolution

Call: visit next node and extend PT

Exit: leave PT, subtree beeing successfuly solved

Redo: visit new choice point in the subtree (if any)

Fail: failed proof using this subtree and no choice point anymore in the subtree

Driven Tracer Approach (requested trace only)

Virtual Full Trace

Process

TracerBuilder

RequestedV. Trace

ActualRequested

DriverFilter/

Manager

Virtual Full Trace: all possible observations

Virtual Full Trace

ObservedProcessO.T.D

RequestedTrace 2

ObservingProcess 2O.B.M

RequestedTrace 1

RequestedTrace 3

Generic Virtual Full Trace: observing a family of processes

Virtual Full Trace 1Observing

ProcessO.B.M

ObservedProcess 1O.T.D

ActualRequested

Trace 1

Virtual Full Trace 2

ActualRequested

Trace 2

Generic/Specialized OBSERVATIONAL SEMANTICS

some points

•Generic OS depends from the considered family of observed processes: it is the “union” of the virtual full traces of all the observed processes.•Generic OS depends from the considered family of observing processes (analyzers): it is the “union” of generic attributes requested by all the analyzers.•Generic OS deals with generic states and generic attributes•A subset of the generic states has 1-1 correspondence with (a subset of) specialized states.•A subset of the generic attributes has 1-1 correspondence with (a subset of) specialized attributes

Specialized Vf trace 3

Generic Virtual Full Trace

METHOD for defining a GOSBuild the generic model for the trace (GOS)

•Define the virtual states (parameters) S•Define the kind of events a and the attributes A (Generic Trace Scheme)

•Define the Observational semantics as the function Fa:

Family indexed by a: S’ = Fa(A,S)

For each observed process build the specific virtual trace model (same steps but OS and Specialized Trace Scheme)

Relate both models (OS and trace schemes) such that there is an isomorphism between kinds of actions, states and attributes of both models.

Examples

•FD Constraint Solver Generic Observational Semantics and GT scheme•Correspondence with GNU-Prolog•Correspondence with Choco•Correspondence with PaLM•Correspondence with CHR(FD)

Example: Generic FD constraint solver

Virtual full state S: (Solver state) So Spt (Choice Tree state)

So : { …}

Spt : { N, , , (N) }

•N : Search Tree, set of ordered labeled nodes

: N So

•failed: So Bool, unsatisfiable store (rejected)

•solution: So Bool, satisfiable store (successful)

•choice-point: So Bool (true iff non deterministic node)

: N, last visited node (current visited node)

: {N} (natural integers), depth of the Choice Tree

Example: Generic FD constraint solver

Attributes A: Attributes related to the control part Apt

Spt : { N, , , (N) }Apt : { v, Dv, v, b, a, c, d }

•v : variable

•Dv : current domain of a variablev : sub domain of a variable

b : previously visited node (before)

a : current visited node (after)

•c : constraint

•d : depth of the Search Tree

Mon texte

•Jkjl

•hjk

GOS: constraint propagation

Mon texte

•Jkjl

•hjk

GNU-Prolog specialized OS

Mon texte

•Jkjl

•hjk

Mon texte

•Jkjl

•hjk

Mon texte

•Jkjl

•hjk

Mon texte

•Jkjl

•hjk

Mon texte

•Jkjl

•hjk

Mon texte

•Jkjl

•hjk

Mon texte

•Jkjl

•hjk

Mon texte

•Jkjl

•hjk

Application to CHR(FD)

Method:

•Refine the operational semantics of CHR(FD) such that an homomorphism may be established with the GOS

Mon texte

•Jkjl

•hjk

Mon texte

•Jkjl

•hjk

Mon texte

•Jkjl

•hjk

Mon texte

•Jkjl

•hjk

Mon texte

•Jkjl

•hjk

Mon texte

•Jkjl

•hjk

Mon texte

•Jkjl

•hjk

Mon texte

•Jkjl

•hjk

Mon texte

•Jkjl

•hjk

CONCLUSION and GENERAL PERSPECTIVES

•Traces• The concept of Virtual Full Trace makes traces as first class objects which can be

studied independently from the processes. It allows to deal with generic trace model.

•Interactions and Tracer Driver• Possibility to implement very large virtual full trace without slowing down

excessively the observed process• It allows to implement tracers as a continuous work.

•Observational Semantics open studies• The concept of OS can be viewed as trace semantics, defined independently from

specific tracers.• What is the (generic) observational semantics when forgetting the trace?• What are the relationships between process operational semantics and the

observational semantics?

References

Bruce Martin and Bashar Jano. Wap binary xml content format, w3c note 24 june1999. Technical report, W3 Consortium, 1999. http://www.w3.org/TR/wbxml.

M.J. Harrold, G. Rothermel, R. Wu and L. Yi, An Empirical Investigation of Program Spectra, Proc. Of teh 1998 ACM SIGPLAN-SIGSOFT workshop on Program Analysis for Software Tools and Engineering, ACM Press, 83-90, 1998

Thank you!

On Using Tracer Driver for External Dynamic Process Observation

Documents

TRACER STUDY (TS) ONLINE KEMRISTEKDIKTI · Introduction • Pencatatan Tracer Study : o Pemetaan hasil tracer secara nasional o Pengelolaan data tracer study institusi / PT • Periode

Tracer Controls, Tracer VV550/551 VAV Controllers · October 2005 CNT-PRC003-EN Tracer™ Controls Tracer VV550/551 VAV Controllers ®

TRACER - spECiAlizEd in fsC CERTifiEd wood · • TRACER fACTs 2009 • 3 3 2 • TRACER fACTs 2009 • TRACER consist of TRACER Aps in denmark

Tracer Brochure

Packet Tracer 5 - kambing.ui.ac.idkambing.ui.ac.id/.../network/packettracer/PacketTracer5_0_DS_0703.pdfPacket Tracer 5.0 Data Sheet Packet Tracer 5.0 As networking systems continue

INTRODUCTION TO TRACER STUDIES - ETF - European Training ...getAttachment... · INTRODUCTION TO TRACER ... Education / training programme graduation Tracer study ... NEW TYPE

Packet Tracer: cree una red simple con Packet Tracer

1 Pierre Deransart WLPE 061 On Using Tracer Driver for External Dynamic Process Observation Pierre Deransart WLPE 2006

Tracer - lablogic.com

Tracer SX5

Cisco Packet Tracer Overview - WikispacesPacket+Tracer... · Cisco Packet Tracer Overview ... Packet Tracer Practice SBA ... •Each CCNA course has a final hands-on skills

How to Use Packet Tracer - atshare.weebly.comatshare.weebly.com/uploads/1/0/8/9/10891690/ptcer_-_01.pdf · How to Use Packet Tracer 1 . What is Packet Tracer • Packet Tracer is

Packet tracer

Voice Tracer

1 Pierre Deransart Rewerse-WP I31 On Using Tracer Driver for External Dynamic Process Observation Pierre Deransart January 29, 2007 REWERSE WP I3 meeting

tracer tool

Tracer Methodology

Daily Operations TRACER SUMMIT - Heating and Air ... Operations Tracer Summit ... Accessing the Training Modules within Tracer Summit. . . . . . . . . 13

Tracer Controllers Tracer MP580/581 Programmable Controllers · Tracer™ Controllers Tracer MP580/581 Programmable Controllers. ... Specifications ... 0–20 mA sensor Temperature

Packet Tracer Network Simulator Book Amazon | Cisco Packet Tracer