<div>With performance like this with Dx Spider software, it is very surprising to me that Dirk is looking into using a database for dx spots.</div> <div> </div> <div>AR Cluster uses a database for dx spots. This database must be trimmed on a monthly basis to 30 days worth of data or else the cluster takes a huge performance hit. After the trimming, the cluster must be shutdown, then the trimmed database must be compacted, the old one moved out of the way and then the cluster restarted.</div> <div> </div> <div>Some ARC sysops do not do this. You can easily tell which ones. You connect to their cluster, do a sh/dx and wait 60 seconds for a reply. Most users grow impatient and figure the cluster has not received their request, so they send it a couple of times more. Then the cluster is completely locked up for 3 minutes, and no one else can do anything.</div> <div> </div> <div>Lee</div> <div> </div> <div>On
Wed, 2006-03-22 at 15:20 +0100, Robert Chalmas wrote:<BR>><I> Well, this depends on the performances of your PC!<BR></I>><I> <BR></I>><I> I agree with Tom for slow machines. With a recent one<BR></I>><I> (around 3 GHz and 1 GB memory) a much higher value is possible.<BR></I>><I> <BR></I>><I> We use 1000 days at HB9IAC-8 and have no problems (the maximum<BR></I>><I> search time is around 3 seconds).<BR></I><BR><BR>><I> > You can set/var $Spot::maxdays = ###<BR></I>><I> > The default is 100 days. But I would think very seriously about<BR></I>><I> > making <BR></I>><I> > it much longer. Certainly not 5 years.<BR></I><BR>><I> > ----- Original Message -----<BR></I>><I> > *From:* Simon Ravnic <mailto:<A href="http://mailman.tobit.co.uk/mailman/listinfo/dxspider-support">simon at hamradio.si</A>><BR></I><BR>><I> > <BR></I>><I>
> A user is bugging me, so I have to bug you :)<BR></I><BR>><I> > Search e.g. sh/dx goes back only three months, although cluster has<BR></I>><I> > data on disk since 2001. Can we change this limit and how?<BR></I>><I> > <BR></I><BR>Memory, as such, is not an issue here, but speed of CPU is. To check<BR>that it is not too much you will need to experiment. Try some values in<BR>the "set/var $Spot::maxdays = nnnn" and then do a "sh/dx QQ01" and see<BR>how it takes to come back with a prompt. <BR><BR>As this program is single threaded, the time that it takes between a<BR>sh/dx and the prompt coming back is 'dead time' during which nothing<BR>else can occur.<BR><BR>I said, earlier, that memory wasn't an issue - that was a slight lie as<BR>subsequent tests on "sh/dx QQ01" may well be faster if you have a lot of<BR>excess RAM as the files will remain cached in RAM by the
operating<BR>system.<BR><BR>Dirk G1TLH<BR><BR></div><p>
<hr size=1>Yahoo! Mail<br>
Bring photos to life! <a href="http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=39174/*http://photomail.mail.yahoo.com">New PhotoMail </a> makes sharing a breeze.