Hi folks,
The important thing to remember is that the maximum latency parameter in
the registry should be consonant with the minimum residence time of the
queue in order to support duplicate product detection and rejection.
Be advised that when the reconciliation-mode registry parameter isn't "do
nothing", the command "ldmadmin vetqueuesize" is kinda like cruise-control
in a car: you don't want to engage it until you're close to where you want
to be.
We run 180 GB queues here, but we get everything and feed many.
--Steve
On Fri, Oct 1, 2021 at 4:44 PM Gilbert Sebenste <gilbert@xxxxxxxxxxxxxxxx>
wrote:
> It bases the size on what you receive per hour, as opposed to what the
> feedtypes are. It tailors is it just for that server.
>
> Gilbert
>
> > On Oct 1, 2021, at 4:22 PM, Patrick L. Francis <wxprofessor@xxxxxxxxx>
> wrote:
> >
> >
> >>
> >>
> >> "ldmadmin vetqueuesize" will adjust your queue size and block size
> based on your hardware and what you are taking in each hour. Let the
> software do the thinking for you. Just tell it how much time you want in
> the queue for,
> >> and it does the rest.
> > vetqueuesize is based upon minimum virtual residence time and is single
> machine and feed specific... does that address the office needs as a whole?
> .. as an upsource feed, should we be looking at variables beyond individual
> machines? :)
> >
> > do you see where i'm going here? :)
> >
> > if i have an old box running just ids|ddsplus feeds, the needs for that
> specific box will be different than one running goesr, or model data, radar
> data and so forth... plus if we are an upstream feed that other's depend
> upon, what variables should we consider?
> >
> > just think these things are important to thinka bout :)
> >
> > cheers,
> >
> > --patrick
> >
> >
> >>
> >>>
> >
>
> _______________________________________________
> NOTE: All exchanges posted to Unidata maintained email lists are
> recorded in the Unidata inquiry tracking system and made publicly
> available through the web. Users who post to any of the lists we
> maintain are reminded to remove any personal information that they
> do not want to be made public.
>
>
> ldm-users mailing list
> ldm-users@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe, visit:
> https://www.unidata.ucar.edu/mailing_lists/
>
