Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!uunet!mdisea!jackb
From: jackb@MDI.COM (Jack Brindle)
Newsgroups: comp.sys.mac.system
Subject: Re: Downloading *is* flaky on the Mac
Message-ID: <1991Apr17.191043.4038@MDI.COM>
Date: 17 Apr 91 19:10:43 GMT
References: <1991Apr13.014000.29394@sbcs.sunysb.edu> <3745@ux.acs.umn.edu> <1991Apr16.215821.4081@vax5.cit.cornell.edu>
Sender: news@MDI.COM
Distribution: comp
Organization: Motorola, Mobile Data Division - Seattle, WA
Lines: 43

In article <1991Apr16.215821.4081@vax5.cit.cornell.edu> umh@vax5.cit.cornell.edu writes:
>In article <3745@ux.acs.umn.edu>,
>oleary@ux.acs.umn.edu (Doc O'Leary) writes: 
>
>While the first poster's contention is not quite true, the second poster is
>glossing over the problem. It is simply NOT TRUE that I can set up a background
>download then do what I want on my Mac. There's no way I could then format a
>floppy, or rearrange my harddrive with Sum Utilties, or run any program that
>prevents context switching for long periods- eg load in a 1Meg MS Word file
>then save as text. I susect I would get a timeout even if I simplt tried to
>copy enough files to floppy at once using Finder. Now many of these problems
>are hardware related because Apple would rather leave out autonomous chips on
>the motherboard than break into their 50% profit margin, and they could not be
>cured no matter how wonderful the OS, but they are real problems. On a Sun I
>don't have to watch each thing I do while using a modem to ensure that transfer
>is not aborted- on my Mac I do.
>
>Also rather than screaming at this poor guy, remember that we all have
>different Macs. When I was using an SE and that SLOW hard drive Apple provide
>with it I could do practically nothing while downloading- timeout was too easy.
>Moving to a much faster hard drive made things better, as did moving to an
>SE/30. Additionally some protocols are more robust than others. Xterm seems
>very quick to die on one, while Kermit is very robust. I imagine timeout
>periods are also settable by each individual BBS etc. Maybe Dave has been
>having experience with BBSs which have their X or Zmodem timeouts set much
>lower tha the BBSs Doc uses.


The background downloading "problem" is actually a matter of implementation. Macs
(all the way back to the 128) CAN do background transfers with very little
interference from other tasks. The only exception I can think of is disk formatting.
The problem is that the folks who wrote the transfer protocol handlers (me included)
just didn't code them to run entirely in the background. It is quite possible to
code the transfers as serial driver asynchronous routines (meaning they run at
the interrupt level). I have done it; it runs quite nicely. It has a big benefit
also - transfers run MUCH faster. I have seen efficiencies over 95% on xmodem
transfers between Mac IIs at 19200 baud. Of course now we need to figure out how
to get the Sparc that sits on my desk to handle transfers this fast ;-).
So, it's not the Mac. Its the software implementation. Yell at the protocol
writers. We ARE listening...

Jack B.
ham radio: wa4fib/7