Polymorph wrote:
> On Feb 20, 12:09 pm, "Michael J. Mahon"  wrote:
> 
>>Eric Rucker wrote:
>>
>>>On Feb 19, 4:30 pm, schmidtd  wrote:
>>
>>>>I see the exact same thing you do with having to do a bunch
of D-Esc-D-
>>>>Esc-D-Esc sequences to get the Uther version to finally connect.  I
>>>>can't seem to figure out why it won't "go" out of
the gate.  I've
>>>>tried several different things to no avail.  The client currently
>>>>sends a ping on startup (if you've previously configured the Ethernet
>>>>parameters) to hopefully cut down on the number of times you have to
>>>>do it yourself.  Maybe I should just try sending a bunch. :-)
>>
>>>Hmm.
>>
>>>Here's another thing, although I know it's not likely... on a GS, is
>>>it possible to be fast enough to pull in data while saving to disk at
>>>the same time, to take advantage of the fast CPU? Or, even if it is
>>>possible, would it just slow things down to do that?
>>
>>On any Apple II, it's not possible to do *anything* else while
>>writing to a 5.25" diskette.  Writing is done with critically
>>timed CPU loops, at the canonical "1MHz" Apple II speed.
>>
> 
> 
> 
> As Michael has pointed out, writes to disk while reading from the
> serial port are a no-go. However, a IIgs generally has vastly more
> memory available to it (2Mb+), and therefore I see a possible increase
> in performance by buffering large portions (possibly the whole file/
> image) of the serial transfer in RAM before writing to disk. I would
> expect an increase in overall throughput by not writing out to disk as
> frequently. How much of an increase I'm not sure, but I plan on
> finding out.  :-)

The time you save will be all but one of the disk "startup" times, if
currently the "transfer" phases take long enough for the disk to stop.

This leads to a peculiar situation in which both lots of short transfers
followed by disk writes and one long transfer followed by a single write
take minimal time, while a transfer length just long enough to allow the
disk to stop takes maximal time, since it maximizes the number of disk
startups.

In all cases, the total transfer time and the total actual write time
are the same (except for minor and uncontrollable rotational latency
differences at the start of each write).

-michael

NadaNet and AppleCrate II: parallel computing for Apple II computers!
Home page: http://home.comcast.net/~mjmahon

"The wastebasket is our most important design
tool--and it's seriously underused."
--- SBBSecho 2.12-Win32