[Dxspider-support] FW: Spider Performance & Bug with >= 10 GH z Spots from AK1A nodes

[Dirk Koopman]

On Wed, 2002-05-22 at 10:22, andy.rj.cook at bt.com wrote:
> Hi Dirk,
> 
> Thanks for that. Dumped field attached.
> 
> 1022059042^<- I GB7DXM
> PC11^10368830.^GB3MHX^22-May-2002^0917Z^test^G4PIQ^GB7DXM^H99^~
> 1022059042^PCPROT: bad field 1, dumped (f, m, d, t, m, c, c, h)

Yep. It is an 'invalid' spot.

This is an AK1A issue (I am presuming) because it (obviously?) has a max
length for the frequency. 

10368830.^ should read: 10368830.0^

Now, what to do about this is a bit of a moot point. I am pretty certain
this is a relatively recent phenomenon. It may be version related? 

There is no intrinsic limit to the size of the frequency in Spider as
such, but I expect it to be a valid decimal number because other
implementations have garbled the QRG in some quite inventive ways. I
expect from a perl point of view it also has to fit into an double (so
it can't get too big without losing precision).

> 
> Interesting on your config - didn't think it was dramatically different to
> our. I said RedHat 6.0, but now am not 100% sure, but can't recall the
> command to check it since you don't see it on SSH login! top shows that when
> the system goes into deep thinking mode it is unsuprisingly perl  that is
> taking all the process time (around 85%). I guess we need to make sure we
> may need to make sure that we have as up to date a version of perl as
> possible.

cat /etc/redhat-release

will tell you what version of redhat you are running. I would recommend
upgrading if it is RedHat 6.0.

perl -v

will tell you what version of perl. I use 5.6.1 (the current 'stable'
release).

> 
> Also oddly having some problems with console not terminating properly when
> doing a 'b' at the spider command line. The process will sometimes (about
> 50% of time) hang and sit eating significant chunks (15%) of CPU time. Dies
> when you close the SSH session of course.

I am now pretty much certain that this is an issue with glibc 2.0 and/or
2.2.x kernels or earlier.

This NEVER happens for me. Another reason to upgrade. It may also be a
issue that there is a 'knee point' of some kind in perl performance v
CPU speed (although I can't say I have noticed). 
 
> 
> Finally planning to turn off DXM in the next week or so (I know we've been
> talking about it for a long time......!), but its just finding the time!
> 

And what will your users say about that? And anyway, it all runs on the
same machine :-)

Dirk
-- 
Please Note: Some Quantum Physics Theories Suggest That When the 
Consumer Is Not Directly Observing This Product, It May Cease to 
Exist or Will Exist Only in a Vague and Undetermined State.