[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GEMPAK #GSX-256823]: garp model plan view initialization



Neil,

the longest delays I see on my system are for RUC and RUC II - each take 
approx. 30 seconds to load around 288 available times from 48 files (in 
$MODEL/ruc, "RUC" are YYYYMMDDHH_ruc211.gem and "RUC II" are 
YYYYMMDDHH_ruc236.gem.

do you have the same number of files on $MODEL/ruc and the same # of available 
times when selecting these?  which models generate the longest delays and how 
many times/files are there to load?  if you're not archiving these gem files 
further back than is preserved on my system and are experiencing such long 
delays, we may have to look at how GARP is reading/loading the header info form 
these files.  if you have a high number of gem files archived then perhaps 
trimming down that number (if it's an option) would help.  I don't devote much 
time to GARP, but if there is something easy to change code-wise that can help 
you, I'll certainly look into it.

Best,

Michael James
Unidata User Support


> gempak 5.11.4 - may 2110
> 
> The model plan view window takes a long time to create the list of available 
> times for a given model selection -- the first time a selection is made 
> during a given garp session.
> 
> I see with the '-verbose 5' option to garp invocation that during the wait 
> time garp is opening and reading the oldest relative model file. If it's a 
> CONDUIT source model, for example, that can take quite some time, relatively 
> speaking. But then there is a further long wait during which the 'verbose' 
> output is not informative but that culminates in the filling out of the 
> available times, garnered from all of the rest of the model files in the 
> source directory. Again, this wait time is next to nothing for a follow-on 
> listing of the same model during the same garp session, like the info is 
> cached.
> 
> Since these wait times can be anywhere from 30 seconds to several minutes, 
> this doesn't seem like a programmer's intended outcome, and is certainly an 
> unacceptable nuisance during an instructional lab with 20+ student 
> workstations hitting the same data source. (these kinds of delays have 
> occurred even when there is only one garp process running). Watching the 
> workstation network load during the model selection process, I am seeing 
> 100's of MB being transfered. Are all of the model files in the (NFS shared) 
> data source directory being read by the garp process on this NFS client 
> workstation?
> 
> I've been trying to determine where the bottleneck is in our setup here but 
> haven't been able to determine anything for certain.
> Can you describe what garp is supposed to be doing during this model 
> selection process and explain what kinds of things you expect will make the 
> wait times long?
> 
> Thanks,
> -Neil
> 
> 
> ---
> Neil Smith         address@hidden
> Comp. Sys. Mngr., Atmospheric Sciences
> 
> 
> 
> 
> 


Ticket Details
===================
Ticket ID: GSX-256823
Department: Support GEMPAK
Priority: Normal
Status: Open