Gerry Creager wrote:
> And I'll argue that anywhere that uses LDM constitutes an IDD. If I
> wanted to get pedantic, LDM is a publish-subscribe system. Pub/sub is
> the basis for all sorts of time-sensitive transaction processing, like
> the financial markets. I'm not suggesting LDM is used there, but the
> pub/sub concept certainly is, and the last time I had a grad student
> evaluate LDM for potential enhancement, that's the gold standard he and
> LDM were held to in his committee.
I understand how you may feel that your semantic argument would apply;
however, it is the definition of the program, UNIDATA, that supports and
propagates the IDD, that applied the very definition of the IDD as
"Internet Data Distribution." It is the "Internet" aspect that does not
apply in all, or possibly even most, situations. I know of several
entities that do not have Internet access, but make use of the LDM on
their private network. Tying the LDM to NTP would cripple those
applications. The LDM != IDD; in fact, the very definition of each is
nearly exclusive - i.e. "Local Data Manager" vs. "Internet Data
Distribution". If you want to play semantics. These same entities sync
their time internally - either through NTP or other methods.
> I think I could support a sanity check for a decent NTP server, and
> argue infavor of a server check. If not NIST, then to something that's
> no worse than a Stratum 2 time server. I'd make it a big, ugly warning
> (and not fail out), and see if we couldn't build some improved performance.
Again, you assume that everyone using LDM is on the Internet. That is
simply not the case . . . by a long ways. In fact, the rather myopic
view that LDM is only used for environmental data may be shattered when
you discover that several hospitals have and continue to use LDM to
shuttle MRI and other imagery around on their *private* network. And I
know of at least one market trader that uses LDM for shuttling data
around their *private* network. All of these instances use a time
server, but a local one, and most use other facilities other than NTP.
> Time stamping on Level II data's been a problem since the first days it
> was introduced in this current networking format. I hoped it'd get
> better and have lobbied for the few additional checks it'd take, but
> it's not gotten better.
And ultimately, therein lies the problem. You want to fix a behavioral
issue - bad administration on the part of someone managing a node of the
CRAFT feed - by adding yet another level of complexity to an already
robust and feature-full application. My argument would be to fix the
behavioral problem, and not make it a technical one.
