[Intel-gfx] [igt-dev] [PATCH i-g-t v2 1/9] trace.pl: Improve time axis labels

[John Harrison]

On 7/17/2018 8:11 AM, John Harrison wrote:
> On 7/17/2018 1:56 AM, Tvrtko Ursulin wrote:
>>
>> On 16/07/2018 18:53, John Harrison wrote:
>>> On 7/13/2018 2:55 AM, Tvrtko Ursulin wrote:
>>>> From: Tvrtko Ursulin<tvrtko.ursulin at intel.com>
>>>>
>>>> It is possible to customize the axis display so change it to display
>>>> timestamps in seconds on the major axis (with six decimal spaces) and
>>>> millisecond offsets on the minor axis.
>>>>
>>>> v2:
>>>>   * Give up on broken relative timestamps.
>>>>
>>>> Signed-off-by: Tvrtko Ursulin<tvrtko.ursulin at intel.com>
>>>> Suggested-by: Chris Wilson<chris at chris-wilson.co.uk>
>>>> Cc: Chris Wilson<chris at chris-wilson.co.uk>
>>>> Cc: John Harrison<John.C.Harrison at Intel.com>
>>>> ---
>>>>   scripts/trace.pl | 37 +++++++++++++++++++++++++++++++++++++
>>>>   1 file changed, 37 insertions(+)
>>>>
>>>> diff --git a/scripts/trace.pl b/scripts/trace.pl
>>>> index fc1713e4f9a7..41f10749a153 100755
>>>> --- a/scripts/trace.pl
>>>> +++ b/scripts/trace.pl
>>>> @@ -1000,6 +1000,42 @@ $first_ts = ts($first_ts);
>>>>   print <<ENDHTML;
>>>>     ]);
>>>>   +  function majorAxis(date, scale, step) {
>>>> +    var s = date / 1000;
>>>> +    var precision;
>>>> +
>>>> +    if (scale == 'millisecond')
>>>> +        precision = 6;
>>>> +    else if (scale == 'second')
>>>> +        precision = 3;
>>>> +    else
>>>> +        precision = 0;
>>>> +
>>>> +    return s.toFixed(precision) + "s";
>>>> +  }
>>>> +
>>>> +  function minorAxis(date, scale, step) {
>>>> +    var ms = date;
>>>> +    var precision;
>>>> +    var unit;
>>>> +
>>>> +    if (scale == 'millisecond') {
>>>> +        ms %= 1000;
>>>> +        precision = 0;
>>>> +        unit = 'ms';
>>>> +    } else if (scale == 'second') {
>>>> +        ms /= 1000;
>>>> +        precision = 1;
>>>> +        unit = 's';
>>>> +    } else {
>>>> +        ms /= 1000;
>>>> +        precision = 0;
>>>> +        unit = 's';
>>>> +    }
>>>> +
>>>> +    return ms.toFixed(precision) + unit;
>>>> +  }
>>>> +
>>>>     // Configuration for the Timeline
>>>>     var options = { groupOrder: 'content',
>>>>             horizontalScroll: true,
>>>> @@ -1007,6 +1043,7 @@ print <<ENDHTML;
>>>>             stackSubgroups: false,
>>>>             zoomKey: 'ctrlKey',
>>>>             orientation: 'top',
>>>> +          format: { majorLabels: majorAxis, minorLabels: minorAxis },
>>>>             start: '$first_ts',
>>>>             end: '$end_ts'};
>>>
>>> I'm still seeing some kind of strange offset. However, it appears to 
>>> be browser dependent. If I use Chrome then the offset is +28.8 
>>> seconds. With Firefox it is -59958115.2 seconds! On the other hand, 
>>> if I try Edge or IE then I don't get a graph at all. I'm wondering 
>>> if the issue is with Vis browser compatibility rather than anything 
>>> in the trace.pl script. Are you seeing anything at all similar?
>>>
>>> Hmm, if I comment out the 'format:' line and go back to the 
>>> unformatted time stamps then IE & Edge still show nothing. However, 
>>> Firefox shows dates based on a year of 0097 whereas Chrome says 1997.
>>>
>>> Either way, I can't spot anything in this patch that could cause a 
>>> random offset. So...
>>
>> Yeah, I can see that now that I tried in Firefox. I was using 
>> Chromium so far and there timestamps are exactly matching the ones 
>> from the tracepoint log. Which is what we want for easy correlation 
>> between the log and HTML..
>>
>> Firefox corrupts that somehow by applying the large negative offset 
>> to everyhting. Perhaps around two year worth of negative seconds if 
>> my rough calculation can be trusted. Or Vis under Firefox, I wouldn't 
>> know really who is to blame.
>>
>> I have no idea what to do here. :(
>>
>> Regards,
>>
>> Tvrtko
>
> I think ship it for now. It is better than it was. Certainly reporting 
> in date format is vaguely meaningless at best and totally meaningless 
> with the x1000 scale factor.
>
> Note that chromium on Ubuntu 16.04 does the same as Chrome on Windows 
> for me - 28.8 seconds offset. It's not as bad as the 1.9 years of 
> Firefox but it is still out :(. I'm guessing it is a bug in the date 
> -> absolute seconds conversion going on within either Javascript 
> itself or Vis in particular. The timestamps are still encoded as dates 
> in the HTML file (and referenced from 0 not from 1900 or 1970 or 
> whatever). So any difference in calculating leap years between the 
> Perl script and the browser would potentially cause quite a 
> significant delta.
>
> Is it at all possible to put absolute seconds style values in the HTML 
> file instead of dates? That would seem like the obvious answer. I 
> don't know if Vis would cope with that, though?
>
> John.
>

Hmm. It looks like if I change the 'ts()' function to use 'localtime()' 
instead of 'gmtime()' and to add on 1900 to the year then it all works 
fine for me :). So yes, I think it is some incompatibility between the 
Perl and Javascript implementations of date <-> absolute seconds 
conversions. Given that the timestamp is no longer being reported as an 
actual date anymore, the relative value doesn't really matter. So I 
would go with using whatever scheme produces the least mutation along 
the way!

I wonder if you see the correct values on Chrome because your logs have 
smaller timestamps? The ones I am currently testing with are of the 
order of 856985.688681. With the above tweaks, that comes out as a date 
of '1997-02-26 11:34:48.681000'. The 'gmtime' version was '1997-02-26 
19:34:48.681000' and obviously the non-1900 version was '0097-02-26 
19:34:48.681000'. Actually, maybe the Chrome difference is because you 
are in the UK and don't have a timezone delta? Although I would assume 
you are on BST not GMT right now?

John.