Yesterday's audio

From yaakov_s@rad.com Mon Mar 9 08:55:57 2009 Return-Path: X-Original-To: tictoc@core3.amsl.com Delivered-To: tictoc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA6563A6C78 for ; Mon, 9 Mar 2009 08:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2ztsaj5-hsL for ; Mon, 9 Mar 2009 08:55:55 -0700 (PDT) Received: from antivir1.rad.co.il (mx1-q.rad.co.il [80.74.100.136]) by core3.amsl.com (Postfix) with ESMTP id 8D4D128C1E6 for ; Mon, 9 Mar 2009 08:55:52 -0700 (PDT) Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir1.rad.co.il with ESMTP; 09 Mar 2009 17:56:26 +0200 Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Mon, 9 Mar 2009 17:56:25 +0200 From: Yaakov Stein To: "tictoc@ietf.org" Date: Mon, 9 Mar 2009 17:56:22 +0200 Thread-Topic: IETF-74 slots Thread-Index: Acmgz5exeaxzdWiRT16xc/25USQwbQ== Message-ID: <424CDC689E5CEF4D9FEADE56A378D9220217E3CB4E@exrad4.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_424CDC689E5CEF4D9FEADE56A378D9220217E3CB4Eexrad4adradco_" MIME-Version: 1.0 Subject: [TICTOC] IETF-74 slots X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 15:55:58 -0000 --_000_424CDC689E5CEF4D9FEADE56A378D9220217E3CB4Eexrad4adradco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, The mailing list has been very quiet recently, but I know that our face-to-face meeting will kick things off again. We will be meeting on Monday afternoon, the day being chosen in order to accommodate those who are will be attending the ITU interim meeting. Please send requests for slots ASAP, as we need to send an initial agenda by Wednesday. Y(J)S --_000_424CDC689E5CEF4D9FEADE56A378D9220217E3CB4Eexrad4adradco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

The mailing list has been very quiet recently,

but I know that our face-to-face meeting will kick thi= ngs off again.

We will be meeting on Monday afternoon,

the day being chosen in order to accommodate those who= are

will be attending the ITU interim meeting.<= /p>

Please send requests for slots ASAP,

as we need to send an initial agenda by Wednesday.

Y(J)S

--_000_424CDC689E5CEF4D9FEADE56A378D9220217E3CB4Eexrad4adradco_-- From Silvana.Rodrigues@Zarlink.Com Thu Mar 12 07:52:33 2009 Return-Path: X-Original-To: tictoc@core3.amsl.com Delivered-To: tictoc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 131513A6864 for ; Thu, 12 Mar 2009 07:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkjOsznHAVrR for ; Thu, 12 Mar 2009 07:52:29 -0700 (PDT) Received: from semigate.zarlink.com (semigate.zarlink.com [209.226.172.67]) by core3.amsl.com (Postfix) with ESMTP id F3DA33A6BA7 for ; Thu, 12 Mar 2009 07:52:28 -0700 (PDT) Received: from ottmta01.zarlink.com (ottmta01 [134.199.14.110]) by semigate.zarlink.com (8.11.6+Sun/8.11.6) with ESMTP id n2CEqxT19626 for ; Thu, 12 Mar 2009 10:52:59 -0400 (EDT) To: yaakov_s@rad.com, stbryant@cisco.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.3 September 26, 2007 Message-ID: From: Silvana.Rodrigues@Zarlink.Com Date: Thu, 12 Mar 2009 10:52:42 -0400 X-MIMETrack: Serialize by Router on ottmta01/Zarlink(Release 7.0.3FP1|February 24, 2008) at 03/12/2009 10:52:58 AM, Serialize complete at 03/12/2009 10:52:58 AM Content-Type: multipart/alternative; boundary="=_alternative 0051BA8285257577_=" Cc: tictoc@ietf.org Subject: [TICTOC] TICTOC agenda X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 14:52:33 -0000 This is a multipart message in MIME format. --=_alternative 0051BA8285257577_= Content-Type: text/plain; charset="US-ASCII" Yaakov and Stewart, I looked at the TICTOC agenda and it reads: Progress on the requirements draft (Silvana) 15 min http://tools.ietf.org/html/draft-rodrigues-lindqvist-tictoc-req-01 I have uploaded rev. 2 of the requirements document, so the agenda is pointing to the wrong document.Rev. 2 can be downloaded from: http://tools.ietf.org/html/draft-rodrigues-lindqvist-tictoc-req-02 Best Regards, Silvana --=_alternative 0051BA8285257577_= Content-Type: text/html; charset="US-ASCII"
Yaakov and Stewart,

I looked at the TICTOC agenda and it reads:
Progress on the requirements draft (Silvana) 15 minhttp://tools.ietf.org/html/draft-rodrigues-lindqvist-tictoc-req-01 I have uploaded rev. 2 of the requirements document, so the agenda is pointing to the wrong document.Rev. 2 can be downloaded from:

http://tools.ietf.org/html/draft-rodrigues-lindqvist-tictoc-req-02

Best Regards,

Silvana

--=_alternative 0051BA8285257577_=-- From yaakov_s@rad.com Thu Mar 12 07:55:59 2009 Return-Path: X-Original-To: tictoc@core3.amsl.com Delivered-To: tictoc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAB023A6A53 for ; Thu, 12 Mar 2009 07:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puRQDBWNO949 for ; Thu, 12 Mar 2009 07:55:58 -0700 (PDT) Received: from antivir2.rad.co.il (mx2-q.rad.co.il [80.74.100.144]) by core3.amsl.com (Postfix) with ESMTP id 963883A6901 for ; Thu, 12 Mar 2009 07:55:56 -0700 (PDT) Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir2.rad.co.il with ESMTP; 12 Mar 2009 16:56:33 +0200 Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Thu, 12 Mar 2009 16:56:32 +0200 From: Yaakov Stein To: "Silvana.Rodrigues@Zarlink.Com" , "stbryant@cisco.com" Date: Thu, 12 Mar 2009 16:56:30 +0200 Thread-Topic: TICTOC agenda Thread-Index: AcmjIkajtC4+2/yEQPWIM1qRzvRdzAAAGS2Q Message-ID: <424CDC689E5CEF4D9FEADE56A378D9220217F1ABB8@exrad4.ad.rad.co.il> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_424CDC689E5CEF4D9FEADE56A378D9220217F1ABB8exrad4adradco_" MIME-Version: 1.0 Cc: "tictoc@ietf.org" Subject: Re: [TICTOC] TICTOC agenda X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 14:56:00 -0000 --_000_424CDC689E5CEF4D9FEADE56A378D9220217F1ABB8exrad4adradco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Silvana Copy and paste error. I fixed it (and similarly the modules draft is 03 !) Y(J)S From: Silvana.Rodrigues@Zarlink.Com [mailto:Silvana.Rodrigues@Zarlink.Com] Sent: Thursday, March 12, 2009 16:53 To: Yaakov Stein; stbryant@cisco.com Cc: tictoc@ietf.org Subject: TICTOC agenda Yaakov and Stewart, I looked at the TICTOC agenda and it reads: Progress on the requirements draft (Silvana) 15 min http://tools.ietf.org/html/draft-rodrigues-lindqvist-tictoc-req-01 I have uploaded rev. 2 of the requirements document, so the agenda is point= ing to the wrong document.Rev. 2 can be downloaded from: http://tools.ietf.org/html/draft-rodrigues-lindqvist-tictoc-req-02 Best Regards, Silvana ---------- This email is confidential and may contain information that is privileged a= nd exempt from disclosure by law. If you have received it in error, please co= ntact the sender immediately by return email and then delete it from your system;= you should not copy it or disclose its contents to anyone. Emails are not secu= re and cannot be guaranteed to be error free as they can be intercepted, amend= ed, lost or destroyed, or contain viruses. Anyone who communicates with us by = email is taken to accept these risks. --_000_424CDC689E5CEF4D9FEADE56A378D9220217F1ABB8exrad4adradco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Silvana

Copy and paste error. I fixed it (and similarly the mo= dules draft is 03 !)

Y(J)S

From: Silvana.Rodrigues@Zarlink.Com [mailto:Silvana.Rodrigues@Zarlink.Com]
Sent: Thursday, March 12, 2009 16:53
To: Yaakov Stein; stbryant@cisco.com
Cc: tictoc@ietf.org
Subject: TICTOC agenda

Yaakov an= d Stewart,

I looked = at the TICTOC agenda and it reads:

Progress on the requirements draft (Silvana) 15 min
http://tools.ietf.org/html/draft-rodrigues-lindqvist-tictoc-req-01 I have uploaded rev. 2 of the requirements document, so the agenda is pointing to the wrong document.Rev. 2 can be downloaded from:http://tools.ietf.org/html/draft-rodrigues-lindqvist-tictoc-req-02<= /tt> Best Regards, Silvana

---------- This email= is confidential and may contain information that is privileged and exempt from disclosure by law. If you have received it = in error, please contact the sender immediately by ret= urn email and then delete it from your system; you sho= uld not copy it or disclose its contents to anyone. Emails are not se= cure and cannot be guaranteed to be error free as they= can be intercepted, amended, lost or destroyed, or co= ntain viruses. Anyone who communicates with us by emailis taken to accept these risks.

--_000_424CDC689E5CEF4D9FEADE56A378D9220217F1ABB8exrad4adradco_-- From RonenS@orckit.com Mon Mar 23 19:34:36 2009 Return-Path: X-Original-To: tictoc@core3.amsl.com Delivered-To: tictoc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C86803A697A for ; Mon, 23 Mar 2009 19:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.34 X-Spam-Level: X-Spam-Status: No, score=-0.34 tagged_above=-999 required=5 tests=[AWL=-2.260, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wENG7wRUbOhu for ; Mon, 23 Mar 2009 19:34:36 -0700 (PDT) Received: from tlvmail1.corrigent.com (unknown [213.31.203.2]) by core3.amsl.com (Postfix) with ESMTP id B88693A6B59 for ; Mon, 23 Mar 2009 19:34:35 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9AC29.2E9C0EBE" Date: Tue, 24 Mar 2009 04:32:40 +0200 Message-ID: <44F4E579A764584EA9BDFD07D0CA081304CF0DC2@tlvmail1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: bi-directional SyncE - Copper GBE Thread-Index: AcmsKM2gvgMZ/AQYQaerU25djIBrUw== From: "Ronen Solomon" To: X-Mailman-Approved-At: Tue, 24 Mar 2009 05:56:52 -0700 Cc: Rafi Ram Subject: [TICTOC] bi-directional SyncE - Copper GBE X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 02:34:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9AC29.2E9C0EBE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yaakov=20 =20 In the last meeting you raised the issue of supporting bi-directional SyncE on Copper GBE. Can you please re-emphasis the problem and the proposed solution. =20 Best regards =20 Ronen=20 ------_=_NextPart_001_01C9AC29.2E9C0EBE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yaakov In the last meeting you raised the issue of = supporting bi-directional SyncE on Copper GBE. Can you please re-emphasis the problem and the = proposed solution. Best regards Ronen ------_=_NextPart_001_01C9AC29.2E9C0EBE-- From stuart.venters@adtran.com Tue Mar 24 07:50:11 2009 Return-Path: X-Original-To: tictoc@core3.amsl.com Delivered-To: tictoc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22BB528C0E5 for ; Tue, 24 Mar 2009 07:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfiwPl8ThH1H for ; Tue, 24 Mar 2009 07:50:10 -0700 (PDT) Received: from p02c12o143.mxlogic.net (p02c12o143.mxlogic.net [208.65.145.76]) by core3.amsl.com (Postfix) with ESMTP id 3449D28C2E0 for ; Tue, 24 Mar 2009 07:50:10 -0700 (PDT) Received: from unknown [76.164.174.99] (EHLO EXV1.corp.adtran.com) by p02c12o143.mxlogic.net (mxl_mta-6.1.1-1) with ESMTP id 453f8c94.2721545104.93952.00-018.p02c12o143.mxlogic.net (envelope-from ); Tue, 24 Mar 2009 08:51:01 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9AC8F.F22A8F33" Date: Tue, 24 Mar 2009 09:50:59 -0500 Message-ID: <8F242B230AD6474C8E7815DE0B4982D70B99D6FE@EXV1.corp.adtran.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Yesterday's audio Thread-Index: Acmsj/JLnACEIJ45T0uGZjVQ2183Cw== From: "STUART VENTERS" To: X-Spam: [F=0.2000000000; S=0.200(2009020301)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.99] Subject: [TICTOC] Yesterday's audio X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 14:50:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9AC8F.F22A8F33 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I never was able to get yesterday's audio to work. Is there a URL for an archive of the audio for yesterday's meeting? ------_=_NextPart_001_01C9AC8F.F22A8F33 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yesterday's audio I never was able to get = yesterday's audio to work. Is there a URL for an archive = of the audio for yesterday's meeting? ------_=_NextPart_001_01C9AC8F.F22A8F33-- From karen.odonoghue@navy.mil Tue Mar 24 08:55:02 2009 Return-Path: X-Original-To: tictoc@core3.amsl.com Delivered-To: tictoc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E34F23A6990 for ; Tue, 24 Mar 2009 08:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvLuEOX7b1rV for ; Tue, 24 Mar 2009 08:55:02 -0700 (PDT) Received: from gate2-norfolk.nmci.navy.mil (gate2-norfolk.nmci.navy.mil [138.162.0.42]) by core3.amsl.com (Postfix) with ESMTP id EE1E23A682B for ; Tue, 24 Mar 2009 08:55:01 -0700 (PDT) Received: from NAEANRFKEG01.nadsusea.nads.navy.mil ([10.16.0.162]) by gate2-norfolk.nmci.navy.mil with Microsoft SMTPSVC(5.0.2195.6872); Tue, 24 Mar 2009 11:11:31 -0500 Received: from naeanrfkeb04v.nadsusea.nads.navy.mil ([10.16.20.107]) by NAEANRFKEG01.nadsusea.nads.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Tue, 24 Mar 2009 11:55:52 -0400 Received: from naeamilleb03v.nadsusea.nads.navy.mil ([10.18.183.76]) by naeanrfkeb04v.nadsusea.nads.navy.mil with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 11:55:52 -0400 Received: from naeamillez05v.nadsusea.nads.navy.mil ([10.18.183.82]) by naeamilleb03v.nadsusea.nads.navy.mil with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 10:55:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Mar 2009 10:55:33 -0500 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0045_01C9AC77.6FAC5360" Message-ID: In-Reply-To: <8F242B230AD6474C8E7815DE0B4982D70B99D6FE@EXV1.corp.adtran.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: recurring timeslot for teleconferences Thread-Index: Acmsj/JLnACEIJ45T0uGZjVQ2183CwACJcmw References: <8F242B230AD6474C8E7815DE0B4982D70B99D6FE@EXV1.corp.adtran.com> From: "Odonoghue, Karen F CIV NSWCDD, W23" To: X-OriginalArrivalTime: 24 Mar 2009 15:55:38.0436 (UTC) FILETIME=[F9E5C040:01C9AC98] Subject: [TICTOC] recurring timeslot for teleconferences X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 15:55:03 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0045_01C9AC77.6FAC5360 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks, During yesterday's discussion we decided to try again to have recurring teleconferences to help establish momentum for the efforts. The suggested time is the first and third Thursday's of the month, 1100 Eastern Daylight Time, for one hour maximum. Karen > -----Original Message----- > From: tictoc-bounces@ietf.org > [mailto:tictoc-bounces@ietf.org] On Behalf Of STUART VENTERS > Sent: Tuesday, March 24, 2009 10:51 > To: tictoc@ietf.org > Subject: [TICTOC] Yesterday's audio > > I never was able to get yesterday's audio to work. > > Is there a URL for an archive of the audio for yesterday's meeting? > > ------=_NextPart_000_0045_01C9AC77.6FAC5360 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQhTCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEMjCCAxqgAwIBAgIBGzANBgkqhkiG9w0BAQUFADBb MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAK BgNVBAsTA1BLSTEWMBQGA1UEAxMNRG9EIFJvb3QgQ0EgMjAeFw0wNjA2MTQxNjM4NDVaFw0xMjA2 MTQxNTM4NDVaMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNV BAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMTUwgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBALVplZ+ltuSfPPOfANWaFQf81jmu2da8VnbAJuA7j4GpaWaKSivC tUpiUV7X+3qA40EWmsNm8+H8hIp8h/3Lu8gqpr3WF3NVGZeQe0SE/L9obop1agTOSBnTqsK5AB5k VIhfO+Sb8MhHFVLfK8TKZaDBbAOvS2yD1rbpOGUWpRCDAgMBAAGjggGBMIIBfTAOBgNVHQ8BAf8E BAMCAYYwHwYDVR0jBBgwFoAUSXS7DF66ev4CVO97oMaVxgmAcJYwHQYDVR0OBBYEFJW1jHirnVYz PPRIo5xY7bFkioqeMAwGA1UdJAQFMAOAAQAwDwYDVR0TAQH/BAUwAwEB/zAwBgNVHSAEKTAnMAsG CWCGSAFlAgELBTALBglghkgBZQIBCwkwCwYJYIZIAWUCAQsKMIHZBgNVHR8EgdEwgc4wOKA2oDSG Mmh0dHA6Ly9jcmwuZ2RzLmRpc2EubWlsL2dldGNybD9Eb0QlMjBSb290JTIwQ0ElMjAyMIGRoIGO oIGLhoGIbGRhcDovL2NybC5nZHMuZGlzYS5taWwvY24lM2REb0QlMjBSb290JTIwQ0ElMjAyJTJj b3UlM2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeTANBgkqhkiG9w0BAQUFAAOCAQEAivmtXKcXvMhM maUqn2rbLInqvnP5k7arBNP7ZNCixWqFx8geDysXKf2nGqg56j98pJOru320IGN5fwFGJIqoqV4u MkxRhtmP9MJf3JLS30+TCMm5oMVyXHjLlgduyQsAeBe++eb5taWIfoHtR4+oi/76m0WCK0Jb+CGl VRLWFrTzzWqbhtisMyUUDhU5kTZMwN0IsbhYdj57g2MaF9lGC51D8c7VZzMRmFTCeFEnVI0rN5sJ Oz1KvwcqpnsU+BzjHv0d2GJnmariD8ymhs0qfad6vZcT5K/38Ylw7R3DJ0G2CEVwMIni16IO1mnd 1cRC1b6yy7Z2wWuZBF6+mfD1rDCCBEQwggOtoAMCAQICAzFgbTANBgkqhkiG9w0BAQUFADBdMQsw CQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNV BAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTE1MB4XDTA4MDcwMzAwMDAwMFoXDTExMDcw MjIzNTk1OVoweDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UE CxMDRG9EMQwwCgYDVQQLEwNQS0kxDDAKBgNVBAsTA1VTTjElMCMGA1UEAxMcT0RPTk9HSFVFLktB UkVOLkYuMTIzMDYxMjM5NzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1e3YkEVFVl9E9rGu IHaMvyh2IhOgAeqDIb2VebH1D67Bx4ycEAtlLZAQXTIua8f8SUbFFt6ZBvPRyTs0A9aKVmGqBrII Nf+tSDg0VWT7/vQ+ZZ0zHAxYDiG5OyLh0qAj9sbaZpN2cqz7Va86dohNdU5hXBUuLRk2j2YDQwwn iXUCAwEAAaOCAfUwggHxMB8GA1UdIwQYMBaAFJW1jHirnVYzPPRIo5xY7bFkioqeMIHVBgNVHR8E gc0wgcowNKAyoDCGLmh0dHA6Ly9jcmwuZGlzYS5taWwvZ2V0Y3JsP0RPRCUyMEVNQUlMJTIwQ0Et MTUwgZGggY6ggYuGgYhsZGFwOi8vY3JsLmdkcy5kaXNhLm1pbC9jbiUzZERvRCUyMEVNQUlMJTIw Q0EtMTUlMmNvdSUzZFBLSSUyY291JTNkRG9EJTJjbyUzZFUuUy4lMjBHb3Zlcm5tZW50JTJjYyUz ZFVTP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q7YmluYXJ5MA4GA1UdDwEB/wQEAwIFIDAWBgNV HSAEDzANMAsGCWCGSAFlAgELCTAdBgNVHQ4EFgQUr+rQ8pSc2DUPLz8ynsEG6eYO2IIwbQYIKwYB BQUHAQEEYTBfMDsGCCsGAQUFBzAChi9odHRwOi8vY3JsLmRpc2EubWlsL2dldHNpZ24/RE9EJTIw RU1BSUwlMjBDQS0xNTAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwIwYDVR0RBBww GoEYa2FyZW4ub2Rvbm9naHVlQG5hdnkubWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMw DQYJKoZIhvcNAQEFBQADgYEAKlWWzo9MTjuFz67yJTrKUbFJcY2uScX5SoAROU7aa0xtq1aBRNAy iXoWyKX6Atw5gfOoPRPyrSqsFHmeeCh97QYEgQMt1ZhjRFnKUgt/RI+SafE7PYHNe221JONCx9Yw IgWJBhDVJY3t/VTZswEIThEIOJNeOVV35nsRGOrnedIwggSPMIID+KADAgECAgMxYHgwDQYJKoZI hvcNAQEFBQAwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UE CxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0xNTAeFw0wODA3MDMw MDAwMDBaFw0xMTA3MDIyMzU5NTlaMHgxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVy bm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMQwwCgYDVQQLEwNVU04xJTAjBgNVBAMT HE9ET05PR0hVRS5LQVJFTi5GLjEyMzA2MTIzOTcwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB AKleuUgQoWp3rAZ9OofALpuCmnQh+C2z/03WBfJhokhEeWy8ppbPIgaiykhzQ0CoPJvStZnlNWF+ +0oq1njtddyvcKTYIgaQEhMp2RMk1mCE7Tkv1CQrx9v68zztpa0OgD4am4FlAC5JkTM0UnXX8Swl TZ6N23DXaAj4Gq61fCl7AgMBAAGjggJAMIICPDAfBgNVHSMEGDAWgBSVtYx4q51WMzz0SKOcWO2x ZIqKnjCB1QYDVR0fBIHNMIHKMDSgMqAwhi5odHRwOi8vY3JsLmRpc2EubWlsL2dldGNybD9ET0Ql MjBFTUFJTCUyMENBLTE1MIGRoIGOoIGLhoGIbGRhcDovL2NybC5nZHMuZGlzYS5taWwvY24lM2RE b0QlMjBFTUFJTCUyMENBLTE1JTJjb3UlM2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292 ZXJubWVudCUyY2MlM2RVUz9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0O2JpbmFyeTAOBgNVHQ8B Af8EBAMCBsAwFgYDVR0gBA8wDTALBglghkgBZQIBCwkwHQYDVR0OBBYEFNUG/r2VX4LFM3XDUVCS 0Ce+vcNWMG0GCCsGAQUFBwEBBGEwXzA7BggrBgEFBQcwAoYvaHR0cDovL2NybC5kaXNhLm1pbC9n ZXRzaWduP0RPRCUyMEVNQUlMJTIwQ0EtMTUwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2Eu bWlsMEMGA1UdEQQ8MDqBGGthcmVuLm9kb25vZ2h1ZUBuYXZ5Lm1pbKAeBgorBgEEAYI3FAIDoBAM DjEyMzA2MTIzOTdAbWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwKQYDVR0lBCIwIAYK KwYBBAGCNxQCAgYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBQUAA4GBAHl2Vzr2rNwW CSCTEyXqIgt/lK/6OefX9t9HAtvV5XrAMcr8UQ2mNOhQ4tNIk61lEmaBmxekSZD4z+dDrw1QlHiV kKHtVunHMxG50miekkjvbL4w97HDaqoIowC1mVaK0/z/9f8EjjL/V8g4ZU8Ap6VrpU+FoEASyy07 FYs/z8qQMYICsTCCAq0CAQEwZDBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5t ZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTE1 AgMxYHgwCQYFKw4DAhoFAKCCAaMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMDkwMzI0MTU1NTMzWjAjBgkqhkiG9w0BCQQxFgQUIIWf/sP936e+zNoKN1aH867u/xow WAYJKoZIhvcNAQkPMUswSTAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwcwYJKwYBBAGCNxAEMWYwZDBdMQswCQYD VQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsT A1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTE1AgMxYG0wdQYLKoZIhvcNAQkQAgsxZqBkMF0x CzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoG A1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMTUCAzFgbTANBgkqhkiG9w0BAQEFAASB gGfoWZe3//E7I3+4ABG7tz52pmNOswedoBwLInM2IANPXJxxLtC6oL0sKT2AZcqvzSTGmEg1rE70 8Wqw+b814vTsHkuPGVVKHzsBIZ4aVuMLCvDh+2OoHXuHAUa+8xDqOzoza84rgXbFDAEZUMbNayI1 S2P0ZljV6DsYm0scIbQ6AAAAAAAA ------=_NextPart_000_0045_01C9AC77.6FAC5360-- From yaakov_s@rad.com Tue Mar 24 10:33:21 2009 Return-Path: X-Original-To: tictoc@core3.amsl.com Delivered-To: tictoc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FE8A28C10C for ; Tue, 24 Mar 2009 10:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ah1UKTK0gXvX for ; Tue, 24 Mar 2009 10:33:19 -0700 (PDT) Received: from antivir2.rad.co.il (mx2-q.rad.co.il [80.74.100.144]) by core3.amsl.com (Postfix) with ESMTP id 2B29D28C28D for ; Tue, 24 Mar 2009 10:33:03 -0700 (PDT) Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir2.rad.co.il with ESMTP; 24 Mar 2009 19:33:53 +0200 Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Tue, 24 Mar 2009 19:33:53 +0200 From: Yaakov Stein To: Ronen Solomon , "tictoc@ietf.org" Date: Tue, 24 Mar 2009 19:33:47 +0200 Thread-Topic: [TICTOC] bi-directional SyncE - Copper GBE Thread-Index: AcmsKM2gvgMZ/AQYQaerU25djIBrUwAfDS5w Message-ID: <424CDC689E5CEF4D9FEADE56A378D92202181B2F56@exrad4.ad.rad.co.il> References: <44F4E579A764584EA9BDFD07D0CA081304CF0DC2@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA081304CF0DC2@tlvmail1> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_424CDC689E5CEF4D9FEADE56A378D92202181B2F56exrad4adradco_" MIME-Version: 1.0 Cc: Rafi Ram Subject: Re: [TICTOC] bi-directional SyncE - Copper GBE X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 17:33:21 -0000 --_000_424CDC689E5CEF4D9FEADE56A378D92202181B2F56exrad4adradco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ronen, The problem is that in 1000BaseT you need to use the same clock in both dir= ections (earlier copper physical interfaces used a different clock in each directio= ns, but with Gb that would lead to cross talk degrading the performance). 802.3-2005 states that when you use autonegotiation, the master is chosen r= andomly. In fact, a random or pseudorandom number is generated for this purpose. This would seem to prohibit the use of Gb copper for SyncE, as the direction of the clock flow has a 50% chance of ending up wrong (i.e. "upstream"). However, apparently the 802.3 people in their wisdom foresaw this problem. They defined a control register bit (9.12) which forces a device to be mast= er. If both sides set this bit the autonegotiation fails, so if the link comes = up you can be sure the right side is master. Y(J)S From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of= Ronen Solomon Sent: Tuesday, March 24, 2009 04:33 To: tictoc@ietf.org Cc: Rafi Ram Subject: [TICTOC] bi-directional SyncE - Copper GBE Yaakov In the last meeting you raised the issue of supporting bi-directional SyncE= on Copper GBE. Can you please re-emphasis the problem and the proposed sol= ution. Best regards Ronen --_000_424CDC689E5CEF4D9FEADE56A378D92202181B2F56exrad4adradco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ronen, The problem is that in 1000BaseT you need to use the same cl= ock in both directions (earlier copper physical interfaces used a different clock i= n each directions, but with Gb that would lead to cross talk degrading the performance). 802.3-2005 states that when you use autonegotiation, the mas= ter is chosen randomly. In fact, a random or pseudorandom number is generated for th= is purpose. This would seem to prohibit the use of Gb copper for SyncE,<= o:p> as the direction of the clock flow has a 50% chance of endin= g up wrong (i.e. "upstream"). However, apparently the 802.3 people in their wisdom foresaw this problem. They defined a control register bit (9.12) which forces a de= vice to be master. If both sides set this bit the autonegotiation fails, so if = the link comes up you can be sure the right side is master.<= /p> Y(J)S From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of Ronen Solomon Sent: Tuesday, March 24, 2009 04:33 To: tictoc@ietf.org Cc: Rafi Ram Subject: [TICTOC] bi-directional SyncE - Copper GBE Yaakov In the last meeting you raised the issue of supporting bi-directional SyncE on Copper GBE. Can you please re-emphasis the problem and the proposed solutio= n. Best regards Ronen --_000_424CDC689E5CEF4D9FEADE56A378D92202181B2F56exrad4adradco_-- From yaakov_s@rad.com Tue Mar 24 10:49:16 2009 Return-Path: X-Original-To: tictoc@core3.amsl.com Delivered-To: tictoc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAA963A67CC for ; Tue, 24 Mar 2009 10:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yxrp+vb9YxsZ for ; Tue, 24 Mar 2009 10:49:07 -0700 (PDT) Received: from antivir1.rad.co.il (mx1-q.rad.co.il [80.74.100.136]) by core3.amsl.com (Postfix) with ESMTP id 903A328C316 for ; Tue, 24 Mar 2009 10:48:10 -0700 (PDT) Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir1.rad.co.il with ESMTP; 24 Mar 2009 19:49:00 +0200 Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Tue, 24 Mar 2009 19:49:00 +0200 From: Yaakov Stein To: STUART VENTERS , "tictoc@ietf.org" Date: Tue, 24 Mar 2009 19:48:56 +0200 Thread-Topic: Yesterday's audio Thread-Index: Acmsj/JLnACEIJ45T0uGZjVQ2183CwAGL9Kg Message-ID: <424CDC689E5CEF4D9FEADE56A378D92202181B2F60@exrad4.ad.rad.co.il> References: <8F242B230AD6474C8E7815DE0B4982D70B99D6FE@EXV1.corp.adtran.com> In-Reply-To: <8F242B230AD6474C8E7815DE0B4982D70B99D6FE@EXV1.corp.adtran.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_424CDC689E5CEF4D9FEADE56A378D92202181B2F60exrad4adradco_" MIME-Version: 1.0 Subject: Re: [TICTOC] Yesterday's audio X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 17:49:16 -0000 --_000_424CDC689E5CEF4D9FEADE56A378D92202181B2F60exrad4adradco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The sessions are supposed to be archived here - ftp://videolab.uoregon.edu/= pub/videolab/media/ietf74/ but there is nothing there yet. Y(J)S From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of= STUART VENTERS Sent: Tuesday, March 24, 2009 16:51 To: tictoc@ietf.org Subject: [TICTOC] Yesterday's audio I never was able to get yesterday's audio to work. Is there a URL for an archive of the audio for yesterday's meeting? --_000_424CDC689E5CEF4D9FEADE56A378D92202181B2F60exrad4adradco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yesterday's audio The sessions are supposed to be archived here - ftp://videol= ab.uoregon.edu/pub/videolab/media/ietf74/ but there is nothing there yet. Y(J)S From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of STUART VENTERS Sent: Tuesday, March 24, 2009 16:51 To: tictoc@ietf.org Subject: [TICTOC] Yesterday's audio I neve= r was able to get yesterday's audio to work. Is the= re a URL for an archive of the audio for yesterday's meeting?<= /p> --_000_424CDC689E5CEF4D9FEADE56A378D92202181B2F60exrad4adradco_-- From stuart.venters@adtran.com Tue Mar 24 12:10:55 2009 Return-Path: X-Original-To: tictoc@core3.amsl.com Delivered-To: tictoc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37C5A3A6A47 for ; Tue, 24 Mar 2009 12:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiBA0uXlpCgX for ; Tue, 24 Mar 2009 12:10:51 -0700 (PDT) Received: from p02c11o142.mxlogic.net (p02c11o142.mxlogic.net [208.65.144.75]) by core3.amsl.com (Postfix) with ESMTP id 951AB3A698E for ; Tue, 24 Mar 2009 12:10:50 -0700 (PDT) Received: from unknown [76.164.174.99] (EHLO EXV1.corp.adtran.com) by p02c11o142.mxlogic.net (mxl_mta-6.1.1-1) with ESMTP id d6039c94.2721246096.29320.00-012.p02c11o142.mxlogic.net (envelope-from ); Tue, 24 Mar 2009 13:11:42 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9ACB4.5C8CE5A9" Date: Tue, 24 Mar 2009 14:11:40 -0500 Message-ID: <8F242B230AD6474C8E7815DE0B4982D70B99D700@EXV1.corp.adtran.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [TICTOC] bi-directional SyncE - Copper GBE Thread-Index: AcmstFzi5NoTQvOkT4mPVJ1P7V44yQ== From: "STUART VENTERS" To: X-Spam: [F=0.2000000000; S=0.200(2009020301)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.99] Cc: tictoc@ietf.org Subject: Re: [TICTOC] bi-directional SyncE - Copper GBE X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 19:10:55 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9ACB4.5C8CE5A9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ronen, It looks like the words that ended up in 8264 to deal with this might = require some reading between the lines to understand that you need to force the negotiation to setup the = desired clock path. For interoperability, it would have been nice if the words said to force = it at the master, or slave , or both. I think Yaakov just said to force it at the master? Alternatively, you could make it provisionable if your hardware knows = how to do it either way. Here are the words in G.8264 related to this. Rec. ITU-T G.8264/Y.1364 (10/2008) - Prepublished version 10.1 Synchronous Ethernet: General Note: there may be sync Ethernet interfaces with reduced functionality = in the sense that they might provide sync Ethernet functionality in a single direction only (transmit = or receive). Details are for further study. 10.2 Operation modes Synchronous operation mode In the particular case of Ethernet interfaces for 1G copper as specified = in IEEE 802.3, these interfaces perform link auto negotiation to determine the master and = slave clocks for the link. In the case where these interfaces are used for Synchronous Ethernet, the = resulting timing path must be considered if frequency distribution based on Synchronous Ethernet is = used. The clock master must be consistent with the network synchronization plan. Regards, Stuart Venters Adtran ------_=_NextPart_001_01C9ACB4.5C8CE5A9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [TICTOC] bi-directional SyncE - Copper GBE Ronen, It looks like the words that ended up = in 8264 to deal with this might require some reading between the = lines to understand that you need to = force the negotiation to setup the desired clock path. For interoperability, it would have = been nice if the words said to force it at the master, or slave , or = both. I think Yaakov just said to force it at = the master? Alternatively, you could make it = provisionable if your hardware knows how to do it either way. Here are the words in G.8264 related to = this. Rec. ITU-T G.8264/Y.1364 (10/2008) = – Prepublished version 10.1 Synchronous Ethernet: = General Note: there may be sync Ethernet = interfaces with reduced functionality in the sense that they = might provide sync Ethernet functionality = in a single direction only (transmit or receive). Details are for further study. 10.2 Operation modes Synchronous operation = mode In the particular case of Ethernet = interfaces for 1G copper as specified in IEEE 802.3, these interfaces perform link auto = negotiation to determine the master and slave clocks for the link. In = the case where these interfaces are used = for Synchronous Ethernet, the resulting timing path must be considered if frequency distribution = based on Synchronous Ethernet is used. The clock master must be consistent with = the network synchronization plan. Regards, Stuart Venters Adtran ------_=_NextPart_001_01C9ACB4.5C8CE5A9-- From yaakov_s@rad.com Tue Mar 24 16:48:20 2009 Return-Path: X-Original-To: tictoc@core3.amsl.com Delivered-To: tictoc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 403AC3A67E1 for ; Tue, 24 Mar 2009 16:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziiXPvs15rEt for ; Tue, 24 Mar 2009 16:48:12 -0700 (PDT) Received: from antivir1.rad.co.il (mx1-q.rad.co.il [80.74.100.136]) by core3.amsl.com (Postfix) with ESMTP id DA0A33A68E3 for ; Tue, 24 Mar 2009 16:48:02 -0700 (PDT) Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir1.rad.co.il with ESMTP; 25 Mar 2009 01:48:54 +0200 Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Wed, 25 Mar 2009 01:48:53 +0200 From: Yaakov Stein To: "tictoc@ietf.org" Date: Wed, 25 Mar 2009 01:48:45 +0200 Thread-Topic: mutual synchornoization Thread-Index: Acms2xH42vWRttCxRoy/5oQeCTSQ7Q== Message-ID: <424CDC689E5CEF4D9FEADE56A378D92202181B2FCE@exrad4.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {436E0268-D0BA-4E86-B739-05309ACCE220} x-cr-hashedpuzzle: 5Qo= AANG AEAF A5ot B/Hr CaZo CeP1 CmEb ETnw FkT4 F8om F+BR GuIY HVAc Hhl9 Htct; 1; dABpAGMAdABvAGMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {436E0268-D0BA-4E86-B739-05309ACCE220}; eQBhAGEAawBvAHYAXwBzAEAAcgBhAGQALgBjAG8AbQA=; Tue, 24 Mar 2009 23:48:45 GMT;bQB1AHQAdQBhAGwAIABzAHkAbgBjAGgAbwByAG4AbwBpAHoAYQB0AGkAbwBuAA== acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_424CDC689E5CEF4D9FEADE56A378D92202181B2FCEexrad4adradco_" MIME-Version: 1.0 Subject: [TICTOC] mutual synchornoization X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 23:48:20 -0000 --_000_424CDC689E5CEF4D9FEADE56A378D92202181B2FCEexrad4adradco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I checked Bregni's "A Historical Perspective on Telecommunications Network = Synchronization" (IEEE Communications Magazine Volume 36, Issue 6, Jun 1998 Page(s):158 - 16= 6) He says Mutual Synchronization (Democracy) Mutual synchronization is based on direct mutual control among the clocks s= o that the output frequency of each is the result of the "suggestions" of the others. Such a pure democracy see= ms appealing - there are no masters and no slaves but mutual cooperation. However, the behavior of the mutually controlled el= ements is hard to govern. Modeling the behavior of such networks, or even ensuring the stability of t= he control algorithms, can be a very complex task. Networks thus designed tend to be quite expensive, but extremely reliable. = Therefore, until now, the field of application of mutual synchronization has been mostly limited to special cases (e.g., m= ilitary networks). A quick google turned up the following : >From these clock frequencies, the synchronization of the nodes of the netwo= rk may be performed by two different basic methods: mutual synchronization = and master-slave synchronization. In mutual synchronization, each node gene= rates its own clock frequency from the average of the frequencies of incomi= ng signals and its own clock frequency at the moment. Thus all nodes of the= network are driven towards a common average frequency and in a stable stat= e they have achieved it. However, a network using mutual synchronization ca= nnot be synchronized with a desired source, which makes an interconnection = of different networks problematic, because the operating frequency of the w= hole network cannot then be predetermined accurately. In master-slave synch= ronization instead, all nodes of the network are synchronized with the cloc= k frequency of one master node. Each node selects the frequency of one inco= ming signal as the source of its own clock frequency. The node tries to sel= ect a signal having the clock frequency of the master node of the network. If this is what is meant by mutual synchronization, then this technique is = completely different from the classlessness I described, and additionally suffers from 2 major flaws. First, it does not clock off a grand master, rather it causes a group to co= nverge to a common, but arbitrary frequency. I take that back, they converge to the average frequency. I take that back, they don't necessarily converge, all that need happen is = that the variance will decrease. Second, each clock averages the clock frequencies it sees with its own. I assume that this is in reality a weighted average, i.e. f' =3D a f + (1-= a) /N SUM f_n so that it is actually a single pole IIR filter over time rather than an av= erage; but I digress. Note that the clocks do NOT remove their influence on the other clocks befo= re taking the average, so each clock averages in its own frequency, and without renormalization th= is scheme can become unstable. I do not need experimental results to see this - it is a necessary result o= f the system. In fact, for such a system I can concoct special situations where the frequ= ency drift will diverge. Thus, the prior art of "mutual synchronization" does not seem to be very re= levant to the discussion. But thanks to those who brought it up - it is always interesting to learn a= bout things that have been tried in the past. Y(J)S --_000_424CDC689E5CEF4D9FEADE56A378D92202181B2FCEexrad4adradco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I checked Bregni's "A Historical = Perspective on Telecommunications Network Synchronization" (IEEE Communications Magazine Volum= e 36, Issue 6, Jun 1998 Page(s):158 - 166)<= /span> He says Mutual Synchronization (Democracy)<= o:p> Mutual synchronization is based on = direct mutual control among the clocks so that the output frequency of each is the result of the "suggestions" of the others. Such a pure democracy seems appealin= g – there are no masters and no slaves but mutual cooperation. However, th= e behavior of the mutually controlled elements is hard to govern. Modeling the behavior of such netwo= rks, or even ensuring the stability of the control algorithms, can be a very comple= x task. Networks thus designed tend to be q= uite expensive, but extremely reliable. Therefore, until now, the field of appli= cation of mutual synchronization has been = mostly limited to special cases (e.g., military networks). <= /p> A quick google turned up the following= : From these clock frequencies, the synchronization of the nodes of the network may be performed by two differe= nt basic methods: mutual synchronization and master-slave synchronization. In mutual synchronization, each node generates its own clock frequency from th= e average of the frequencies of incoming signals and its own clock frequency = at the moment. Thus all nodes of the network are driven towards a common avera= ge frequency and in a stable state they have achieved it. However, a network u= sing mutual synchronization cannot be synchronized with a desired source, which makes an interconnection of different networks problematic, because the operating frequency of the whole network cannot then be predetermined accurately. In master-slave synchronization instead, all nodes of the netwo= rk are synchronized with the clock frequency of one master node. Each node sel= ects the frequency of one incoming signal as the source of its own clock frequen= cy. The node tries to select a signal having the clock frequency of the master = node of the network. If this is what is meant by mutual synchronization, then this technique is completely different from the classlessness I described, and add= itionally suffers from 2 major flaws. First, it does not clock off a grand m= aster, rather it causes a group to converge to a common, but arbitrary frequency.<= o:p> I take that back, they converge to the= average frequency. I take that back, they don't necessari= ly converge, all that need happen is that the variance will decrease. Second, each clock averages the clock frequencies it sees with its own. I assume that this is in reality a wei= ghted average, i.e. f' =3D a f + (1-a) /N SUM f_n so that it is actually a single pole I= IR filter over time rather than an average; but I digress. Note that the clocks do NOT remove the= ir influence on the other clocks before taking the average,<= /p> so each clock averages in its own freq= uency, and without renormalization this scheme can become unstable. I do not need experimental results to = see this – it is a necessary result of the system. In fact, for such a system I can conco= ct special situations where the frequency drift will diverge. Thus, the prior art of "mutual synchronization" does not seem to be very relevant to the discussion.<= o:p> But thanks to those who brought it up = – it is always interesting to learn about things that have been tried in the past. Y(J)S --_000_424CDC689E5CEF4D9FEADE56A378D92202181B2FCEexrad4adradco_-- From yaakov_s@rad.com Tue Mar 24 17:59:03 2009 Return-Path: X-Original-To: tictoc@core3.amsl.com Delivered-To: tictoc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 966593A6A1E for ; Tue, 24 Mar 2009 17:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFEbPO4geyLH for ; Tue, 24 Mar 2009 17:59:00 -0700 (PDT) Received: from antivir2.rad.co.il (mx2-q.rad.co.il [80.74.100.144]) by core3.amsl.com (Postfix) with ESMTP id B57DA3A68A7 for ; Tue, 24 Mar 2009 17:58:59 -0700 (PDT) Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir2.rad.co.il with ESMTP; 25 Mar 2009 02:59:51 +0200 Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Wed, 25 Mar 2009 02:59:50 +0200 From: Yaakov Stein To: "tictoc@ietf.org" Date: Wed, 25 Mar 2009 02:59:44 +0200 Thread-Topic: sensor network text Thread-Index: Acms5PyuX/+OxAPVRiSu9fVmvX1TLg== Message-ID: <424CDC689E5CEF4D9FEADE56A378D92202181B2FD4@exrad4.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_424CDC689E5CEF4D9FEADE56A378D92202181B2FD4exrad4adradco_" MIME-Version: 1.0 Subject: [TICTOC] sensor network text X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 00:59:03 -0000 --_000_424CDC689E5CEF4D9FEADE56A378D92202181B2FD4exrad4adradco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, It turns out that somehow I left Silvana's email address off "To" list of m= y summary if the conference call with the ROLL chairs. Since this might interest others, I am copying the contents below. Y(J)S Call between Yaakov and David - 28 Jan 2009 (JP out of office, Stewart couldn't make the call). The point of the call was to try to fill in the tables needed for the secti= on on sensor networks in the TICTOC requirements document. David started by emphasizing the main constraint of all sensor network appl= ications, namely the low power consumption requirement. This constraint is so over-ri= ding that it defines the problem. For the timing questions it means that the cry= stal is the only active element that stays powered up over time, everything else= is usually sleeping and only wakes up for critical functions. In particular, the time between t= iming updates (whether NTP or otherwise) is always going to be relatively long. Similarly, it is also a good strategy to piggyback time information on rout= ing advertisements that are being sent in any case. With that in mind, there are several different applications for sensor netw= orks, each with distinctive features. A basic application is lowrate monitoring, e.g., automated metering, reading of thermostats for climate monitoring, etc. Here the sensors send a timestamped data reading, and thus need to have the= ir local clocks automatically calibrated by an NTP-like mechanism about once every 10 - 20 minutes. Typical transaction rates are once per 5 minutes (once per minute is considered very fast, once per 15 minutes relatively sl= ow). Thus the update rate for this application is in the range of one per 100-10= 00 sec, i.e. the sampling rate is 1 - 10 milliHertz. The required time of day accuracy is on the order ot 1 sec (or possibly a f= ew seconds) i.e. about 1 part per hundred. Since the data is sent with a timestamp, we can accomodate several seconds = of "jitter| on the transaction times, but this jitter must not accumulate to m= ore than a few seconds. YJS - note that since the sampling is done once per 100-1000 seconds, the dividing line between jitter and wander is at a frequency of one in 100= -1000 seconds, and not the 10 per second conventionally used in telecom applications. There is a holdover requirement since the data may only collected once a da= y, and the application should be able to sustain 1 day to 10 days without more= than 1-2% wander. Wander can be considered over a year integration period, and percentile is = a useful mechanism. The local oscillator crystal is a $1 - $2 item (which is a significant perc= entage of the BOM) with 15ppm accuracy. The sensors must be plug-and-play. Link-level AES-128 is a common security mechanism - note that even if the d= ata is correct, having incorrect timestamp can be bad - e.g. forcing the collector to belie= ve that a temperature reading is from last night instead of this afternoon. The expected network characteristics are specific to wireless sensor networ= ks - a typical number of hops between the sensor to the collector is 15, but can even be up to 75 hops. A second application is acceleration sensors distributed in a structure, e.g. a building or bridge. The point of this is to measure the amount of en= ergy in the various vibrational modes, by collecting temporal-spatial data. This can help detect material fatigue, predict failures in machinery, etc. The sensors are placed at various known positions in the structure, and the inaccuracies in positioning are yet another source of error. Update rates are 100 Hz - 1KHz instead of the milliHertz of the previous ap= plication. For this application, determining the power spectrum is not enough, since we need to separate the 3D modes of vibration, and 1 - 2% accuracies = are about right. In this application one is allowed to work hard at calibrating at the begin= ning and end of the run, and temperature data may be available for the duration of the run to help p= redict crystal drift. The accuracy is driven by family of error terms including jitter, A/D noise= , accelerometer transducer noise, lack of knowledge of physical position, etc= . In this application the plug-and-play and security aspects are less importa= nt, and the cost is less constrained (e.g., can use more expensive crystals). Two more applications are: timing for the communication infrastructure itself - i.e. the timing needed to maintain routes and power efficiency (wake up) remote monitoring (tanks) - here the data is sent back once per day or even= once per week. These will be discussed in another call. --_000_424CDC689E5CEF4D9FEADE56A378D92202181B2FD4exrad4adradco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, It turns out that somehow I left Silvana's email addre= ss off "To" list of my summary if the conference call with the ROLL chai= rs. Since this might interest others, I am copying the con= tents below. Y(J)S Call between Yaakov and David - 28 Jan 2009= (JP out of office, Stewart couldn't make the call). The point of the call was to try to fill in the tables needed for the section on sensor networks in the TICTOC requirements document. David started by emphasizing the main constraint of al= l sensor network applications, namely the low power consumption requirement. This con= straint is so over-riding that it defines the problem. For the timing questions = it means that the crystal is the only active element that stays powered up over = time, everything else is usually sleeping and only wakes up for critical functions. In particula= r, the time between timing updates (whether NTP or otherwise) is always going to be relat= ively long. Similarly, it is also a good strategy to piggyback tim= e information on routing advertisements that are being sent in any case. With that in mind, there are several different applica= tions for sensor networks, each with distinctive features. A basic application is lowrate monitoring, e.g., autom= ated metering, reading of thermostats for climate monitoring, etc. Here the sensors send a timestamped data reading, and = thus need to have their local clocks automatically calibrated by an NTP-like mechanism about once every 10 - 20 minutes. Typical transaction rates are once per 5 minutes<= /o:p> (once per minute is considered very fast, once per 15 minutes relatively slow). Thus the update rate for this application is in the ra= nge of one per 100-1000 sec, i.e. the sampling rate is 1 - 10 milliHertz. The required time of day accuracy is on the order ot 1= sec (or possibly a few seconds) i.e. about 1 part per hundred. Since the data is sent with a timestamp, we can accomo= date several seconds of "jitter| on the transaction times, but this jitte= r must not accumulate to more than a few seconds. YJS - note that since the sampling is done once per 10= 0-1000 seconds, the dividing line between jitter and wander is at a frequency of one in 100-1000 seconds, and not the 10 per second conventionally used in telec= om applications. There is a holdover requirement since the data may onl= y collected once a day, and the application should be able to sustain 1 day to= 10 days without more than 1-2% wander. Wander can be considered over a year integration perio= d, and percentile is a useful mechanism. The local oscillator crystal is a $1 - $2 item (which = is a significant percentage of the BOM) with 15ppm accuracy. The sensors must be plug-and-play= . Link-level AES-128 is a common security mechanism - no= te that even if the data is correct, having incorrect timestamp can be bad - e.g. forcing t= he collector to believe that a temperature reading is from last night instead of this afternoon. The expected network characteristics are specific to wireless sensor networks - a typical number of hops between the sensor to the col= lector is 15, but can even be up to 75 hops. A second application is acceleration sensors distribut= ed in a structure, e.g. a building or bridge. The point of this is to mea= sure the amount of energy in the various vibrational modes, by collecting temporal-spatial data. This can help detect material fatigue, predict failure= s in machinery, etc. The sensors are placed at various known positions in t= he structure, and the inaccuracies in positioning are yet another so= urce of error. Update rates are 100 Hz - 1KHz instead of the milliHer= tz of the previous application. For this application, determining the power spectrum i= s not enough, since we need to separate the 3D modes of vibration, a= nd 1 - 2% accuracies are about right. In this application one is allowed to work hard at calibrating at the beginning and end of the run, and temperature data may be available for the duration= of the run to help predict crystal drift. The accuracy is driven by family of error terms includ= ing jitter, A/D noise, accelerometer transducer noise, lack of knowledge of physical position, etc. In this application the plug-and-play and security asp= ects are less important, and the cost is less constrained (e.g., can use more expensive crystals). Two more applications are: timing for the communication infrastructure itself - i= .e. the timing needed to maintain routes and power efficiency (wake up)= remote monitoring (tanks) - here the data is sent back= once per day or even once per week. These will be discussed in another call. --_000_424CDC689E5CEF4D9FEADE56A378D92202181B2FD4exrad4adradco_-- From vs@cesnet.cz Fri Mar 27 02:13:42 2009 Return-Path: X-Original-To: tictoc@core3.amsl.com Delivered-To: tictoc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD9D43A68EB for ; Fri, 27 Mar 2009 02:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtzUyBAGhTl3 for ; Fri, 27 Mar 2009 02:13:42 -0700 (PDT) Received: from beba2.cesnet.cz (beba2.cesnet.cz [195.113.144.239]) by core3.amsl.com (Postfix) with ESMTP id 7A8F43A6825 for ; Fri, 27 Mar 2009 02:13:40 -0700 (PDT) Received: from [130.129.71.119] (dhcp-4777.meeting.ietf.org [130.129.71.119]) by beba2.cesnet.cz (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id n2R9EVNO029128 for ; Fri, 27 Mar 2009 10:14:32 +0100 Message-ID: <49CC98F5.5040603@cesnet.cz> Date: Fri, 27 Mar 2009 10:14:29 +0100 From: Vladimir Smotlacha User-Agent: Thunderbird 2.0.0.21 (X11/20090302) MIME-Version: 1.0 To: tictoc@ietf.org Content-Type: multipart/mixed; boundary="------------080707030704070407090403" Subject: [TICTOC] table 8 - metrology X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 09:13:42 -0000 This is a multi-part message in MIME format. --------------080707030704070407090403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello, I filled in table 8 and added some text to section 3.8 of draft-rodrigues-lindqvist-tictoc-req-02.txt Vladimir -- ---------------------------------------------------------------------------- Vladimir Smotlacha CESNET z.s.p.o E-Mail: vs@cesnet.cz Zikova 4 Phone: +420 2 24352915 160 00 Prague 6 Fax: +420 2 24313211 Czech Republic ---------------------------------------------------------------------------- --------------080707030704070407090403 Content-Type: text/plain; name="tictoc-req-sec3_8.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="tictoc-req-sec3_8.txt" This document contains edited chapter 3.8 of TICTOC Requirement draft-rodrigues-lindqvist-tictoc-req-02.txt 3.8. Metrology Metrology for time and frequency is today mostly using tailored equipment and cabling for time/frequency transfer when doing laboratory work. However, in the future, using IP over existing networks in the laboratories would allow for greater flexibility and reuse of existing infrastructure rather than building out more special purpose infrastructure. 3.8.1. Metrology Requirements We should distinguish between "primary" metrology of time and frequency performed in national metrology laboratories and some other timing centers (which deals with highly accurate and stable frequency standards, typically cesium standards and hydrogen masers and which ensures synchronization with a nanosecond accuracy) and applied metrology that mainly calibrates oscillators and clocks used as "secondary" standards in research organizations and industry. The use of time and frequency transfer in packet networks is limited in "primary" metrology, as it operates with frequency accuracy and stability in the order of 1e-14 and better and time accuracy in nanoseconds (1 ns represents 1 foot of the light path in vacuum). In turn, time and frequency transfer through packet networks is quite challenging for applied metrology - it can profit from any improvement of transfer accuracy, therefore the values in table 8 should be considered as minimum target values. Whenever possible, accuracy of distributed time should be better then time accuracy provided by a GPS receiver. Short distance application (over LAN) usually require better accuracy than long distance application using WAN. Note: some applications might belong into both metrology and measurement application groups. The requirements for the Metrology is summarized in the table 8. Metrology Requirements +-----------------------------+-----------------------------+ | Requirements | Metrology | +-----------------------------+-----------------------------+ | Synchronization type (e.g. | Time and frequency | | time, frequency or phase) | | | --------------------------- | --------------------------- | | Frequency stability | 1 ppb, lowest possible | | | phase noise | | --------------------------- | --------------------------- | | Frequency accuracy | 1 ppb | | --------------------------- | --------------------------- | | Uncalibrated time/time | Lowest possible phase noise | | stability | | | --------------------------- | --------------------------- | | Uncalibrated time/time | 1 us | | accuracy | | | --------------------------- | --------------------------- | | Stabilization time | Not important, 1 hour is | | | acceptable | | --------------------------- | --------------------------- | | Jitter on recovered timing | 1 us | | signal | | | --------------------------- | --------------------------- | | Wander on recovered timing | 1 us | | signal | | | --------------------------- | --------------------------- | | What expected network | Any that can offer | | characteristics (WAN, LAN, | required parameters | | MAN, private, public, etc)? | | | --------------------------- | --------------------------- | | Does the application | Authentication is required | | requires security? (if so, | when public networks | | which one: authentication, | are used | | encryption,traceability, | | | others) | | | --------------------------- | --------------------------- | | Reliability requirements | Low fault tolerance, user | | (e.g. fault tolerance) | should know whether expected| | | parameters were assured | | | or not | | --------------------------- | --------------------------- | | Traceability to a specific | Very important | | clock, clock quality, path, | | | time | | | --------------------------- | --------------------------- | | Holdover requirement | | | --------------------------- | --------------------------- | | Cost (consumer, enterprise, | Cost should correspond | | carrier) | with provided pamaters | | --------------------------- | --------------------------- | | Auto-configuration (plug | Important at client side | | and play) | | | --------------------------- | --------------------------- | | Manageability (how much | Both provider and customer | | effort the operator needs | should accept network | | to put in to manage this | related configuration, | | application?) - In-band or | long distribution path | | out-of-band of protocol | might require calibration | | (MIBs?) | | | --------------------------- | --------------------------- | | Scale and scalability | Scalability is not | | | important, only a few | | | transfers will be active | | | from one source at the same | | | time | +-----------------------------+-----------------------------+ Table 8 --------------080707030704070407090403-- From mayer@ntp.org Sun Mar 29 11:16:46 2009 Return-Path: X-Original-To: tictoc@core3.amsl.com Delivered-To: tictoc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5213C3A6BF7 for ; Sun, 29 Mar 2009 11:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIi3jBgP24ZD for ; Sun, 29 Mar 2009 11:16:45 -0700 (PDT) Received: from mail2.ntp.org (mail2.ntp.org [204.152.184.138]) by core3.amsl.com (Postfix) with ESMTP id 343F53A6BFB for ; Sun, 29 Mar 2009 11:16:45 -0700 (PDT) Received: from firewall.antoniuk.lan (mail.antoniuk.md [65.86.158.146]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail2.ntp.org (Postfix) with ESMTP id 9C6D839905 for ; Sun, 29 Mar 2009 18:17:39 +0000 (UTC) (envelope-from mayer@ntp.org) Received: from cust-63-209-224-130.bos-dynamic.gis.net ([63.209.224.130] helo=[10.10.10.101]) by firewall.antoniuk.lan with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1LnzZc-0005RH-PD for tictoc@ietf.org; Sun, 29 Mar 2009 14:17:33 -0400 Message-ID: <49CFBB3F.6060209@ntp.org> Date: Sun, 29 Mar 2009 14:17:35 -0400 From: Danny Mayer Organization: NTP User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "tictoc@ietf.org" X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-kostecke.net-MailScanner: Found to be clean X-kostecke.net-MailScanner-From: mayer@ntp.org Subject: [TICTOC] [Fwd: Re: [ntp:questions] Using different timebase for ntpd] X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mayer@ntp.org List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2009 18:16:46 -0000 The TICTOC working group might be interested in this from Dave Mills. Danny -------- Original Message -------- Subject: Re: [ntp:questions] Using different timebase for ntpd Date: Sun, 29 Mar 2009 17:30:48 +0000 From: David Mills To: questions@lists.ntp.org Danny, Thanks for the qick pic. Indeed, the full interleaved mode is in the current development version at the backroom site, but might not yet be in the current snapshot. The web page cited is not quite up to date, as I am refining it offline to include in the next revision of my book. Meanwhile, the interleaved symmetric mode has been proposed for the Proximity-1 space link protocol to distribute time in the vicinity of Mars and the Moon. As space links operate at far lower data rates than Ethernets, interleaved mode is a necessity. Interleaved broadcast mode with hardware derived timestamps and the NTP calibration round is functionally equivalent to IEEE 1588. However, there is a showstopper in that 1588 disciplines a good quality TCXO in the NIC clock, while NTP disciplines a rotten quality computer clock. 1588 profices a mechanism to wrangle a herd of instrument and computer NICs to a Grandmaster, but not necessarily to wrangle the computer clock to that herd. This would be an interesting work item for TICTOC. Dave Danny Mayer wrote: >Patrick Loschmidt wrote: > > >>Hi! >> >>Thanks a lot for your detailed answer! >> >>Greg Dowd schrieb: >> >> >>>Most if not all commercial ntp appliance manufacturers have some sort of >>>hardware support, either RTOS, custom clock, better oscillator or even >>>modified Ethernet devices to support hardware time stamping. >>> >>> >>Well I'm mostly interested in systems doing hardware time stamping on >>the Ethernet interface. My intention to just use another timebase are >>just an intermediate step to ease my development. >> >> >> >>>I tried modifying one >>>of our SyncServers and gave a presentation at ietf tictoc bof on >>>precision frequency transfer over packet based networks. Dave Mills also >>>did some experimentation with this. While I used mode 3/4 with a >>>lagging timestamp for the followup function, Dave restricted that >>>operation to symmetric modes. I have another presentation from a sync >>>conference last year comparing the two protocols. Let me know if you >>>are interested and I'll dig them up. >>> >>> >>Yes, please, I'm very much interested, since I did an extensive search >>via IEEE Explore, ACM Library, google, etc. and couldn't really find any >>results or even products explicitly stating that they use hardware support. >> >> >> >>>In your case, you are not talking about hardware timestamping but >>>software timestamping using a hardware clock. It is a good first step >>>but os/stack jitter is still likely to be dominant. >>> >>> >>Thanks for all the further hints. I have to admit, that I'm working in >>the IEEE 1588 community for quite a while. Since I'm currently compiling >>my PhD, I asked myself the basic questions like, why didn't we just >>enhance NTP with HW timestamping to reach the accuracy? >>So I came up with that idea, searched for implementations or scientific >>papers giving results, reasons, etc. but had not much luck. >> >>I found "A brief history of NTP time: Confessions of an Internet Time >>Keeper" by David Mills, mentioning the Nanokernel and some fancy >>synchronization results with 50ns RMS but I couldn't dig out the cited >>reference, since the cite is incorrect ... Also proceedings of the PTTI >>didn't help much. :-( >> >>So, what I still would like to have is either documentation of someone >>who already did NTP with hardware timestamps on Ethernet or can I >>somewhere find a documentation of the NTP-Daemon to kernel clock >>interface, in order to replace all the necessary system calls? >> >>Anyway, I'll dig through the code an all your hints. Thank's a lot for >>all the helpful answers in this newsgroup. >> >>Regards, >>Patrick >> >> > >There is work going on in the TICTOC working group of the IETF to define >standards and protocols to take advantage of of the IEEE 1588-2 standard >but it's early days yet. Dave Mills himself has come up with ideas of >how NTP can take advantage of 1588 to improve NTP results. Don't forget >that 1588 assumes a strict tree and you need 1588 everywhere and I >believe it applies only to Ethernet. Dave Mills himself has some ideas >on implementing this in NTP and has discussed this either here on in the >hackers mailing list. Dave's research documents can be found on his NTP >research web site: http://www.eecis.udel.edu/~mills/ntp.html and you >will find a reference on the left hand side to "NTP Interleaved On-Wire >Protocol" which is what I believe you are looking for. > >If you are finding some of the references are wrong, please ask Dave and >he will correct them. In addition if you are interested in getting this >implemented in NTP I am sure that Dave would be more than happy to take >you on to get it implemented for general use. From the look of that >reference he has implemented a simulator (lev.c) for testing scenarios >as well as in the NTP reference implementation but I don't think that he >has made that available yet. > >Dave will say more and is very approachable in these matters. > >Danny > > > _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.