Yes, rank values are easy at the single file level. They pose problem
when logically merging or filtering files.
I think we agree on this one.
The OS already caches the file data. Here you would copy data from the
files into a time sorted cache, eventually competing for memory. If the
time merging process is expensive, this may be the right place to
"cache". Otherwise, it is better to use the filesystem cache already
provided by the OS.
The cached file data contains raw events while the Trace cache would contain parsed TMF events. I see an advantage to this if there are multiple concurrent requests for the same set of events (e.g. form multiple views). I also see that this might become obsolete when request coalescing comes in...
> Here, I would like to point out that finding the Nth event of a trace
Is the user really ever asking for the Nth event, independent of time?
Today, the Events View makes the assumption that positioning its scrollbar to the middle position means that you want to display the middle event. It seems like the intuitive thing to do and what a user would expect. I agree that in the case of roughly evenly distributed events (in time) this is quite similar to displaying the mid-range event.
It is easy to come up with corner cases where this assumption breaks down. For example, for an OS I can't name :-) the start up events occur Jan/1, 1970 until the clock is synchronized with the network. This would skew things a little when a few tens of events happen in 1970 followed by an avalanche of events in 2009. The middle event would occur sometime in 1985...
Also, for the same OS I can't name, you can have peaks of events that occur in the same millisecond.... and far from being evenly distributed over a time range. A rough position could be or not be acceptable.
However, if an event distribution histogram was added to the Time Frame view, this would definitely ease things for a user.
> Again, maybe not all tracing tools are as friendly as LTTng as to
> provide that time range up front (specially in streaming), in which
> case, the trace has to be somehow scanned to determine it. It follows
> that if the trace has to be scanned anyway (in the general case), it
> would be advantageous to build that index at the same time. BTW, I am
> toying with the idea of indexing individual traces as they are
> imported and store the index (and time range, why not?) with the
> trace. Then, TMF will become eerily similar to LTTng :-)
All logs/traces contain timestamps. Otherwise they cannot be merged on
the time axis and the problem becomes simple anyway. If a log cannot be
I guess I wasn't clear on this one so let me rephrase it.
Unless you know the trace/experiment time range, it is not obvious (to me) how you can properly populate the Events View, the Time Frame View, Statistics View, etc. Without some kind of pre-parsing, how do we get this information? I understand that the LTTV library does provide it (probably because it does some kind of internal pre-parsing anyway) but what about the other tracing/logging tools? Either we impose a constraint on tracing tools to provide this type of info up front (else find another FW) or we provide the generic facility. I prefer the latter with a possibility to bypass it if, like LTTng, it is already handled.
So, assuming we pre-parse the trace for timestamps (in the general case), we automatically get ranking at the trace level, which might or might not be useful.
No, you can seek to a certain time effeciently in each trace and then
you merge events from there to fill your display table, implicitly
getting a local ranking, no nightmare. This is where I dont see how you
can proceed if you base everything on ranking?
I don't base everything on ranking. The Events View has a use for it although that's about it for now. Is it worth the indexing time and space? You think not, I think maybe and would like to see how efficiently it can be done. I have a week off to think about it :-)
Thanks for the input!
Best Regards,
/fc
