Subject: RE: npmps-04bis

From: Grotefeld Glenn-cecl03 <[email-masked]>
Date: Wed, 27 Dec 2000 09:13:23 -0600

Vilho,

Thank you for the update.  Unfortunately, I got the to end of your note and found this:

"Thus, I find it a bit difficult to justify adding a mention of real
application behaviour in this context. In my view, the goal should be that
incT is (for practical purposes) negligible."

It appears that something may have been left out of this sentence, possibly from the earlier discussion about errors in incT.  For Voice over IP (VoIP)and interactive multi-media applications, incT is nominally 20ms with a desired one-way delay on the order of 100ms.  On this scale, I would consider incT non-negligible.

Glenn Grotefeld

Motorola, Inc.
[email-masked]
US  847 576-5992
      847 538-7455  FAX

~-----Original Message-----
~From: [email-masked] [mailto:[email-masked]]
~Sent: Friday, December 22, 2000 4:42 AM
~To: [email-masked]
~Cc: [email-masked]; G.Grotefeld; [email-masked]; [email-masked];
[email-masked]
~Subject: npmps-04bis
~
~
~Dear IPPMers,
~
~please find attached the version -04bis of the npmps draft. 
~Thanks to Al &
~Glenn for comments. The following changes to -04 have been made:
~
~- I got rid of the the spurious month names due to Emacs' 
~case-insensitive
~search & replace algorithm. Indeed, these JUNE have caused 
~some confusion.
~- I implemented Al's refinement into 4.6. and added some more 
~text into incT
~error bullet pt. The section now reads
~
~   The description of any specific measurement method should include an
~   accounting and analysis of various sources of error or uncertainty.
~   The Framework document [1] provides general guidance on this point, 
~   but we note here the following specifics related to periodic
~   streams and delay metrics:
~
~   +  Error due to variation of incT. The reasons for this can be e.g.
~      uneven process scheduling, possibly due to CPU load.
~   +  Errors or uncertainties due to uncertainties in the clocks of the
~      MP(Src) and MP(Dst) measurement points.
~   +  Errors or uncertainties due to the difference between 'wire time'
~      and 'host time'.
~
~Earlier during the e-mail thread, Al commented that also real 
~sources of
~periodic streams may (and do) exhibit variation in 
~transmission times. This
~is true, but incorporation of intentional deviations from 
~periodic behaviour
~into the actual measurement metrics would result in a quite complex
~construct. Basically, a (public domain) source should be cited for
~definitive research results on "typical" variations due to O/S or
~application. This should then be mapped into a corresponding metrics
~description and so forth.
~
~Thus, I find it a bit difficult to justify adding a mention of real
~application behaviour in this context. In my view, the goal 
~should be that
~incT is (for practical purposes) negligible.
~
~Season's greetings,
~
~	Vilho
~
~%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
~ Vilho Räisänen                           
~ [email-masked]                 
~ Senior research engineer                 
~ Nokia Research Center, Helsinki, Finland 
~%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
~
~