[ltt-dev] RFC LTTv TextDump

[ltt-dev] RFC LTTv TextDump

[David Goulet]

Hi everyone,

I propose here, only an idea, to create a lttv plugin for "human 
readable" text dump. There is too much information in the current 
textdump and it's not quite useful showing a lot of cryptic symbol and 
sec.nsec timestamp.

 From this (currently) :

ust.event: 336310.284597315 
(/data/dave/.usttraces/raoul-20101122150921506792809/12821_5542468726404202641/ust_6), 
0, 0, , , 0, 0x0, MODE_UNKNOWN { n = 42, b = 1 }

I propose that this plugin output something like that :

[%H:%M:%S nsec] <channel>.<event_name> : <PAYLOAD>

(here is the example below)

[93:25:10 284597315] ust.event : { n = 42, b = 1 }
(we could maybe cut down 93 hours to 3 days)

and having the first output of the trace being the information like :

Trace set contains 1 traces
<PATH_OF_TRACE>
Buffer size, basic stats.

For "user friendly" output, it will be way more useful.

Anyone wants to jump in that kind of "small" project :)

Thanks
David
-- 
David Goulet
LTTng project, DORSAL Lab.

PGP/GPG : 1024D/16BD8563
BE3C 672B 9331 9796 291A  14C6 4AF7 C14B 16BD 8563

[ltt-dev] RFC LTTv TextDump

[Alexandre Montplaisir]

On 10-11-22 03:20 PM, David Goulet wrote:
> Hi everyone,
>
> I propose here, only an idea, to create a lttv plugin for "human 
> readable" text dump. There is too much information in the current 
> textdump and it's not quite useful showing a lot of cryptic symbol and 
> sec.nsec timestamp.
> ...

Make the textdump readable? What is this heresy!

But seriously, +1 from me too. Especially for the long path that gets 
repeated every line, we could only put it once at the start of the file.
For kernel traces, the PID, TGID and exec name are nice to have, but 
that's it. May need to add a "cpu number" that's normally at the end of 
the file path.

Not sure about making the timestamp in H:M:S format though. This should 
be the job of the viewer, as it would make parsing more difficult. 
Unless we want two different modules, a "human readable textdump" and a 
"parseable textdump".


Cheers,
Alexandre

[ltt-dev] RFC LTTv TextDump

[Mathieu Desnoyers]

* David Goulet (david.goulet at polymtl.ca) wrote:
> Hi everyone,
>
> I propose here, only an idea, to create a lttv plugin for "human  
> readable" text dump. There is too much information in the current  
> textdump and it's not quite useful showing a lot of cryptic symbol and  
> sec.nsec timestamp.
>
> From this (currently) :
>
> ust.event: 336310.284597315  
> (/data/dave/.usttraces/raoul-20101122150921506792809/12821_5542468726404202641/ust_6), 
> 0, 0, , , 0, 0x0, MODE_UNKNOWN { n = 42, b = 1 }
>
> I propose that this plugin output something like that :
>
> [%H:%M:%S nsec] <channel>.<event_name> : <PAYLOAD>
>
> (here is the example below)
>
> [93:25:10 284597315] ust.event : { n = 42, b = 1 }
> (we could maybe cut down 93 hours to 3 days)
>
> and having the first output of the trace being the information like :
>
> Trace set contains 1 traces
> <PATH_OF_TRACE>
> Buffer size, basic stats.
>
> For "user friendly" output, it will be way more useful.
>
> Anyone wants to jump in that kind of "small" project :)

Note that the textdump can output content coming from multiple traces,
where having the trace name in the output for each event becomes
convenient.

But when we show only one trace, it would not be needed. I'm just saying
we should not remove it entirely in every cases, because it is sometimes
needed.

Thanks,

Mathieu


-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com

[ltt-dev] RFC LTTv TextDump

[Alexandre Montplaisir]

On 10-11-23 01:26 PM, Mathieu Desnoyers wrote:
> Note that the textdump can output content coming from multiple traces,
> where having the trace name in the output for each event becomes
> convenient.
>
> But when we show only one trace, it would not be needed. I'm just saying
> we should not remove it entirely in every cases, because it is sometimes
> needed.
>
> Thanks,
>
> Mathieu
>
>

Yeah, I thought about that just after posting. In that case we could 
have the complete trace paths at the start in the header of the file, 
and in the events just a quick fixed-width reference. Something like:


Trace 01 : /home/user/traces/.../trace-alpha
Trace 02 : /tmp/autotrace1

...
channel.eventtype, timestamp, 01, 01, 1000, 1000, Event payload { n = 
42, b = 2 }
...

the numbers representing Trace #1, CPU #1, PID 1000, TGID 1000


Alexandre

[ltt-dev] RFC LTTv TextDump

[Mathieu Desnoyers]

* Alexandre Montplaisir (alexandre.montplaisir at polymtl.ca) wrote:
> On 10-11-23 01:26 PM, Mathieu Desnoyers wrote:
>> Note that the textdump can output content coming from multiple traces,
>> where having the trace name in the output for each event becomes
>> convenient.
>>
>> But when we show only one trace, it would not be needed. I'm just saying
>> we should not remove it entirely in every cases, because it is sometimes
>> needed.
>>
>> Thanks,
>>
>> Mathieu
>>
>>
>
> Yeah, I thought about that just after posting. In that case we could  
> have the complete trace paths at the start in the header of the file,  
> and in the events just a quick fixed-width reference. Something like:
>
>
> Trace 01 : /home/user/traces/.../trace-alpha
> Trace 02 : /tmp/autotrace1
>

We also really need a legend at the top.

Mathieu

> ...
> channel.eventtype, timestamp, 01, 01, 1000, 1000, Event payload { n =  
> 42, b = 2 }
> ...
>
> the numbers representing Trace #1, CPU #1, PID 1000, TGID 1000
>
>
> Alexandre
>

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com

[ltt-dev] RFC LTTv TextDump

[Michel Dagenais]

>> Note that the textdump can output content coming from multiple traces,
>> where having the trace name in the output for each event becomes
>> convenient.

The problem is having the full path, a short "id" when interleaved 
events are there would be useful (something about hostname and CPU)

myhost   p1
yourhost p1
myhost   p1
myhost   p2

[ltt-dev] RFC LTTv TextDump

[David Goulet]

On 10-11-24 02:11 PM, Michel Dagenais wrote:
>
>>> Note that the textdump can output content coming from multiple traces,
>>> where having the trace name in the output for each event becomes
>>> convenient.
>
> The problem is having the full path, a short "id" when interleaved
> events are there would be useful (something about hostname and CPU)

Yep exactly. Just to make it easy to read and easy to refer.

I've also though of a small thing we could add is the time offset in 
nsec (or sec..) between two events.

[...]
event 1 (+4)
event 2 (+7)
[...]

So that way we know *very* quickly what time it took from event 1 to 
event 2 which is 7. Considering a UST trace, this would be of great use!!

We only need someone to do it now :)

David
>
> myhost p1
> yourhost p1
> myhost p1
> myhost p2
>
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev

-- 
David Goulet
LTTng project, DORSAL Lab.

PGP/GPG : 1024D/16BD8563
BE3C 672B 9331 9796 291A  14C6 4AF7 C14B 16BD 8563

[ltt-dev] RFC LTTv TextDump

[Julien Desfossez]

On 24/11/10 03:43 PM, David Goulet wrote:
> On 10-11-24 02:11 PM, Michel Dagenais wrote:
>>
>>>> Note that the textdump can output content coming from multiple traces,
>>>> where having the trace name in the output for each event becomes
>>>> convenient.
>>
>> The problem is having the full path, a short "id" when interleaved
>> events are there would be useful (something about hostname and CPU)
>
> Yep exactly. Just to make it easy to read and easy to refer.
>
> I've also though of a small thing we could add is the time offset in
> nsec (or sec..) between two events.
>
> [...]
> event 1 (+4)
> event 2 (+7)
> [...]
>
> So that way we know *very* quickly what time it took from event 1 to
> event 2 which is 7. Considering a UST trace, this would be of great use!!
>
> We only need someone to do it now :)

While we are in the dream features, I would also like to see a way to 
pass a format string to the program to choose how the output is 
formatted (like the "date" program). For example "%t : %c, %e" to output 
"timestamp : channel, event". That way the output would suit everyone's 
need and specific parsers could be implemented on top of that.

Julien