[ntp:questions] Symmetricom BC635 reference clock for linux

Greg Dowd GDowd at symmetricom.com
Tue May 27 21:17:27 UTC 2008


I suppose you're right but since I made all the expensive ones
(bancomm/datum) I haven't really noticed.  We always felt like the
multi-decode, multi-encode general purpose boards, which are a lot more
expensive to design and maintain, were better products for our long term
customer base.  Learn one, learn them all.  I can honestly say that the
basic architecture across the vme,vxi,sbx,at,sbus,pci,pmc,etc was
maintained in the 635 and 637 lines and continues to this day inside
boxes like the SyncServer.  Much like ntp, a lot of refinement and
testing went into the separation of control plane register access from
packet transfer space which provides a more deterministic response over
any bus architecture in any config mode.  It's actually kind of silly
the way we still use 8 bit data transfers which emulate the hardware
fifo from the vme days.  But believe me, it's robust.

Having said that, the software was always the sore point.  In the old
days, software just enabled the sales of hardware.  Call it the Xilinx
model.  Once PCI and Win32 showed up, the software became a requirement
as most people using Windoze couldn't write their own 32bit driver but
we still didn't invest in a large sw group to develop and maintain the
drivers.  Now, most people know our hardware via some software interface
but we still haven't inverted the model towards software.

The interface for our hardware is defined in the user guides that come
with every board.  And we do have software for most platforms.  Buy a
card, you get a driver disk with Windoze drivers and applications to
control the ops on the board.  But, the driver uses an abstraction tool
that limits how we can use it.  We can't let people write software
against it unless we provide a library, or control utility that limits
the application due to licensing issues.

In linux land, I wrote a native mode driver in 2.2 and 2.4 days along
with a toolkit of sorts and the product managers did hand that out on a
per case basis.  I made them do it to ensure that they told the customer
many, many, many times that the code is AS IS and they were on their
own.  Still didn't work but it did limit the interruption somewhat.  I
haven't updated the driver to 2.6 but it's not too tough if you know
what you're doing.  I still hand out that code occasionally.  I went
through the GPL hurdles here in Symmetricom to ensure that we were okay
to distribute.  Turns out that no matter what I say, there is quite a
lot of legal precedent stating implicit support with any corporate
sponsored distribution.  I know that the world is changing but legal
departments are very conservative by design.




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 David L. Mills
Sent: Tuesday, May 27, 2008 12:27 PM
To: questions at lists.ntp.org
Subject: Re: [ntp:questions] Symmetricom BC635 reference clock for linux

Greg,

Not to put a blunt point on it, but Symmetricom did buy out all the
competition and skewed the product line toward extremely expensive
solutions. Why not put up candidate source code with appropriate
disclaimers, including no support whatsoever?

Dave

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: 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
> questions at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/questions

_______________________________________________
questions mailing list
questions at lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions



More information about the questions mailing list