Give this guy a look, 1RMU form factor, GPS with Rubidium holdover (7 days) if you need it very inexpensive, http://www.fibrolan.com/FibroLAN/SendFile.asp?DBID=1&LNGID=1&GID=3979 or http://www.fibrolan.com/FibroLAN/SendFile.asp?DBID=1&LNGID=1&GID=3978 if you have a SYC-E source or If you just need highly accurate NTP without the holdover, you can do it with FBSD, and a GPS device. http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm http://www.brandywinecomm.com/46-products/bus-level-plug-in-boards/212-pcie-... -----Original Message----- From: NANOG [mailto:nanog-bounces@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 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 Internet, and support a single type of traffic: audio streams. I’ve done demonstrations of VoIP that works well in this environment, and you get the advantages of IP routing for redundancy, as opposed to clunky T1 failover mechanisms usually based on hardware switches. But public safety customers are not swayed. TDM works, and it’s the gold standard. They don’t want to change, and you can’t make them. They only see risk, no reward. BTW, in the TDM model, remote data and audio are usually two different systems, which is probably a good idea for redundancy: you might lose audio or data, but rarely both. In any event, I’m only proposing that public safety upgrade their audio systems to VoIP (or cellular-style private GSM, which is in essence VoIP). But nobody is willing. -mel
On May 16, 2016, at 9:02 AM, Lamar Owen <lowen@pari.edu> wrote:
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 radio and optical astronomy, and at least the timing aspect is higher-challenge that most IT environments.
You're implicitly suggesting there might be a technical case for replacing these T1/T3 trunks with some kind of VOIP provisioning less dependent on accurate time synch. Do you think that's true?
While I know the question was directed at Mel specifically, I'll just say from the point of view of a T1 voice trunk customer that I hope to never see it go to a VoIP solution. VoIP codecs can have some serious latency issues; I already notice the round-trip delay if I try to carry on a conversation between our internal VoIP system and someone on a cell phone. And this is before codec artifacting (and cascaded codec scrambling) is counted. Can we please keep straight μ-law (A-law if relevant) lossless DS0 PCM timeslices for trunklines so we get at least one less lossy codec cascade? Or have you never experimented with what happens when you cascade G.722 with G.729 with G.726 and then G.711 and back? Calls become mangled gibberish.
I would find it interesting to see how many carriers are still doing large amounts of SONET, as that is the biggest use-case for high-stability timing.