Subject: [TICTOC] Section headings for requirements document

From: "STUART VENTERS" <[email-masked]>
Date: Mon, 14 Apr 2008 10:28:40 -0500

Yaakov, etal:

I'm not sure if the oscillator stuff should be part of a requirements document either,
  but I think it's a necessary part of the inputs to the spec process.

Consider what is needed to have a discussion on packet rates:
Assuming implementations are perfect with respect to timestamping and algorithm.
The oscillator stability, coupled with the system accuracy requirement
    says how long you can wait between updates.
This coupled with the packet path statistics
   determines the minimum update rate.

Building an accurate timing transfer system appears to be a tradeoff involving an assortment of issues.
    The list will grow, but it includes:
	0) The accuracy requirement for the application, both absolute to UTC and relative wander.
	1) The update rate available to the client.
	2) The packet delay statistics of the packet path, including the probability of low delay packets.
	3) The characteristics of on path support in the packet path.
	4) The stability of common local references available to the client.
	5) The characteristics of common timestamping methods.
	6) The characteristics of control algorithms available to the client implementer.
	
To make good choices for precision timing, we need a quorum of folks versed in the whole list.  
At the last IETF, the presentation on on-path support seemed particularly productive towards getting this quorum.

For the oscillator item, I don't speak oscillator, but I have been gathering data on an assortment for the last few weeks.  If there is an oscillator expert who would like to talk off line, I can show what I have and we can decide if it would be useful to publish the data to the list.

Regards,

Stuart Venters

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of [email-masked]
Sent: Monday, April 14, 2008 7:19 AM
To: [email-masked]
Subject: TICTOC Digest, Vol 20, Issue 23

Send TICTOC mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/tictoc
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of TICTOC digest..."

Today's Topics:

   1. Re:  Section headings for requirements document (Yaakov Stein)

----------------------------------------------------------------------

Message: 1
Date: Mon, 14 Apr 2008 15:19:18 +0300
From: "Yaakov Stein" <[email-masked]>
Subject: Re: [TICTOC] Section headings for requirements document
To: "Alexander Vainshtein" <[email-masked]>
Cc: Ronen Sommer <[email-masked]>, [email-masked]
Message-ID:
	<[email-masked]>
Content-Type: text/plain; charset="us-ascii"

Sasha
 
There is a direct link between, on the one hand 
 - the stability of the local frequency reference
 - the update rate, and 
 - the amount of frequency information you get from each update (or
conversely the noise on the frequency information)
and, on the other hand
 - the frequency accuracy obtainable.
 
There is furthermore a direct link between 
 - the frequency accuracy of the (disciplined) local reference, and
 - the update rate
and
 - the time accuracy obtainable.
 
These are physical constraints, and are independent on the algorithm
used.
 
If this is what you meant, then I fully agree.
 
These points are indeed important to consider when planning a timing
distribution system,
but I still don't see how they fit into a requirements document
(unless we are placing requirements on basic physics and math ...)
 
Y(J)S

________________________________

From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Monday, April 14, 2008 1:25 PM
To: Yaakov Stein
Cc: [email-masked]; Ronen Sommer
Subject: RE: Section headings for requirements document

Yaakov,
Actually I've had in mind something else.
 
The NTP people have been stating for quite some time (and, presumably,
correctly), that NTP has been optimized to cope with a certain type of
the local oscillator meeting some minimal requirements. And my gut
feeling has always been that NTP could  produce better results with a
better local oscillator (probably with a different algorithm).
 
Hence I suspect (and I may be quite wrong here), that there is a
theoretical limit of what you can achieve with clock recovery assuming
given the quality of the local local oscillator (and, possibly, some
other measurable parameters, .e. frequency of the time-carrying
packets).
 
If (and it is a BIG IF) such kind of a dependency exists, then exposing
it would be surely be beneficial (similar to the energy conservation law
that prevents some people from trying to build perpetuum mobile and some
others - from the need to find specific bugs in the perpetuum mobile
designs:-).
 
What do you think?
 
Regards,
            Sasha

________________________________

	From: Yaakov Stein [mailto:[email-masked]] 
	Sent: Monday, April 14, 2008 1:00 PM
	To: Alexander Vainshtein
	Cc: [email-masked]; Ronen Sommer
	Subject: RE: Section headings for requirements document

	Sasha
	 
	Yes, I agree that the issue is an important one from the point
of view of performance
	(certainly the performance of frequency recovery will depend on
the local oscillator)
	but I am not sure how it fits into a requirements draft.
	 
	I don't see stating that the application requirements change
based on the frequency reference available.
	 
	Perhaps we can add to the algorithm section that if a good
frequency reference is available,
	then time clients should make good of it.
	 
	Do you have any other idea ?
	 
	Y(J)S

________________________________

	From: Alexander Vainshtein
[mailto:[email-masked]] 
	Sent: Monday, April 14, 2008 11:23 AM
	To: Yaakov Stein
	Cc: [email-masked]; Ronen Sommer
	Subject: RE: Section headings for requirements document

	Yaakov and all,
	Maybe it is worth to add a "Local oscillator dependencies"
section to the table of contents?
	 
	While TICTOC definitely shall not develop anything in this area,
understanding these dependencies (and, possibly, aligning the
expectations of the quality of the recovered clocks with the
requirements for the local oscillator quality) would be IMHO highly
beneficial for the community.
	For those who doubt whether such dependencies exist: consider
two extreme uses cases:

	*	A client with a locally available PRC 
	*	A client without any local reference clock.

	(But do not expect me to write this section; rather, count me in
the community that would benefit from such a section:-).
	 
	Regards,
	           Sasha

________________________________

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Yaakov Stein
		Sent: Monday, April 14, 2008 10:46 AM
		To: [email-masked]
		Subject: [TICTOC] Section headings for requirements
document

		Hi all, 
		 
		Stewart and I just finished merging the problem
statement and Kurt's ITP draft, 
		together with all the requirements statements we found
in presentations
		given at the BOFs, and came up with the following
proposed table of contents
		for the TICTOC requirements draft.
		 
		We suggest starting from these headings at the interim
meeting in June. 
		We encourage all of you to provide text for these
sections.
		Of course, suggestions for changes in the sections or
subsections are also welcome.
		 
		Y(J)S
		 
		========================================================
		1 Introduction
		2 Terminology
		3 Application requirements 
		  3.1 Time Service
		  3.2 Frequency Service
		4 Problems with Existing Time and Frequency Distribution
Mechanisms  
		  4.1 Non-packet distribution
		  4.2 Packet distribution
		5 Time scale issues
		  5.1 Time definition and translations (TAI, UTC, local
time)
		  5.2 Required accuracy
		  5.3 Resolution
		  5.4 Time format
		  5.5 Handling discontinuities (leap seconds,
monotonicity, handover)
		6 Network dependencies
		  6.1 Layers and encapsulations (including MPLS)
		  6.2 Path asymmetry
		  6.3 Handling congestion
		  6.4 On-path support
		7 Network topology
		  7.1 Autodiscovery
		  7.2 Optimal path selection
		8 Protocol requirements
		  8.1 Scalability (memory, computation and rate
constraints)
		  8.2 Service requests (accuracy, update rate, etc.)
		  8.3 Compatibility
		  8.4 Extensibility (TLVs, etc.)
		  8.5 Profiling
		  8.6 Packet format
		  8.7 Algorithm independence
		  8.8 Multicast, unicast, anycast
		  8.9 Robustness
		9 Host API
		10 Algorithms
		  10.1 Best Master
		  10.2 Frequency locking
		  10.3 Ranging
		  10.4 Mitigation (minimum gating, etc.)
		  10.5 Clustering and combining
		  10.6 Disciplining
		11 Performance measurement and management
		12 OAM
		13 Network management
		14 Supporting protocols (DNS, DHCP, IGP)
		15 Security Considerations
		  15.1 Client authentication 
		  15.2 Server authentication
		  15.3 Secure traceability

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ietf.org/pipermail/tictoc/attachments/20080414/44fa9dbb/attachment.htm 

------------------------------

_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc

End of TICTOC Digest, Vol 20, Issue 23
**************************************
_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 15 Apr 2008 08:47:10 +0300

Stuart (and all),
I agree that the oscillator stuff is and input to the spec process, not part of the requirements per se.
At the same time I would very much like to have ALL the relevant inputs to the spec process
in a single document and not distributed. If this makes somebody feel better,
this stuff can be placed in an annex and not in the main body of the requirements document.

But I firmly believe that we should try to preserve (as much as possible) to keep in line
with the IETF tradition fo presenting not just "how to" but the "why" side of the protocols
we are going to develop. And the oscillator stuff definitely is part of this.

Regards,
              Sasha

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of STUART VENTERS [[email-masked]]
Sent: Monday, April 14, 2008 6:28 PM
To: [email-masked]
Subject: [TICTOC] Section headings for requirements document

Yaakov, etal:

Regards,

Stuart Venters

-----Original Message-----

Today's Topics:

Message: 1

Sasha

Y(J)S

Yaakov,

What do you think?

Regards,
            Sasha

        Sasha

        Y(J)S

        Yaakov and all,

        Regards,
                   Sasha

                Hi all,

                Y(J)S

---

From: "STUART VENTERS" <[email-masked]>
Date: Tue, 15 Apr 2008 11:30:16 -0500

All,

With regards measuring the stability of oscillators,
  one figure of merit is how long the oscillator can keep you going between measurements.

(In other words,
  if you use past measurements to estimate the local reference,
  then how long in the future can you provide time from the reference without more measurements.)

The code below may be useful in quantifying this,
  but the methodology needs to be reviewed first.

Regards,

Stuart

ps. We probably could use an FTP site for data files if this direction seems useful.

// CalcAllen.c  calculate oscillator statistics from a set of frequency measurements
//
//   Written by Stuart Venters.
//     Permission to use at your own risk for learning about time and furthering the TICTOC effort hereby granted.
//     Other rights reserved.
//
//   usage: CalcAllen inputfreqfile {output.csv} >logfile
//
//   Input is a text file with floating point frequency measurements white space delimited (for fscanf(%lf))
//       Frequencies are assumed to be measured on 1 second intervals
//
//   Output is a .csv file suitable for graphing
//        There is a row for each averaging interval
//                 (10**0 .. 10**N seconds, depending on how much data is there)
//        The columns are as follows:
//           Averaging interval in seconds
//           Allen Variance (RMS interval to interval normalized delta Freq)
//           Max time offset (interval seconds * (MAX abs interval to interval normalized delta Freq seen)
//           Standard deviation of normalized frequency from average
//           Average abs interval to interval normalized delta Freq
//    
//   
//   Hopefully, the Max time offset tells us how long we can wait between NTP measurements
//          for a given accuracy requirement.
//
//   Warning, although it makes pretty graphs, the math in this program could use peer review.
//   
//   

#include <stdio.h>
#include <io.h>
#include <assert.h>
#include <fcntl.h>
#include <string.h>
#include <math.h>

#define MAX_DATA 3600*24*10   /* 10 days worth */

// the raw frequency readings
double Data[MAX_DATA];
long DataCount = 0;

double M0;
double M1;
double M2;

double MinFreq;
double MaxFreq;
double AvgFreq;
double StdDev;

FILE *Csv = 0;

// read in the data file
int ReadData( char * Fname ) {
	double Temp;
	FILE *F = fopen( Fname, "r");
	if( ! F ) {
		printf("Unable to open '%s' for reading.\n", Fname );
		return(0);
	}

	while( 1 == fscanf(F," %lf", &Temp )) {
		Data[DataCount++] = Temp;
		if( DataCount >= MAX_DATA ) break;
	}
	printf("Found %d samples.\n", DataCount );

	return( DataCount > 1 );

}

// calculate the average frequency
void CalcAverages ( void ) {
	long i;
	double Var=0;
	double Min, Max;
	M0 = M1 = M2 = 0;

	// calculate moments and average
	for( i=0; i<DataCount; i++) {
		double T = Data[i];
		M0++;
		M1 += T;
		M2 += (T * T);
		if( i==0) {
			MinFreq = T;
			MaxFreq = T;
		} else {
			if( T < MinFreq) MinFreq = T;
			if( T < MaxFreq) MaxFreq = T;
		}
		if( i == 0 ) {
			Min = T;
			Max = T;
		} else {
			if( T < Min ) Min = T;
			if( T > Max ) Max = T;
		}
	}
	AvgFreq = M1 / M0;

	for( i=0; i<DataCount; i++) {
		double T = Data[i];
		double D = T - AvgFreq;
		Var += (D * D);
	}
	Var /= (M0 - 1);

    //Var = (M2 - M1*M1/M0)/(M0-1);
	//Var = M2/M0 - (M1*M1)/(M0*M0);
	StdDev = sqrt( Var );

	printf(" M0 = %20g, M1 = %20g, M2 = %20g.\n", M0, M1, M2);
	printf(" Min=%20.10lf, Max = %20.10lf.\n", Min, Max);
	printf("Average Freq =       %20.10lf.\n", AvgFreq);
	printf("Standard Deviation = %20.10lf.\n", StdDev);

}

void DoAllen( long Stride ) {
	long i;
	double Sum = 0;
	double Count = 0;
	double Allen;
	double Max;
	double Var = 0;
	double T;
	double Avg = 0;

	for( i=0; i<DataCount; i+= Stride ) {    // boxcar averages
	//for( i=0; i<DataCount; i+= 1 ) {         // moving averages
		// decide where the data is
		long i0 = i;
		long i1 = i0 + Stride;
		long i2 = i1 + Stride;
		long j;
		double Sum1 = 0;
		double Sum2 = 0;
		double Diff;

		if( i2 > DataCount) break;

		// calculate average frequency for 2 stride long blocks
		for( j=i0; j<i1; j++) Sum1 += Data[j];
		for( j=i1; j<i2; j++) Sum2 += Data[j];
		Sum1 /= Stride;
		Sum2 /= Stride;

		// calculate a normalized difference
		Diff = (Sum1 - Sum2)/AvgFreq;
		if( Diff < 0) Diff = - Diff;

		// keep up with max difference seen
		if( Count == 0) {
			Max = Diff;
		} else {
			if( Diff > Max) {
				Max = Diff;
			}
		}

		// add to accumulator
		Sum += (Diff * Diff);
		Avg += Diff;
		T = (Sum1/AvgFreq) - 1;
		Var += (T * T);
		Count += 1;
	}

	if( Count < 2 ) return;

	// calculate allen variance, etc
	Allen = sqrt(Sum/(Count*2));
	Var /= (Count-1);
	Var = sqrt( Var );
	Avg /= Count;

	Max *= Stride;

	// output the results
	printf("Allen Var(%d) = %10.5e. Max*Stride = %10.5e. StdDev = %10.5e AvgAbsDiff = %10.5e (Count=%f).\n",
		               Stride, Allen, Max, Var, Avg, Count);
	fflush( stdout );

	if( Csv ) fprintf(Csv, "%d, %10.5e, %10.5e, %10.5e, %10.5e, \n", Stride, Allen, Max, Var, Avg );

}

int main( int argc, char * argv[] ) {
	long g;

	// open the log file
	assert( argc >= 2 );
	assert( ReadData( argv[1] ));
	fflush( stdout );

	if( argc >= 3 ) {
		Csv = fopen( argv[2], "w");
		fprintf(Csv, "Interval, AllenVariance, MaxTimeOffset, StdDev, AverageAbsDelta,\n");
	}

	// calculate averages
	CalcAverages();
	fflush( stdout );

	// calculate allen variances
	for( g=1; g<1000000; g*= 10 ) {
		DoAllen( g * 1);
		DoAllen( g * 2);
		DoAllen( g * 3);
		DoAllen( g * 5);
		DoAllen( g * 7);
	}

	if( Csv) fclose( Csv);
	return(0);

}