perfsonar development work

Author: verena
Date: 2007-10-09 06:20:58 -0400 (Tue, 09 Oct 2007)
New Revision: 286

Modified:
   branches/owd/rnc/summary.rnc
Log:
See comments in summary.rnc:
Some points to be discussed further.


Modified: branches/owd/rnc/summary.rnc
===================================================================
--- branches/owd/rnc/summary.rnc        2007-10-08 19:32:37 UTC (rev 285)
+++ branches/owd/rnc/summary.rnc        2007-10-09 10:20:58 UTC (rev 286)
@@ -83,6 +83,19 @@
 # If you want to move this into 'data' somehow, I would be ok with that.
 # But, it is not metadata.
 #
+# VV begin:
+# The idea was to ask for a certain percentile, which (like other 
+# aggregations) can be computed by the service.
+# I think, it does not make sense, to report a percentile in the data 
+# section without giving the possibility to say _which_ percentile should
+# be reported.
+# So either we have this as a parameter and a corresponding value in the 
+# data section, ot we do not have it at all.
+# I tend to the latter (if the need arises, we can add this later on and
+# still be downwards compatible). As you said, this can also be computed 
+# by the buckets.
+# VV end.
+#
 #        element nmwg:parameter { 
 #                attribute name { "percentile" } &
 #                (
@@ -105,6 +118,14 @@
 #                        attribute value { xsd:unsignedInt } |
 #                        xsd:unsignedInt
 #                )
+#
+# VV begin:
+# this was a typo: "sub_count" would have been the right word. This
+# would correspond to the "groupsize" in our (hades) case. I'm not
+# sure about the name, though. As we are sending packet trains, it
+# represents the number of packets in one train.
+# VV end.
+# 
 # We may want to include other information about the schedule here,
 # things like sending rate.
         }
@@ -138,13 +159,39 @@
 # would not allow for aggregation of the data.
 #end-jwb
 #
+# VV begin:
+# in our implementation at the moment, you can specify the port numbers. It
+# is possible (but unlikely) to have two measurements on the same route with
+# same parameters but running on different ports (I'm quite sure that this
+# would not make sense unless you are also changing some more parameters
+# like packet size, in which case it would be unambiguousl even if you do not
+# know the port number). We could maybe take this in as an optional parameter
+# in the metadata set, but leave it out in the summary...
+# VV end.
+# 
 # . same goes for "sync" and "sent"
 #
 #start-jwb
 # sync just indicates if both clocks were synchronized at the time of the 
test.
 #
+# VV begin:
+# we have a problem there, as we are not reporting the sync status in our
+# data files
+# VV end.
+#
 # sent is required for most of the rest to make any sense. Lost, dups are
 # really only useful if you know how many packets were sent...
+#
+# VV begin:
+# as we (hades)are sending packet trains, all our statistics are relating to 
+# one packet train. The number of packets in this train is given by the 
+# somewhat ominous styled "sub_count" (see above, should be discussed).
+# if we are going to give out a summary for the whole time-span, we have to
+# change quite some things in our output format. 
+# Visualisations like psUI rely on the per-train summarization to show a 
+# continuous graph over a longer time span.
+# VV end.
+#
 #end-jwb
 #
 # . added ipdv (IP delay variation aka jitter)
@@ -155,6 +202,13 @@
 # determined based on the 'buckets' that are here.
 #end-jwb
 #
+# VV begin:
+# the term "jitter" is wrong here (sorry my mistake), what we are reporting
+# conforms to the definiton of ipdv in the IPPM RFC (at least I think so.
+# this needs maybe some verification). Again, psUI is visualising this kind
+# of data, so we should report it. 
+# VV end.
+#
 # . possible other bucket definitions?
 #
 #start-jwb
@@ -163,10 +217,26 @@
 # By convention, we could specify that the 'sync' value of StartTime
 # indicates the sync status.
 #
+# VV begin:
+# I checkes nmtime.rnc and found that the nmtime element needs to have
+# an absolut timestamp. And there we have a problem: a delay value is only
+# a duration. We are reporting absolut timestamps per packet train, not per
+# delay. Of course we can just take this timestamp but then we are indicating
+# something wrong, as it is (maybe) not the timestamp of (e.g.) the maximum
+# delay measurend in the group of packets.
+# This timestamp is already reported in the form of an nmtime element (see 
+# StartTime and EndTime elements).
+# So there is no added benefit (from our point of view) to make the delay
+# values real nmtime elements. And it would not add more information
+# as we do not have more. On the other hands, we would have considerable
+# effort, to report the real timestamps.
+# VV end.
+#
 # I'm not sure about the port numbers...  I'm ok with them being optional
 # 'data', but I would not want them in the metadata part. They vary too
 # much.
 #end-jwb
+# VV: port numbers: see above.
 #
 SummaryDatum =
         element summary:datum {
@@ -176,6 +246,12 @@
 # If is is known that any of the packet measurements were made with
 # unsynchrnonized clocks, then the synchronization attribute of the
 # StartTime SHOULD be set to False.
+#
+# VV begin:
+# I'm OK with that, and I think it is sufficient to report the sync status
+# for the whole session (or per packet train, in our case).
+# VV end.
+#
                 StartTime &
                 EndTime &
                 (