pcp
[Top] [All Lists]

kmchart updates

To: pcp@xxxxxxxxxxx
Subject: kmchart updates
From: nscott@xxxxxxxxxx
Date: Mon, 19 Nov 2007 20:25:28 +1100 (EST)
Importance: Normal
Sender: pcp-bounce@xxxxxxxxxxx
User-agent: SquirrelMail/1.4.8-4.el4.centos
Changes committed to git://oss.sgi.com:8090/nathans/kmchart.git

 README                    |   15 --------
 src/chart/chart.cpp       |   26 +++++++++++++--
 src/chart/chart.h         |    3 +
 src/chart/main.cpp        |    5 +-
 src/chart/tab.cpp         |   79
+++++++++++++++++++++++++++-------------------
 src/chart/timecontrol.cpp |    2 -
 src/time/kmtimelive.cpp   |    5 ++
 src/time/main.cpp         |    5 +-
 8 files changed, 81 insertions(+), 59 deletions(-)

commit 823072236ff521396ad8634e9b3c377429ef474e
Author: Nathan Scott <nathans@xxxxxxxxxx>
Date:   Mon Nov 19 20:23:03 2007 +1100

    When using a subsecond interval, we need a fuzzy-time-match
    tolerance that isn't larger than the delta.

    Fine-tune the code that selects a matching time point in live
    mode when changing "world view", matching up already-observed
    values to required time points.

    Finally, we only adjust chart state now when not entering the
    stopped state.  This resolves the problem of getting an extra
    (unintential) step in by pressing stop in the time controls.

commit 8892f260170c77e3562809cc7dac2e5d1b46a5a2
Author: Nathan Scott <nathans@xxxxxxxxxx>
Date:   Mon Nov 19 15:36:08 2007 +1100

    Series of live mode time control fixes:
    - kmtime now sends a VCR mode message rather than step as
    the first protocol message after play.  This ensures that
    we see delta changes correctly and know to deal with them
    in clients.
    - fix a rounding error in kmtime timeval calculations that
    resulted in sub-second deltas being rounded to zero.
    - fix sideStep calculations to detect large drifts inside
    a series of steps, and correctly display the missing data.
    - fix a fuzzyTimeMatch issue where consecutive samples were
    exactly a delta apart the double precision calculations got
    confused at times.
    - The time matching algorithm for live mode vs archive mode
    is now completely different.  This had to be done to make
    live mode function, as "stop" in live mode is different to
    "stop" in archive mode, in terms of what happens next with
    all known values (need to cater for the block of missing
    data and the fact that the next (play) reposition is always
    going to mismatch with all existing samples.




<Prev in Thread] Current Thread [Next in Thread>