Talk About Network



Register and Login
Nick
Password
Register create new account Sign up is FREE and you can post replies, new topics, bookmark posts and more!
Recover lost password


Programming > Assembly 370 > Re: S/360
Latest [ Topics | Posts ] Archive Post A New Topic Post a Reply
<< Topic < Post Post 1 of 2 Topic 268 of 328
Post > Topic >>

Re: S/360

by Anne & Lynn Wheeler <lynn@[EMAIL PROTECTED] > Jan 17, 2006 at 04:37 PM

"robin" <robin_v@[EMAIL PROTECTED]
> writes:
> FYI, our s/360 was slower than the machine that it replaced for
> small jobs -- yet the machine it replaced was 50 times slower (add
> time 64uS).  When LCS was put on the S/360, it ran even slower,
> because the OS took up most of the fast memory, so that user
> programs were loaded into slow memory.

our 360/67 at the univ. had significantly worse thruput than the 709
(tube machine) that it replaced. the 360/67 had 8-byte wide 750ns
memory (and instruction) cycle time (compared to 360/50 2-byte 2mic
memory, and most LCS was 8mic). 360/67 was essentially a 360/65 that
had virtual memory hardware bolted on.

a dominate workload was fortran student jobs ... there was 1401
front-end that handled unitrecord<->tape ... and you carried tapes
between the 1401 and 709 (this was 40 yrs ago, 1966). the 709 fortran
monitor ran student jobs (tape to tape) at a couple seconds per.

360/67 came in with os/360 and 2311 disks. job processing was
syncronous with unit record process ... read the cards ... write stuff
to disk, read stuff from disk, eventually execute ... print output
.... do the next job. this was taking minutes per student job. most of
the time 360/67 ran as non-virtual memory 360/65 with vanilla os/360.
the 67 associative array hardware lookup (virtual to real address
translation) did add 150ns to 750ns basic memory cycle (900ms total).

by os/mft11 release, the univ got HASP, which decoupled the unit
record processing from the job execution. the other operating system
gorp of moving lots of stuff back&forth between memory and disk was
still resulting in student fortran job processing taking over 30
seconds.

i did a lot of detailed analysis and careful construction/placement of
operating system stuff on disk for optimized arm seek operation and
got the typical student fortran job elapsed time to a little under 12
seconds (still longer than they had run on 709) ... but almost three
times faster than it had been taking.

it wasn't until we got watfor monitor from univ. of waterloo that
student fortran job thruput started to exceed what it had been on the
709.

i gave talk at fall '68 share meeting in boston on both the
optimization work on os/360 as well extensive kernel rewrites that i
had done to cp/67 (i was still undergraduate) ... previous posting
referencing part of that talk
http://www.garlic.com/~lynn/94.html#18
CP/67 & OS MFT14
http://www.garlic.com/~lynn/94.html#20
CP/67 & OS MFT14

for a little drift ... i had done some of the work on gcard ...
an ios3270 version of the 360 green card ... and just recently
did something of a rough conversion to html
http://www.garlic.com/~lynn/gcard.html

and of course, the 360 functional characteristics documents game
detailed machine timings ... several have been scanned and are
available here (including 360/65, 360/67, 360/91, and 360/195):
http://bitsavers.trailing-edge.com/pdf/ibm/360/funcChar/
http://www.bitsavers.org/pdf/ibm/360/funcChar/

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




 2 Posts in Topic:
Re: S/360
Anne & Lynn Wheeler &  2006-01-17 16:37:33 
Re: S/360
"robin" <rob  2006-01-20 00:14:18 

Post A Reply:
  Go here to Signup

AddThis Feed Button


About - Advertising - Contact - Frequently Asked Questions - Privacy Policy - Terms of Use - Signup

Contact
tan12V112 Wed May 14 3:21:45 CDT 2008.