From patchwork Tue Jul 17 16:22:09 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Tvrtko Ursulin X-Patchwork-Id: 10530099 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 4B93760247 for ; Tue, 17 Jul 2018 16:22:17 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 310AD28620 for ; Tue, 17 Jul 2018 16:22:17 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 22DC72863F; Tue, 17 Jul 2018 16:22:17 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=2.0 tests=BAYES_00, MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id F0A5D28620 for ; Tue, 17 Jul 2018 16:22:15 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 87CBC6E6E2; Tue, 17 Jul 2018 16:22:14 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) by gabe.freedesktop.org (Postfix) with ESMTPS id 4FDDD6E7A3 for ; Tue, 17 Jul 2018 16:22:13 +0000 (UTC) Received: by mail-wr1-x441.google.com with SMTP id q10-v6so1855519wrd.4 for ; Tue, 17 Jul 2018 09:22:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=lY1tAlYpoqY4U1yfnw6dlfnmIVH333pQgIhKX8XjMtg=; b=oDwET6ozeaZPoIMwq06MJ8QlUZFcugnTkkWwH+hKxPBWKeUnU31bSiKS8RnInJzmE9 KZsxVfQPZ1UydlANsUxX4SOGgMv/48Cy6jRtt7brPEiqQqDpSyb2l7tPDwK6yFOI63a8 YQ0i2gKRnCQhEEYz3mqB7DRM08IWJ3zPmfN+0kSnRB+uc6QP2sahWWQ+RZQ86w2n6QA6 4GSoecPdofyEs5LOWokJ4n3suicv+BQwWQd7iLUt1JLLC2sPXsEz7iw2BfrQ3Xa0nJ6F 2JvF9ZgRyWfAYD0PDXuuuLhPHxDjUKm20OIosum+fBUu1JGiUSaW8mXybAsfTK/fshYT b1Qw== X-Gm-Message-State: AOUpUlEMeSW0cwcQFdHtFyzEKK3qb3TqNPPIaaP6RsBrI5N8f2pAkaX7 1r2S354/P8Ad/CgH9X46gDZS1w== X-Google-Smtp-Source: AAOMgpdn9Lvz+EkNz9MvKV7GX9OgzL3BIKZPbEERqgUbYnyQIGgRb0JjzlayAJUJYX698ldha8eiIw== X-Received: by 2002:adf:aadb:: with SMTP id i27-v6mr1871601wrc.149.1531844531981; Tue, 17 Jul 2018 09:22:11 -0700 (PDT) Received: from [192.168.0.197] ([95.146.151.144]) by smtp.googlemail.com with ESMTPSA id m144-v6sm2415242wma.36.2018.07.17.09.22.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jul 2018 09:22:10 -0700 (PDT) To: John Harrison , Tvrtko Ursulin , igt-dev@lists.freedesktop.org References: <7d8a4756-c021-2751-f81c-0e67b2eba076@Intel.com> <20180713095537.21080-1-tvrtko.ursulin@linux.intel.com> <98e2bb4d-b037-af25-90ed-ef54f5033381@Intel.com> <9e7c8c93-c2f3-4595-535d-95cbd3b399bb@Intel.com> <07840c0e-3509-27e3-d78d-cd89b60c49cb@Intel.com> From: Tvrtko Ursulin Message-ID: <67dccb96-1f8f-23b5-b547-283e1c97632e@ursulin.net> Date: Tue, 17 Jul 2018 17:22:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <07840c0e-3509-27e3-d78d-cd89b60c49cb@Intel.com> Content-Language: en-US Subject: Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v2 1/9] trace.pl: Improve time axis labels X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: intel-gfx@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Virus-Scanned: ClamAV using ClamSMTP 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 >>>>> >>>>> 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 >>>>> Suggested-by: Chris Wilson >>>>> Cc: Chris Wilson >>>>> Cc: John Harrison >>>>> --- >>>>>   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 <>>>>     ]); >>>>>   +  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 <>>>>             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: Could be the gotcha we were missing! Regards, Tvrtko 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 <