Community
Participate
Working Groups
Currently the statistical UI allows the user to view data from any number of machines, all overlayed on the same graph. This is useful for correlating data across the machines. However, this usefulness ends when the clocks on the machines are out of sync, because the graphs don't line up. We need a way for the user to adjust this, and "shift" all the timestamps forward or backward for a particular agent. It should not be on the host node because an agent on one host can be collecting data from a remote machine. It should not actually modify the timestamps in the model, but simply add a delta on the agent, and the view must take that delta into account when plotting the data. As far as how to do this, I leave it up to you, but this should be done consistently across TPTP (it is already being done for logs and trace). Please discuss this with the other component owners as the current way to do it is not intuitive to users. If it is possible to automate this task in any way, or help the user determine the clock skew, this would be a great addition, even if it's not perfectly accurate. It is a difficult task for users to find the exact skew on their machines without proper tools.
In the design document, it reads: "This button will be responsible for adjusting the horizontal time offset for each agent so that the data is aligned to the current clock. " Later on it reads "The horizontal time offset for each counter will be adjusted to be the difference between the current workbench time and the last gathered data point time in the model. " We would like to clarify these: We initially thought that the first statement meant you would be applying a single offset to all the counters in a given agent. The latter statement clarified this, but just to confirm: You are not applying a user-defined offset to all the counters in an agent, but rather applying an offset that's calculated on a per counter basis, correct? This leads to questions about how the offset is calculated. If you are adjusting every counter in such a way that it's last data point appears at the current time, there are some issues: - Suppose the last data point arrives with timestamp x1. This gets adjusted to be the current time on the workbench (say the offset is 'y'). Then the next data point comes in (now becoming the new 'last data point'), and the offset (for whatever reason) is different then y. This means readjusting the times of all the data points prior to the last data point. -> It seems like you may have to readjust all the data points every time a new data point comes in. Is this true? Won't this cause problems? - You also lose the relative differences between data collected by different counters. Have you considered allowing a user to apply fixed offsets to groups of counters? This would allow all the data to be shifted by a set amount and the relative differences don't get lost. Another major issue is: How will correlation between different views work after the user has shifted the graphs to the current time? (E.g., user should be able to link between the log view and the stats view based on time. The log view won't have its timestamps adjusted, so if a user right clicks and says go to stats view on a particular log message, will it go to the 'adjusted' time in the stats view or will it go to the time that's in the model? In the former case, this is wrong, in the latter case I can see the user being confused about why the stats view is taking it to a time that that UI shows as being different from that of what's written in the log view.)
The purpose of the offsets is to correlate statistical data in a single statistical view. These are no new issues for the statistical views (or for statcon for that matter). Yes, we are applying an offset that is calculated on a per counter basis. There is no guarantee that the offset is correct (infact, it will almost certainly not be)- it will simply apply a horizontal shift to all data. No, we will not calculate the offsets for every new data point. The offsets are instantaneous adjustments. Currently, there is no concept of a relative or absolute shift and we see no real benefit to this. We might consider using a node based shift, much like the profiling views do, but we find this very unintuitive. We will not alter model data or the way the data is presented to any other views.
*** Bug 108311 has been marked as a duplicate of this bug. ***
requested version changed to 'future'. This feature was not approved for 4.2 plan.
The affected code is no longer supported by the commiter community and all change requests are being closed. If you are impacted or feel strongly otherwise, please reopen the bugzilla with comments and suggestions for follow up action.
As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As such, TPTP is not delivering enhancements. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement is resolved as WONTFIX. For this enhancement to be considered, please re-open with an attached patch including the Description Document (see http://www.eclipse.org/tptp/home/documents/process/development/description_documents.html), code (see http://www.eclipse.org/tptp/home/documents/resources/TPTPDevGuide.htm), and test cases (see http://www.eclipse.org/tptp/home/documents/process/TPTP_Testing_Strategy.html).
As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since this enhancement/defect has been resolved and unverified for more than 1 year and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open.
