davidsen@steinmetz.ge.com (William E. Davidsen Jr) (03/04/89)
I have found what appears to be a major problem in MicroPort V/AT
v2.4. We have been fighting with the clock since the system was
converted from pc/ix. No matter how the clocktic is patched, it gain or
loses time. It is also not useful as a terminal using kermit or cu,
because it fails to keep up with the input form the serial line.
Examination showed that the display rate was about 800 cps, just
enough slower than a 9600 baud connection to make it lose data
constantly. When trying to time the actual transfer rate, we created a
file with ls which was 11347 bytes long. We did a cat of it to the
screen and "time" reported 5.4 sec elapsed time for a speed of 2101
cps. The clock on the wall reported 14.2 sec, however. Repeating the
test showed that the time command was simply lying about the elapsed
time.
We then tried:
date
cat bigfile
date
and found that the date only reported 5 sec elapsed time. After the test
the time of day was slow by 9 sec! After checking it because apparent
that sending data to the console screen causes the clock to lose time.
We tried to talk to MP by phone but were unable to get a connection
good enough for (voice) data transfer. We've had that problem before.
We're trying the bbs now... we have three numbers, two of which seem to
have been disconnected, and one which has been changed. When trying the
changed number we got a voice at MicroPort. Bleah! I would like to
know: is this a problem others are having? If you send 15-20k to your
screen does your clock slow down? Do other SysV versions do this, such
as Bell Tech?
If there a trick to get the console to run at a reasonable speed?
Systems around here speak nothing between 2400 and 9600, and having to
use 2400 is pretty painful. Any info would be highly appreciated.
I would think this is of general interest, but if you disagree send
mail instead of posting.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -meshocking@physiol.su.oz (Stephen Hocking) (03/06/89)
In article <13302@steinmetz.ge.com>, davidsen@steinmetz.ge.com (William E. Davidsen Jr) writes: < < because it fails to keep up with the input form the serial line. < < Examination showed that the display rate was about 800 cps, just < enough slower than a 9600 baud connection to make it lose data < constantly. When trying to time the actual transfer rate, we created a < file with ls which was 11347 bytes long. We did a cat of it to the < screen and "time" reported 5.4 sec elapsed time for a speed of 2101 < cps. The clock on the wall reported 14.2 sec, however. Repeating the < test showed that the time command was simply lying about the elapsed < time. <........... < I would think this is of general interest, but if you disagree send < mail instead of posting. < -- < bill davidsen (wedu@ge-crd.arpa) > {uunet | philabs}!steinmetz!crdos1!davidsen > "Stupidity, like virtue, is its own reward" -me It's probably something to do with writes to the console being at a particular interrupt level. A bit of discussion was around recently about sundry people writing 1Mb to the 386 console under Xenix and having this screw up the clock something woeful. Stephen -------- Stephen Hocking ACSnet shocking@physiol.su.oz UUCP ...!uunet!munnari!physiol.su.oz!shocking