29 Years of the Digest ... founded August 21, 1981

Add this Digest to your personal   or  

The Telecom Digest for July 11, 2011
Volume 30 : Issue 171 : "text" Format
Messages in this Issue:
Re: System Clock Apparently Gaining One Second Every 30 Minutes(John Meissen)
Re: System Clock Apparently Gaining One Second Every 30 Minutes(Sam Spade)
Re: System Clock Apparently Gaining One Second Every 30 Minutes(Robert Bonomi)
Re: System Clock Apparently Gaining One Second Every 30 Minutes(Robert Bonomi)
Re: System Clock Apparently Gaining One Second Every 30 Minutes(Harold Hallikainen)
Re: "Underground" demarc?(Joseph Singer)

====== 29 years of TELECOM Digest -- Founded August 21, 1981 ======

Telecom and VOIP (Voice over Internet Protocol) Digest for the Internet. All contents here are copyrighted by Bill Horne and the individual writers/correspondents. Articles may be used in other journals or newsgroups, provided the writer's name and the Digest are included in the fair use quote. By using -any name or email address- included herein for -any- reason other than responding to an article herein, you agree to pay a hundred dollars to the recipients of the email.
Addresses herein are not to be added to any mailing list, nor to be sold or given away without explicit written consent. Chain letters, viruses, porn, spam, and miscellaneous junk are definitely unwelcome.

We must fight spam for the same reason we fight crime: not because we are naive enough to believe that we will ever stamp it out, but because we do not want the kind of world that results when no one stands against crime.  - Geoffrey Welsh

See the bottom of this issue for subscription and archive details and the name of our lawyer, and other stuff of interest. 




Date: Sat, 09 Jul 2011 17:35:22 -0700
From: "John Meissen" <john@meissen.org>
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Re: System Clock Apparently Gaining One Second Every 30 Minutes
Message-ID: <20110710003522.46BD217F607@john>

> Please tell us which ones were able to handle the DST change. 

I'm pretty sure they were La Crosse Technology clocks, but I don't
remember for sure. When they didn't change I called the manufacturer
and they sent me new clocks, no charge.

I haven't had the problem with any clocks since then. I sent the old
ones to my sister in Arizona. Since they don't observe DST the problem
won't affect her.

"Gary" wrote:
> As far as DST goes, don't forget that Arizona and parts of Indiana don't use
> DST.  They stay on standard time all year.  So, unless the clock has a way of
> knowing if it's in such a location it will need some sort of user input to
> tell it to use or ignore the DST flag. Since the clock also has to be manually
> adjusted for UTC offset (i.e. time zone), I can see why manufactures skimped
> on adding an auto-DST option for the standard consumer "atomic" clocks. 

All of my consumer clocks have buttons on the back to specify US timezones,
and a switch to disable DST changes.




Date: Sat, 09 Jul 2011 18:16:14 -0700
From: Sam Spade <sam@coldmail.com>
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Re: System Clock Apparently Gaining One Second Every 30 Minutes
Message-ID: <j8qdncKSdJLCYIXTnZ2dnUVZ_smdnZ2d@giganews.com>

Peter R Cook wrote:
> In message 
> <kqCdnfjrbeU204vTnZ2dnUVZ_hKdnZ2d@posted.nuvoxcommunications>, Robert 
> Bonomi <bonomi@host122.r-bonomi.com> writes:
> 
>> The NIST facility is amazingly accurate.  They have 'smarts' on the
>> server end that measure the round-trip latency to the user, and
>> advance the 'tick' so that it arrives at the user's location at the
>> proper instant.  With quality software, one can set the system clock
>> with sub- millisecond accuracy.  If memory serves, the 'jitter' is
>> around 15 _micro- second_.
> 
> 
> This is a standard feature designed into the NTP protocol. It uses 
> Marzullo's algorithm to determine the round trip delay.
> 

I've used this program for years:

http://www.dillobits.com/yats32.html




Date: Sat, 09 Jul 2011 18:54:34 -0500
From: bonomi@host122.r-bonomi.com (Robert Bonomi)
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Re: System Clock Apparently Gaining One Second Every 30 Minutes
Message-ID: <j_-dnX602Jqnd4XTnZ2dnUVZ_gGdnZ2d@posted.nuvoxcommunications>

In article <$A8tDkC+G3FOFwcs@wisty.plus.com>,
Peter R Cook  <News@wisty.plus.com> wrote:
>In message <kqCdnfjrbeU204vTnZ2dnUVZ_hKdnZ2d@posted.nuvoxcommunications>, 
>Robert Bonomi <bonomi@host122.r-bonomi.com> writes:
>
>>The NIST facility is amazingly accurate.  They have 'smarts' on the
>>server end that measure the round-trip latency to the user, and
>>advance the 'tick' so that it arrives at the user's location at the
>>proper instant.  With quality software, one can set the system clock
>>with sub- millisecond accuracy.  If memory serves, the 'jitter' is
>>around 15 _micro- second_.
>
>This is a standard feature designed into the NTP protocol. It uses 
>Marzullo's algorithm to determine the round trip delay.

All well and good, but the NIST dial-up service does not use NTP.

Also, all references  I i find for Marzullo's algorithm reference finding 
the 'best fit' for uncertainty from MULTIPLE sources, over a _variable-
latency_ packet network.  When you have only a single source Marzullo 
doesn't seem to be of much use.   Claimed accuracy is circa 10 milliseconds,
for WAN sources, and circa 200 microsecond for in local networks.

A dial-up connection to NIST is, for all practical purposes, a fixed
latency connection, and thus the 'uncertainty' that Marzullo addresses is
essentially zero to start with.

You can have the far end simply 'echo' _character_by_character_, what the
server side sends, and measure the delay from when the UART 'transmit' is
toggled to when the 'received' interrupt is raised.  subtract off the 
duration of the character, divide by 2, and you have a good estimate of
the one-way latency.  Advance the UART transmit toggle  by one character 
duration plus the one-way latency, the far-end 'received' interrupt
will occur very close to the actual 'tick'. 




Date: Sat, 09 Jul 2011 19:01:25 -0500
From: bonomi@host122.r-bonomi.com (Robert Bonomi)
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Re: System Clock Apparently Gaining One Second Every   30 Minutes
Message-ID: <cO-dnX3Jxe9IdoXTnZ2dnUVZ_gGdnZ2d@posted.nuvoxcommunications>

In article <1310172112.80007.YahooMailClassic@web111717.mail.gq1.yahoo.com>,
Wes Leatherock  <wleathus@yahoo.com> wrote:
>
>--- On Thu, 7/7/11, Robert Bonomi <bonomi@host122.r-bonomi.com> wrote:
> 
>      [ ... ]
>
>> The NIST facility is amazingly accurate.  They have 'smarts' on
>> the server end that measure the round-trip latency to the user, and
>> advance the 'tick' so that it arrives at the user's location at
>> the proper instant.  With quality software, one can set the system
>> clock with sub- millisecond accuracy.  If memory serves, the
>> 'jitter' is around 15 _micro- second_.
>
>     This must be the one that you reach at www.time.gov.  When you
>click on your time zone it tells you to wait, which appears to be
>while it is measuring the round trip latency.  Then in a few seconds
>the digital time (hours, minutes, seconds) appears in the box.
>
>     If it doesn't want to come up at www.time.gov there is also a
>button to click at www.nist.gov, which brings up the same page.

"Accuracy", over the Internet, is orders of magnitude worse than the direct
dial-up connection.  The Internet NTP protocol is good for getting within
about 100 milliseconds.

>     The is also a timing pulse in the interstitial information on PBS
>stations, as the instructions on video recorders often spell out in
>detail.

"Most" PBS stations, when broadcasting 'network' programming, to be precise.
Since this is a one-way protocol, derived from a 'synchronized' source at
the network head-end, one can easily have 600-800 (or more!) millisecond
'delay' at the receiving end.  "Good enough" for a VCR, but absolutely
dreadful if you need a high-precision/high-accuracy timestamp.




Date: Sun, 10 Jul 2011 11:49:38 -0700 (PDT)
From: Harold Hallikainen <harold@hallikainen.com>
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Re: System Clock Apparently Gaining One Second Every 30 Minutes
Message-ID: <31579e65-8cc4-4f28-a17f-86c33ae9cd3f@j14g2000prn.googlegroups.com>

DST is complicated! I designed a system that logs events in UTC. For
user convenience, I wanted to display in various local times,
including the time where the unit is located and the time where the
user is located. Standard time is simple enough. I just add an offset.
DST is a lot more difficult. It applies in some locations and not
others. It changes based on local time, not UTC. The date and time of
the change varies by country. Countries change the date and time of
DST changes. I read that some countries may delay the change one year
to put an election in DST. I finally gave up and let the user select
whether to apply a DST offset to the displayed time or not.

A list of various DST change time and dates is located at
http://www.timeanddate.com/time/dst/2011.html .

Harold




Date: Mon, 4 Jul 2011 13:12:51 -0700 (PDT)
From: Joseph Singer <joeofseattle@yahoo.com>
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Re: "Underground" demarc? 
Message-ID: <1309810371.30985.YahooMailClassic@web161514.mail.bf1.yahoo.com>

Fri, 1 Jul 2011 10:59:42 -0700 (PDT) grumpy44134 <grumpy44134@gmail.com> wrote:

<<My friend is having an intermittent problem with her home phone.  I
told her to find the gray demarc/Telephone Network Interface (Ohio)
box. After not being able to find it, she reminded me her power and
telephone wires were underground to her house.  Question - where is
the demarc for underground telephone service (in Ohio)?>>

I would think wherever the telephone service entered the building.  If there's no obvious place where the service is distributed in the building it may start at one of the jacks.  Many times if there's a jack in the kitchen all other jacks will feed from that jack.  There has to be a distribution point somewhere in the house whether it's a terminal in a utility room or where the cable comes into the house if you have a basement or through a spot in a utility room or even through a garage.  If the house was built in the mid to late seventies there should be a telco provided NIC where the subscriber can have their own wiring done and where you can test the line by plugging in your regular phone to see if the line is OK.





TELECOM Digest is an electronic journal devoted mostly to telecom-
munications topics. It is circulated anywhere there is email, in
addition to Usenet, where it appears as the moderated newsgroup
'comp.dcom.telecom'.

TELECOM Digest is a not-for-profit, mostly non-commercial educational
service offered to the Internet by Bill Horne. All the contents
of the Digest are compilation-copyrighted. You may reprint articles in
some other media on an occasional basis, but please attribute my work
and that of the original author.

The Telecom Digest is moderated by Bill Horne.
Contact information:Bill Horne
Telecom Digest
43 Deerfield Road
Sharon MA 02067-2301
781-784-7287
bill at horne dot net
Subscribe:telecom-request@telecom-digest.org?body=subscribe telecom
Unsubscribe:telecom-request@telecom-digest.org?body=unsubscribe telecom 
This Digest is the oldest continuing e-journal about telecomm-
unications on the Internet, having been founded in August, 1981 and
published continuously since then.  Our archives are available for
your review/research. We believe we are the oldest e-zine/mailing list
on the internet in any category!

URL information: http://telecom-digest.org


Copyright (C) 2009 TELECOM Digest. All rights reserved.
Our attorney is Bill Levant, of Blue Bell, PA.

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

Finally, the Digest is funded by gifts from generous readers such as
yourself who provide funding in amounts deemed appropriate. Your help
is important and appreciated. A suggested donation of fifty dollars
per year per reader is considered appropriate. See our address above.
Please make at least a single donation to cover the cost of processing
your name to the mailing list. 

All opinions expressed herein are deemed to be those of the
author. Any organizations listed are for identification purposes only
and messages should not be considered any official expression by the
organization.
End of The Telecom Digest (6 messages)

Return to Archives ** Older Issues