X-Git-Url: http://git.liburcu.org/?a=blobdiff_plain;f=lttv%2Flttv%2Fsync%2FREADME;h=fe242e9778a7818f71e449d2dd614d5ba0d7824a;hb=29dd991d045247414d55071fe4390e97f627b8e3;hp=ada0210b99f01ddc71a64450ea0b4fecbca17b00;hpb=bc7c054de1fd8331749c1a73bb1842caae909aa2;p=lttv.git

diff --git a/lttv/lttv/sync/README b/lttv/lttv/sync/README
index ada0210b..fe242e97 100644
--- a/lttv/lttv/sync/README
+++ b/lttv/lttv/sync/README
@@ -1,6 +1,6 @@
 Benjamin Poirier
 benjamin.poirier@polymtl.ca
-2009
+2009, 2010
 
 + About time synchronization
 This framework performs offline time synchronization. This means that the
@@ -129,7 +129,7 @@ There are also other, less common, types. See the enum ApproxType in
 event_analysis_chull.h.
 
 +++ Linear Regression
-linreg sometimes gives more accurate results than chull but it provides no
+linreg sometimes gives more precise results than chull but it provides no
 garantee
 
 +++ Synchronization evaluation
@@ -137,8 +137,11 @@ eval is a special module, it doesn't really perform synchronization, instead
 it calculates and prints different metrics about how well traces are
 synchronized. Although it can be run like other analysis modules, it is most
 useful when run in a postprocessing step, after another synchronization module
-has been run. Eval is most common run in text mode. To do this, run
-lttv -m eval [usual options, ex: -t traces/node1 -t traces/node2 --sync ...]
+has been run. Eval is most commonly run in text mode. To do this, run:
+lttv -m sync_chain_batch [usual options, ex: -t traces/node1 -t traces/node2
+--sync ...]
+It can also be run from the lttv source tree via runlttv:
+./runlttv -m eval [usual runlttv options, ex: traces/node1 traces/node2]
 
 eval provides a few more options:
 --eval-rtt-file  -  argument: FILE
@@ -160,7 +163,9 @@ fields are separated by whitespace. '#' comments a line.
 Many commands can be used to measure the RTT, for example:
 ping -s 8 -A -c 8000 -w 10 192.168.112.57
 
-Note that this must be repeated in both directions in the file.
+Note that this must be repeated in both directions in the file, that is:
+192.168.112.49 192.168.112.50 0.057
+192.168.112.50 192.168.112.49 0.050
 
 ++++ Linear Programming and GLPK
 The synchronization evaluation can optionally perform an analysis similar to
@@ -170,7 +175,12 @@ measure of the accuracy of the synchronization in any point (this is seen in
 the graph output).
 
 This is enabled by default at configure time (--with-glpk) if the GNU Linear
-Programming Kit is available (libglpk).
+Programming Kit is available (libglpk). On Debian-like systems (ex. Ubuntu),
+install the package "libglpk-dev".
+
+To see the output of this mode, run:
+lttv -m sync_chain_batch --eval-graphs [usual options, ex: -t traces/node1 -t
+traces/node2 --sync ...]
 
 + Design
 This part describes the design of the synchronization framework. This is to
@@ -192,9 +202,11 @@ This reads parameters, creates SyncState and calls the processing init
 function. The "sync chain" is the set of event-* modules. At the moment there
 is only one module at each stage. However, as more module are added, it will
 become relevant to have many modules at the same stage simultaneously. This
-will require some modifications. I've kept this possibility at the back of my
-mind while designing. It is already partly supported at the matching stage
-through encapsulation of other matching modules.
+will require some modifications. It is already partly supported at the
+matching stage through encapsulation of other matching modules.
+
+sync_chain_unitest:main() provides a fairly simple example of sync chain
+implementation.
 
 ++ Stage 1: Event processing
 Specific to the tracing data source.