This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
On Tue, 15 Jun 1999, Pete Pokrandt wrote: > In a previous message to me, you wrote: > > >Pete, > > > >I would take some of the options out: > > > > > >-make your queue size 100MB > >-reboot the machine. > > > > Robb, > > Just an update on my irix 6.5 queue corruption problems. I had > increased my queue size to 180 Mb and things were running along > just fine, until Friday June 4 (when I left on vacation of course..) > when the ldm tried to increase the size of the queue. As soon as > that happened, corrupt queue and crash. Pete, A little more info, the queue isn't actually corrupt even though there are assertion messages in the logs. The queue growing conflicts with pqexpire and it hangs the ldm but usually the queue is OK. We have increase the time pqexpire runs from 5 to 20 minutes to avoid the conflict. The other alternative is to make the queue higher then the high water mark, which you already have done. Another option is to build from source in ./configure modify "#define _NOGROW 1" Robb... We were down for 2 days > until I got logged in from my folks house and restarted it. > > Made the queue 200 Mb and that was fine til yesterday, it tried > upping again and boom. Same deal. I don't know if this problem > is specific to something about *that* machine or not. I have > another SGI that I will put 6.5 on also and play around with it > a bit, though I will eventually upgrade that one (and possibly > this first one too) to 6.5.3 and see if that changes anything. > > To sum up, on my SGI running IRIX 6.5, I currently have my > queue size set at 250 Mb to handle all UNIDATA feed (DDPLUS, > HRS,MCIDAS,IDS), WSI 1+3floaters, and NLDN feeds. 250 is > a bit more than enough, 200 is not. Any time the ldm attempts > to increase the size of the queue, it gets corrupted and the > ldm dies. It seems that the volume of data coming through > NOAAPORT keeps increasing, so this may continue to be a problem > for a while.. > > Pete > > > -- > +>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<+ > ^ Pete Pokrandt V 1515 AOSS Bldg 1225 W Dayton St^ > ^ Systems Programmer V Madison, WI 53706 ^ > ^ V address@hidden ^ > ^ Dept of Atmos & Oceanic Sciences V (608) 262-3086 (W) 222-0919 (H) ^ > ^ University of Wisconsin-Madison V 262-0166 (Fax)262-3086 (VM)^ > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<+>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+ > =============================================================================== Robb Kambic Unidata Program Center Software Engineer III Univ. Corp for Atmospheric Research address@hidden WWW: http://www.unidata.ucar.edu/ ===============================================================================