[Css-csts] FW: Ambiguous specification of CLTU transfer buffer
behavior
Boxell, Jeff
jeff.boxell at lmco.com
Mon Jun 2 11:07:15 EDT 2008
Thanks John,
It hasn't caused us any operational problems because we spotted the
difference in the implementations early on and we had Vendor A change
their implementation to match vendor B. Our CLTU buffer monitoring is
tuned to reduce latency at the ground site yet provided sufficient
buffering to overcome jitter in the WAN between the user and provider.
When we first started running with vendor A's provider, we noted that
its buffer level consistently ran 1 CLTU lower than vendor B's
implementation. That is the operational impact one would see. The
impact of this difference is dependent on how finely tuned one's buffer
monitoring algorithm is. Since we have to maintain continuous output
with no underflows and still meet a fairly strict latency requirement,
we are likely more sensitive to a 1 CLTU difference than most
(particularly when we run at our 18K low-rate setting where only 1 or 2
CLTUs is ever being buffering).
At a minimum, I would hope that a paragraph could be added alerting SLE
readers of potentials differences in the CLTU buffer reporting
implementation.
-----Original Message-----
From: John Pietras [mailto:john.pietras at gst.com]
Sent: Monday, June 02, 2008 8:02 AM
To: Wolfgang.Hell at esa.int
Cc: css-csts at mailman.ccsds.org; Boxell, Jeff; Erik Barkley
Subject: RE: [Css-csts] FW: Ambiguous specification of CLTU transfer
buffer behavior
Wolfgang,
Thanks of the quick response. As you can see, I'm adding Jeff Boxell,
who raised this issue, to the distribution list.
Jeff, has this difference caused any operational problems, or is it just
a matter of looking for consistency in implementation and interpretation
of the buffer level that's being reported back?
Best regards,
John
John Pietras
Global Science & Technology, Inc. (GST)
7855 Walker Drive
Suite 200
Greenbelt, Maryland, USA
20770-3239
Direct: +1-240-542-1155
GST Main: +1-301-474-9696
Fax: +1-301-474-5970
> -----Original Message-----
> From: Wolfgang.Hell at esa.int [mailto:Wolfgang.Hell at esa.int]
> Sent: Monday, June 02, 2008 3:43 AM
> To: John Pietras
> Cc: css-csts at mailman.ccsds.org; css-csts-bounces at mailman.ccsds.org
> Subject: Re: [Css-csts] FW: Ambiguous specification of CLTU transfer
> buffer behavior
>
>
> John,
>
> Firstly you are correct that the F-CLTU specification does not
prescribe
> any
> specific implementation of the interface between the CLTU buffer and
the
> modulator. In practice, in particular if also higher command rates
shall
> be
> reported, I would assume that most implementations will feature a
double
> buffer as to make sure that radiation of consecutive CLTUs can be
> contiguous
> without idle sequence in between except where that is imposed by the
> delay-time specified by the service user.
>
> The real-world implementations that I have seen so far all provided
ample
> buffering so that parameter cltu-buffer-available is of hardly any
> interest
> from an operational perspective as it won't be filled up anyway in any
> realistic scenario.
>
> Besides that I feel that the specification is not ambiguous in the
sense
> that
> the provider is supposed to report the available buffer at the point
in
> time
> when the CLTU-TRANSFER-DATA response is generated. I concede that
because
> of
> the unspecified input buffer to the modulator two different
> implementations
> with the same buffer capacity under the same operational condition may
> report
> different values for the available buffer capacity. I do not regard
that
> to
> be a problem.
>
> The above is my personal view on this issue and other members of the
WG
> may
> have a different view. If so, I would appreciate to get such input as
soon
> as
> possible so that I can take that into account before sending the
updated
> CLTU
> spec to the CCSDS secretariat.
>
> Best regards,
>
> Wolfgang
>
>
>
>
>
> "John Pietras"
> <john.pietras at gst.
> com>
> To
> Sent by: <css-csts at mailman.ccsds.org>
> css-csts-bounces at m
> cc
> ailman.ccsds.org
>
> Subject
> [Css-csts] FW: Ambiguous
> 30/05/2008 18:41 specification of CLTU transfer
> buffer behavior
>
>
>
>
>
>
>
>
>
>
> Members of the CSTSWG:
>
> The following email exchange describes an ambiguity encountered in the
> defined behavior of the CLTU buffer in the FCLTU specification. If you
> have
> an interest in this issue, please comment on whether the behavior of
the
> CLTU
> buffer should be more tightly defined in the FCLTU specification.
>
> Best regards,
> John
>
> From: John Pietras
> Sent: Friday, May 30, 2008 12:33 PM
> To: 'Boxell, Jeff'; css-csts at mailman.ccsds.org
> Cc: Michael Stoloff; Kazz, Greg J (X-JPL); Peter Shames; Erik Barkley;
> Fred
> Brosi; Petkevich, Michael; Kluksdahl, Norman C. (JSC-DD22); Hill,
Frank9
> Subject: Ambiguous specification of CLTU transfer buffer behavior
>
> Jeff,
> It's possible that the ambiguity that you have encountered was
> intentionally
> left "loose" to accommodate some flexibility in vendor implementations
and
> user requirements, but I am not certain of that. I'll forward the
> pertinent
> part of your note to the membership of the Cross Support Transfer
Service
> Working Group, which is responsible for maintaining the SLE
> specifications.
>
> Best regards,
> John
>
>
> From: Boxell, Jeff [mailto:jeff.boxell at lmco.com]
> Sent: Friday, May 23, 2008 11:55 AM
> ..
> Subject: RE: SLE provider
>
> ... I would like to get your thoughts on a possible upgrade to the SLE
Spec
> based the difficulties we experienced having 1 SLE User implementation
> talk
> to two different vendor SLE provider implementations (one vendor user
for
> real-time operations, another used strictly for simulations). Each
vendor
> managed the reporting of the CLTU buffer level differently. One
vendor
> extracted a CLTU to be radiated and immediately started radiating the
> CLTU;
> the other vendor extracted a CLTU and staged it for radiation so that
2
> CLTUs
> were typically outside the CLTU buffer (one being radiated, the other
> waiting
> to be radiated). To keep our buffer level management and reporting
in
> sync,
> we asked the SIM vendor to tailor their implementation to meet the
other's
> implementation and they willingly did this. Together we looked at the
> Specs
> and saw that this level of detail was not explicitly specified. Can
you
> give
> me some feedback on what might be done to prevent others from
encountering
> this problem (e.g. should I submit an update to the Spec)?
> ...
>
> Jeff Boxell
> Lockheed Martin Mission Services
> Houston, Tx
> 281-853-2240_______________________________________________
> Css-csts mailing list
> Css-csts at mailman.ccsds.org
> http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts
More information about the Css-csts
mailing list