[lttng-dev] status of lttng top

[lttng-dev] status of lttng top

[McDermott, Andrew]

I was wondering what the status of lttng top was.  I'm happy to add the daily Ubuntu PPA and try it that way, or equally building from source.  But, before I tread that route, are there any gotchas to be aware of. Is it still considered work-in-progress, etc.

Thanks.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20121008/24fc9c4c/attachment.html>

[lttng-dev] status of lttng top

[Julien Desfossez]

Hi,

LTTngTop is still work in progress and will remain that way for a long
time, but the version in the PPA (or in the master branch in git) is
perfectly usable for offline traces (traces recorded and replayed
through LTTngTop).

The "live" branch is more experimental and requires patches in both
Babeltrace and Lttng-tools (all documented in the README-LIVE file), but
it worked at the time of Plumbers, I didn't have much time since then to
rebase the branches.

I am waiting for the release of Lttng-tools 2.1 (currently in RC) before
merging those patches. After these patches are integrated, LTTngTop will
be able to work live without any modifications, so directly reading
traces in memory shared with the tracer.

In the meantime we are working on replacing the "home made" state system
in LTTngTop with a more generic one (which will be used also in LTTV),
this will cleanup this part of the code and allow to store the state on
disk. So in a near future we will be able to only read the state instead
of the trace (once it has been generated), which will compress
significantly the amount of data we need to keep in order to access the
kind of statistics provided by LTTngTop.

If you want to try LTTngTop, you can just install the package and follow
the man page to record a trace with the right contexts, it should work
as is.

If you have any questions and/or feedback, please don't hesitate to ask.

Thanks,

Julien


On 08/10/12 05:57 PM, McDermott, Andrew wrote:
> I was wondering what the status of lttng top was.  I'm happy to add the
> daily Ubuntu PPA and try it that way, or equally building from source.
>  But, before I tread that route, are there any gotchas to be aware of.
> Is it still considered work-in-progress, etc.
> 
> Thanks.
> 
> 
> 
> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

[lttng-dev] status of lttng top

[McDermott, Andrew]

Hi,

> LTTngTop is still work in progress and will remain that way for a long
> time, but the version in the PPA (or in the master branch in git) is
> perfectly usable for offline traces (traces recorded and replayed
> through LTTngTop).
>
> The "live" branch is more experimental and requires patches in both
> Babeltrace and Lttng-tools (all documented in the README-LIVE file), but
> it worked at the time of Plumbers, I didn't have much time since then to
> rebase the branches.
>
> I am waiting for the release of Lttng-tools 2.1 (currently in RC) before
> merging those patches. After these patches are integrated, LTTngTop will
> be able to work live without any modifications, so directly reading
> traces in memory shared with the tracer.

Thanks for this info.

Right now my interest is with the live streaming; we have a use case
where the live streaming is really the only practical solution.

Very roughly, would you expect the RC series to conclude this year, or
(early) next year?

> In the meantime we are working on replacing the "home made" state system
> in LTTngTop with a more generic one (which will be used also in LTTV),
> this will cleanup this part of the code and allow to store the state on
> disk. So in a near future we will be able to only read the state instead
> of the trace (once it has been generated), which will compress
> significantly the amount of data we need to keep in order to access the
> kind of statistics provided by LTTngTop.
>
> If you want to try LTTngTop, you can just install the package and follow
> the man page to record a trace with the right contexts, it should work
> as is.
>
> If you have any questions and/or feedback, please don't hesitate to ask.
>
> Thanks,
>
> Julien
>
>
> On 08/10/12 05:57 PM, McDermott, Andrew wrote:
>> I was wondering what the status of lttng top was.  I'm happy to add the
>> daily Ubuntu PPA and try it that way, or equally building from source.
>>  But, before I tread that route, are there any gotchas to be aware of.
>> Is it still considered work-in-progress, etc.
>> 
>> Thanks.
>> 
>> 
>> 
>> _______________________________________________
>> lttng-dev mailing list
>> lttng-dev at lists.lttng.org
>> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

[lttng-dev] status of lttng top

[Julien Desfossez]

Hi Andrew,

On 22/10/12 07:00 AM, McDermott, Andrew wrote:
> 
> Hi,
> 
>> LTTngTop is still work in progress and will remain that way for a long
>> time, but the version in the PPA (or in the master branch in git) is
>> perfectly usable for offline traces (traces recorded and replayed
>> through LTTngTop).
>>
>> The "live" branch is more experimental and requires patches in both
>> Babeltrace and Lttng-tools (all documented in the README-LIVE file), but
>> it worked at the time of Plumbers, I didn't have much time since then to
>> rebase the branches.
>>
>> I am waiting for the release of Lttng-tools 2.1 (currently in RC) before
>> merging those patches. After these patches are integrated, LTTngTop will
>> be able to work live without any modifications, so directly reading
>> traces in memory shared with the tracer.
> 
> Thanks for this info.
> 
> Right now my interest is with the live streaming; we have a use case
> where the live streaming is really the only practical solution.
> 
> Very roughly, would you expect the RC series to conclude this year, or
> (early) next year?

Just to clarify, are you interested in live network trace reading or
live in-memory reading ?
The patches I was talking about are for in-memory trace reading.

Thanks,

Julien

[lttng-dev] status of lttng top

[McDermott, Andrew]

Hi,

> On 22/10/12 07:00 AM, McDermott, Andrew wrote:
>> 
>> Hi,
>> 
>>> LTTngTop is still work in progress and will remain that way for a long
>>> time, but the version in the PPA (or in the master branch in git) is
>>> perfectly usable for offline traces (traces recorded and replayed
>>> through LTTngTop).
>>>
>>> The "live" branch is more experimental and requires patches in both
>>> Babeltrace and Lttng-tools (all documented in the README-LIVE file), but
>>> it worked at the time of Plumbers, I didn't have much time since then to
>>> rebase the branches.
>>>
>>> I am waiting for the release of Lttng-tools 2.1 (currently in RC) before
>>> merging those patches. After these patches are integrated, LTTngTop will
>>> be able to work live without any modifications, so directly reading
>>> traces in memory shared with the tracer.
>> 
>> Thanks for this info.
>> 
>> Right now my interest is with the live streaming; we have a use case
>> where the live streaming is really the only practical solution.
>> 
>> Very roughly, would you expect the RC series to conclude this year, or
>> (early) next year?
>
> Just to clarify, are you interested in live network trace reading or
> live in-memory reading ?
> The patches I was talking about are for in-memory trace reading.

So I guess I don't understand enough of the low-level detail here.  What
I was interested in was being able to consume events, maybe periodically
(1 /s), from a trace written by another process on the same machine.  I
guess that would fall under in-memory trace reading.

-- 
andy

[lttng-dev] status of lttng top

[Julien Desfossez]

Hi,

>>>> LTTngTop is still work in progress and will remain that way for a long
>>>> time, but the version in the PPA (or in the master branch in git) is
>>>> perfectly usable for offline traces (traces recorded and replayed
>>>> through LTTngTop).
>>>>
>>>> The "live" branch is more experimental and requires patches in both
>>>> Babeltrace and Lttng-tools (all documented in the README-LIVE file), but
>>>> it worked at the time of Plumbers, I didn't have much time since then to
>>>> rebase the branches.
>>>>
>>>> I am waiting for the release of Lttng-tools 2.1 (currently in RC) before
>>>> merging those patches. After these patches are integrated, LTTngTop will
>>>> be able to work live without any modifications, so directly reading
>>>> traces in memory shared with the tracer.
>>>
>>> Thanks for this info.
>>>
>>> Right now my interest is with the live streaming; we have a use case
>>> where the live streaming is really the only practical solution.
>>>
>>> Very roughly, would you expect the RC series to conclude this year, or
>>> (early) next year?
>>
>> Just to clarify, are you interested in live network trace reading or
>> live in-memory reading ?
>> The patches I was talking about are for in-memory trace reading.
> 
> So I guess I don't understand enough of the low-level detail here.  What
> I was interested in was being able to consume events, maybe periodically
> (1 /s), from a trace written by another process on the same machine.  I
> guess that would fall under in-memory trace reading.
> 

Ok I will just describe this a little more, when we talk about live
reading the trace, we have two aspects :
- reading a trace while it is being written on disk (whether it is
received from the network or from a local consumer)
- reading a trace directly from memory mapped buffers between the tracer
and the consumer without writing the trace files.

So if you want to read the trace on the machine that is being traced
without ever writing the trace on disk, yes you want the in-memory trace
reading.

For 2.2, the focus is to support live trace reading from disk (local and
network).
In my development branches (referenced in previous email), I have code
that provides live trace reading from memory, I will try to merge it in
2.2 but I cannot guarantee it will be accepted since it is not the
current priority (but definitely a use-case we want to support).

I hope it clarifies the situation,

Thanks,

Julien

[lttng-dev] status of lttng top

[McDermott, Andrew]

Julien Desfossez <jdesfossez at efficios.com> writes:

> Hi,
>
>>>>> LTTngTop is still work in progress and will remain that way for a long
>>>>> time, but the version in the PPA (or in the master branch in git) is
>>>>> perfectly usable for offline traces (traces recorded and replayed
>>>>> through LTTngTop).
>>>>>
>>>>> The "live" branch is more experimental and requires patches in both
>>>>> Babeltrace and Lttng-tools (all documented in the README-LIVE file), but
>>>>> it worked at the time of Plumbers, I didn't have much time since then to
>>>>> rebase the branches.
>>>>>
>>>>> I am waiting for the release of Lttng-tools 2.1 (currently in RC) before
>>>>> merging those patches. After these patches are integrated, LTTngTop will
>>>>> be able to work live without any modifications, so directly reading
>>>>> traces in memory shared with the tracer.
>>>>
>>>> Thanks for this info.
>>>>
>>>> Right now my interest is with the live streaming; we have a use case
>>>> where the live streaming is really the only practical solution.
>>>>
>>>> Very roughly, would you expect the RC series to conclude this year, or
>>>> (early) next year?
>>>
>>> Just to clarify, are you interested in live network trace reading or
>>> live in-memory reading ?
>>> The patches I was talking about are for in-memory trace reading.
>> 
>> So I guess I don't understand enough of the low-level detail here.  What
>> I was interested in was being able to consume events, maybe periodically
>> (1 /s), from a trace written by another process on the same machine.  I
>> guess that would fall under in-memory trace reading.
>> 
>
> Ok I will just describe this a little more, when we talk about live
> reading the trace, we have two aspects :
> - reading a trace while it is being written on disk (whether it is
> received from the network or from a local consumer)
> - reading a trace directly from memory mapped buffers between the tracer
> and the consumer without writing the trace files.
>
> So if you want to read the trace on the machine that is being traced
> without ever writing the trace on disk, yes you want the in-memory trace
> reading.
>
> For 2.2, the focus is to support live trace reading from disk (local and
> network).
> In my development branches (referenced in previous email), I have code
> that provides live trace reading from memory, I will try to merge it in
> 2.2 but I cannot guarantee it will be accepted since it is not the
> current priority (but definitely a use-case we want to support).
>
> I hope it clarifies the situation,

Yes it does.  Many thanks.

-- 
andy