🚀 go-pugleaf

In article <1991May28.175809.13532@convex.com> hamrick@convex.com (Ed Hamrick) writes:
>(Another interesting area of discussion is how to increase this to ~64 KBytes
>without breaking very much.  HIPPI NFS performance would benefit from this.)

[All of my comments below apply only to applications requiring large amounts
of data, on the scale of this thread. Any application which primarily can only
use a few K of whatever is sent to it will probably not benefit from using
large buffer sizes. Perhaps this could be tunable on a per-mount basis? It
already is to some extent, with rsize and wsize.]

Yes! Yes! This has three benefits: 1) it would reduce the number of client
requests by almost an order of magnitude, 2) throughput on any high-speed 
network will benefit from larger buffer sizes (Ultranet is another), and 3) by 
asking the disk for 64K instead of 8K, you can take advantage of physical 
contiguity on the disk as well as decent buffering in the drive itself. While 
most current disks do not have as many as 128 sectors on a single track, track-
to-track seeks are very fast, and if the filesystem is sensible it will mini-
mize latency on this type of seek. Many of the modern disks (e.g. SCSI) have
enough internal buffer to hold 2 tracks' worth of data, and will send that
out at a burst rate - much higher than the direct-from-disk transfer rate - 
when the bus is free.

Also, since this would reduce the number of requests the server had to respond 
to, it would require less of the server's attention and improve response time
overall to all clients.
-- 
Ruth Milner
Systems Manager                     NRAO/VLA                  Socorro NM
Computing Division Head      rmilner@zia.aoc.nrao.edu