Subject: RE: npmps-04bis

From: [email-masked]
Date: Thu, 28 Dec 2000 11:25:46 +0200

My intention was indeed to say that the _error_ in incT is preferably
negligible in a realistic measurement setup.

This correction applies to my explanation, and does not - in my
understanding - require any changes to the draft.

	BR,
		Vilho

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
 Vilho Räisänen                           
 [email-masked]                 
 Senior research engineer                 
 Nokia Research Center, Helsinki, Finland 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

> -----Original Message-----
> From: EXT Grotefeld Glenn-cecl03 [mailto:[email-masked]]
> Sent: 27. December 2000 17:13
> To: [email-masked]'; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: npmps-04bis
> 
> 
> 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 
> ~%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> ~
> ~
>