[ntp:questions] Symmetricom BC635 reference clock for linux

Greg Dowd GDowd at symmetricom.com
Tue May 27 18:32:39 UTC 2008


I'll still focus on the second part of the answer, which is related to
support.  Without a thorough understanding of your application, it is
not possible to answer your query correctly or completely.

1) There is no "most" folks in this arena, at least in my experience.
If anything, the number of people taking this route is dropping with the
falling cost of commercial ntp servers.  If there were a larger
community, you would see this type of thing reflected on the list as a
generic state machine for hardware solns.
2) Specifically, the ioctl call will typically have a coldstart flag
which means that the ioctl should fail if IRIG has never been decoded.
That's because your clock will show Jan 1, 1970.  Next, during short
term discontinuities in tracking, I say don't fail the call.  Further,
even if you lose IRIG, and you're in holdover, I say don't fail the call
and let ref time and dispersion float up.  Later, there may be some hard
stop where you wish to again fail the call to force selection of an
alternate source.  So you can see it is hard to know if you looking for
a general idea of what time it is or you are initializing a missile's
inertial nav system :-)  This question would have been better posted to
hackers.
3) 2 boards is almost always the worst scenario.  Who's right if they
disagree?  But I'm sure you've heard that story before.
4) What do you want to happen when there is a disagreement,
disconnection, discontinuity?  Are you looking for absolute accuracy,
relative accuracy between nodes, reliability, quick convergence on power
cycles, etc?  These are all important things for you to consider in your
design and we don't know your answers.  Therefore, you see the response
you do which is that our support organization can't handle that level of
support in addition to their other workload.  

To be clear, I am not part of the support organization, or even the test
and measurement division which manufactures these products anymore but I
have a long history of assocation with them.  


Greg Dowd
gdowd at symmetricom dot com (antispam format)
Symmetricom, Inc.
www.symmetricom.com
"Everything should be made as simple as possible, but no simpler" Albert
Einstein

-----Original Message-----
From: Andy Helten [mailto:andy.helten at dot21rts.com] 
Sent: Tuesday, May 27, 2008 10:12 AM
To: Greg Dowd; questions at lists.ntp.org
Cc: hardy at cubrc.org
Subject: Re: [ntp:questions] Symmetricom BC635 reference clock for linux

Here was part of my question to Symmetricom support:

""""""""
Regarding NTP, what do most folks do when using your card with NTP? 
Should the ioctl() to retrieve time fail when there is no IRIG input
signal?  I have another IRIG PMC I plan to use for driving an IRIG
signal to the application SBC for test purposes.  Maybe everything will
be happy when I get that working.
""""""""


And, instead of a paraphrase, here is the exact reply to my support
request:



""""""""
As we sell Timeservers we recommend that you buy those as there we have
redundancy and security and documentation on how it will behave. So far
we haven't really wanted to support the PCI card as a Timeserver, in a
way it would be competition and it would also have to be decided at what
level we would "support" it. There can be unrealistic expectations
and/or pitfalls to using a bus card to serve NTP packets "reliably".
""""""""

We have IRIG PMCs on two single board computers and we want NTP
synchronization between all of the other single board computers in our
system.  Why should we buy a complete system for NTP synchronization
when we have all the components we need to do exactly what is done in
any given NTP time box?  Besides the fact that none of our requirements
or needs were considered in this situation.  By the way, you (Greg) were
not the support person quoted above.

Needless to say, none of this matters because the end result was that I
had to figure it out by myself with no help from Symmetricom.  The
solution ended up being simple, but to a Linux newbie, an NTP newbie,
and an IRIG newbie, it did take a little time to figure it out.  One
would have expected some amount of help in this area for the $250 price
of the driver.  Humorously, when I later wanted to verify the accuracy
of a Symmetricom GPS-to-IRIG box and I explained we were using NTP with
the BC635 on a single board computer running linux, the same support
person made the comment (to paraphrase) "How are you doing that?  We
don't support that."  Yeah, no shit.

Andy


Greg Dowd wrote:
> I don't think the issue is the competition.  In the past decade, I 
> haven't seen more than a handful of people actively trying to create 
> refclocks for the pci card.  The more likely issue is actually the 
> business model.  There is no money in it and the support cost is 
> incredibly high due to the variety of implementation skill levels and 
> supported platforms.  Keep in mind that we are responsible for 
> supporting a half dozen platforms from Windoze to VxWorks.  And there 
> are a half dozen flavors of blades as well (pci, vme, vxi).  At least 
> there used to be.  The skill level to write, maintain and support 
> native mode drivers in each of those platforms is quite high.  
> Therefore, most of the drivers leverage an abstraction tool to isolate

> the memory mapped data transfers.  Because of this, we have to blind 
> parts of the driver using binary modules.  And, in linux, we need to 
> compile for the kernel and you can see that it starts getting sticky 
> from there.  Now, the customer wants something "free" because it's 
> linux, right?  But a few, not all, of them will contact tech support, 
> and then development engineering, 25-30 times during the integration 
> of the code into their system because they type "make" and for some 
> reason, the results are not what they expected.  What the majority of 
> customers have told us is that the average cost of integration is much

> higher than buying an appliance for ntp use.  Not a little higher, a
lot higher.
>
> There are still plenty of projects (e.g., observatories or labs) where

> they reuse the card or have a custom application and they take the 
> time but there we sell a SDK with example code and support.  My guess 
> is that we still lose money but it enables the hardware so we amortize
the cost.
>
> For guys/gals who are just hacking for fun or one-off projects, I try 
> to help them out with source code or advice.
>
>
> Greg Dowd
> gdowd at symmetricom dot com (antispam format) Symmetricom, Inc.
> www.symmetricom.com
> "Everything should be made as simple as possible, but no simpler" 
> Albert Einstein
>
> -----Original Message-----
> From: questions-bounces+gdowd=symmetricom.com at lists.ntp.org
> [mailto:questions-bounces+gdowd=symmetricom.com at lists.ntp.org] On 
> Behalf Of Andy Helten
> Sent: Tuesday, May 27, 2008 8:16 AM
> To: questions at lists.ntp.org
> Subject: Re: [ntp:questions] Symmetricom BC635 reference clock for 
> linux
>
> Richard B. Gilbert wrote:
>   
>> Michael Hardy wrote:
>>   
>>     
>>> Has anyone developed the reference clock to the symmetricom BC635PCI

>>> card under linux? There was chatter on this but the thread ended. 
>>> The
>>>       
>
>   
>>> name Rob appeared in the thread an it appeared he developed the 
>>> driver. I would greatly appreciate help getting this reference clock

>>> since symmetricom appears to have no interest in providing one
>>>
>>> Thanks
>>> Mike Hardy
>>>     
>>>       
>> I think there is an NTP driver for this device.  For the hardware 
>> device driver, you will have to look to Symmetricom or write your
own.
>>     
> Writing
>   
>>   a hardware device driver is not for the faint at heart!  You need 
>> an
>>     
>
>   
>> excellent knowledge of how the hardware works and how the O/S you are

>> using interfaces with devices. An error in a device driver has the 
>> potential to crash the system!
>>
>> I'm fairly certain that Symmetricomm offers some software support 
>> (device drivers, etc.) for some operating systems and hardware 
>> platforms but you will need to get the details from them.
>>     
> NTP has BC635 reference clock support as of version 4.2.4p0 in 
> refclock_bancomm.c.  The reference clock support does expect the 
> Symmetricom driver, but it wouldn't be difficult to write one since 
> the only real support needed is reading the time register.  No 
> interrupt support is needed and, depending on your IRIG setup, 
> possibly no BC635 configuration is necessary.  However, the 
> Symmetricom device driver for linux was only $250 one year ago, so it
is hardly worth your time.
>
> One hint if you purchase the Symmetricom driver is that you will need 
> to convert their static library (.a) into a shared library for use 
> with NTP.  Then configure NTP to use that shared library.  This 
> prevents modifying NTP to use the static library.  Symmetricom 
> provides no help in this arena (I asked originally) because, to 
> paraphrase them, they would be competing with themselves if they 
> helped other folks build NTP time boxes.  Nice, huh?
>
> Andy
>   




More information about the questions mailing list