proff@phoenix.pub.uu.oz.au (Frederick Solidus) (11/16/90)
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? Proff
ben@epmooch.UUCP (Rev. Ben A. Mesander) (11/18/90)
>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! >Proff -- | ben@epmooch.UUCP (Ben Mesander) | "Cash is more important than | | ben%servalan.UUCP@uokmax.ecn.uoknor.edu | your mother." - Al Shugart, | | !chinet!uokmax!servalan!epmooch!ben | CEO, Seagate Technologies |
peter@sugar.hackercorp.com (Peter da Silva) (11/18/90)
In article <ben.3472@epmooch.UUCP> ben@epmooch.UUCP (Rev. Ben A. Mesander) writes: > 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! Um, why not? A floppy device can. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
ben@epmooch.UUCP (Rev. Ben A. Mesander) (11/19/90)
>In article <7070@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <ben.3472@epmooch.UUCP> ben@epmooch.UUCP (Rev. Ben A. Mesander) writes: >> 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! > >Um, why not? A floppy device can. Really? Try downloading a file into a directory on a fragmented Amiga floppy with a few hundred small files in it. Watch the terminal program lose characters. Watch jrcomm die. The terminal program can only hold to a certain point, then buffers start to overrun. >Peter da Silva. `-_-' -- | ben@epmooch.UUCP (Ben Mesander) | "Cash is more important than | | ben%servalan.UUCP@uokmax.ecn.uoknor.edu | your mother." - Al Shugart, | | !chinet!uokmax!servalan!epmooch!ben | CEO, Seagate Technologies |
phil@adam.adelaide.edu.au (Phil Kernick) (11/19/90)
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? What *exactly* do you mean by "overflows"? If you mean that your command seems to hang when you type it, it means that the pipe: internal buffer is full. This buffer is 4k long (it says so in the 1.3 docs). Try the following: 1> newcli 1> copy fubar.lzh pipe:l.lzh [ swap window ] 2> lharc x pipe:l Disclamier: I have not tried this but it should work. The problem may be that lharc expects a .lzh suffix? Hope this helps, Phil -- Phil Kernick EMail: phil@adam.adelaide.edu.au Departmental Engineer Phone: +618 228 5914 Dept. of Psychology Fax: +618 224 0464 University of Adelaide Mail: GPO Box 498 Adelaide SA 5001
peter@sugar.hackercorp.com (Peter da Silva) (11/20/90)
In article <ben.3504@epmooch.UUCP> ben@epmooch.UUCP (Rev. Ben A. Mesander) writes: > Really? Try downloading a file into a directory on a fragmented Amiga > floppy with a few hundred small files in it. Watch the terminal program > lose characters. Watch jrcomm die. The terminal program can only hold to > a certain point, then buffers start to overrun. That's why there are such things as "handshaking" and "download protocols". There are lots of ways to tell the system at the other end "hey! I'm out of breath here. Give me a break!". -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
proff@phoenix.pub.uu.oz.au (Frederick Solidus) (11/21/90)
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.
proff@phoenix.pub.uu.oz.au (Frederick Solidus) (11/22/90)
In <phil.658973999@adam.adelaide.edu.au> phil@adam.adelaide.edu.au (Phil Kernick) writes: >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? >What *exactly* do you mean by "overflows"? >If you mean that your command seems to hang when you type it, it means that >the pipe: internal buffer is full. This buffer is 4k long (it says so in >the 1.3 docs). >Try the following: >1> newcli >1> copy fubar.lzh pipe:l.lzh >[ swap window ] >2> lharc x pipe:l >Disclamier: I have not tried this but it should work. The problem may be >that lharc expects a .lzh suffix? >Hope this helps, >Phil No, that is nope the problem (execpt ARP tends to deal with non-filing devices poorly). This sort of overflow only occurs with downloading from a terminal program to pipe: Proff/The Force Don't trust the mail header, use munnari.oz!labtam!eyrie!phoenix!proff
koren@hpfcdc.HP.COM (Steve Koren) (11/22/90)
> >Um, why not? A floppy device can. > floppy with a few hundred small files in it. Watch the terminal program > lose characters. Watch jrcomm die. The terminal program can only hold to > a certain point, then buffers start to overrun. Try using flow control. CTS/RTS will allow most terminal programs to stop the sender while they digest the recently sent data. - steve
ggk@tirith.UUCP (Gregory Kritsch) (11/24/90)
koren@hpfcdc.HP.COM (Steve Koren) writes: >> floppy with a few hundred small files in it. Watch the terminal program >> lose characters. Watch jrcomm die. The terminal program can only hold to >> a certain point, then buffers start to overrun. >Try using flow control. CTS/RTS will allow most terminal programs to >stop the sender while they digest the recently sent data. The whole point of the discussion is quite simple: a call to Write() will take as long as it pleases to take. If you happen to be a terminal program, and it takes 10 hours for the user to wake up the next morning and stick the right disk in, chances are the other end of session has timed out on you. Also, the calls are generally syncronous, so the terminal program can't do anything while waiting for the Write() to return. There are ways using asyncronous io and large allowable memory buffer sizes to safely download a file to a disk not currently in any drive. Essentially, whenever you queue one write request, you allocate another buffer if none have returned. If you have the RAM, the transfer will complete normally with a number of queued write requests, which will get processed when the disk is mounted. > - steve -- Gregory Kritsch | University of Waterloo Fido: 1:221/208.11110 [1:163/109.30] | 1A Computer Engineering OCUG: ggk@tirith.ocug.on.ca |---------------------------- UUCP: ggk@tirith.UUCP | The University doesn't get ...!watmath!xenitec!tirith!ggk | a chance to censor me!
koren@hpfcdc.HP.COM (Steve Koren) (11/25/90)
> The whole point of the discussion is quite simple: a call to Write() > will take as long as it pleases to take. If you happen to be a terminal > program, and it takes 10 hours for the user to wake up the next morning > and stick the right disk in, chances are the other end of session has > timed out on you. Well, yeah, it goes without saying that you've gotta stick the disk in the drive :-) - but even if the floppy takes several minutes to write the data, that'll work just fine. I use cts/rts all the time and it works like a charm. It will, as I mentioned before, allow receiving data to a floppy from a high speed serial line. I've done this at 14400+ bps with no problems. Granted, the other system will have to pause sometimes to wait for the floppy, but no data is lost. If your remote system give up *that* fast, I'd think something would be wrong with it. Similarly, as long as the consumer end of the pipe got around to consuming a block every few minutes, things should work just fine. - steve
proff@phoenix.pub.uu.oz.au (Frederick Solidus) (11/28/90)
In <11640032@hpfcdc.HP.COM> koren@hpfcdc.HP.COM (Steve Koren) writes: >> The whole point of the discussion is quite simple: a call to Write() >> will take as long as it pleases to take. If you happen to be a terminal >> program, and it takes 10 hours for the user to wake up the next morning >> and stick the right disk in, chances are the other end of session has >> timed out on you. >Well, yeah, it goes without saying that you've gotta stick the disk >in the drive :-) - but even if the floppy takes several minutes to >write the data, that'll work just fine. I use cts/rts all the time >and it works like a charm. It will, as I mentioned before, allow >receiving data to a floppy from a high speed serial line. I've done >this at 14400+ bps with no problems. Granted, the other system will >have to pause sometimes to wait for the floppy, but no data is lost. >If your remote system give up *that* fast, I'd think something would >be wrong with it. Similarly, as long as the consumer end of the pipe >got around to consuming a block every few minutes, things should >work just fine. > - steve Thats not the case with me. Downloading to pipe: from jrcomm, and then taking that pipe out put and feeding it to lharc does not work, after 10k, the files become currupted. I assume this is because Jrcomm keeps a buffer of its own and that buffer is larger than the transfer buffer of pipe: Is that correct? Or, perhaps jrcomm does not handshake correctly with the transfer buffer, and jrcomm is held before it has time to inform the sender of its condition. However, zmodem should find this fault, and resend the lost packets - which it does not, so I must assume that the fault lays somewhere in the jrcomm to pipe: communication. Proff/The Force