PLOUFF%mit-mc@sri-unix.UUCP (01/24/84)
From: Robert L. Plouffe <PLOUFF@mit-mc> The following message from Keith Petersen correctly and completely explains the reason for the 2k file transfer buffer. He assumed as I did that the data capture buffer (even if started at the same point) and the file transfer buffer had independent size limits - i.e, one set by the BUFSIZ equate for file transfer, and the other set by checking to see if either the CCP or BDOS (optionally) was about to be overwritten so that the whole TPA can be used on a dynamic basis for data capture. This is the way that the program always used to work. HOWEVER, it was changed somewhere along the line and it now allows the printer buffer to use the TPA dynamically and fixes both the file transfer and data capture buffers to BUFSIZ. THIS NEEDS TO BE STRAIGHTENED OUT SO THAT THE FILE TRANSFER BUFFER CAN BE SET TO 2K (THE OPTIMAL COMPROMISE AS EXPLAINED BY KEITH), AND THE DATA CAPTURE BUFFER ALLOWED TO USE THE TPA WITH A COMPROMISE SIZED PRINTER BUFFER (FIXED) [4K OUGHT TO BE ENOUGH]. If I understand the mail correctly, Ron Fowler is working on this, or some variation, and it will hopefully be in MDM718. In the mean time, the only thing that can be done is to leave the BUFSIZ equate set at 16 as Hoff has done in MDM717. Do make sure to SAVE 69 after patching with DDT as Keith has repeatedly warned because ever since MDM715, the program has been larger than indicated in the overlay patch files. Forwarded message: ------------------------ Date: Wed, 11 Jan 84 21:40:07 EST From: Keith Petersen <w8sdz at brl-bmd> To: Charlie Strom (NYU) <strom at brl-bmd> cc: Chan.CST at hi-multics, INFO-CPM at brl-vgr Re: buffer size in mdm716 Please tell Irv Hoff that Bob Plouffe and Ron Fowler already have MDM717 "in progress" and we should have something forthcoming from them with these fixes in about a week. I'd hate to see all that good stuff that Bob Plouffe put in MDM716 "stripped out" by Irv "because he doesn't agree with it" or "doesn't like it". That's how we lost the "retry after ten errors" option, amoung other things. On the subject of the 2k buffer size. This is true ONLY for the protocol file transfer mode. It does not affect the terminal capture mode. It was done after NUMEROUS complaints from people with slower disk systems which took so long writing the 16k buffer out (and consequently closing that extent and opening the next in the directory) that they lost the next sector and several tries from the sender. In many cases this caused the transfer to abort. The 2k buffer was chosen MANY versions back (when the program was MODEM2) as an acceptable compromise between disk access speed and the improvement in receiving speed by putting the characters into the buffer instead of writing every sector (which was the way Ward Christensen's old origithe disk. -------------- End of forwarded message..