Number: 315

Date: 27-Mar-84 10':25':43

Submitter: Sannella.PA

Source: JONL.PA

Subject: LEAF should buffer a page ahead

Lisp Version: 

Description: '
Date': 26 MAR 84 18':34 PST'
From': JONL.PA'
Subject': lack of "look ahead" buffering for LEAF'
To':   LispSupport'
While trying to LISTFILES on a relatively small file, I did a frequent'
backtrace in the process doing the listing;  it seems to be spending all'
of its time (real time, that is) underneath an AWAIT.EVENT on the socket'
that it is waiting for the next packet.  Since \BIN doesn''t initiate a'
"reload" until it has read the last byte of a page, there is no overlapping'
of the processing done on a file and transit time for packets on the'
net (and this is especially important for a remote host that is somewhat '
What harm would there be in simply requesting one page ahead of the current'
buffered page?  Thus when \BIN hits the end of that page, \TURNPAGE could'
immediately re-fill from the packet that was requested "some time ago",'
while also initiating a request for the page beyond that one.  For truely'
random file positionings, there is the possibility of having sent too'
much data from the remote host, but this must be balanced with the number'
of times that a BIN of a byte on page n will shortly be followed by a BIN'
on page n+1.'
Date': 27 Mar 84 11':02 PST'
Subject': Re': AR 315': LEAF should buffer a page ahead'
In-reply-to':''s message of 27 Mar 84 10':26':07 PST (Tuesday)'
cc':, JonL'
Leaf already buffers a page (or more) ahead, at least when the file server is willing to give it that much allocation.  But note that if the file server is slow, or Lisp is fast, so that the time to fetch a remote page substantially exceeds the time to process a page, then it will still look like you are spending most of your time waiting for the remote server (especially since you can only do the backtrace when the process is waiting).'
Date': 29 MAR 84 12':42 PST'
From': JONL.PA'
Subject': Re': AR 315': LEAF should buffer a page ahead'
To':   vanMelle, LispSupport'
cc':   JONL'
In response to the message sent  27 Mar 84 11':02 PST from'
The LISTFILES process indeed is "waiting" at many places, so BT shows'
a wide variation of states; the preponderance of times that it is waiting'
for a packet from PHYLUM suggests either that a Dorado is blindingly fast,'
or (more likely) Phylum is hopelessly bogged down these days.'


Test Case: 

Edit-By: Sannella.PA

Edit-Date: 30-Mar-84 12':03':06


Assigned To: 



System: Communications

Subsystem: PUP Protocols



Microcode Version: 

Memory Size: 

File Server: 

Server Software Version: 


Frequency: Intermittent

Impact: Annoying

Priority: Perhaps

Status: Declined

Problem Type: Performance

Source Files: