root%bostonu.csnet@CSNET-RELAY.ARPA (BostonU SysMgr) (09/23/85)
>From: rbp@investor.UUCP (Bob Peirce) >How big is the pipe? I read somewhere pipes use the root file system, >which on our computer has about 1100 free blocks. Yet, I have used >cphier to transfer, for example, the entire netnews source, including >rn, from one drive to another. All I created was the highest level >directory. Cphier made all the rest. Will it sometimes work and sometimes >fail on a transfer of this size? If the 'producer' gets too far ahead of the 'consumer' the 'producer' will be blocked at it's next attempt to write to the pipe until the 'consumer' catches up some. The answer is no, it should not fail in the way you fear, of course, Murphy has proven that it will find a different way to fail :-) -Barry Shein, Boston University
jbn@wdl1.UUCP (09/26/85)
Approaches differ. In AT&T's UNIX, a pipe is implemented as a circular buffer in a file, normally four blocks long. But if the pipe is reasonably active the buffers never get written to the disk; all the action is in the buffer cache. In 4.2BSD, a pipe is a special case of a socket, and the operation is performed entirely in memory. In MS-DOS, a pipe is an illusion created by the command interpreter; "p1 | p2" is implemented as "p1 > tmp; p2 < tmp; rm tmp". John Nagle
chris@neology.OZ (Chris Maltby) (10/04/85)
Sys V pipes will work fine in just about all circumstances as long as PIPSIZ (usually 5120) is a multiple of the file system buffer size (typically 1024). However, on the 3b2 (and the ELXSI) which have 2048 byte buffers, you get quite interesting behavior from pipes when reading and writing in 2048 byte chunks. We discovered and fixed this on the ELXSI - the 3b2 is still broken at sys5 rel2. The best fix is to set PIPSIZ to be (10 * BSIZE). Symptoms include pipe 'constipation', data mangling etc. -- Chris Maltby - Neology Ltd (chris@neology.oz) PHONE: +61-2-662-4111 UUCP: seismo!neology.oz!chris CSNET: chris@neology.oz ARPA: chris%neology.oz@seismo.cs.gov.arpa
brent@poseidon.UUCP (Brent P. Callaghan) (10/05/85)
>buffer size (typically 1024). However, on the 3b2 (and the ELXSI) >which have 2048 byte buffers, you get quite interesting behavior ^^^^^^^^^^^^^^^^^ According to the 3b2 admin guide you must allow 1076 bytes per buffer in the buffer pool. I imagine that this is 1024 bytes of data + overhead. -- Made in New Zealand --> Brent Callaghan AT&T Information Systems, Lincroft, NJ {ihnp4|mtuxo|pegasus}!poseidon!brent (201) 576-3475
david@ecrhub.UUCP (David M. Haynes) (10/09/85)
> >buffer size (typically 1024). However, on the 3b2 (and the ELXSI) > >which have 2048 byte buffers, you get quite interesting behavior > ^^^^^^^^^^^^^^^^^ > According to the 3b2 admin guide you must allow 1076 bytes > per buffer in the buffer pool. I imagine that this is > 1024 bytes of data + overhead. > -- > > Made in New Zealand --> Brent Callaghan > AT&T Information Systems, Lincroft, NJ > This may fall into the area of fuzzy thinking, but what's wrong with this arguement? To find out how big a pipe is, grab your handy manual and see how many pipes you can have open at one time. Remember that a pipe takes an inode so, this number times the size of your system's blocks should give the maximum capacity of a pipe. No? -- -------------------------------------------------------------------------- They only asked me one question, and David M. Haynes that was, "What is your name?" Exegetics Inc. And I got 75% on that one... ..!utzoo!ecrhub!david [Peter Cook - Beyond the Fringe] Exegetics Inc. is a legal convenience and does not care what I have to say. Emerald City Research Inc. is very kind to let me use their machine, but in no way is even remotely responsible for the stuff I post.
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (10/14/85)
> This may fall into the area of fuzzy thinking, but Yes > what's wrong with this arguement? Everything > To find out how big a pipe is, grab your handy manual and see how > many pipes you can have open at one time. > Remember that a pipe takes an inode so, this number > times the size of your system's blocks should give the maximum > capacity of a pipe. No? (Assuming block I/O system pipes/FIFOs:) There are several "sizes" associated with pipes. The maximum amount of unread data bufferable in a pipe seems to be the one under consideration. On older UNIXes, this was 4096 bytes, and on newer UNIXes it is supposed to be 5120 bytes, according to the manual. The simplest pipe implementation uses only "direct blocks" named in the inode, for efficiency. There are typically 10 direct blocks in an inode, and the system blocksize is usually 512 or 1024 bytes, or a "dual" 512/1024 system. If you have a /usr/include/limits.h file, look in it to see what PIPE_BUF and PIPE_MAX are defined as. Why does anyone really care? The size of an atomic write seems much more important to me; this is a complicated issue that is affected by O_NDELAY, the amount of unread data still in the pipe, etc. Possibly interesting note: I heard that someone measured pipe throughput using both the block I/O inode ripoff scheme and 4.2BSD's socketpair scheme, and found that the traditional way generally had higher throughput.
mjs@sfmag.UUCP (M.J.Shannon) (10/19/85)
> According to the 3b2 admin guide you must allow 1076 bytes > per buffer in the buffer pool. I imagine that this is > 1024 bytes of data + overhead. > -- > Made in New Zealand --> Brent Callaghan The overhead is not part of the buffer data area, it is "sizeof (struct buf)", the data structure the kernel uses to manage bufers and queues of same. The reference to the additional storage is to used in considering the cost in kernel data space of each buffer. -- Marty Shannon UUCP: ihnp4!attunix!mjs Phone: +1 (201) 522 6063 Disclaimer: I speak for no one.