This is the mail archive of the frysk@sources.redhat.com mailing list for the frysk project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: EventViewer and time.


I just remembered another couple of considerations while I was in the
shower just now:  (I've always done my best thinking in the shower--I
just wish my keyboards were waterproof.)

First is that traces don't /have/ to represent threads, procs, or
whatever.  It's easily possible, and probably useful, to do something
like have one trace represent clone events, another trace term events,
and so on.  On a single-processor machine, there's no way to have truly
simultaneous events, but on an MP machine, it would be easy to have,
e.g., simultaneous clone events on separate threads running on different
processors.  Under these circumstances, using the unit-interval
approach, it would be possible have a requirement to show two events in
the same time slot.

Another issue is that the way the tooltip popups work is that they map
the position of the pointer on the screen to a time (which was
originally, of course, used to map to a screen position to display the
event--a reversible transformation.)  The unit-interval approach is not
reversible, at least not linearly or simply, so using it would break
tooltips, at least without a fair amount of work.  (This, by the way,
could be an issue--the popup code has to be fairly fast.)

Sorry if I'm sounding thoroughly negative about all this, but these
complications are why I never got around to implementing unit-interval.

One thing I did consider was trying to use a reversible non-linear
mapping.  At the moment, the mapping from an event time to a screen
x-position is a simple linear one: x = at + b, where a and b are
functions of the interval and offset slider values.  Nothing says that
the mapping has to be that simple.  Take a look at the attached image
(assuming that sources.redhat.com will accept attachments).  Given a
hypothetical situation where you have a two widely separated clusters of
points that would normally be mapped at widely separated places in the
viewer, using a non-linear mapping as shown would increase the interval
between the clustered points and decrease the interval between the
clusters.  The only requirement is that the transformation be continuous
and strictly monotonic, and would therefore be unambigously reversible. 
It probably wouldn't be terribly difficult to compute such
transformation on the fly to optimise the display of the data you have
and still maintain reversibility, thereby keeping tooltips from breaking.

Chris

(Okay, I'll stop rambling now...)

Chris Moller mumbled something on 07/19/06 20:42:
> Events are stored per trace in the viewer, i.e., every trace structure
> contains a pointer to an array containing the events associated with
> that trace.  Within each event array, the events are chronologically
> monotonic, but there's no correlation between different event arrays. 
> What this means is that for Trace A, for example, you could have:
>
>    1. 1    sec  eventA
>    2. 1.1 sec  eventB
>    3. 30  sec  eventC
>
> It's easy enough to plot those events at uniform sequential intervals:
>
>     A B C
>
> but if Trace B has an eventD at 15 seconds, the result is
>
>     A B     C
>          D
>
> i.e., you'll have to resequence Trace A to include a gap in which to put
> EventD on Trace B.  The implication of all this is that you'll have to
> either recompute the global sequence every time you expose, or maintain
> a global chronologically monotonic event index, or some such thing. 
> (Maybe something involving concurrent scans of all the event arrays...?)
>
> Another potential complication is that I'd left the potential to have
> the event timestamp accompany the event when it's stored.  The current
> method--having the viewer generate and attach the timestamp
> internally--is fine as long as all the events being recorded are being
> generated on the same machine frysk is running on, but I seem to recall
> (at least I designed for the possibility) that a single frysk instance
> on one machine could monitor (by means TBD) events that occur remotely
> on other machines.  If that indeed is ever actually implemented, the
> remote machines will have to generate its own per-event timestamps. 
> Failing to do that will introduce unpredictably inconsistent
> transmission delays, potentially violating monotonicity  (i.e., if it
> takes Machine B longer to transmit a record of the occurrence of EventA
> than it takes to transmit EventB and frysk generates the timestamps when
> it receives the events, it could appear that EventB occurred before
> EventA).  The only way to make sure this doesn't happen is if Machine B
> generates its own timestamps and frysk records them rather than
> generating its own.  (With the current method of storing events, the
> events need not be stored with chronological monotonicity--each event
> contains its own timestamp and is thus independent of every other event.)
>
> Chris
>
> Nurdin Premji mumbled something on 07/19/06 16:02:
>   
>> I've been thinking about how the eventviewer represents events and I
>> think in terms of a time-line it does this too realistically. What I
>> mean by this is that if there is 10 seconds of time between event "a"
>> and event "b", and 5 seconds of time between event "b" and event "c",
>> then we will see event "a", a large gap, event "b", a smaller gap, event
>> "c".
>>
>> This seems natural, however when debugging for the most part we don't
>> really care how much time is between each pair of events, we just want
>> to know that event "a" happened, then event "b" then event "c". (or "c"
>> then "b" and we see the race condition that we were looking for for
>> example.)
>>
>> So is anybody really set on having realistic time differences between
>> events or can I start switching it over to have a set amount of space
>> between each event. I don't want events to overlap, so if an event
>> happens then each trace will move forward one space to decide where to
>> put an event.
>>
>> So previously if thread A forked, then waited 10 seconds, then thread B
>> cloned, wait 5 seconds,  and thread A exited we would see:
>>
>> Thread A -------[]-------------*
>> Thread B--------------------()---
>>
>> I propose:
>>
>> Thread A -----[]-----------*
>> Thread B -----------()-----
>>
>> Any thoughts?
>>
>>   
>>     
>
>   

PNG image

Attachment: signature.asc
Description: OpenPGP digital signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]