OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsdm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsdm] Question about example of Sec. 4.6 Metrics


Hi Kirk,

I agree with your example in case of GatheringTime = "OnChange".
As you mentioned, I assumed GatheringTime is "Periodic" in my past mail.

And in your example, I found some trivial errors.

1. value of mows-xs:ServiceTime will be "PT3H28M13.52S" (format of
duration).
2. Duration attribute of mows-xs:MaxResponseTime will be about
"PT1H47M38.54S".
    16:12:36.37 - (14:24:58.21 - 0.38S)
3. value of mows-xs:MaxResponseTime should be greater value (10S or
20S).
    ServiceTime (3H28M13.52S = 12493.52S)
    12493.52S / 1556 requests = 8.02 sec./req.
    I think that at least average service (response) time of one request
(8.02sec) should be less than MaxResponseTime (0.02 sec in this
example).

I guess that we should continue to discuss about metric's attributes and
metadatas and sort out these things for next version of WSDM spec.

P.S.
 I hope the Interop Demo at EMW will succeed tomorrow.
----
Mitsunori SATOMI (mailto:Mitsunori.Satomi@hds.com)
  Director, Advanced Software Architect
    Hitachi Data Systems Corporation 


> -----Original Message-----
> From: Wilson, Kirk D [mailto:Kirk.Wilson@ca.com] 
> Sent: Monday, September 12, 2005 8:34 AM
> To: Mitsunori Satomi; Murray, Bryan P.
> Cc: wsdm@lists.oasis-open.org; fred.carter@amberpoint.com
> Subject: RE: [wsdm] Question about example of Sec. 4.6 Metrics
> 
> Satomi-san,
> 
> Attached is further elaboration of the example.  I show two 
> sets of examples, the first set (which was part of my 
> original attachment) is for TimeScope=SinceReset (or 
> PointInTime in the case of LastResponseTime).  The second set 
> is for the same data for TimeScope=Interval (for those NOWS 
> metric properties that can be either SinceReset or Interval). 
>  I assume that Duration = LastUpdate - ResetAt, as you show 
> in your example of MaxResponseTime.
> 
> I did find one error in my original example.  
> LastResponseTime (a PointInTime metric) MUST NOT have a ResetAt.
> 
> I did notice that the MOWS metric properties are not 
> perfectly in conformance with the MUWS, which requires a 
> GatheringTime instance for each metric property.  This 
> metadata is not specified for the MOWS metric properties in 
> the MOWS spec.  I assume that the MOWS metrics are 
> "OnChange".  (IMHO, I think Bryan's comment, which you quote, 
> may be confusing TimeScope=interval with 
> GatheringTime=P(eriodic and/or
> CalculationInterval.)
> 
> Note that at one point the text states that Duration can 
> change every time the metric is updated.  I assume that one 
> case in which this would be true is in the case of 
> MaxResponseTime.  Each time a new MaxResponseTime is hit, the 
> duration changes to the duration from the last 
> MaxReponseTime. (???--This strikes me as a little strange.  
> The statement seems to conflict with the earlier statement 
> that "a duration usually remains the same for every reading 
> of a metric.") Thus, in this case ResetAt has no 
> significance, since the first response time after a "reset" 
> will be the max.  (This idea is reflected in the second 
> example of MaxResponseTime.)
> 
> Also, the definition of ChangeType=Gauge in the MUWS text is 
> unacceptable--it says noting.
> 
> I hope
> Kirk Wilson
> Architect, Development
> Office of the CTO
> 802 765-4337
>  
> 
> -----Original Message-----
> From: Mitsunori Satomi [mailto:Mitsunori.Satomi@hds.com]
> Sent: Friday, September 09, 2005 9:47 PM
> To: Wilson, Kirk D; Murray, Bryan P.
> Cc: wsdm@lists.oasis-open.org; fred.carter@amberpoint.com
> Subject: RE: [wsdm] Question about example of Sec. 4.6 Metrics
> 
> Bryan, Kirk and Jane. Thank you for help.
> 
> Kirk, I make sense of your example.
> 
> But the point I'd like to clarify is just what Bryan 
> mentioned as follows,
> 
> > - ResetAt may be included with the metric value. There is no clear 
> > indication of what ResetAt means for an Interval metric, however, I 
> > believe it is the time at which the metric was reset. For example, 
> > this metric was reset at midnight, but the interval ends at 
> the end of 
> > every hour. I am not sure what it means to reset an 
> interval metric, 
> > except if the ResetAt value is less than the Duration, 
> which I guess 
> > means that the metric was reset in this interval.
> 
> IMHO, if "reset" event is occurred before the start time of 
> Interval, I guess that the "reset" event has no effect to the 
> measurement of this interval.
> So in this case, if "ResetAt" attribute is returned, 
> "ResetAt" value should indicate the beginning time of 
> interval. (Because I think that the start of interval means 
> nearly the "reset" event.)
> 
> And I guess that we should include at least one example of "Interval"
> metric
> in the Primer's example
> like followings,
> 
>  <mows-xs:MaxResponseTime
>   ResetAt="2005-06-14T14:14:20.1881806-04:00"
>   LastUpdated="2005-06-14T14:24:20.1881806-04:00"
>   Duration="PT10M" >PT0.02S</MaxResponseTime>
> 
> One of the reasons we confused in this topic, we removed the "reset"
> operation from WSDM 1.0 spec, I think.
> 
> Anyway, we should discuss about this topic and have to 
> clarify the value of "ResetAt" and also meaning of "reset" of 
> metrics in the next version of WSDM specification.
> 
> Regards,
> ----
> Mitsunori SATOMI (mailto:Mitsunori.Satomi@hds.com)
>   Director, Advanced Software Architect
>     Hitachi Data Systems Corporation 
> 
> > -----Original Message-----
> > From: Wilson, Kirk D [mailto:Kirk.Wilson@ca.com]
> > Sent: Friday, September 09, 2005 12:42 PM
> > To: Murray, Bryan P.; Mitsunori Satomi; fred.carter@amberpoint.com; 
> > wsdm@lists.oasis-open.org
> > Subject: RE: [wsdm] Question about example of Sec. 4.6 Metrics
> > 
> > I have reworked the data in the 4.6 Metrics example (see attached).
> > Does this data make more sense?  If so, Heather/Bryan, please 
> > substitute the example (in vers 17 the example replaces lines
> > 4736 - 4762.
> > 
> > I still need to study the issues of what attributes support what 
> > metadata for metrics.  (IOW, there may be changes to the text.)
> > 
> > Kirk Wilson
> > Architect, Development
> > Office of the CTO
> > 802 765-4337
> >  
> > -----Original Message-----
> > From: Murray, Bryan P. [mailto:bryan.murray@hp.com]
> > Sent: Thursday, September 08, 2005 9:45 PM
> > To: Mitsunori Satomi; fred.carter@amberpoint.com; 
> > wsdm@lists.oasis-open.org
> > Subject: RE: [wsdm] Question about example of Sec. 4.6 Metrics
> > 
> > I have always been confused over which attributes 
> may/should/must be 
> > used with which values of metadata for metrics. It is pretty 
> > complicated.
> > 
> > I don't think the spec explains it well, but here is how I 
> understand 
> > a metric with TimeScope=Interval:
> > 
> > - Duration attribute must be used. It specifies the during 
> which data 
> > was collected. The length of the interval might be longer than the 
> > duration. The metadata CalculationInterval migh offer information 
> > about the length of the interval.
> > 
> > - ResetAt may be included with the metric value. There is no clear 
> > indication of what ResetAt means for an Interval metric, however, I 
> > believe it is the time at which the metric was reset. For example, 
> > this metric was reset at midnight, but the interval ends at 
> the end of 
> > every hour. I am not sure what it means to reset an 
> interval metric, 
> > except if the ResetAt value is less than the Duration, 
> which I guess 
> > means that the metric was reset in this interval.
> > 
> > - LastUpdated should indicate the end of the interval for which the 
> > metric represents. LastUpdated - Duration should be the time of the 
> > beginning of the interval. CurrentTime - LastUpdated should 
> tell you 
> > how far into the next interval the data collection is going.
> > 
> > 
> > Now if we look at the values used.
> > 
> > - The metric was reset ~1 minute 4 seconds before the 
> metric was read.
> > - it was last updated only 0.04 seconds after the reset
> > - the data collection time for this value was more than 24 seconds
> > 
> > I agree with you that the times do not make sense. The values 
> > indicate that the metric was reset in the middle of data 
> > collection. I do not think we should give such an example.
> > 
> > In my mind, metrics should extremely rarely or never be 
> > reset. This is due to the complications it offers in a 
> > multiple manager situation. So, I would set the ResetAt value 
> > to be 3 days ago, or a month ago, or some long period 
> > relative to the other values. I think it is fine to have the 
> > last update time be just a few seconds ago.
> > 
> > What I would do for ServiceTime is make it a SnceReset metric 
> > and not include the duration. I think ServiceTime is an 
> > accumulated time for the total time spent in that service 
> > across all requests. So for the example I would set its value 
> > to something that is a few hours. My expectation is to 
> > request ServiceTime with NumberOfRequests and calculate the 
> > time per request myself. This is the behavior that works with 
> > multiple managers.
> > 
> > If my understanding is incorrect regarding the above, please 
> > correct me.
> > 
> > Bryan
> >  
> > 
> > -----Original Message-----
> > From: Mitsunori Satomi [mailto:Mitsunori.Satomi@hds.com]
> > Sent: Wednesday, September 07, 2005 7:56 PM
> > To: fred.carter@amberpoint.com; wsdm@lists.oasis-open.org
> > Subject: [wsdm] Question about example of Sec. 4.6 Metrics
> > 
> > Hi Fred and folks,
> > 
> > I have one question about the example of "4.6 Metrics" in 
> > wsd-wsdm-primer-15.doc.
> > 
> > Line #4770 to #4796, e.g. mows-xs:ServiceTime is a "Interval" 
> > type metric (not SinceReset) because it has a Duration attribute.
> > And its attributes are written as follows in this example,
> > 
> >  ResetAt      = "2005-06-14T14:24:58.2181944-04:00"
> >  LastUpdated="2005-06-14T14:24:58.2582128-04:00"
> >  Duration      ="PT24.621S"
> > 
> > I think that LastUpdated - ResetAt will be nearly equal to 
> > the Duration value.
> > But these values of example break this relationship.
> > 
> > (And mows-xs:CurrentTime is "2005-06-14T14:25:21.6589722-04:00".)
> > 
> > In this example CurrentTime - ResetAt is nearly equal to the 
> > Duration, so value of LastUpdated will be adjusted near time 
> > of CurrentTime or Duration should be corrected.
> > 
> > 
> > And I'd like to clarify the meaning of "ResetAt" value in 
> > case of "Interval".
> > 
> > From line #4801 to 4803,
> > > On the other hand, the management service may report the data as
> > occurring
> > over an interval of time. 
> > > In that case, the ResetAt attribute is optional, and the 
> LastUpdated
> > attribute should not be used. 
> > 
> > I understand that value of ResetAt attribute means the 
> > beginning time of this interval. Is that correct?
> > 
> > Regards,
> > ----
> > Mitsunori SATOMI (mailto:Mitsunori.Satomi@hds.com)
> >   Director, Advanced Software Architect
> >     Hitachi Data Systems Corporation 
> > 
> > 
> ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS 
> > TC that generates this mail.  You may a link to this group 
> > and all your TCs in OASIS
> > at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> > oups.php 
> > 
> > 
> > 
> ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS 
> > TC that generates this mail.  You may a link to this group 
> > and all your TCs in OASIS
> > at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> > oups.php 
> > 
> > 
> > 
> 
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]