RE: Making the present code run faster

["Albertson, Chris" <CAlbertson@primeadvantage.com>]

The longer term solution of course is to have software
that takes effectively zero time to write the data to disk
by over lapping the disk writes with other operations.
This can be done.  It takes just seconds for my driver to
save an image.

Given enough RAN even Windows98 and BASIC can do this.  Try
turning on  "write caching" in Win98.  This will delay disk
writes.  The default is to wait for each write to complete 
before doing anything else.  Caching writes should speed things
up quite a bit.

> -----Original Message-----
> From: aah@nofs.navy.mil [mailto:aah@nofs.navy.mil]
> Sent: Monday, January 29, 2001 8:20 AM
> To: tass@listserv.wwa.com
> Subject: Re: Making the present code run faster
> 
> 
> From Michael's description in the troubleshooting notes,
> it sounds like he was reading the CCDs in reasonable time,
> but taking five minutes instead of one minute to _write_ the
> image to disk.  So I think Tom's request to speed up the
> reading loop is the wrong one to fix.  Michael, is
> this right?
>   Then it is not a question of CPU speed, but rather disk
> speed or some interaction between the BASIC code and disk
> writing.  It is often better to just upgrade the computer
> than play with these problems.  Remember: Tom's BASIC program
> is just there for testing things, not to run the Mark IV
> in a production mode.
>   Regarding Andrew's tests:  using Pascal or any other
> language for reading or storing is fine, as long as it
> can be linked to BASIC or shelled from BASIC.  Rewriting
> Tom's entire BASIC code is not the proper way to proceed,
> as Tom needs to make changes and doesn't want to learn
> a new language.  I'd say at most a program needs to be
> written that, after the BASIC program has detected a block
> done, is started and reads the memory card and writes a
> primitive FITS file before returning to BASIC.  You could
> get a little more complex and have the new program read
> the log file to get temperature, exposure times, etc.,
> but you soon run into handshaking problems that are probably
> not worth solving at this point.
> Arne
>