On 9/6/2012 6:42 AM, Rajagopal Venkat wrote:
> (305177)(4380506988525) (4380506988525)
> (4380507324219) (4380507019042) (0)<<<
> (4380507354736) (4380596923827) (4380596893310)
> (4380507415771) (4380606964111) (4380606903076)
On 5 September 2012 23:36, Arjan van de Ven wrote:
> On 9/5/2012 10:45 AM, Rajagopal Venkat wrote:
>> On 5 September 2012 22:52, Arjan van de Ven wrote:
>>> On 9/5/2012 10:19 AM, Rajagopal Venkat wrote:
On 5 September 2012 22:39, Arjan van de Ven wrote:
> On 9/5/2012 9:56 AM, Rajagopal
On 9/5/2012 10:45 AM, Rajagopal Venkat wrote:
> On 5 September 2012 22:52, Arjan van de Ven wrote:
>> On 9/5/2012 10:19 AM, Rajagopal Venkat wrote:
>>> On 5 September 2012 22:39, Arjan van de Ven wrote:
On 9/5/2012 9:56 AM, Rajagopal Venkat wrote:
>> measure1:
>> ev3.start
>> ev1
On 5 September 2012 22:52, Arjan van de Ven wrote:
> On 9/5/2012 10:19 AM, Rajagopal Venkat wrote:
>> On 5 September 2012 22:39, Arjan van de Ven wrote:
>>> On 9/5/2012 9:56 AM, Rajagopal Venkat wrote:
> measure1:
> ev3.start
> ev1.end <
evX.end <
These events
On 9/5/2012 10:19 AM, Rajagopal Venkat wrote:
> On 5 September 2012 22:39, Arjan van de Ven wrote:
>> On 9/5/2012 9:56 AM, Rajagopal Venkat wrote:
measure1:
ev3.start
ev1.end <
>>>
>>> evX.end <
>>> These events are causing numbers to go wrong.
>>
>> but out of a 20 second
On 5 September 2012 22:39, Arjan van de Ven wrote:
> On 9/5/2012 9:56 AM, Rajagopal Venkat wrote:
>>> measure1:
>>> ev3.start
>>> ev1.end <
>>
>> evX.end <
>> These events are causing numbers to go wrong.
>
> but out of a 20 second window.. this is a tiny tiny window...
> if you see 100.
On 9/5/2012 9:56 AM, Rajagopal Venkat wrote:
>> measure1:
>> ev3.start
>> ev1.end <
>
> evX.end <
> These events are causing numbers to go wrong.
but out of a 20 second window.. this is a tiny tiny window...
if you see 100.1% I'd buy this reasoning.
but you're seeing much more than that
On 5 September 2012 18:14, Sergey Senozhatsky
wrote:
> Hi,
>
> On (09/05/12 15:52), Rajagopal Venkat wrote:
>> Incorrect timer and work perf events timestamp tracing is one
>> of the reason for reporting usage over 100%. This patch will
>> resolve the issue by
>> - rejecting the events for which e
On 09/05/2012 05:44 AM, Sergey Senozhatsky wrote:
Hi,
On (09/05/12 15:52), Rajagopal Venkat wrote:
Incorrect timer and work perf events timestamp tracing is one
of the reason for reporting usage over 100%. This patch will
resolve the issue by
- rejecting the events for which entry timestamp is
Hi,
On (09/05/12 15:52), Rajagopal Venkat wrote:
> Incorrect timer and work perf events timestamp tracing is one
> of the reason for reporting usage over 100%. This patch will
> resolve the issue by
> - rejecting the events for which entry timestamp is not recorded.
how is that possible?
do you m
On Wed, Sep 5, 2012 at 3:52 PM, Rajagopal Venkat
wrote:
> Incorrect timer and work perf events timestamp tracing is one
> of the reason for reporting usage over 100%. This patch will
> resolve the issue by
> - rejecting the events for which entry timestamp is not recorded.
> Currently these events
Incorrect timer and work perf events timestamp tracing is one
of the reason for reporting usage over 100%. This patch will
resolve the issue by
- rejecting the events for which entry timestamp is not recorded.
Currently these events exit timestamp itself is considered as
usage period resulting in o
12 matches
Mail list logo
