Hi,
During the last week I have been trying to get closer to an
understanding of what I should expect of CSPP now and in the future,
concerning latency for VIIRS RDR to SDR processing. At SMHI we see
CSPP processing times varying somewhere of around 30 to 45-50 minutes
(wall clock time), for one locally received NPP VIIRS scene (RDR
file), which has hindered an operational implementation so far. (We
need a latency of no more than 5 minutes.)
I have understood that these are the figures also seen at other DB
centers (DMI and FMI, and EUMETSAT). I have put forward these figures
to NOAA and Raytheon at the conference, but have been met mostly by
surprised faces, and figures that would indicate that the RDR to SDR
processing should be faster. Today I spoke to Mitch Goldberg who
showed me a presentation by Liam Gumley at the last TOVS conference.
You can find the presentation here:
http://cimss.ssec.wisc.edu/itwg/itsc/itsc18/program/files/Gumley_CSPP_ITSC18.pdf
At slide 13 it says the following:
"Nigel Atkinson recommends dual Intel hex-core 3.06 GHz
CPUs and 64 GB RAM (10 min. VIIRS pass processed in 10 min)."
So, maybe Nigel can comment and explain on this?
"dual intel hex-core" doesn't really help much in the case of CSPP as
it is not threaded!?
We have 4xIntel Xeon Hex-core 2.67GHz, so I wouldn't expect a factor
of 4 difference.
The only alternative I see to get the SDR with something that comes
close to a reasonable latency (~3-4 minutes) would be to feed several
CSPP instances with smaller segments/granules. But that I think
remains to be seen how it can be done in a proper way. And if it is
doable, it should definitely be documented and shared with the DR-
community!
I think we really have to join forces to support a DB package that can
meet our requirements for Direct Readout!
PS: Apart, from giving even more headache concerning VIIRS SDR
processing, It was a really good conference! Thanks to all the nice
people I met (again)!
Best regards from Sopot!
Adam