umh@vax5.cit.cornell.edu (04/17/91)
In article <3745@ux.acs.umn.edu>, oleary@ux.acs.umn.edu (Doc O'Leary) writes: > In article <1991Apr13.014000.29394@sbcs.sunysb.edu> dtiberio@eeserv1.ic.sunysb.edu (David Tiberio) writes: > >> For example, open up a terminal program, such as ZTerm. Then start sending >>a big file. Next, open a DA. The terminal will stop sending. In fact, even >>by selecting a menu or the title bar of a window you will freeze the terminal >>sending process. This is not good. > > I just downloaded the new TrueType fonts with ZTerm in the background without > a hitch. I've done background downloading in System 6.0.3 - 7.0b4 without > any problems. Are you using the current version? > > Something tells me Dave doesn't even own (perhaps never used) a Mac. Not a > flame, but I wish that kind of misinformation didn't get posted. While any > experienced Mac user will know it to be false, there are some new-comers or > potential new-comers that will believe it, wasting their time waiting for > a download to complete and having, perhaps spreading, a misconception of > what a Macintosh can and can't do. > 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. Maynard Handley
jackb@MDI.COM (Jack Brindle) (04/18/91)
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
dtiberio@eeserv1.ic.sunysb.edu (David Tiberio) (04/22/91)
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: >> In article <1991Apr13.014000.29394@sbcs.sunysb.edu> dtiberio@eeserv1.ic.sunysb.edu (David Tiberio) writes: >> >>> For example, open up a terminal program, such as ZTerm. Then start sending >>>a big file. Next, open a DA. The terminal will stop sending. In fact, even >>>by selecting a menu or the title bar of a window you will freeze the terminal >>>sending process. This is not good. >> >> >> Something tells me Dave doesn't even own (perhaps never used) a Mac. Not a Of course, I both use and own a Mac Plus and an SE/Superdrive. :) >> flame, but I wish that kind of misinformation didn't get posted. While any It was not misinformation. I never use Multifinder, because I only have 2.5 megs of ram and two floppy drives on my Plus (Ithink I tried to use Multifinder only once on this computer). Second, I tested it out again today, while sending some files between two computers (in the same room via null modem, 19200 baud). I found that opening a DA temporarily freezes downloading, then severely cripples it. I watched it drop from 96% to about 56% before I got bored with it. >> experienced Mac user will know it to be false, there are some new-comers or >> potential new-comers that will believe it, wasting their time waiting for >> a download to complete and having, perhaps spreading, a misconception of >> what a Macintosh can and can't do. >> > >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. > >Maynard Handley -- David Tiberio SUNY Stony Brook 2-3481 AMIGA DDD-MEN Tomas Arce Any students from SUNY Oswego? Please let me know! :) Un ragazzo di Casalbordino, Italia.