🚀 go-pugleaf

In <ben.3472@epmooch.UUCP> ben@epmooch.UUCP (Rev. Ben A. Mesander) writes:

>>In article <1990Nov16.104712.20944@phoenix.pub.uu.oz.au> proff@phoenix.pub.uu.oz.au (Frederick Solidus) writes:
>>I know the 1.3.2 PIPE: device overflows if asked to preform something like
>>downloading a 10k+ plus file to pipe: as one "lharc x pipe:"'s but does
>>the dpipe: device on dnet have this problem?

>At a guess, the pipe device probably has something like a 2K buffer. If
>you don't read out of one end with lharc faster than the terminal program
>is dumping to it, you're gonna have problems. If dpipe: comes with source,
>I'd just try increasing the internal buffer size. The pipe device can't
>very well tell your terminal program to stop transferring the file while
>it catches up! 

No, I have worked out the problem, and it may just work with jrcomm now.
I could not understand why, even if I started the recieve end of the pipe:
first, it would still overflow. The piping obviously was faster than the
modem transfer (v22). But The terminal programs I usedm buffered 8 k or so
of serial data, before writing, in an attempt to save disk-over-use. This
means that 8 K was transfered at internal speeds, and thus over-flowed
the pipe buffer. (I also gave lharc a 35k input buffer, but it seems that
internal pipe fill is faster than drain)

If anyone has pipe: or dpipe: source, if they wouldn't mind recompiling it
so that the buffers size is configerable from "mountlist", I would be pleased



Proff/The Force

Dont't trust the mail header! Use   munnari.oz!labtam!eyrie!phoenix!proff
or the path.