[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FW: RE: And the Winner Is.../faster stll?
I am using the gcc compiler. things may work just a little
different if you use some other compiler.
One nice thing about having the work done in an OS lever
device driver i that all the normal utility programs will
work with the TASS RAM buffer card. For example
cat /dev/mkIV/ > imagefile.raw
Will read the buffer to a disk file.
Below is the relevant snippet taken from the Linux device driver
for the RAM buffer card. It is more complex then needs be
because the driver supports multiple cards per computer, as
many as will physically fit in. So the index variable "card"
is either 0, 1, 2,... Just assume card == 0. Also this
driver allows the user to request < 16MB of data so he can
read out say 2Kb at a time and overlap RAM readout with disk I/O.
For your use you could replace all the parameters to "insb" with
constants. Also if "data_buffer" is your image array you can
skip the code the follows the line
/* Send one block of data to the user */
In my case (A device driver) I need to move the data from
"kernel space" into the user's address space. the function
"copy-to-user" plays tricks with the i386's memory mapping
registers to make this happen.
If you read in small (~16K) blocks you can overlap reading with
writing. When you do this overlapping the entire "read from card
write to disk" takes as long as just reading from the card.
Don't wait for the last byte to come off the card before you
start writting to the disk.
"bytes_in_card" holds the number of unread bytes in the RAM card.
"bytes_to_send" is what the user asked for. It could be anything
but is subjected to a sanity check before this code is executed.
The key here is to use "insb". This translates
to a single hardware instruction that will read a block of
data from a port to a buffer.
Basically "insb()" replaces
for (i=0;i<bytes_to_send;i++){ buffer[i] = ins_b(IO_Dataport) }
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
/* Read data from card */
IO_dataport = 1+Base_IO_Addr[card];
insb(IO_dataport, data_buffer, bytes_to_send);
bytes_in_card[card] = bytes_in_card[card] - bytes_to_send;
/* Send one block of data to the user */
if(copy_to_user(user_buffer, data_buffer, bytes_to_send))
{
/* ERROR Not all bytes where sent */
if (Debug)
{
printk(KERN_INFO "mk4: EFAULT (%d)\n", __LINE__);
}
return -EFAULT;
}
/* return bytes moved */
return bytes_to_send;
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> -----Original Message-----
> From: Robert Creager [mailto:Robert@CarolineCreager.com]
> Sent: Monday, February 05, 2001 1:00 PM
> To: CAlbertson@primeadvantage.com
> Cc: Tom Droege
> Subject: Re: FW: RE: And the Winner Is.../faster stll?
>
>
>
> Chris,
>
> I eagerly await your code snippet. I indeed am reading out a byte
> at a time. I'm very curious as to how you're doing this. I'm doing
> Win32 programming... BTW: If you could make the file as small
> as possible, as I'm on an error prone 26,400 connection...
>
> Tom, could you make sure this gets to Chris's daytime e-mail
> and/or the list? I'm forwarding the list from work, and as you can
> see, his e-mail didn't come through the forward.
>
> Thanks,
> Rob
> >
> >
> > -----Original Message-----
> > From: Albertson, Chris
> > Sent: Monday, February 05, 2001 7:42 PM
> > To: 'tass@listserv.wwa.com'
> > Cc:
> > Subject: RE: And the Winner Is.../faster stll?
> >
> >
> >
> >
> > Rob,
> >
> > Email me and I'll send you a little snippet of code that
> > reads out the RAM buffer in about 8 seconds. If you are
> > reading out the card with a byte wide read infor a "for
> > loo" this will go about 5x faster. If you are already
> > reading by the same method I use then it is just that
> > Windows is dog slow. My P100 beats Tom's K500 by about
> > a factor of five.
> >
> > My P100 with Mk IV electronics is aailable on-line 24x7.
> > Just ask if you want access. This is a Mk IV system that
> > is intended for public access. The control computer runs
> > _both_ MS DOS 6.2 and QBASIC and RedHat Linux 6.2 (Wow the
> > same versions.)
> >
> > > -----Original Message-----
> > > From: Tom Droege [mailto:tdroege@veriomail.com]
> > > Sent: Monday, February 05, 2001 10:51 AM
> > > To: tass@listserv.wwa.com
> > > Subject: And the Winner Is...
> > >
> > >
> > > Rob now has his code working so we can compare the results:
> > >
> > > Tom QuickBasic 64.48 Seconds
> > > Rob C and CFITSIO 37.12 Seconds
> > > Andrew Pascal 35.12 Seconds
> > >
> > > All tests were made on a 500 MHz K6 in a DOS window with no
> > > other windows
> > > open. It is also run with an ALT ENTER which gives
> windows the full
> > > screen. This may make a difference. Note that the programs slow
> > > down a lot, as much as a factor of two, if a second
> window is open.
> > >
> > > Tom is not writing a .fts header so the raw files need a
> > > processing step
> > > with RawToFits with will take a few seconds per file. Note
> > > that this only
> > > takes a few seconds, so it is much faster to read a file, add
> > > a .fts header
> > > and then write it back to disk than it is to read from the
> > > memory card and
> > > write a disk file. Obviously most of the time is taken
> > > reading the memory
> > > card with an 8 bit wide I/O instruction.
> > >
> > > Rob is using C and CFITSIO which wirtes out an "official"
> > > looking .fts
> > > header. He is also writing out some test data so it is
> > > possible that the
> > > program will speed up a little when that is removed.
> > >
> > > Andrew is coding in Pascal and makes up his own .fts header.
> > >
> > > It looks like we are running up against the brick wall of the
> > > I/O speed. I
> > > am curious as to how Chris gets to 20 seconds.
> > >
> > > OK, this is just great and a near halving of the present run
> > > time with
> > > QBasic. It also writes out the .fts headers on the first
> pass. The
> > > remaining job is to have the program read in two files that I will
> > > write in a specified format to put arbitrary things into the .fts
> > > header. I envision a constants file which contains things like
> > > location name, lattitude and longitude, etc.. The second
> file will
> > > be changed each time the program runs and writes a file and will
> > > include things like shutter open times and RA and
> Declination of the
> > > telescope. OK, you experts will have better names for
> these files,
> > > I will fix my QBasic code to write anything requested. I
> hope I can
> > > write straight .txt files.
> > >
> > > Thanks to everyone who has worked on this so far. This will
> > > help a lot.
> > >
> > > Tom Droege
> > >
> > >
> >
>
>
> Later,
> Rob
>