ARPAVAX:C70:info-cpm (08/25/82)
>From w8sdz@BRL Tue Aug 24 23:44:43 1982
This was sent to Info-Micro instead of Info-Cpm. I am forwarding
it to save Ted the trouble of retyping the message. Replies to
address below, please...
----- Forwarded message # 1:
Mail-from: DECNET site ECLD rcvd at 24-Aug-82 1840-PDT
Date: 24 Aug 1982 1837-PDT
From: Ted Shapin <BEC.SHAPIN.USC-ECLD@Usc-Ecl>
Subject: MODEM221 Overrun Problems
To: info-micro at Brl
cc: BEC.SHAPIN.USC-ECLD at Usc-Ecl
Mail-Address: 2500 Harbor Blvd., Fullerton, CA 92634
Phone: (714) 970-3393
Via: Usc-Ecl; 24 Aug 82 21:44-EDT
Via: Brl; 24 Aug 82 21:49-EDT
Via: Brl-Bmd; 24 Aug 82 21:56-EDT
I have been fixing some things in MODEM TOPS20 and experienced the same
inability of MODEM221 to recover after receiving 80H sectors and giving
an overrun message. That is 16K on the CP/M disk and CP/M BDOS needs to
get another extent and takes more time before it is ready to receive.
Operating at 1200 baud, I get this error every time regardless of how
lightly or heavily my DEC system is loaded. MODEM221 doesn't recover;
but an earlier MODEM207 does - - it gives one error message and gets
back in sync.
Ted.
P.S. On MODEM TOPS20 it is necessary to turn off pause on command and
pause on end of page, otherwise block 13H is treated as an X-OFF and will
stop transmission from the TOPS system. One of the mods I made is to set
this automatically on entry if the logged terminal is the one that is
connected to the modem.
-------
----- End of forwarded messagesARPAVAX:C70:info-cpm (08/25/82)
>From w8sdz@BRL Wed Aug 25 00:05:23 1982
Many MANY revisions back in "MODEM2xx" I changed the old original time-out
values to 10 seconds to allow for slow disk systems. I have a Micropolis
Mod II mini-floppy that has a 30 millisecond track-to-track seek time and
it was constantly screwing up everytime it crossed a 16k extent boundry
because it had to seek back to the directory and then back to the data
area again, and by that time the sender was already sending the next
sector. Somewhere along the line someone thought they "knew better"
and changed my 10 second values to much lower values. I have seen
them as low as 3 and as high as 7. My experience is that 10 was the
minimum reliable value for very slow disk systems and since the time-out
loop includes the input and it does not slow down the program to have it
set for 10 seconds, I see no reason to have it be less than that!
There are two timings involved in MODEM2xx. 1) the timing between
received bytes, which is set for one second maximum, and 2) the
timeout value between sectors, which as I said above should be 10
seconds.
There has been some discussion lately about some between-byte delays]
caused by heavy system load, which caused the 1-second byte timeout
to cause problems. It would probably be a good idea to consider
changing that to 3 seconds, but I wouldn't increase it too much more
because it might cause problems getting back into "sync" after some
line disturbance or over-run.