From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Mel Beckman
Sent: Monday, May 16, 2016 11:27 AM
To: Lamar Owen
Cc: nanog@nanog.org
Subject: Re: Cost-effectivenesss of highly-accurate clocks for NTP
Lamar,
Although VoIP has different technical challenges than TDM, they are all
surmountab
Lamar,
Although VoIP has different technical challenges than TDM, they are all
surmountable. Usually VoIP problems result from poor network design (e.g.,
mixed traffic with no QoS, Internet transport with no guarantees, etc). Public
safety networks are generally well designed, don’t use the Int
On 05/15/2016 03:16 PM, Måns Nilsson wrote:
...If you think the IP implementations in IoT devices are naîve, wait
until you've seen what passes for broadcast quality network
engineering. Shoving digital audio samples in raw Ethernet frames is
at least 20 years old, but the last perhaps 5 years
On 05/15/2016 01:05 PM, Eric S. Raymond wrote:
I'm not used to thinking of IT as a relatively low-challenge environment!
I actually changed careers from broadcast engineering to IT to lower my
stress level and 'personal bandwidth challenge.' And, yes, it worked.
In my case, I'm doing IT for
> I was just thing about this WAN jitter issue myself. I'm wondering how many
> folks put NTP traffic in priority queues? At least for devices in your
> managed IP ranges. Seems like that would improve jitter. Would like to
> hear about others doing this successfully prior to suggesting it for
-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Leo Bicknell
Sent: Monday, May 16, 2016 10:28 AM
To: nanog@nanog.org
Subject: Re: Cost-effectivenesss of highly-accurate clocks for NTP
>For a typical site, there are two distinct desires from the same
In a message written on Fri, May 13, 2016 at 03:39:27PM -0400, Eric S. Raymond
wrote:
> According to RFC 5095 expected accuracy of NTP time is "several tens
> of milliseconds." User expectations seem to evolved to on the close
> order of 10ms. I think it's not by coincidence this is pretty close
Joe and Eric,
It's frustrating how far public safety technology lags behind what Industry can
actually deliver. It's the same in aviation. Institutions are slow to adopt new
tech due to fears about reliability, and and unwillingness to take any risk at
all. So PS and aviation capabilities lag
On 5/15/16 10:05 AM, Eric S. Raymond wrote:
> Mel Beckman :
>> The upshot is that there are many real-world situations where
>> expensive clock discipline is needed. But IT isn't, I don't think,
>> one of them, with the exception of private SONET networks (fast
>> disappearing in the face of metro
Subject: Re: Cost-effectivenesss of highly-accurate clocks for NTP Date: Sun,
May 15, 2016 at 03:21:02PM + Quoting Mel Beckman (m...@beckman.org):
> The upshot is that there are many real-world situations where expensive clock
> discipline is needed. But IT isn't, I don'
On Sun, 15 May 2016 15:21:02 -, Mel Beckman said:
> But a more critical deployment of rubidium clocks is in cash-strapped public
> safety institutions, such as local police dispatch centers. Timing is crucial
> for the squad car communication systems, which these days are all digital,
> based o
Mel Beckman :
> The upshot is that there are many real-world situations where
> expensive clock discipline is needed. But IT isn't, I don't think,
> one of them, with the exception of private SONET networks (fast
> disappearing in the face of metro Ethernet).
Thank you, that was very interesting i
I have deployed rubidium-disciplined clocks at cellular carriers, where money
is no object (look at your cellphone bill), typically for $20K-$100K for
redundant clocks. The holdover time on these is supposed to be days, but we've
never tested that. I think I'd better.
But a more critical deplo
Bruce Simpson :
> On 13/05/16 20:39, Eric S. Raymond wrote:
> >In 2012, nearly three years before being recruited for NTPsec, I
> >solved this problem as part of my work on GPSD. The key to this
> >solution is an obscure feature of USB, and a one-wire
> >patch to the bog-standard design for generi
Baldur Norddahl :
> Ok how many hours or days of holdover can you expect from quartz,
> temperature compensated quartz or Rubidium?
Sorry, I don't have those drift figures handy. I'm a programmer, not
a large-site sysadmin - I've never had purchase authority with a
budget large enough to buy a ru
> I clearly need three of those maser things for my network.
Gives new meaning to the phrase "Set and forget". :)
-mel beckman
> On May 14, 2016, at 12:40 PM, Baldur Norddahl
> wrote:
>
>> On 13 May 2016 at 23:01, Baldur Norddahl wrote:
>>
>> Ok how many hours or days of holdover can you e
On 13 May 2016 at 23:01, Baldur Norddahl wrote:
> Ok how many hours or days of holdover can you expect from quartz,
> temperature compensated quartz or Rubidium? Should we calculate holdover as
> time until drift is more than 1 millisecond, 10 ms or more for NTP
> applications?
>
> I am thinking
On 05/13/2016 03:39 PM, Eric S. Raymond wrote:
Traditionally dedicated time-source hardware like rubidium-oscillator
GPSDOs is sold on accuracy, but for WAN time service their real draw
is long holdover time with lower frequency drift that you get from the
cheap, non-temperature-compensated qua
Den 13. maj 2016 21.40 skrev "Eric S. Raymond" :
> Traditionally dedicated time-source hardware like rubidium-oscillator
> GPSDOs is sold on accuracy, but for WAN time service their real draw
> is long holdover time with lower frequency drift that you get from the
> cheap, non-temperature-compensa
Mel Beckman :
>Finally, do you want to weigh in on the necessity for highly accurate local RT
>clocks in NTP servers? That seems to be the big bugaboo in cost limiting right
>now.
Yes, this is a topic on which I have some well-developed judgments
due to having collected (and, where practical, test
20 matches
Mail list logo
