[Info-vax] TK50 - this is annoying...

[Paul Sture]

In article 
<fdcd17c8-63cb-42e8-bb53-4ee4458ffebb at d17g2000vbv.googlegroups.com>,
 John Wallace <johnwallace4 at gmail.com> wrote:

> Average seek time of disks from RM03 to RA81 seems to be around 30ms.
> Nominal transfer rate was around 1MB/s on the RM03, maybe twice that
> on the RA81, but for safety let's assume a sustained application-layer
> data rate of 1MB/s. So for a 30ms seek (far less than the maximum
> seek) you would have to be able to buffer 30KB of data, and then be
> able to catch up again afterwards. Far from impossible, given enough
> memory and clever coding, but not exactly simple or comfortable
> either.

For a project in 1982 we used a figure of 50ms per seek to estimate 
throughput.

> The RT11 file system used an extremely simple file system in which all
> files were contiguous, in part because it was simple (ie compact code)
> and in part because it meant that realtime support was easier - no
> middle-of-file seeks needing tens of Kbytes of buffering. It also
> meant that if a disk had enough free space, but it wasn't all
> contiguous, any attempted allocation request which was bigger than the
> largest contiguous free space but smaller than the total free space
> would fail, and thus people might want to use the provided utility to
> SQUEEZE it all into one big chunk from time to time.

How that worked in practice, certainly for the DIBOL run time, was that 
unless you specified a smaller file size as part of the open for output 
statement, you got half the free space.  When writing to a spool file, 
once that allocation was filled, you would be prompted for another file 
name, which would be half the size of the original.  At this point, if 
you had another disk with sufficient free space, you could aim the 
continuation file at that disk.
 
> If you'd like to learn a little more about RT11, RT11 V5.3 seems to be
> freely downloadable for use with SIMH, e.g. for use on your favourite
> Android phone. No 30ms seek problems or shortage of a few kBytes of
> memory there.
> 
> The tradition of disk defragmentation continues to this day, although
> Windows defrag (at least prior to Win7) at least drew prettier
> pictures than RT11 SQUEEZE.

Microsoft put quite a bit of effort into this area for Windows 7:

"Disk Defragmentation ­ Background and Engineering the Windows 7 
Improvements"

http://blogs.msdn.com/b/e7/archive/2009/01/25/disk-defragmentation-backgr
ound-and-engineering-the-windows-7-improvements.aspx

-- 
Paul Sture