Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site watcgl.UUCP
Path: utzoo!watmath!watcgl!dmmartindale
From: dmmartindale@watcgl.UUCP (Dave Martindale)
Newsgroups: net.unix-wizards
Subject: Re: How to make 4.2BSD ``/etc/dumps faster
Message-ID: <884@watcgl.UUCP>
Date: Fri, 4-Jan-85 00:13:29 EST
Article-I.D.: watcgl.884
Posted: Fri Jan  4 00:13:29 1985
Date-Received: Fri, 4-Jan-85 05:15:30 EST
References: <6894@brl-tgr.ARPA>
Reply-To: dmmartindale@watcgl.UUCP (Dave Martindale)
Organization: U of Waterloo, Ontario
Lines: 20

In article <6894@brl-tgr.ARPA> chris@maryland (Chris Torek) writes:
>I figured pipes would be fairly slow 'cause the network interface
>limits you to 2048 bytes per transfer (although you can increase
>it).  This means that for a 10240 block write (like dump() uses)
>you need 5 pairs of context switches, which can beat a 750 into
>the ground pretty well.  Also, it makes it harder to communicate
>success/failure statuses.
>
Passing *data* though the pipes would indeed be slow.  But I suspect that
the original author did the same thing I did for a general double-buffered
block copy routine: have two processes, one reading and writing even-numbered
blocks and one doing odd-numbered ones, and using pipes only for
synchronization to make sure that the reads and writes occur in the correct
logical sequence (in case either input or output is a tape drive).

Actually, the one-byte values passed around via the pipes can also encode
various types of special conditions, to ensure that one process quits
when the other detects an EOF or error for example.  You can come quite
close to making the program behave like it was a single process that
just overlaps reads and writes.