| Message ID | 67dccb96-1f8f-23b5-b547-283e1c97632e@ursulin.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 7/17/2018 9:22 AM, Tvrtko Ursulin wrote: > On 17/07/18 16:31, John Harrison wrote: >> 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@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@intel.com> >>>>>> Suggested-by: Chris Wilson<chris@chris-wilson.co.uk> >>>>>> Cc: Chris Wilson<chris@chris-wilson.co.uk> >>>>>> Cc: John Harrison<John.C.Harrison@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? > Can you try leaving gmtime in ts() and adding this diff: > > diff --git a/scripts/trace.pl b/scripts/trace.pl > index 88abc2ee5ebf..2e43b68e3163 100755 > --- a/scripts/trace.pl > +++ b/scripts/trace.pl > @@ -1338,6 +1338,10 @@ print <<ENDHTML; > zoomKey: 'ctrlKey', > orientation: 'top', > format: { majorLabels: majorAxis, minorLabels: minorAxis }, > + moment: function(date) { > + return vis.moment(date).utc(); > + }, > + > start: '$first_ts', > end: '$end_ts'}; > > Could be the gotcha we were missing! > > Regards, > > Tvrtko Doesn't seem to make a difference for me :(. The +1900 gets rid of the massive negative offset in Firefox but only the localtime() fixes the 28.8s offset in both Firefox and Chrome.
diff --git a/scripts/trace.pl b/scripts/trace.pl index 88abc2ee5ebf..2e43b68e3163 100755 --- a/scripts/trace.pl +++ b/scripts/trace.pl @@ -1338,6 +1338,10 @@ print <<ENDHTML; zoomKey: 'ctrlKey', orientation: 'top', format: { majorLabels: majorAxis, minorLabels: minorAxis }, + moment: function(date) { + return vis.moment(date).utc(); + }, + start: '$first_ts', end: '$end_ts'};