Re: Average Seek times are pretty confusing

"Bob" <bob3635x@xxxxxxxxx> writes:
> Doesn't this assume the disk is full? It also assumes that
> disk accesses are random, which is far from true in most
> real systems. Files that are written close together tend to
> be read close together.

when i was an undergraduate ... i reorganized a mainframe filesystem
so that the avg. elapsed time for a standard job at the university
improved by nearly a factor of three. the major thruput bottleneck was
seek time ... significantly reducing avg. seek time resulted in a
corresponding thruput increase (and decrease in elapsed time, from a
little over 30 seconds to a little under 13 seconds).

ref. to past postings on a presentation i gave at aug '68 user group
meeting in boston;
http://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14
http://www.garlic.com/~lynn/94.html#20 CP/67 & OS MFT14
http://www.garlic.com/~lynn/97.html#22 Pre S/360 IBM Operating Systems?
http://www.garlic.com/~lynn/98.html#21 Reviving the OS/360 thread (Questions about OS/360)
http://www.garlic.com/~lynn/2001f.html#26 Price of core memory
http://www.garlic.com/~lynn/2001k.html#37 Is anybody out there still writting BAL 370.
http://www.garlic.com/~lynn/2002c.html#45 cp/67 addenda (cross-post warning)
http://www.garlic.com/~lynn/2002m.html#3 The problem with installable operating systems
http://www.garlic.com/~lynn/2002n.html#29 why does wait state exist?
http://www.garlic.com/~lynn/2003d.html#72 cp/67 35th anniversary
http://www.garlic.com/~lynn/2004f.html#6 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2005m.html#16 CPU time and system load

note, in the reference presentation in the above, there is several different
items discussed.

one is the re-organizing of the mainframe batch filesystem and disk
layout to significantly increase the thruput from well-over 30 seconds
(in a default, standard, out-of-the-box organization) and the 12.9
seconds (in the re-organization).

the other work described in the presentation was significantly
rewritting major pathlengths in the virtual machine cp/67 kernel.to
reduce the cpu utilization (and the combined result of running the
virtual machine cp/67 kernel in combination with the batch operating
system).

not described in the presentation ... was that i had also rewritten
portions of the disk i/o scheduling to introduced ordered arm seek
scheduling (aka when there are multiple queued i/o requests for the
same disk, the queue is re-ordered to sort the i/o requests for
minimum arm seek distance). the change to ordered arm seek queueing
(from FIFO) tended to further reduce the arg. arm seek distance under
heavy load. with ordered arm seek queuing, the avg. seek distance
tended to decrease as the load increased.

misc. past postings referring to changing implementation from F(IFO
queueing to ordered seek queueing:
http://www.garlic.com/~lynn/93.html#0 360/67, was Re: IBM's Project F/S ?
http://www.garlic.com/~lynn/98.html#17 S/360 operating systems geneaology
http://www.garlic.com/~lynn/2001h.html#26 TECO Critique
http://www.garlic.com/~lynn/2002e.html#0 Storage Virtualization
http://www.garlic.com/~lynn/2002i.html#42 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002o.html#46 Question about hard disk scheduling algorithms
http://www.garlic.com/~lynn/2004o.html#9 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005j.html#51 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005s.html#22 MVCIN instruction

another change that i made in the paging implementation was slot
chaining, when there was independent I/O requests for different
records on the same "cylinder" (records on the same track or records
on different tracks at the same arm position in multi-platter
devices). this had some benefit in the thruput in the records
processed per second on moveable arm disks ... but it showed even
greater thruput in the numbers of records per second in "fixed-head"
device (i.e. device that had a read/write head per track so there was
no track-to-track arm motion). request chaining on the 2301 fixed-head
device (used in cp/67 systems) increased the peak record transfer
thruput from approx. 80 4k records per second to 300 4k records per
second.

for moveable arm devices, request chaining somewhat increased the
avg. seek distance ... since multiple independent zero seek requests
are collapsed into a single, multiple-record request operation

misc. past posts on subject of request record chaining:
http://www.garlic.com/~lynn/95.html#12 slot chaining
http://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2001d.html#49 VTOC position
http://www.garlic.com/~lynn/2001d.html#68 I/O contention
http://www.garlic.com/~lynn/2001g.html#29 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001j.html#3 YKYGOW...
http://www.garlic.com/~lynn/2002.html#14 index searching
http://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
http://www.garlic.com/~lynn/2002i.html#42 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2003g.html#25 303x, idals, dat, disk head settle, and other rambling folklore
http://www.garlic.com/~lynn/2004b.html#32 The SOB that helped IT jobs move to India is dead!
http://www.garlic.com/~lynn/2004n.html#22 Shipwrecks
http://www.garlic.com/~lynn/2004o.html#9 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005j.html#51 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005r.html#51 winscape?
http://www.garlic.com/~lynn/2005s.html#22 MVCIN instruction
http://www.garlic.com/~lynn/2005s.html#25 MVCIN instruction
http://www.garlic.com/~lynn/2005s.html#28 MVCIN instruction

finally here is collected postings on numerous changes to filesystem
implementation code i made in the early 70s ... one of the changes was
support for contiguous allocation which tried to allocate records for
the same file at contiguous physical disk locations (increasing
the ability to do mutliple request record chaining):
http://www.garlic.com/~lynn/subtopic.html#mmap

improving contiguous allocation can increase the effectiveness of
multiple record chaining (i.e. multiple records transferred in a
single operation). again this can result in the avg. seek distance
increasing, since multiple request transfer may appear as a single
seek request (depends oon how the infrastructure statistics treats
zero arm motion operations and multiple record transfer operations).

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
.

Relevant Pages

  • [PATCH -mm] [3/3] Add the Elevator I/O scheduler
    ... This is the Elevator I/O scheduler. ... with a couple tunables for reducing latency or starvation. ... disk controllers and multiple brands of disk. ... * We usually wish to take the next request from the head queue. ...
    (Linux-Kernel)
  • Re: Caching control
    ... | should not allow disk cache to grow large enough to push the working ... | 2) It tells the operating system the *reason* you don't want the data ... |> swap altogether. ...
    (comp.os.linux.development.system)
  • Re: Pluggable Disk Scheduler Project
    ... is anybody working on the `Pluggable Disk Scheduler Project' from ... hardware) outstanding request and to pass new requests to its ... You'll want to queue at least two requests at once. ...
    (freebsd-hackers)
  • Re: Determine Disk Block Size ?
    ... that it may state you need multiple files to spawn multiple threads. ... > mentioned that EE can exceed the number of concurrent extents per request ... > Sql Server can spawn multiple threads to read a single file as well. ... We have done so with a dramatic total disk I/O ...
    (microsoft.public.sqlserver.server)
  • Re: Determine Disk Block Size ?
    ... more files per Filegroup will spawn additional disk threads per request. ... In 2000 Sql Server can spawn multiple threads to read a single file as well. ...
    (microsoft.public.sqlserver.server)