Robert_Toxen@harvard.harvard.EDU (05/07/87)
CU's low performance is, in deed, due its reading a character at a time.
It should be easy (for those with source) to modify it on System III/V and
possibly 4.2/3 BSD to read, say, 64 characters at a time and to do an
ioctl() for the system to buffer up 64 characters at a time with a maximum
delay of .1 or .2 seconds (VMAX=64 VTIME=1 or 2).
Bob Toxen
Stratus Computer, Marlboro, Mass.
{ucbvax!ihnp4,harvard}!anvil!bob (Please use THIS address to reply)
"Just say NO to drug TESTS; say YES to the Constitution."akf@blic.BLI.COM (Andrew Fullford) (05/08/87)
In article <7284@brl-adm.ARPA>, anvil!es!Robert_Toxen@harvard.harvard.EDU writes: > CU's low performance is, in deed, due its reading a character at a time. > It should be easy (for those with source) to modify it on System III/V and > possibly 4.2/3 BSD to read, say, 64 characters at a time and to do an > ioctl() for the system to buffer up 64 characters at a time with a maximum > delay of .1 or .2 seconds (VMAX=64 VTIME=1 or 2). > I did this on a 3B5 running V.2.2 with VTIME=1 and saw a 40 fold cpu time improvement on cat'ed text. No more stutttttering when somebody typed cc.
mikel@codas.UUCP (05/11/87)
>> i have always wondered why they cannot add a >> %bintake >> and %binput >> under cu and have it invoke uucico on both sides to >> do the uucp-type protocol. You can get the new version of C-kermit which will co-exist with cu on a system (ie: will create & obey locks) very well. It will also let you transfer a non-ascii file using the kermit error checking protocol (and much more). Cu is really a dog. If anyone has a StarLan that they are still using cu on, please write me. I have written an "rlogin" program that increases the troughput drastically over cu's 1 byte/packet nonsense. -- Mikel Manitius @ AT&T-IS mikel@codas.att.com.uucp Copyright 1987. Redistribution via Stargate PROHIBITED