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: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Andy Helten
> Sent: Tuesday, May 27, 2008 8:16 AM
> To: [email protected]
> 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
>   

_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.org/mailman/listinfo/questions

Reply via email to