List of Archived Posts

2006 Newsgroup Postings (02/26 - 03/07)

IBM 610 workstation computer

Hercules 3.04 announcement

IBM 610 workstation computer

Hercules 3.04 announcement

IBM 610 workstation computer

IBM 610 workstation computer

IBM 610 workstation computer

IBM 610 workstation computer

IBM 610 workstation computer

IBM 610 workstation computer

IBM 610 workstation computer

IBM 610 workstation computer

IBM 610 workstation computer

IBM 610 workstation computer

IBM 610 workstation computer

Hercules 3.04 announcement

IBM 610 workstation computer

IBM 610 workstation computer

IBM 610 workstation computer

Hercules 3.04 announcement

Statistics on program constant sizes?

IBM 610 workstation computer

IBM 610 workstation computer

IBM 610 workstation computer

IBM 610 workstation computer

Caller ID "spoofing"

Caller ID "spoofing"

IBM 610 workstation computer

Caller ID "spoofing"

Caller ID "spoofing"

Caller ID "spoofing"

Caller ID "spoofing"

When *not* to sign an e-mail message?

When *not* to sign an e-mail message?

When *not* to sign an e-mail message?

Fw: Tax chooses dead language - Austalia

When *not* to sign an e-mail message?

transputers again was Re: The demise of Commodore

Fw: Tax chooses dead language - Austalia

transputers again was Re: The demise of Commodore

transputers again was Re: The demise of Commodore

Caller ID "spoofing"

IBM 610 workstation computer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 610 workstation computer
Newsgroups: alt.folklore.computers
Date: Sun, 26 Feb 2006 15:42:31 -0700

"Rostyslaw J. Lewyckyj" writes:

Oh sure but unless the problem was such that you couldn't submit a
second, or further independant jobs before you got back the output
from the first job, then : On the 195 the process would have been
like instructions in a pipeline.  If you submitted jobs one week
apart, the first results wouldn't be back until three months after
submission. But then you would get a set of results out every week,
as your jobs got to execute from the input queue.  While on the 145,
because the job was in the background to soak up available time, a
second or subsequent jobs wouldn't run until the first job
finished. So you would only get one set of results per month.

the issue on the 370/195 in bldg. 28 was that unless you had special
priority ... the normal job execution backlog ... was in fact, 3
months (even if all the pending jobs executed at peak 370/195
thruput). the 370/195 service in bldg. 28 also had operational stuff
to catch individuals and/or organizations having multiple instances of
the same work concurrently submitted ... as an attempt to reduce their
turn-around latency (frequently seen in student university
environments and there usually are countermeasures developed to handle
the situation).

there is a separate issue with concurrently executing jobs
... typically used in interactive environments and/or batch
enviornments where no specific job was processor bound, processor was
the most expensive resource in the system, and the system was
optimized to maximum processor utilization.

the issue with the pasc job was that it would only run for a couple
hrs ... but the workload backlog on the 370/195, was in fact, 3months
(at least for the job priority given their workload). some other
workload might get higher priority and more frequently turn-around.
note this was effectively three months turn-around before it even
started the job (much more FIFO than any round-robin). i've posted
before about the air-bearing simulation job that was getting something
like one week turnaround from the bldg. 28 370/195 service (instead of
3 month turn around) ... which was part of the effort that went into
designing the thin-film floating heads for 3380 (and possibly
considered higher priority to get out the thin-film floating disk head
design).

now in the various concurrent workload scenarios ... like the 370/145
machine installed at pasc for providing interactive computing vm/cms
service ... the scheduler started out basically being a combination of
priority and round-robin. the original scheduler on cp67 that i saw
(possibly adapted from ctss) was a ten level priority
scheduler. certain type of events would reset a task (or a brand new
task) and place it at the best priority with very short cpu time-slice
(multiple tasks at the same level were handled fifo). once the task
had executed for the very short cpu time-slice it was bumped down to
the next level scheduling level (where it would get a slightly larger
cpu time-slice but scheduled for execution behind any processes at
higher level). concurrent, time-slice workload that required any
amount of cpu resources, quickly filtered thru all ten levels to the
bottom level ... where most of the long-running, concurrent processor
intensive tasks found themsleves ... and they would be executed in
round-robin fashion with cpu time-slice on the order of a second or
so. if higher priority workload showed up, it could pre-empt workload
running at lower scheduling priority.

as the number of concurrent tasks and workload increased in normal
cp67 service ... this ten level dispatcher maintenance overhead was
starting to consume something like 10-15% of total elapsed time.  it
also suffered from not having any sort of page thrashing control
overhead. one of the people at lincoln labs, then replace the
ten-level dispatcher with a much simpler two-level dispatcher that
included very rudimentary page-trashing controls. the operation
between the two queues were similar to the ten-level dispatcher
... basically high-priority, short time-slice, fifo queue and then
quickly drop into bottom queue and effectively round-robin.

i then rewrote all this stuff and created the original fair-share
dispatcher. it basically calculated advisory deadline based on things
like recent resource consumptioin and the size of the allocated
time-slice.
http://www.garlic.com/~lynn/subtopic.html#fairshare

i also rewrote the page thrashing control to estimate real storage
requirements of each task (the rudimentary page-thrashing code put in
by lincoln labs. just placed an arbitrary limit on the total number of
concurrent tasks in the dispatch queue w/o actually tracking their
real storage requirements).
http://www.garlic.com/~lynn/subtopic.html#wsclock

note that this was in the same era that there was publication in the
technical literature about working sets and working set dispatcher.
as previously mentioned, 10-15 yrs later there was a conflict when
somebody was publishing a stanford phd thesis on technology very
similar to the work that i had done nearly 15 years earlier (and also
contridicted the technical literature that had been published at the
time i did my original work). there was a major effort to not allow
that the phd be granted on the work (and the thesis be published).
one of the contributions that help break the deadlock was that there
was an implementation done on cp/67 running on identical hardware of
the working set dispatcher ... and you could have direct A:B
comparison between my implementation and an implementation that
faithfully reproduced what was in the technical literature.

so in the morphing from cp67 to vm370, much of the code that i had
done as an undergraduate got dropped. somewhat because of that, there
were some lobbying via various customers (in places like SHARE and
other user group organizations) to have my code put back into the
product. that was finally approved and I got to ship the "resource
manager" .... coming up on 30 year anniv. in a couple months. It had
pretty much the same dynamic adaptive resource management, advistory
deadline scheduling, real-storage and page thrashing controls, etc.
One of the things that I was able to add was an additional, somewhat
more, background dispatching queue that was much more FIFO than
round-robin. I even did a write-up on the effects of having things
like ten identical tasks/jobs that would nominally run for several
minutes. The resource manager write-up was something along the line
that if I had ten concurrent tasks each requiring six minutes and
executed round-robin ... then it would take nearly an hour for all ten
to complete. The avg. completion time then is one hour. However, if i
ran the same workload FIFO, the first task could complete after six
months ... and only one would take the full hour (with the avg.
completion time a little over 30 minutes instead of 60
minutes).

in any case, PASC had a choice between their in-house 370/145 and the
bldg. 28 370/195. the 370/145 was installed to supply interactive
computing for science center members that primarily worked 1st
shift. as a result, the machine was otherwise idle much of 2nd shift,
nearly all of 3rd shift, and nearly all of the weekends. The 370/195
workload was effectively run FIFO and the PASC turn-around still was 3
months.

now the 370/195 had another issue. most normal codes, unless
specifically optimized for 195 pipeline ... ran about 50percent peak
instruction thruput. somewhere along the way, there was a project that
I got pulled in that was working on effectively hyperthreading for the
195. it involved created a second PSW (instruction counter) and
registers and misc. other stuff ... providing dual i-stream support
... emulating a two-process smp. The pipeline stayed the same and the
number of functional units stayed the same ... but all the work in the
pipeline was tagged with an one-bit instruction stream flag
(indicating which instruction stream that instructions and registers
were associated with). this effort never shipped any hardware to
customers. the idea with the dual i-stream was that if most normal
codes could only keep the pipeline half busy ... then having a pair of
i-streams might be able to maintain peak aggregate thruput.

misc. past posts mentioning bldg. 28 370/195 service and air-bearing
simulation job
http://www.garlic.com/~lynn/2001n.html#39 195 was: Computer Typesetting Was: Movies with source code
http://www.garlic.com/~lynn/2002j.html#30 Weird
http://www.garlic.com/~lynn/2002n.html#63 Help me find pics of a UNIVAC please
http://www.garlic.com/~lynn/2002o.html#74 They Got Mail: Not-So-Fond Farewells
http://www.garlic.com/~lynn/2003b.html#51 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#52 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003j.html#69 Multics Concepts For the Contemporary Computing World
http://www.garlic.com/~lynn/2003m.html#20 360 Microde Floating Point Fix
http://www.garlic.com/~lynn/2003n.html#45 hung/zombie users ... long boring, wandering story
http://www.garlic.com/~lynn/2004.html#21 40th anniversary of IBM System/360 on 7 Apr 2004
http://www.garlic.com/~lynn/2004b.html#15 harddisk in space
http://www.garlic.com/~lynn/2004o.html#15 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2004o.html#25 CKD Disks?
http://www.garlic.com/~lynn/2005.html#8 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005f.html#4 System/360; Hardwired vs. Microcoded
http://www.garlic.com/~lynn/2005f.html#5 System/360; Hardwired vs. Microcoded
http://www.garlic.com/~lynn/2005o.html#44 Intel engineer discusses their dual-core design
http://www.garlic.com/~lynn/2006.html#29 IBM microwave application--early data communications
http://www.garlic.com/~lynn/2006c.html#6 IBM 610 workstation computer

misc. past posts mentioning the stanford clock phd thesis incident:
http://www.garlic.com/~lynn/94.html#49 Rethinking Virtual Memory
http://www.garlic.com/~lynn/94.html#54 How Do the Old Mainframes
http://www.garlic.com/~lynn/96.html#0a Cache
http://www.garlic.com/~lynn/98.html#2 CP-67 (was IBM 360 DOS (was Is Win95 without DOS...))
http://www.garlic.com/~lynn/99.html#18 Old Computers
http://www.garlic.com/~lynn/2000e.html#34 War, Chaos, & Business (web site), or Col John Boyd
http://www.garlic.com/~lynn/2001h.html#26 TECO Critique
http://www.garlic.com/~lynn/2002c.html#54 Swapper was Re: History of Login Names
http://www.garlic.com/~lynn/2002k.html#63 OT (sort-of) - Does it take math skills to do data processing ?
http://www.garlic.com/~lynn/2002o.html#30 Computer History Exhibition, Grenoble France
http://www.garlic.com/~lynn/2003f.html#30 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#48 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#55 Alpha performance, why?
http://www.garlic.com/~lynn/2003g.html#0 Alpha performance, why?
http://www.garlic.com/~lynn/2003k.html#8 z VM 4.3
http://www.garlic.com/~lynn/2003k.html#9 What is timesharing, anyway?
http://www.garlic.com/~lynn/2004.html#25 40th anniversary of IBM System/360 on 7 Apr 2004
http://www.garlic.com/~lynn/2004b.html#47 new to mainframe asm
http://www.garlic.com/~lynn/2004g.html#13 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004q.html#73 Athlon cache question
http://www.garlic.com/~lynn/2005f.html#47 Moving assembler programs above the line
http://www.garlic.com/~lynn/2006b.html#15 {SPAM?} Re: Expanded Storage
http://www.garlic.com/~lynn/2006b.html#35 Seeking Info on XDS Sigma 7 APL

misc. past posts mentioning dual i-stream work
http://www.garlic.com/~lynn/94.html#38 IBM 370/195
http://www.garlic.com/~lynn/99.html#73 The Chronology
http://www.garlic.com/~lynn/99.html#97 Power4 = 2 cpu's on die?
http://www.garlic.com/~lynn/2000g.html#15 360/370 instruction cycle time
http://www.garlic.com/~lynn/2001b.html#38 Why SMP at all anymore?
http://www.garlic.com/~lynn/2001j.html#27 Pentium 4 SMT "Hyperthreading"
http://www.garlic.com/~lynn/2001n.html#63 Hyper-Threading Technology - Intel information.
http://www.garlic.com/~lynn/2002g.html#70 Pipelining in the past
http://www.garlic.com/~lynn/2002g.html#76 Pipelining in the past
http://www.garlic.com/~lynn/2003l.html#48 IBM Manuals from the 1940's and 1950's
http://www.garlic.com/~lynn/2003m.html#60 S/360 undocumented instructions?
http://www.garlic.com/~lynn/2003p.html#3 Hyperthreading vs. SMP
http://www.garlic.com/~lynn/2004.html#27 dual processors: not just for breakfast anymore?
http://www.garlic.com/~lynn/2004e.html#1 A POX on you, Dennis Ritchie!!!
http://www.garlic.com/~lynn/2004o.html#18 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005.html#5 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005.html#19 The Soul of Barb's New Machine (was Re: creat)
http://www.garlic.com/~lynn/2005f.html#22 System/360; Hardwired vs. Microcoded
http://www.garlic.com/~lynn/2005p.html#1 Intel engineer discusses their dual-core design
http://www.garlic.com/~lynn/2005p.html#14 Multicores
http://www.garlic.com/~lynn/2006c.html#6 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006c.html#29 IBM 610 workstation computer

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

Hercules 3.04 announcement

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hercules 3.04 announcement
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sun, 26 Feb 2006 16:12:06 -0700

phil@isham-research.co.uk wrote:

I thought Iceberg was the MSS?

ref:
http://www.garlic.com/~lynn/2006c.html#46 Hercules 3.04 announcement

mss/3850 provided simulated 3330s (icebergs) staged from tape cartridges.

originally had real 3330 drives for staging the simulated 3330 drives.
mss/3850 had two modes ... staging a full cartridge or staging six 3330
cylinders (at a time). i/o done to a simulated 3330 address could get
back a unit check with "cylinder fault" in the sense data ... prompting
for the operating system to stage the appropriate data from tape to disk.

later there was a mss/3850 option that would use 3350 drives for staging
the simulated 3330 data.

later during the ADSTAR period in san jose ... there was the C-STAR
project which was working on a new disk controller that was to suppose
to provide equivalent function to the STK (iceberg/9200, different
project, different vendor, same name) controller that had virtualized
disks (compression and various other functions) ... as well as raid
support. Slightly later, IBM licensed and marketed the STK iceberg/9200
controller. the stk iceberg was some 25 years after the 3330 iceberg.

some 3850/mss pictures
http://www.columbia.edu/acis/history/mss.html
http://www-03.ibm.com/ibm/history/exhibits/storage/storage_3850.html

a few references from search engine mentioning stk iceberg/9200
http://www.findarticles.com/p/articles/mi_m0EIN/is_1995_Feb_7/ai_16420403
http://calbears.findarticles.com/p/articles/mi_m0EIN/is_1995_April_18/ai_16828928
http://storageadvisors.adaptec.com/2005/12/02/the-origin-of-raid-6/

IBM 610 workstation computer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 610 workstation computer
Newsgroups: alt.folklore.computers
Date: Sun, 26 Feb 2006 17:00:39 -0700

jmfbahciv writes:

If I understand what you're saying..I think this is where JMF/TW's
macros were used; and I cannot recall what we called them.  These
guys wrote a series of MACRO-10 macroes that did all the right stuff
around local pieces of code.  Not only did this execute the correct
code but the 6-character macro name could be cross-refed and, more
importantly, documented in the sources where care had to be taken.
It wasn't just in comments, which always have to be assumed to be
wrong.

one of the things done with macros for the vm370 kernel ... was that
all activity inside the kernel was associated a data structure called
a vmblok ... and all processing was accounted for related to a
vmblok. In single processor mode, the kernel switching from one
task another would switch pointers to the active vmblok as well
as the value loaded into the cpu timer.

there was a macro for this

            SWTCHVM

which basically did a

            STPT   VMTTIME
            SPT    VMTTIME-VMBLOK(R1)
            LR     R11,R1

which saved the current value of the cpu timer in the previous vmblok,
switch the vmblok pointers and loaded its current value into cpu
timer.  a vmblok's cptime value was initialized to a large positive
double word. when loaded into the cpu timer, it was decremented in
real time. when tasks were switched, the current cpu timer value was
stored. amount of cpu consumed by a specific task was the difference
between the current value and the original value (or some intermediate
checkpointed value).

for fine-grain smp locking support, a data-structure lock was defined
for each vmblok. the SWTCHVM macro then had additional code that was
expanded when a smp kernel was generated. this included releasing the
(vmblok data structure) lock on the previous vmblok and obtaining the
(vmblok data structure) lock on the task being switched to.

relatively new discussion from vmshare about converting from "CHARGE"
macro (which was UP-oriented and only did the cpu timer gorp) to
the SWTCHVM macro ... which would expand to MP appropriate code if
kernel was being built for SMP
http://vm.marist.edu/~vmshare/browse?fn=UP_TO_MP&ft=MEMO

this is much longer post from vmshare ... but embedded in the thread
is a more detailed discussion of the SWTCHVM macro
http://vm.marist.edu/~vmshare/browse?fn=SUSPEND&ft=MEMO

another vmshare thread/post with some discussion of SWTCHVM
macro and also mention of some installations ("like CIA") that
generate all their kernels as SMP for all machines (even
their non-smp processors)
http://vm.marist.edu/~vmshare/browse?fn=MP_ON_UP

there was also a lock specific macro that had this form

         LOCK  OBTAIN,TYPE=VMBLOK,SPIN=NO,SAVE
         LOCK  RELEASE,TYPE=VMBLOK,SAVE

recent thread discussing 360 location 80 cpu timer, and the tod clock
and other timers introduced with 370:
http://www.garlic.com/~lynn/2006c.html#20 Military Time?
http://www.garlic.com/~lynn/2006c.html#21 Military Time?
http://www.garlic.com/~lynn/2006c.html#22 Military Time?
http://www.garlic.com/~lynn/2006c.html#23 Military Time?

section discussing tod clock and cpu timer
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/4.6?SHELF=EZ2HW125&DT=19970613131822

SET CPU TIMER (SPT) instruction
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/10.36?SHELF=EZ2HW125&DT=19970613131822

STORE CPU TIMER (STPT) instruction
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/10.47?SHELF=EZ2HW125&DT=19970613131822

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

Hercules 3.04 announcement

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hercules 3.04 announcement
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sun, 26 Feb 2006 17:20:14 -0700

Anne & Lynn Wheeler wrote:

later during the ADSTAR period in san jose ... there was the C-STAR
project which was working on a new disk controller that was to suppose
to provide equivalent function to the STK (iceberg/9200, different
project, different vendor, same name) controller that had virtualized
disks (compression and various other functions) ... as well as raid
support. Slightly later, IBM licensed and marketed the STK iceberg/9200
controller. the stk iceberg was some 25 years after the 3330 iceberg.

ref:
http://www.garlic.com/~lynn/2006d.html#1 Hercules 3.04 announcement
and the original post
http://www.garlic.com/~lynn/2006c.html#46 Hercules 3.04 announcement

i shouldn't have been so flip ... it wasn't actually called c-star ...
it was called seastar. there was also a seahorse that would provide
fileserver capability. some of this was "jupiter" controller project
reborn ... but some ten years later. if i remember correctly, dynamic
pathing survived out of jupiter (someplace i may have some long
dissertation on how to slightly modify the original dynamic pathing
architecture proposal and save something like an order of magnitude or
more in the number of circuits to implement as you scaled up).

oh, lots of collected past posts on having fun in bldg. 14 (disk
engineering lab) and bldg. 15 (product test lab).
http://www.garlic.com/~lynn/subtopic.html#disk

IBM 610 workstation computer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 610 workstation computer
Newsgroups: alt.folklore.computers
Date: Sun, 26 Feb 2006 20:52:46 -0700

"Rostyslaw J. Lewyckyj" writes:

On the 195
On day 001  submit the Pasc job with data  {a,b,c,...}
On day 008  submit the Pasc job with data  {d,e,f,...}
On day 015  .... with data {g,h,i,...)
....... and so on........
On day 091 get back the results for {a,b,c,...}
On day 098 get back the results for {d,e,f,...}
On day 105 get back the results for {g,h,i....}
........ and so on......
i.e. each job has three months turn around. But independant
outputs can pop out one week, at a time, or however densely
the independaant jobs are permitted to be submitted.

On the 145
On day 001 submit the job (A) with data {a,b,c,...}
On day 007 submit job (B) with data {d,e,f,...}  etc.
But because job A only gets service during idle time,
which it soaks up, job B doesn't get to run till A
completes on day 030. Or else B competes with A and
delays its completion past day 030 etc.
So on the 195 the 5'th job submitted on day 1+4*7 = 029
would come back on day 91+28 = 119, while on the 145
the 5'th job would come back on day 151 (as long as it
had been submitted before 121 :) ) .

The rest of what you wrote while informative and interesting
does not explain how using the 145 could give the Pasc crew
better service after the first several jobs.  :)

PASC owns the 145 ... they've paid for the machine and it otherwise
sits idle most nights and weekends.

the 370/195 doesn't have any idle time ... one of the reasons
that pasc can only get one turn-around every three months.
the application was somewhat that the results from the
previous run is needed before the next run.

because of the significant backlog for 370/195 ... availability to
pasc 370/195 was controlled by both policy and budget constaints.
they would have needed to provide significant policy and budget
justification to improve their ability to submit additional jobs
and/or increase amount of work.

that is one of the reasons i referenced the student scenario for
such strategies ... because there was frequently no budgetary
constaint on their machinations.

in your strategy ... since the next run was dependent on the output
from the previous run ... and there was somewhat limited storage space
... so you wouldn't have good mechanism from passing the output from a
job that hadn't been executed by the time the next job was submitted
... you could have 12 jobs all queued that would be exact duplicates
and repeat the same calculations, all getting the same results ... but
using 12 times the resources and 12 times the budget.

the policy restrictions however, would have prevented PASC from
getting more than one such turn-around per 3 month period ...  no
matter how you staggered the submissions. again the submission
strategy scenario you describe is more like what a lot of students
scheme ... based on much simpler straight-forward computing scheduling
strategy that was only based on simple submission strategy ... and not
assuming any more sophisticated resource scheduling strategies in use
by the computing systems (like aggregate per organization resource per
period).

some univ. would do similar type of stuff for student classes per
semester. some bright student would come up with a strategy for a
large number of submissions ... and within the first couple days blow
the complete semester's budget for that class (leaving the class w/o
computing resources for the rest of the semester). then smarter
policies would even preclude any single student using more than there
pro-rated share of the resources allocated for the class. if some
student blew their complete resource budget within the first day or
two ... that would just mean that no more of their jobs would be run
... as opposed to penalizing the whole class.

long ago i saw an aggravated case of this when a state univ.  system
went from owning their own computer to the state legislature
contracting for univ. computing time with an independent computer
service. then such student machinations were no longer simple case
of internal univ. "funny" money ... but involved real money
budgeted from the state legislature.

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

IBM 610 workstation computer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 610 workstation computer
Newsgroups: alt.folklore.computers
Date: Sun, 26 Feb 2006 21:49:21 -0700

Morten Reistad writes:

There are levels of SMP in terms of scalability.

These OS'es (and other complex stuff like databases, rendering
systems etc)  tend to go through the same "levels" of SMP.

There seems to be a particular point at 4-6 way parallellism
that a lot of coders and hardware builders struggle with.

two-way 370 processor adds cache overhead such that a two-way 370 is
considered to be at best 1.8 times the performance of a
uniprocessor. part of the issue is that the 370 caches are slowed down
10percent to allow for cross-cache chatter in support of cache
coherency. any cache thrashing invalidates would further degrade the
smp thruput compared to uniprocessor.

using the 1.8times hardware thruput rule-of-thumb ... actual system
thruput was frequently pegged at 1.5times ... because of additional
kernel overhead managing smp environment.

the orignal smp software version adapted from VAMPS ... turned out to
require minimal number of changes to a uniprocessor kernel, almost
zero lock contention in normal operation and managed close to the 1.8
times thruput (having almost zero incremental smp software
overhead). there were even a couple cases of greater than 2times
thruput (with some funny situations involving improved cache hit
ratios compared to uniprocessor).

this changed with a rewrite of the code for sp1. with the 3081, there
was no longer going to be a uniprocessor option. one of the major
operating systems was TPF (transaction processing facility, the
renamed airline control program used heavily by airline reservation
systems ... but also starting to see a lot of use in financial
transaction networks).

the problem was that the TPF didn't have smp support ... and the
generation of computers was smp only. you could take 3081, bring
up vm370 on the machine (with smp support) and run tpf in a
single process virtual machine (under vm370). the issue in a
dedicated TPF environment the 2nd 3081 processor would be idle
most of the time.

part of the issue was that standard virtual machine operation ...
involve the virtual machine execution and then when there were various
kind of privilege operations which then be handled by the vm370
kernel. this processing was serialized for a single virtual machine
(alternating virtual machine execution with kernel execution
... multiple processing execution was normally achieved by having
multiple processor virtual machines and/or having lots of independent
virtual machines).

so a gimmick was created to re-organize the multiprocessing
implementation that would enable asynchronous/concurrent execution of
TPF virtual machine with kernel code executing stuff on behalf of the
TPF virtual machine. This rework increased the overall smp kernel
overhead by about ten percent of each processor ... but it allowed the
2nd 3081 processor to get about another 50precent thruput in the
single, dedicated TPF operation (with overlapped execution of
kernel code and virtual machine operation ... on a processor that
was otherwise idle).

the issue was that the dedicated TPF operation was only a small
precentage of the multiprocessor customers ... but the new kernel
rework took an additional ten percent of every customer smp processor
(reducing their overall thruput ... except for the small number of
dedicated TPF 3081 installations).

lots of past posts mentioning smp and compare&swap
http://www.garlic.com/~lynn/subtopic.html#smp

eventually a 3083, uniprocessor was announced for the TPF market.
this was a uniprocessor version of the 3081 ... with the smp
cache slow-down removed.

misc. past posts mentioning 3083:
http://www.garlic.com/~lynn/99.html#103 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
http://www.garlic.com/~lynn/2000b.html#65 oddly portable machines
http://www.garlic.com/~lynn/2000d.html#9 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000f.html#69 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2001b.html#37 John Mashey's greatest hits
http://www.garlic.com/~lynn/2001c.html#13 LINUS for S/390
http://www.garlic.com/~lynn/2001j.html#17 I hate Compaq
http://www.garlic.com/~lynn/2002c.html#9 IBM Doesn't Make Small MP's Anymore
http://www.garlic.com/~lynn/2002i.html#83 HONE
http://www.garlic.com/~lynn/2002m.html#67 Tweaking old computers?
http://www.garlic.com/~lynn/2002o.html#28 TPF
http://www.garlic.com/~lynn/2002p.html#58 AMP  vs  SMP
http://www.garlic.com/~lynn/2003g.html#30 One Processor is bad?
http://www.garlic.com/~lynn/2003p.html#45 Saturation Design Point
http://www.garlic.com/~lynn/2004.html#7 Dyadic
http://www.garlic.com/~lynn/2004c.html#35 Computer-oriented license plates
http://www.garlic.com/~lynn/2004e.html#44 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2005.html#22 The Soul of Barb's New Machine (was Re: creat)
http://www.garlic.com/~lynn/2005j.html#16 Performance and Capacity Planning
http://www.garlic.com/~lynn/2005m.html#55 54 Processors?
http://www.garlic.com/~lynn/2005o.html#44 Intel engineer discusses their dual-core design
http://www.garlic.com/~lynn/2005s.html#7 Performance of zOS guest
http://www.garlic.com/~lynn/2005s.html#38 MVCIN instruction

all sorts of past posts mentioning TPF or ACP
http://www.garlic.com/~lynn/96.html#29 Mainframes & Unix
http://www.garlic.com/~lynn/99.html#100 Why won't the AS/400 die? Or, It's 1999 why do I have to learn how to use
http://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#152 Uptime (was Re: Q: S/390 on PowerPC?)
http://www.garlic.com/~lynn/2000b.html#20 How many Megaflops and when?
http://www.garlic.com/~lynn/2000b.html#61 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000b.html#65 oddly portable machines
http://www.garlic.com/~lynn/2000e.html#21 Competitors to SABRE?  Big Iron
http://www.garlic.com/~lynn/2000e.html#22 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000f.html#20 Competitors to SABRE?
http://www.garlic.com/~lynn/2001b.html#37 John Mashey's greatest hits
http://www.garlic.com/~lynn/2001e.html#2 Block oriented I/O over IP
http://www.garlic.com/~lynn/2001g.html#35 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001g.html#45 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001g.html#46 The Alpha/IA64 Hybrid
http://www.garlic.com/~lynn/2001g.html#47 The Alpha/IA64 Hybrid
http://www.garlic.com/~lynn/2001g.html#49 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001n.html#0 TSS/360
http://www.garlic.com/~lynn/2002c.html#9 IBM Doesn't Make Small MP's Anymore
http://www.garlic.com/~lynn/2002g.html#2 Computers in Science Fiction
http://www.garlic.com/~lynn/2002g.html#3 Why are Mainframe Computers really still in use at all?
http://www.garlic.com/~lynn/2002h.html#43 IBM doing anything for 50th Anniv?
http://www.garlic.com/~lynn/2002i.html#63 Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002i.html#83 HONE
http://www.garlic.com/~lynn/2002n.html#29 why does wait state exist?
http://www.garlic.com/~lynn/2002o.html#28 TPF
http://www.garlic.com/~lynn/2002p.html#58 AMP  vs  SMP
http://www.garlic.com/~lynn/2003.html#48 InfiniBand Group Sharply, Evenly Divided
http://www.garlic.com/~lynn/2003g.html#30 One Processor is bad?
http://www.garlic.com/~lynn/2003g.html#32 One Processor is bad?
http://www.garlic.com/~lynn/2003g.html#37 Lisp Machines
http://www.garlic.com/~lynn/2003j.html#2 Fix the shuttle or fly it unmanned
http://www.garlic.com/~lynn/2003n.html#47 What makes a mainframe a mainframe?
http://www.garlic.com/~lynn/2003p.html#45 Saturation Design Point
http://www.garlic.com/~lynn/2004.html#24 40th anniversary of IBM System/360 on 7 Apr 2004
http://www.garlic.com/~lynn/2004.html#49 Mainframe not a good architecture for interactive workloads
http://www.garlic.com/~lynn/2004.html#50 Mainframe not a good architecture for interactive workloads
http://www.garlic.com/~lynn/2004b.html#6 Mainframe not a good architecture for interactive workloads
http://www.garlic.com/~lynn/2004b.html#7 Mainframe not a good architecture for interactive workloads
http://www.garlic.com/~lynn/2004c.html#35 Computer-oriented license plates
http://www.garlic.com/~lynn/2004e.html#44 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004n.html#5 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004o.html#29 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005.html#22 The Soul of Barb's New Machine (was Re: creat)
http://www.garlic.com/~lynn/2005b.html#6 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005h.html#22 Today's mainframe--anything to new?
http://www.garlic.com/~lynn/2005j.html#16 Performance and Capacity Planning
http://www.garlic.com/~lynn/2005j.html#17 Performance and Capacity Planning
http://www.garlic.com/~lynn/2005m.html#55 54 Processors?
http://www.garlic.com/~lynn/2005n.html#4 54 Processors?
http://www.garlic.com/~lynn/2005o.html#44 Intel engineer discusses their dual-core design
http://www.garlic.com/~lynn/2005p.html#8 EBCDIC to 6-bit and back
http://www.garlic.com/~lynn/2005s.html#7 Performance of zOS guest
http://www.garlic.com/~lynn/2005s.html#38 MVCIN instruction

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

IBM 610 workstation computer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 610 workstation computer
Newsgroups: alt.folklore.computers
Date: Sun, 26 Feb 2006 22:38:29 -0700

"Dennis Ritchie" writes:

I don't doubt this, but I seem to recall an old paper (perhaps in
Computing Reviews or some other ACM pub.) about the
performance of the fully-duplexed and highly symmetric 360/67
running MTS. The paper was from U. Mich.

It was reported that on some test job mix the 2 CPU system
achieved a slightly greater than 2:1 speedup over the single CPU
version.  This was attributed to the fact that the clever 360/67
hardware sent interrupts preferentially to a momentarily idle processor,
generating less state-saving, thus less interrupt overhead.

ref:
http://www.garlic.com/~lynn/2006d.html#5 IBM 610 workstation computer

there was a separate issue/paper involving TSS/360 on 360/67 which
claimed over three times the thruput on two-processor 360/67 compared
to single processor.

my scenario was a particular workload which had heavy asynchronous i/o
interrupts and causing lots of cache line replacement (high cache miss
rate). some hacks with the smp support did some stuff for
processor/cache affinity ... the improved cache hit rate because
of two caches more than offset the degradation introduced by
smp cross-cache chatter.

the 360/67 didn't have cache ... the maximum memory on a uniprocessor
was one megabyte but you could double that to two megabytes in a two
processor configuration. the tss/360 kernel fixed memory requirements
was neary 700kbytes ... on a one mbyte sysetm, that left possibly
300kbytes ... which resulted in lot of page thrashing (and very low
cpu utilization). going to two-processor system increase the memory
for applications pages by nearly a factor of four (from about 300k to
about 1.3m). the evidence was thruput was highly paging constrained
... since it strictly only doubled the processor thruput (didn't have
the cache gimmick where processor thruput is a function of both the
cache hardware performance as well as the cache hit ratio). however,
the tss/360 thruput was almost directly proportional to the amount of
real storage available for application execution.

what i didn't say in the 370 uniprocessor to 370 two-processor
operation was that both workloads ran at 100percent cpu utilization of
all available processors. assuming identical cache hit rate, strict
hardware thruput should have only 1.8 (with an ideal smp kernel
pathlength implementation) ... the additional thruput was because of
some gimmicks with cache hit rate because of processor/cache affinity.

the tss/360 360/67 "improvement" was because the single processor
thruput was highly real storage constrained and had very low cpu
utilization. the two processor approx. doubled the cpu power (which
wasn't the limit in the single processor scenario) but increased real
storage for application execution by approximately a factor of four
... which was the limiting factor.

the 360/67 multiprocessor nominally had a lower mip rate ... not
because of cache and cache coordination ... but the 360/67
uniprocessor had a single ported memory bus with 750ns cycle time for
8byte storage access. the 360/67 multiprocessor implementation used a
multi-ported memory bus ... which slightly increase memory cycle time
(and resulted in slower mip rate).

however, in an workload that was both heavy cpu utilization as well as
heavy i/o activity ... in the uniprocess/simplex machine there was
lots of memory contention between processor and i/o (resulting in
reduced processor thruput). in the multiprocessor, multi-ported memory
bus ... heavy i/o had much lower memory interferance contention with
cpu use and/or memory contention between multiple cpus and i/o.

a "half-duplex" 360/67 with a single processor had lower idealized mip
rate than a "simplex" 360/67 because of the fixed additional latency
introduced by the multi-ported memory bus. however, in a workload that
was both cpu intensive and i/o intensive, a "half-duplex" 360/67 had
higher effective mip rate than a simplex 360/67 (because of reduced
memory bus contention between cpu and i/o)

misc. past posts mentioning half-duplex and/or multi-ported memory:
http://www.garlic.com/~lynn/94.html#23 CP spooling & programming technology
http://www.garlic.com/~lynn/96.html#26 System/360 Model 30
http://www.garlic.com/~lynn/96.html#39 Mainframes & Unix
http://www.garlic.com/~lynn/97.html#18 Why Mainframes?
http://www.garlic.com/~lynn/98.html#49 Edsger Dijkstra: the blackest week of his professional life
http://www.garlic.com/~lynn/99.html#4 IBM S/360
http://www.garlic.com/~lynn/2000.html#88 ASP (was: mainframe operating systems)
http://www.garlic.com/~lynn/2000c.html#56 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#59 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#65 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#79 Unisys vs IBM mainframe comparisons
http://www.garlic.com/~lynn/2000e.html#2 Ridiculous
http://www.garlic.com/~lynn/2000g.html#11 360/370 instruction cycle time
http://www.garlic.com/~lynn/2001.html#18 Disk caching and file systems.  Disk history...people forget
http://www.garlic.com/~lynn/2001.html#46 Small IBM shops
http://www.garlic.com/~lynn/2001b.html#35 John Mashey's greatest hits
http://www.garlic.com/~lynn/2001e.html#62 Modem "mating calls"
http://www.garlic.com/~lynn/2001j.html#14 Parity - why even or odd (was Re: Load Locked (was: IA64 running out of steam))
http://www.garlic.com/~lynn/2001j.html#23 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001k.html#22 ESCON Channel Limits
http://www.garlic.com/~lynn/2001m.html#25 ESCON Data Transfer Rate
http://www.garlic.com/~lynn/2002.html#48 Microcode?
http://www.garlic.com/~lynn/2002b.html#56 Computer Naming Conventions
http://www.garlic.com/~lynn/2002e.html#32 What goes into a 3090?
http://www.garlic.com/~lynn/2002f.html#6 Blade architectures
http://www.garlic.com/~lynn/2002f.html#7 Blade architectures
http://www.garlic.com/~lynn/2002f.html#37 Playing Cards was Re: looking for information on the IBM 7090
http://www.garlic.com/~lynn/2002g.html#33 ESCON Distance Limitations - Why ?
http://www.garlic.com/~lynn/2002h.html#26 Future architecture
http://www.garlic.com/~lynn/2002i.html#43 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002j.html#36 Difference between Unix and Linux?
http://www.garlic.com/~lynn/2002j.html#74 Itanium2 power limited?
http://www.garlic.com/~lynn/2002j.html#78 Future interconnects
http://www.garlic.com/~lynn/2002q.html#35 HASP:
http://www.garlic.com/~lynn/2003b.html#44 filesystem structure, was tape format (long post)
http://www.garlic.com/~lynn/2003b.html#46 internal network drift (was filesystem structure)
http://www.garlic.com/~lynn/2003g.html#10a Speed of APL on 360s, was Any DEC 340 Display System Doco ?
http://www.garlic.com/~lynn/2003g.html#10 Speed of APL on 360s, was Any DEC 340 Display System Doco ?
http://www.garlic.com/~lynn/2003h.html#0 Escon vs Ficon Cost
http://www.garlic.com/~lynn/2003j.html#2 Fix the shuttle or fly it unmanned
http://www.garlic.com/~lynn/2003o.html#54 An entirely new proprietary hardware strategy
http://www.garlic.com/~lynn/2003o.html#64 1teraflops cell processor possible?
http://www.garlic.com/~lynn/2004.html#25 40th anniversary of IBM System/360 on 7 Apr 2004
http://www.garlic.com/~lynn/2004c.html#46 IBM 360 memory
http://www.garlic.com/~lynn/2004d.html#68 bits, bytes, half-duplex, dual-simplex, etc
http://www.garlic.com/~lynn/2004e.html#2 Expanded Storage
http://www.garlic.com/~lynn/2004g.html#35 network history (repeat, google may have gotten confused?)
http://www.garlic.com/~lynn/2004n.html#45 Shipwrecks
http://www.garlic.com/~lynn/2004p.html#29 FW: Is FICON good enough, or is it the only choice we get?
http://www.garlic.com/~lynn/2005.html#11 CAS and LL/SC
http://www.garlic.com/~lynn/2005.html#38 something like a CTC on a PC
http://www.garlic.com/~lynn/2005.html#50 something like a CTC on a PC
http://www.garlic.com/~lynn/2005e.html#12 Device and channel
http://www.garlic.com/~lynn/2005h.html#7 IBM 360 channel assignments
http://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
http://www.garlic.com/~lynn/2005j.html#13 Performance and Capacity Planning
http://www.garlic.com/~lynn/2005l.html#26 ESCON to FICON conversion
http://www.garlic.com/~lynn/2005n.html#7 54 Processors?
http://www.garlic.com/~lynn/2005r.html#12 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#43 Numa-Q Information
http://www.garlic.com/~lynn/2005s.html#20 MVCIN instruction
http://www.garlic.com/~lynn/2005v.html#0 DMV systems?
http://www.garlic.com/~lynn/2006c.html#1 Multiple address spaces
http://www.garlic.com/~lynn/2006c.html#7 IBM 610 workstation computer
http://www.garlic.com/~lynn/93.html#0 360/67, was Re: IBM's Project F/S ?

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

IBM 610 workstation computer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 610 workstation computer
Newsgroups: alt.folklore.computers
Date: Sun, 26 Feb 2006 23:32:20 -0700

Brian Inglis writes:

The assumption here is that you have sufficient contention on your
global system lock(s): if you don't, then going to fine grained
doesn't make much sense.  With global system lock(s), you can get
contention costing 15-20% of each CPU, and I can't imagine an OS
designed such that fine grained locks, where contention is less
likely, add up to the same 15-20% of each CPU.  (Well, maybe there's
one OS vendor where that could happen!)

this is somewhat dependent on the traditional spin-lock approach to
global system lock. this was almost totally eliminated with the VAMPS
bounce lock approach (reducing the cost of having lock contention) and
moving some very selective kernel pieces outside the global system
lock (reducing the probability of lock contention). misc. recent
bounce lock post
http://www.garlic.com/~lynn/2006.html#16 Would multi-core replace SMPs?
http://www.garlic.com/~lynn/2006b.html#39 another blast from the past
http://www.garlic.com/~lynn/2006b.html#40 another blast from the past ... VAMPS
http://www.garlic.com/~lynn/2006c.html#40 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006c.html#47 IBM 610 workstation computer

part of the bounce lock benefit was a extremely high performance
light-weight deferred execution mechanism specifically designed around
asynchronous serialization of the global lock use. part of the benefit
of the given the processors and the cache sizes of the period ... if
there was existing code executing in the kernel and there was
additional request for kernel execution ... when the current processor
finished it kernel work, it would check if there was additional work
for the kernel. this would then tend to be resumed on the processor
that was already executing in the kernel ... and you would tend to get
some cache affinity and reuse of kernel cache lines (improving overall
cache hit rate and peak execution rate).

the spin-lock approach not only can loose a lot of cpu cycles in the
spin ... but the processor acquiring the kernel lock would then
typically have high cache miss rate as kernel lines were loaded into
the cache of the newly acquiring processor.

there was a lot of smp overhead later introduced ... not directly with
lock contention itself ... but overhead of effectively trying to break
what had been a single thread of work into two pieces of work that can
be executed concurrently on two separate processors.  a lot of
overhead was additional cpu signalling trying to get another processor
to pick up the dynamically split of new piece of work ...  allowing
the current processor to return to executing the virtual machine.
then there was some serialization that had to occur when the two
pieces had to come back into sync.

recent ref:
http://www.garlic.com/~lynn/2006d.html#5 IBM 610 workstation computer

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

IBM 610 workstation computer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 610 workstation computer
Newsgroups: alt.folklore.computers
Date: Sun, 26 Feb 2006 22:11:18 -0700

Andrew Swallow writes:

Modern instruction sets containing index registers and return
instructions from have practically eliminated self modifying software.
The CPU does not need write access to the code areas of Linux, Windows
and WORD whilst running them.

Note the buffer overflow bugs abused by virus writers would not work if
code areas were read-execute only.

Placing the programs in rom would also cause them to run a lot faster,
disk reads are very slow.

some amount of virus writers put instructions into a data area ... and
then clobber stack/return address to point to the attacker's
instruction in some data area. in this attack scenario, it hasn't
actually modified existing instruction areas.

a countermeasure for this exploit is no-execute attribute placed on
data areas ... i.e. preventing instructions being fetched from areas
that are otherwise considered pure data.

lots of past posts mentioning buffer overflow
http://www.garlic.com/~lynn/subintegrity.html#overflow

some specific posts mentioning no-execute attribute (in contrast to
read-only/execute-only attribute)
http://www.garlic.com/~lynn/2004q.html#82 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005.html#0 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005.html#1 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005.html#3 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005.html#5 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005.html#32 8086 memory space [was: The Soul of Barb's New Machine]
http://www.garlic.com/~lynn/2005b.html#25 360POO
http://www.garlic.com/~lynn/2005b.html#39 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#66 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#28 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#44 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005d.html#53 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005d.html#54 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005d.html#55 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005d.html#65 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005o.html#10 Virtual memory and memory protection

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

IBM 610 workstation computer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 610 workstation computer
Newsgroups: alt.folklore.computers
Date: Mon, 27 Feb 2006 07:54:46 -0700

jmfbahciv writes:

However, after the second CPU is on-line, each CPU added after that
should be a whole unit increase.  Thus the third would provide,
2.8, the fourth would give 3.8, etc.  We got to measure five
but never got to see how the system did with a sixth.

ref:
http://www.garlic.com/~lynn/2006d.html#5 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006d.html#6 IBM 610 workstation computer

the problem was that with one cpu ... the cache ran at full-speed.
with two cpus, the cache ran at full-speed ... but its use by local
cpu was slowed down by 10percent to accomodiate cross-cache chatter
coming from one other cache (as part of cache coherency) ... basically
the overall processor machine cycle ran at 10 percent slower.

with four cpus ... each cache was further slowed down to accomodate
cross-cache chatter from three other cpus. by the time they got to
3090, the cache technology implementation had to use technology that
ran significantly faster than processor machine cycle ... in order to
mask any degradation caused by the massive amounts of cross-cache
chatter.

now that was just the basic cache slow-down to accomodate cross-cache
processing ... any cache slow-down involving actually invalidating
cache-lines from signals coming from other caches was over and above
base machine cycle.

part-way into the 3084 (4-way) processor time-frame there was
significant projects to restructure most of the major kernels to
carefully cache align kernel data structures in order to minimize
cache-line thrashing (one case was different data structures
overlapping in the same cache line). this cache-line data structure
reorganization is claimed to have resulted in 5-6 percent overall
system thruput improvement (storage alterations was still causing the
cross-cache cache-line invalidates to be broadcast, but the same cache
line was much less frequently being subject of concurrent use by
multiple processors).

the heavy penalty paid by 370 multiprocessor cache implementations for
extremely strong memory consistency ... was one of the reasons that
i've claimed that 801/risc went to opposite extreme ....  and you
didn't even find hardware cache consistency between the separate
I(nstruction) and D(ata) caches on the same processor. this also
manifested it in system "program loaders" requiring new (software)
instruction to force changed cache-lines from the data cache to memory
(so that program instruction memory areas that the program loader may
have been treating as data and altered ... were forced to memory
... so the alterations would be picked up by the instruction cache
when the loaded program started running). Basically the system program
loader is a special case where instruction memory areas would be
treated as data areas and modified.

this slightly drifts into the thread posting on buffer overflow
exploits. it becomes slightly more problamatical for architectures
with separate I & D caches (with no automatic cache consistency).  any
storage alterations that are resident in the (store into) data cache
may take some time before appearing in memory and be visible to the
instruction cache.
http://www.garlic.com/~lynn/2006d.html#8 IBM 610 workstation computer

collected past posts mention buffer overflow
http://www.garlic.com/~lynn/subintegrity.html#overflow

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

IBM 610 workstation computer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 610 workstation computer
Newsgroups: alt.folklore.computers
Date: Mon, 27 Feb 2006 08:07:19 -0700

jmfbahciv writes:

Right.  The biz did a similar thing when disks were
[emoticon tries to think of a description] primitive. What
I don't understand is why memory development has lagged
so far behind.  Yea, yea.  People spout "faster" numbers
at me but nobody can spout a number that includes the
full system because it's impossible.  So controls need to
be made available to the human who can then tweak and,
based on experiment, judge the best settings for that
particular system.  Load balancing in the olden days,
included discrimination of groups of users (kiddies got
on System X and profs got on System Y).   Profs might
be more compute-intensive so their settings and imposed
limitation will be vastly different than the limitations
for the kiddies who are only learning how to use the gear.

it isn't that memory technology has lagged. there are certain physical
constant issues that existing paradigms are constrained by. you may
have to significantly change the paradigm to get around the
limitations of various physical constants (like maximum signal
propagation time).

tera (now renamed cray) attempted one such paradigm change with
massive threading and eliminated (cpu) cache all together. this is
similar to the 370/195 dual i-stream threading change. normal codes
were only keeping the 195 pipeline half-full (and ran at half the peak
195 instruction thruput rate). the idea was to add a second
instruction stream in hopes that would keep the (single) 195 pipeline
full and hopefully maintain aggregate peak instruction thruput rate
(by having dual i-stream/threads). tera talks about things like 256
concurrent threads.

misc. past posts mentioning tera
http://www.garlic.com/~lynn/2001j.html#48 Pentium 4 SMT "Hyperthreading"
http://www.garlic.com/~lynn/2002l.html#6 Computer Architectures
http://www.garlic.com/~lynn/2003.html#34 Calculating expected reliability for designed system
http://www.garlic.com/~lynn/2003p.html#5 Hyperthreading vs. SMP
http://www.garlic.com/~lynn/2004.html#27 dual processors: not just for breakfast anymore?

in the late 70s, i started noticing similar technology system
mismatches with disk. i got in trouble with the disk division by
claiming that disk technology system thruput had declined by a factor
of 10 over a period of 10-15 years (i.e. disks thruput got five times
faster but processor got 50 times faster and the amount of electronic
memory increased by 50 times). as a result, you saw paradigm shift to
significant amounts of electronic file caching ... at all levels in
the system (analogous to use of cpu caching to compensate for memory
latency restrictions).

misc. past posts:
http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
http://www.garlic.com/~lynn/94.html#43 Bloat, elegance, simplicity and other irrelevant concepts
http://www.garlic.com/~lynn/94.html#55 How Do the Old Mainframes Compare to Today's Micros?
http://www.garlic.com/~lynn/95.html#10 Virtual Memory (A return to the past?)
http://www.garlic.com/~lynn/98.html#46 The god old days(???)
http://www.garlic.com/~lynn/99.html#4 IBM S/360
http://www.garlic.com/~lynn/2001d.html#66 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001f.html#62 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001f.html#68 Q: Merced a flop or not?
http://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
http://www.garlic.com/~lynn/2001l.html#61 MVS History (all parts)
http://www.garlic.com/~lynn/2001m.html#23 Smallest Storage Capacity Hard Disk?
http://www.garlic.com/~lynn/2002.html#5 index searching
http://www.garlic.com/~lynn/2002b.html#11 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002b.html#20 index searching
http://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
http://www.garlic.com/~lynn/2002e.html#9 What are some impressive page rates?
http://www.garlic.com/~lynn/2002i.html#16 AS/400 and MVS - clarification please
http://www.garlic.com/~lynn/2003i.html#33 Fix the shuttle or fly it unmanned
http://www.garlic.com/~lynn/2004n.html#22 Shipwrecks
http://www.garlic.com/~lynn/2004p.html#39 100% CPU is not always bad
http://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
http://www.garlic.com/~lynn/2005k.html#53 Performance and Capacity Planning

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

IBM 610 workstation computer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 610 workstation computer
Newsgroups: alt.folklore.computers
Date: Mon, 27 Feb 2006 08:33:28 -0700

jmfbahciv writes:

And that's what happens when people have a "task-based" thinking
style.  Timesharing thinking styles don't wait until task 1 is done
before looking at task2.

I've been playing with the hypothesis that "task-based" is a male
thinking style; timesharing is a female thinking style.  Before you
type bits at me, ask a female who know about the computing biz.

i don't think it is necessarily gender limited. there may be actually
be two separate issues ... one is the different thinking styles and
two actually being able to dynamically adapt thinking styles as
appropriate to the circumstance.

note that single thread vis-a-vis multi-threaded thinking modes may
also spill over into areas like doing single variable/objectiive
optimizations vis-a-vis doing multi-model optimizations (aka
trade-offs).

one of the things that i was doing back as an undergraduate with the
dynamic adaptive fairshare scheduling ... was being able to dynamic
adapt scheduling to the bottleneck. some strategies might be able to
default cpu use to resource utilization and dynamically adapt
scheduling to amount of (cpu) resource consumed. one of the things
that i was playing with was attempting to dynamically determine
different resource system bottlenecks on a moment-to-moment basis and
dynamically adapt bottleneck resource factors given to the different
types of resources that might be consumed by a task.

for instance, for a heabily paging constrained/bottleneck moment the
amount of cpu consumed by a task may be nearly immaterial in the
efficient operation of the overall system.

one of the things that i got into trouble with doing the scheduler is
that a lot of kernel programmers tend to be strictly state oriented
... setting and testing particular state bits. there were places in
the scheduler that i would arbitrarily switch back and forth from a
highly optimized bit/state manipulation style of programming ... to
much more a fortran/apl probabilistic (say operations research) style
of programming (although done in assembler). individuals accustomed to
a single programming style/mode frequently found it difficult to
follow the logic flow across the arbitrary different programming
styles.

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

IBM 610 workstation computer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 610 workstation computer
Newsgroups: alt.folklore.computers
Date: Mon, 27 Feb 2006 08:45:26 -0700

Anne & Lynn Wheeler writes:

i don't think it is necessarily gender limited. there may be actually
be two separate issues ... one is the different thinking styles and
two actually being able to dynamically adapt thinking styles as
appropriate to the circumstance.

note that single thread vis-a-vis multi-threaded thinking modes may
also spill over into areas like doing single variable/objectiive
optimizations vis-a-vis doing multi-model optimizations (aka
trade-offs).

ref:
http://www.garlic.com/~lynn/2006d.html#11 IBM 610 workstation computer

of course, i would now be remise if i failed to mention boyd.
http://www.garlic.com/~lynn/subboyd.html#boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2

part of his OODA-loops (repeative observe, orient, decide, act
iterations) was that as you were cycling thru the iterations you were
also constantly looking at things from different perspectives and
dealing with issues from a multi-faceted standpoint.

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

IBM 610 workstation computer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 610 workstation computer
Newsgroups: alt.folklore.computers
Date: Mon, 27 Feb 2006 09:53:41 -0700

jmfbahciv writes:

Is this 3 months' runtime or 3 months' wallclock time?  I've been
told stories in the recent past about 3 months of runtime.

it was 3 months job queue elapsed time from the time that the job was
submitted until it got to run. it only ran for several hrs, but there
was big backlog for 370/195 service in bldg. 28.  it also depended
some of priority and/or importance ... some of the priority/importance
was also by size of job (i.e. runtime duration).

misc. posts in this thread:
http://www.garlic.com/~lynn/2006c.html#44 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006d.html#4 IBM 610 workstation computer

by comparison, i've mentioned that the air bearing simulation work
.... part of designing the first thin-film, floating disk heads was
getting one week turn-around (again that was mostly job queue time,
waiting for other things in the queue to finish).
http://www.garlic.com/~lynn/2006d.html#0 IBM 610 workstation computer

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

IBM 610 workstation computer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 610 workstation computer
Newsgroups: alt.folklore.computers
Date: Mon, 27 Feb 2006 10:19:28 -0700

Bernd Felsche writes:

Non-stop computing is a luxury for the vast bulk of systems that can
and do benefit from SMP. If there's a CPU fault, they will probably
crash and the failed CPU will simply not be "found" should the
system be able to reboot without further physical intervention.
That's the limit of fault tolerance.

part of the issue is fault isolation. also, i think Jim Gray, after he
left sjr for tandem ... published a paper in the early 80s about major
sources of faults were software rather than hardware (hardware
reliability was significantly improving while software reliability
wasn't seeing similar improvements ... and the amount of software was
drastically increasing).

isolating various kinds of software faults can be a lot harder in a
shared memory configuration.

i mentioned that one of the reasons that we did ha/cmp cluster
scale-up was that 801/rios had no provisions for cache consistency
... and so cluster approach was about the only way left for adding
processors. however, we also did quite a bit of work on fault
isolation and recovery as part of ha/cmp product.
http://www.garlic.com/~lynn/subtopic.html#hacmp

recent post in this thread ... mentiong distribute lock manager for
ha/cmp and some aspects of database logs and commits as part of
recovery.
http://www.garlic.com/~lynn/2006c.html#8 IBM 610 workstation computer

an earlier scenario i faced was trying to get operating system into
bldg. 14 disk development machine room. they had tried doing testing
of components in development in operating system environment and found
things like the (system software) MTBF for MVS was on the order of 15
minutes with a single test cell.

I undertook to rewrite the operating system input/output supervisor to
be absolutely bullet-proof ... so they could not only perform testcell
testing in an operating system environment ... but could do multiple
concurrent testcell testing ... concurrently with other activity.
Part of the effort in the redesign and rewrite was having a rich
source of i/o errors ... a single testcell might generate more errors
in 15 minutes (and/or other types of failures modes) than a typical
datacenter with football field full of disk would see in a year (in
addition to exhibiting behavior that was precluded by standard
architecture specified operation). misc. past postings mentioning work
for bldg. 14 and bldg. 15
http://www.garlic.com/~lynn/subtopic.html#disk

part of this intersects the scheduling of the air bearing simulation
job mention in other posts in this thread
http://www.garlic.com/~lynn/2006c.html#6 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006d.html#0 IBM 610 workstation computer

bldg. 14 (engineering lab) and bldg. 15 (product test lab) got
early/first processor models. bldg. 15 took delivery of one of the
first 3033s (long before they shipped to customers) for testing with
current and new disks. the 3033 had instruction thruput of about half
that of peak 370/195 (but was the same for most workloads). I had
gotten the rewritten ios operational and most of the machines in
bldg. 14 & 15 were running it. previously machines had to be serially
scheduled for stand-alone testing, a single testcell at a time. now
any testcell could do its testing as needed w/o having to wait for
stand-alone test time. with operating system environment ... even with
multiple testcell testing going on, the 3033 rarely got more than
5percent busy. as a result, we now had essentially a whole lot of
unused cpu power to play with. while there was one week to 3 month
backlog for scheduling work on the 370/195 in bldg. 28, just across
the street, in bldg. 15, we had seemingly unlimited amounts of
processing power immediately available. so one of the things we did
was get the air-bearing simulation application running on the 3033 in
bldg. 15 ... where it got nearly immediate availabiltiy of almost all
the processing it needed. Not only did getting fixing operating system
so that it was useable in bldg. 14 & bldg. 15 ... significantly
improve productivity of new hardware testing, it also made available
significant amounts of additional cpu power that we put to use for
things like getting the air-bearing simulation part of designing new
thin-film floating heads speeded up.

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

Hercules 3.04 announcement

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hercules 3.04 announcement
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 27 Feb 2006 11:26:11 -0700

Anne & Lynn Wheeler wrote:

i shouldn't have been so flip ... it wasn't actually called c-star ...
it was called seastar. there was also a seahorse that would provide
fileserver capability. some of this was "jupiter" controller project
reborn ... but some ten years later. if i remember correctly, dynamic
pathing survived out of jupiter (someplace i may have some long
dissertation on how to slightly modify the original dynamic pathing
architecture proposal and save something like an order of magnitude or
more in the number of circuits to implement as you scaled up).

part of the issue with jupiter controller work starting in early 80s and
then some 10+ years later with seastar and seahorse ... was that disk
controller culture tended to be quite point/targeted ... much more like
embedded system operation. you had a culture that was very box oriented
(again more akin to embedded system) ... trying to move to extremely
complex system design & implementation (huge amount of complex system
being designed/built into the controller).

one might even assert this was some revival of some of the objectives
from the (failed) future system project from the 70s
http://www.garlic.com/~lynn/subtopic.html#futuresys

with complex integration between main processor and outboard controllers
(which somewhat implied that the outboard controllers needed to sport
some amount of complex feature/function ... as prerequisite to having
complex integration with the main processor).

http://www.ecole.org/Crisis_and_change_1995_1.htm

from above:

IBM tried to react by launching a major project called the 'Future
System' (FS) in the early 1970's. The idea was to get so far ahead
that the competition would never be able to keep up, and to have such
a high level of integration that it would be impossible for
competitors to follow a compatible niche strategy. However, the
project failed because the objectives were too ambitious for the
available technology.  Many of the ideas that were developed were
nevertheless adapted for later generations. Once IBM had acknowledged
this failure, it launched its 'box strategy', which called for
competitiveness with all the different types of compatible
sub-systems. But this proved to be difficult because of IBM's cost
structure and its R&D spending, and the strategy only resulted in a
partial narrowing of the price gap between IBM and its rivals.

... &

This first quiet warning was taken seriously: 2,500 people were
mobilised for the FS project. Those in charge had the right to choose
people from any IBM units. I was working in Paris when I was picked
out of the blue to be sent to New York. Proof of the faith people had
in IBM is that I never heard of anyone refusing to move, nor
regretting it. However, other quiet warnings were taken less
seriously.

... snip

i didn't make myself popular at the time making references to future
system project having some similarities with a cult film that had been
playing non-stop for more than a decade down in central sq. (some
reference to the inmates being in charge of the institution and that
there was so much impractical stuff for the period that they couldn't
possibly pull it off).

of course i was also somewhat opinionated that what i had already
deployed and running in scheduling was more advanced than the
daydreams about scheduling in the FS documents.

misc. past posts taking note of the crisis and change article
http://www.garlic.com/~lynn/2000f.html#16 [OT] FS - IBM Future System
http://www.garlic.com/~lynn/2003l.html#30 Secure OS Thoughts
http://www.garlic.com/~lynn/2003p.html#25 Mainframe Training
http://www.garlic.com/~lynn/2005p.html#8 EBCDIC to 6-bit and back
http://www.garlic.com/~lynn/2005p.html#15 DUMP Datasets and SMS
http://www.garlic.com/~lynn/2005s.html#16 Is a Hurricane about to hit IBM ?
http://www.garlic.com/~lynn/2006.html#7 EREP , sense ... manual

the intro/abstract for the referenced article
http://www.ecole.org/Crisis_and_change_1995_1.htm

The rise and fall of IBM

Jean-Jacques DUBY
Scientific Director of UAP
Former Science & Technology Director of IBM Europe

After 40 years of unrivalled success, IBM is now in serious trouble.
What has happened? Jean-Jacques Duby explains how the company's values
and the cogs and wheels of its internal management system doomed IBM to
failure, in the light of long developments in the technical, economic
and commercial environment.

But why there should have been such a sudden shock remains a mystery.
Perhaps IBM's mighty power had delayed its downfall, making this all the
more brutal as a result, like the earthquake which follows the sudden
encounter of two continental plates.

IBM 610 workstation computer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 610 workstation computer
Newsgroups: alt.folklore.computers
Date: Tue, 28 Feb 2006 07:55:58 -0700

jmfbahciv writes:

TOPS-10 called it system idle time.  The system that had the
most continuous high idle time was the boring one which
not many people used.  Thus the system load on the "slower"
machine was so much lighter that it could deliver more
computing service for this application than the "faster,
sexier" machine because everybody else (a.k.a. users) was
using the faster machine.

the 370/195 in bldg. 28 was setup as a service for lots of
organizations. pasc's 370/145 was setup just for pasc's personal
computing use.

pasc had a big number crunching job that only took several hrs to run
on the 370/195 ... but over time the 370/195 service acquired a bigger
and bigger backlog of number crunching jobs (and turn-around time is a
combination of queuing time and actual service time).

at some point, somebody realized that the idle time on the pasc
machine intended for personal computing use ... could be harnessed for
doing number crunching intensive application. this is somewhat
analogous to some of the current distributed applications that have
harnessed the idle time on thousands of personal computers for
tackling compute intensive applications (although the pasc application
wasn't amenable to distributed implementation ... its use of idle time
on computer installed for personal computing uses has some
similarities).

part of the issue is realizing that a tool could be adapted for
purposes that it wasn't originally intended to be used ... i.e.  the
idle time on a computer installed for interactive computing use could
be adapted for single long running compute intensive application.

the 370/195 service was extremely popular with the computing
intensive, number crunching community ... but wasn't very popular with
the interactive, personal computing crowd. idle time was a
characteristic of hard-to-use and/or unpopular computers ...  but also
started to become a characteristic of computers installed for
interactive, personal computing use ... especially as the trade-off
between people time costs and computer time costs shifted.

during this poriod ... before idle time was widely accepted as
overhead for optimizing for personal computing use ... there were lots
of studies on the effect of interactive response on personal
productivity ... and different classes of systems that either did well
or poorly at providing interactive response (could a system be created
that optimized for total, 100 percent system resource utilization
while still providing optimized interactive response). this was an era
of the arguments about whether subsecond response was either good or
bad for humans, whether it might actually make a different in human
productivity, and/or whether optimizing for human productivity was
actually a good or bad thing.

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

IBM 610 workstation computer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 610 workstation computer
Newsgroups: alt.folklore.computers
Date: Tue, 28 Feb 2006 08:05:43 -0700

KR Williams writes:

That is *not* SMP.  Fault-tolerant computing comes closer and SMP
isn't needed to tolerate faults.  &Bigbank. in the UK used a four-
way (2SPx2AP) 3090 as a MP (each side doubling for the other), then
doubled that on-site, and doubled that again off-site to get to a
level or FT they could live with.  This certainly isn't SMP.

when we were doing ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp

we coined the terms disaster survivability and geographic
survivability to distinquish from simple disaster/recovery.  in that
period, there had been some studies of dataprocessing operations
surviving natural disaster ... and something about most of them tended
to have localized geographic impact within 40mile radius (although
noted in past threads, there could be some with natural resource
specific distribution characteristic ... like less than a mile on each
side of a flooding river ... but the length of the documented flood
plains could stretch for much more than 40 miles).

also during that period we were asked to help write the corporate
continuous availability strategy document ... we put in some stuff
based on some work we were doing on ha/cmp geographic survivability
... which was later removed because of objections from other corporate
product divisions (as not being able to be met by them).

misc. past posts mentioning disaster survivability and/or geographic
survivability:
http://www.garlic.com/~lynn/98.html#23 Fear of Multiprocessing?
http://www.garlic.com/~lynn/99.html#145 Q: S/390 on PowerPC?
http://www.garlic.com/~lynn/99.html#184 Clustering systems
http://www.garlic.com/~lynn/aadsm2.htm#availability A different architecture? (was Re: certificate path
http://www.garlic.com/~lynn/aepay2.htm#cadis disaster recovery cross-posting
http://www.garlic.com/~lynn/2000g.html#27 Could CDR-coding be on the way back?
http://www.garlic.com/~lynn/2001.html#33 Where do the filesystem and RAID system belong?
http://www.garlic.com/~lynn/2001.html#41 Where do the filesystem and RAID system belong?
http://www.garlic.com/~lynn/2001g.html#46 The Alpha/IA64 Hybrid
http://www.garlic.com/~lynn/2001i.html#41 Withdrawal Announcement 901-218 - No More 'small machines'
http://www.garlic.com/~lynn/2001i.html#43 Withdrawal Announcement 901-218 - No More 'small machines'
http://www.garlic.com/~lynn/2001i.html#46 Withdrawal Announcement 901-218 - No More 'small machines'
http://www.garlic.com/~lynn/2001i.html#48 Withdrawal Announcement 901-218 - No More 'small machines'
http://www.garlic.com/~lynn/2001i.html#49 Withdrawal Announcement 901-218 - No More 'small machines'
http://www.garlic.com/~lynn/2001j.html#23 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001k.html#13 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2001k.html#18 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2001n.html#47 Sysplex Info
http://www.garlic.com/~lynn/2002.html#44 Calculating a Gigalapse
http://www.garlic.com/~lynn/2002c.html#39 VAX, M68K complex instructions (was Re: Did Intel Bite Off More Than It Can Chew?)
http://www.garlic.com/~lynn/2002e.html#67 Blade architectures
http://www.garlic.com/~lynn/2002e.html#68 Blade architectures
http://www.garlic.com/~lynn/2002f.html#4 Blade architectures
http://www.garlic.com/~lynn/2002i.html#24 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002l.html#15 Large Banking is the only chance for Mainframe
http://www.garlic.com/~lynn/2002m.html#5 Dumb Question - Hardend Site ?
http://www.garlic.com/~lynn/2002p.html#54 Newbie: Two quesions about mainframes
http://www.garlic.com/~lynn/2003.html#38 Calculating expected reliability for designed system
http://www.garlic.com/~lynn/2003f.html#36 Super Anti War Computers
http://www.garlic.com/~lynn/2003h.html#31 OT What movies have taught us about Computers
http://www.garlic.com/~lynn/2003h.html#60 The figures of merit that make mainframes worth the price
http://www.garlic.com/~lynn/2003o.html#6 perfomance vs. key size
http://www.garlic.com/~lynn/2003p.html#37 The BASIC Variations
http://www.garlic.com/~lynn/2004c.html#16 Anyone Still Using Cards?
http://www.garlic.com/~lynn/2004h.html#20 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004m.html#24 IBM Spells Out Mainframe Strategy
http://www.garlic.com/~lynn/2004m.html#26 Shipwrecks
http://www.garlic.com/~lynn/2004n.html#39 RS/6000 in Sysplex Environment
http://www.garlic.com/~lynn/2004o.html#5 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004p.html#48 History of C
http://www.garlic.com/~lynn/2005.html#52 8086 memory space
http://www.garlic.com/~lynn/2005c.html#6 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#7 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
http://www.garlic.com/~lynn/2005i.html#11 Revoking the Root
http://www.garlic.com/~lynn/2005k.html#28 IBM/Watson autobiography--thoughts on?
http://www.garlic.com/~lynn/2005n.html#0 Cluster computing drawbacks
http://www.garlic.com/~lynn/2005n.html#7 54 Processors?
http://www.garlic.com/~lynn/2005n.html#26 Data communications over telegraph circuits
http://www.garlic.com/~lynn/2005o.html#38 SHARE reflections
http://www.garlic.com/~lynn/2005p.html#11 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005q.html#38 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005u.html#37 Mainframe Applications and Records Keeping?

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

IBM 610 workstation computer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 610 workstation computer
Newsgroups: alt.folklore.computers
Date: Wed, 01 Mar 2006 12:14:35 -0700

Morten Reistad writes:

The $TELCO procedures I mentioned could clearly be problematic
in a setting like New Orleans; but they would be among the last
services to go.

In addition to the separation requirement there are requirements
that the sites not share a single CO for telco access, nor the
same power substation. It is also a requirement that they are not
in the same floodarea (i.e. a full set of dikes between them
if they are lowlaying); also they are not to be served by the same
main road; and some distance requirements to airports, pipelines etc.

They are not overdoing it either. Telcos don't expect to provide
other than emergency services after martial law has been declared.
Sending out notices about this is a routine occurrence at any large
telco.

there was a single dataprocessing site that had carefully selected
building in a block that had different water mains down two different
sides of the building, different electrical substation from two
different directions, and telco from four different COs from four
different service directions (lots of this is frequently referred to
as telco provisioning and/or diverse routing). one day a transformer
in the basement blew and required that the building be evacuated
... in addition to taking out the service.

in the early 80s, my wife was involved in putting in a (non-AT&T) CO
into westchester country area. turns out that they didn't get their
48v battery array setup correctly ... and at the first power outage
... the lack of having gotten the 48v battery array correctly setup
... took out all phone service in westchester country (lots of nasty
finger pointing from multiple directions).

there is the well-known story about internet service to new england
being taken out. the service had been carefully set up with 9
different lines going by 9 different trunks in 9 different directions
out of the new england area. however, over the years the 9 different
trunks had been slowly consolidated ... until they were all being
carried by a single fiber optic cable that went thru some place in
Connecticut ...  where a backhoe was digging one day.

one of the scenarios is to consider no single point of failure
... which not only includes the provisioning of actual equipment in
the datacenter, but all services required by the datacenter ... and
making sure that none of them are likely to be subject to a common
disaster (i.e. the rule-of-thumb about 40miles separation ... however
that might not preclude all possible kinds of common disasters ...
for instance something like a complete regional power blackout).

there is also the story about a major atm transaction processing
datacenter ... that had its disaster/recovery site in WTC. after the
bombing in the early 90s, the disaster/recover site was down .. and in
that period there was heavy snowfall in the area and the roof of the
prime site datacenter collapsed. it took them something like 48hrs to
get something back up and running.

as US HONE evolved from a couple simple cp67 datacenters in the early
70s into several major vm370 by the mid-70s providing online services
for all sales, marketing and field people in the US (sometime in
mid-70s, mainframe computer orders were getting so complex that they
could no longer be filled out by hand and had to be run thru a HONE
configurator). around 77, all the US HONE datacenters were
consolidated into a single datacenter in northern cal. this had
multiple large SMP processors in clusters all interconnected with the
disk farm and other services. load-balancing and fall-over was
provided across all processors in the complex.

approx. 1980, the US HONE datacenter was replicated in Dallas because
of earthquake issues as a failure mode. this provided load balancing
and fall-over within the datacenters as well as between the northern
cal. datacenter and the dallas datacenter. shortly afterwards a third
redundant, load-balancing, fall-over datacenter was created in
boulder. About that time, the US HONE datacenter had number of defined
userids approaching 40k (sales, marketing, and field people in the
US).

this is in addition to the US HONE datacenter being cloned at many
places around the world ... providing world-wide support for sales,
marketing, and field people.

misc. past postings mentioning HONE (and/or APL)
http://www.garlic.com/~lynn/subtopic.html#hone

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

Hercules 3.04 announcement

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hercules 3.04 announcement
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 01 Mar 2006 12:17:41 -0700

"Kevin G. Rhoads" writes:

Was that "King of Hearts"?

ref:
http://www.garlic.com/~lynn/2006d.html#15  Hercules 3.04 announcement

yep

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

Statistics on program constant sizes?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Statistics on program constant sizes?
Newsgroups: comp.arch,comp.programming
Date: Wed, 01 Mar 2006 14:10:03 -0700

MitchAlsup writes:

Address constants need to be considered in two situations, offsets
and direct addresses. These constants are invented by the compiler
and/or linker and not typically seen by the application
programmer. There are typically more of these constants than there
are arithmetic constants.  Offsets are typically small, direct
address constants are rarely small.  Offsets are used to represent a
displacement from the beginning of a structure to that element,
displacements onto the stack for that element, and displacements
into a frame. Only rarely are frames and stack depths such that
these displacements need to be large (> 8-bits).  Direct addresses
are amost always left to the linker for virtual placement of the
referenced data item. As such, these are almost invariably allocated
a virtual address bit-size* in the instruction even if the linker
succeeds in placing that data item in a location that could be
addressed directly with fewer bits.

there is an issue with "absolute" address constants in virtual
page-mapped operations ... avoiding needing to pin a page-mapped
object to a specific virtual address because of direct address objects
embedded in the page-mapped object and/or having to prefetch random
pieces of the page-mapped object to swizzle the direct address objects
to correspond to the address that the page-mapped object has been
loaded in a specific address space (this is particularly aggravating
in large systems with the possibility that the same page-mapped object
may appear simulataneously in multiple different virtual address
spaces concurrently on the same real machine ... and possibly have to
be materizlied at different virtual addresses).

systems designed from the start for this type of virtual address
space behavior have possibly done

1) a lot larger offset address objects that can cover the a large,
complete page-mapped object

2) direct address objects in different structure from program
... where the direct address objects can be swizzled for mapping to
specific virtual address (within a specific address space) w/o needing
to impact the (program) page mapped object.

I got into trying to craft both techniques in the early 70s when
introducing page-mapped paradigm into a system that hadn't been
originally designed for virtual address page mapping operation.
misc. past posts mentioning some of the difficulties
http://www.garlic.com/~lynn/subtopic.html#adcon

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

IBM 610 workstation computer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 610 workstation computer
Newsgroups: alt.folklore.computers
Date: Thu, 02 Mar 2006 10:21:40 -0700

jmfbahciv writes:

As for sceduling, there are times when just doing the work brute
force method is a huge performance win rather than spending a lot of
CPU exec time trying to do the most elegant scheduling.  IIRC,
TTYCHK echoing fell into this category.  It was more efficient to
just do the echo at the interrupt rather than stack it.  Note that
this is based on my recall of the guys talking about it.

that was something akin to the original cp67 10 level scheduler (some
of which may have even been inherited from ctss). the cpu overhead was
more overhead than any benefit it provided (in part because it only
looked at cpu and didn't have any page thrashing controls). it also
had some stuff that rescanned the whole list ... that resulted in the
overhead being proportional to the size of the queue (number of users)
... not the amount work performed.

the change done by lincoln labs to two level scheduler ... got lot
less sophisticated about differentiating cpu utilization ...
significantly reduced the scheduling cpu overhead and thru in a very
rudimentary page thrashing control ... however it left in some
frequent list scanning ... so while the overhead scanning the lists
was reduced (compared to the earlier implementation) ... it still grew
as the size of the queues grew ... not proportional to the thruput.

so the dynamic adaptive feedback stuff ... fundamental approach was
attempt to achieve near zero scheduling pathlength overhead at the
same time making it much more proportional to the work perform ...
not proportional to the size of the queues (which can grow non-linear
independent of the amount of resources handed out).

so that was part of the various slight of hand stuff ... to come up
with coding solutions that didn't involve rescanning complete queues
and attempting to do things like n*(n-1)/2 set of comparisons
regarding various states.

rule of thumb, scheduling overhead was proportional to the thruput,
not the size of the queues. for some topic drift ... we encountered a
drastic example of this in the early web scale-up days. tcp
implementations originally assumed relatively long-lived sessions.
http came along and used tcp for reliable transaction operations
... with all the setup/teardown ... minimum of 7 packet exchange (we
had earlier worked on xtp that had minimum of 3 package exchange for
reliable transaction). tcp kept a finwait list of all terminated
sessions on the off chance that there might be some dangling packets
arrive after the termination handshake (because of out-of-order
delivery feature of underlying ip). as webservers scaled up ... there
was a period where several major platforms were spending 95percent of
total cpu doing linear scan of the finwait list on packet
arrival. misc. past finwait posts:
http://www.garlic.com/~lynn/99.html#1 Early tcp development?
http://www.garlic.com/~lynn/99.html#164 Uptime (was Re: Q: S/390 on PowerPC?)
http://www.garlic.com/~lynn/2000c.html#52 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2002.html#3 The demise of compaq
http://www.garlic.com/~lynn/2002.html#14 index searching
http://www.garlic.com/~lynn/2002i.html#39 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002j.html#45 M$ SMP and old time IBM's LCMP
http://www.garlic.com/~lynn/2002q.html#12 Possible to have 5,000 sockets open concurrently?
http://www.garlic.com/~lynn/2003e.html#33 A Speculative question
http://www.garlic.com/~lynn/2003h.html#50 Question about Unix "heritage"
http://www.garlic.com/~lynn/2004m.html#46 Shipwrecks
http://www.garlic.com/~lynn/2005c.html#70 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005g.html#42 TCP channel half closed
http://www.garlic.com/~lynn/2005o.html#13 RFC 2616 change proposal to increase speed

misc. past posts mentioning xtp (and hsp, high-speed protocol, as well
as our problems with OSI in ISO standards meetings)
http://www.garlic.com/~lynn/subnetwork.html#xtphsp

another scheduling point i learned from cp67 in my undergraduate days
is that frequently there is a whole bunch of scenarios where spending
a lot of time making a decision has little or no overall effect. make
the most frequent decisions a lot simpler and save more sophisticated
stuff for less frequent. misc. past posts on scheduling
http://www.garlic.com/~lynn/subtopic.html#fairshare

one of the other places that i threw in slight of hand coding was in
the page replacement. i had highly optimized the selection to be near
zero overhead ... while still near optimally approx.  true LRU
replacement. a problem is that true LRU (and the various approx)
degenerate to FIFO under various conditions. I came up with a slight
of hand that degnerated to random (instead of fifo) under those
conditions. part of the trick was the transition to random didn't
involve any real coding ... it involved a slightly different way that
the data structures were built/handled ... such that degenerating to
random (instead of FIFO) was much more a side-effect of the data
structure ... as opposed to lots of fancy coding (that would have
tended to have significantly more overhead).

misc. past postings on page replacement, etc
http://www.garlic.com/~lynn/subtopic.html#wsclock

for even more drift ... effectively part of dynamic adaptive resource
management was keeping track of the rate at which resources were
consumed. xtp also wandered into doing rate-based pacing ... as
opposed to windows and things like slow-start for congestion control.
in the same period that slow-start was originally published ... there
was paper in acm sigcomm conference showing that window-based
congestion control was unstable in high-latency, heterogeneous
networking environments (and the original point of windows is as
latency compensation in high-latency environments). misc. past
posts mentioning rate-based pacing
http://www.garlic.com/~lynn/93.html#28 Log Structured filesystems -- think twice
http://www.garlic.com/~lynn/94.html#22 CP spooling & programming technology
http://www.garlic.com/~lynn/99.html#33 why is there an "@" key?
http://www.garlic.com/~lynn/2000b.html#11 "Mainframe" Usage
http://www.garlic.com/~lynn/2001h.html#44 Wired News :The Grid: The Next-Gen Internet?
http://www.garlic.com/~lynn/2002.html#38 Buffer overflow
http://www.garlic.com/~lynn/2002i.html#45 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#57 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002k.html#56 Moore law
http://www.garlic.com/~lynn/2002p.html#28 Western Union data communications?
http://www.garlic.com/~lynn/2002p.html#31 Western Union data communications?
http://www.garlic.com/~lynn/2003.html#55 Cluster and I/O Interconnect: Infiniband, PCI-Express, Gibat
http://www.garlic.com/~lynn/2003.html#59 Cluster and I/O Interconnect: Infiniband, PCI-Express, Gibat
http://www.garlic.com/~lynn/2003b.html#44 filesystem structure, was tape format (long post)
http://www.garlic.com/~lynn/2003g.html#54 Rewrite TCP/IP
http://www.garlic.com/~lynn/2003g.html#64 UT200 (CDC RJE) Software for TOPS-10?
http://www.garlic.com/~lynn/2003j.html#1 FAST - Shame On You Caltech!!!
http://www.garlic.com/~lynn/2003j.html#19 tcp time out for idle sessions
http://www.garlic.com/~lynn/2003j.html#46 Fast TCP
http://www.garlic.com/~lynn/2003p.html#15 packetloss bad for sliding window protocol ?
http://www.garlic.com/~lynn/2004f.html#37 Why doesn't Infiniband supports RDMA multicast
http://www.garlic.com/~lynn/2004k.html#8 FAST TCP makes dialup faster than broadband?
http://www.garlic.com/~lynn/2004k.html#12 FAST TCP makes dialup faster than broadband?
http://www.garlic.com/~lynn/2004k.html#13 FAST TCP makes dialup faster than broadband?
http://www.garlic.com/~lynn/2004k.html#16 FAST TCP makes dialup faster than broadband?
http://www.garlic.com/~lynn/2004k.html#29 CDC STAR-100
http://www.garlic.com/~lynn/2004n.html#35 Shipwrecks
http://www.garlic.com/~lynn/2004o.html#62 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2004q.html#3 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2004q.html#57 high speed network, cross-over from sci.crypt
http://www.garlic.com/~lynn/2005d.html#6 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005g.html#4 Successful remote AES key extraction
http://www.garlic.com/~lynn/2005q.html#22 tcp-ip concept
http://www.garlic.com/~lynn/2005q.html#28 tcp-ip concept
http://www.garlic.com/~lynn/2005q.html#37 Callable Wait State
http://www.garlic.com/~lynn/2005t.html#38 What ever happened to Tandem and NonStop OS ?

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

IBM 610 workstation computer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 610 workstation computer
Newsgroups: alt.folklore.computers
Date: Thu, 02 Mar 2006 11:17:31 -0700

Steve O'Hara-Smith writes:

No it's not. The most common way of providing delivery of non
stop continuous computing services these days is massive redundancy
at the machine level rather than redundancy within the machine.

The first setup I worked on with this approach used 20
Motorola 88K based UNIX boxes with a spec requirement that any
single machine could fail and be replaced with a new box without
interrupting the processing or losing a single bit of data. It took
some careful design but that spec was achieved. These days it's
considered to be an easy stunt to pull off and systems of several
hundred machines in which several machines can die without anyone
noticing a glitch are in use.

when were were doing ha/cmp ... we talked to the 1-800 people.  they
had five-nines requirement (5 minutes downtime per year) ... and were
using a platform that was hardware fault tolerant. however, the
platform periodically required system software maint. ... even
doing it only once a year ... they still saw outages on the
order of 30+ minutes (using several years worth of down-time
budget per year).

the ss7 had a pair of T1 links that it used to talk to the 1-800
lookup box ... and if it failed to get an answer from one side ... it
would redrive the same request down the other line (in some sense
1-800 are like domain/host names that have to be looked up to get the
real network address ... err, phone number)

a pair of ha/cmp boxes ... one attached to each T1 link could provide
the same hardware MTBF as the fault tolerant hardware box ... with the
redirve from the ss7 masking any failure/fall-over.

then, there was a proposal to use a pair of fail-over fault tolerant
hardware boxes ... in order to mask their software downtime; however
going to the expense of a pair of fail-over fault tolerant hardware
boxes then negated the purpose of having the fault tolerant hardware
boxes in the first place. part of this was that the reliability of
basic (non-fault-tolerant) hardware had significantly
advanced/improved over the years.

misc. past ha/cmp posts
http://www.garlic.com/~lynn/subtopic.html#hacmp

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

IBM 610 workstation computer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 610 workstation computer
Newsgroups: alt.folklore.computers
Date: Fri, 03 Mar 2006 07:54:12 -0700

cdl@deeptow.ucsd.edu (Carl Lowenstein) writes:

LBTs?? Well, I cast my mind back about 35 years and say
"aha  Little Blue Tapes" for sticking down the ends of DECtape.
I always thought they stuck on by static electricity not by spit.

they were also common on ibm tapes ... especially the ptf tapes
... small gray plastic ... barely bigger than the space for the hub
... pontentially having a 100ft or so. they didn't have cases.  the
little blue tapes were little less important on the tapes that came in
cases. "ptf" ... program temporary fixes ... distributed on these
really cheap mini-reels.

then came the drive sthat supported the autoloading band ... and you
no longer needed such stuff.

a little topic drift, recent thread about mounting tape
(have some URL pointers to pictures of tape drives and
(large) reels of tape:
http://www.garlic.com/~lynn/2006b.html#2 Mount a tape
http://www.garlic.com/~lynn/2006b.html#7 Mount a tape

this is picture of 3420 9track tape ... with the autoload strap
... you no longer needed the little blue tapes to keep the tape from
unraveling around the hub.
http://ftp.columbia.edu/acis/history/media.html

the small gray plastic ptf tapes (with possible 100ft-200ft of tape,
as opposed to 2400ft of tape for full-size tapes, there were also
"mini-reels" that were 1200ft and mini/mini reels that came in a
rubbermaid-like snap-off cover container with possibly as little as
400ft of tape) had maybe half inch wide flange for tape (maybe inch
bigger diameter than the hole in the middle for the tape drive hub).

another picture of 3420 9track tape reel, along with a 3480
tape cartridge
http://researchweb.watson.ibm.com/journal/rd/474/brads7.jpg

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

IBM 610 workstation computer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 610 workstation computer
Newsgroups: alt.folklore.computers
Date: Fri, 03 Mar 2006 12:44:17 -0700

David Scheidt writes:

If the fault tolerent application has performance requirements, then
you can't.  Half the machine has to be able to meet the peak demands.
If you're relying on the "redundant" gear to meet performance goals,
then you've no longer got redundancy.

It's possible to build systems that take advantage of the redundant
hardware for increased performance.  I've even run some.  But there is
always pressure to add features, and those features eat system
resources.  If the system managers aren't careful, the resource usage
will exceed what the cluster in a degraded state can do.  For lots of
applications, a system that is performing poorly is worse than one
that's dead.

when we started project for ha/cmp product ...
http://www.garlic.com/~lynn/subtopic.html#hacmp

i created a cluster taxonomy around

• mode1 ... 1+1 fail-over (2nd processor idle)
• mode2 ... 1+1 mutual fall-over .. both processors running
            but 2nd, fail-over processor running non-critical
            apps
• mode3 ... 2 ... i.e. concurrent operation running shared workload
            and concurrent access to shared disks. this required
            something more akin to mainframe loosely-coupled or
            vax/cluster concurrent disk access support.

from there we expanded from 2 to N ... where there could be N+1
... spare processor could stand-in for any single failed processor
(some years later found some other vendors using similar language in
some of their marketing brochures).

this is more akin to raid for disk reliability ... aka simple
mirroring has fully replicated disks ... but you have have raid5
something like 8+1 ... eight data disks, plus a parity disk ... where
any single disk failure and keep running with the remaining.

there are also some similarities to the resource consumption discussed
in background batch ... i.e. applications soaking up resources not
needed by other processors (and possibly lack any significant
time-critical requirements).
http://www.garlic.com/~lynn/2006c.html#44 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006d.html#0 IBM 610 workstation computer

note that with software becoming more & more the primary failure cause
... partitioned, non-shared memory provides an extra level of fault
isolation ... that may be compromised in shared-memory/smp
configurations.

and, of course, shared-memory is very conducive for geographic
separation implementations.

for a little topic drift ... my wife did a stint in pok where
she was responsible for (mainframe) loosely-coupled (cluster)
architecture ... where she created peer-coupled shared data
architecture ...
http://www.garlic.com/~lynn/subtopic.html#shareddata

which has evolved into today's parallel sysplex; a few references:
http://www-03.ibm.com/servers/eserver/zseries/swprice/sysplex/
http://www.redbooks.ibm.com/abstracts/sg245346.html

and geographically dispersed parallel sysplex (geoplex):
http://www-306.ibm.com/software/success/cssdb.nsf/CS/AMWR-646P8F?OpenDocument&Site=software

and current ha/cmp web page
http://www-03.ibm.com/servers/systems/p/software/hacmp.html

which even mentions various remote site backup implementations

this mentions ha/cmp enhanced scalability
http://www.redbooks.ibm.com/Redbooks.nsf/RedbookAbstracts/sg245327.html?Open

... which somewhat got side-tracked ... because we were doing
scale-up as part of the original ha/cmp effort ... minor ref
http://www.garlic.com/~lynn/95.html#13

as mentioned in the above, we sort of got our hands slapped and told
we couldn't work on anything with more than four processors.

for more drift, when we started hsdt (high-speed data transport) project
http://www.garlic.com/~lynn/subnetwork.html#hsdt

 ... one of the things were some high-speed satellite links (pilot
stuff we had dedicate transponder on sbs-4) and got involved with
designing fault tolerant tdma earth stations (requirements more akin
to telco/CO switching hardware ... had hot-pluggable boards ...  could
do real-time removal and re-insertion of processor and communication
boards in the rack). unsubstantiated ... but one of the vendors
building a set of tdma earth stations to our "spec" ... claimed to
have been approached (by some other organization) to build a duplicate
of earth stations to our same specification (a little industrial
espionage?)

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

Caller ID "spoofing"

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Caller ID "spoofing"
Newsgroups: alt.folklore.computers
Date: Fri, 03 Mar 2006 13:12:11 -0700

greymaus writes:

PS, Lynn was making the point a while ago about the rate of change
in hardware. Marx's `Das Kapital' tried to theorize about how
changes in technology create changes, and forced further changes in
society, Marx tried to extend this to show that genuinely socialist
system would take over (In my opinion, forcing the original theories
into his preferred world outlook), but that was technology working
fairly slowly, the frantic pace at the moment will create a logjam
(to make an analogy) that may crash the system..

part of that was boyd and OODA-loops
http://www.garlic.com/~lynn/subboyd.html#boyd

some of the other web-sites where you find boyd and OODA-loop
references are now looking at it from standpoint of business agility
and adaptability.
http://www.garlic.com/~lynn/subboyd.html#boyd2

boyd would do his briefing to commercial companies and the issues of
agility and adaptability are very applicable ... but the historical
agile/adapting examples in the core briefings tended to be pulled from
military history. the principles are applicable to any sort of
competitive situations ... but historical short-period agile/adaptible
examples are harder to find outside of military history (unless
possibly you go all the way to darwin).

with regard to mentioned ach pull/push (dda / checking accounts)
... the x9a10 financial standards working group was given the
requirement to preserve the integrity of financial infrastructure
for all retail payments. as a result we did a pretty detailed
threat and vulnerability examination of various retail payment
mechanisms; ach, debit, credit, stored-value, etc. when coming up with
the x9.59 standard
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

the requirement for x9.59 was "ALL" ... not just a single transaction
type or just retail or just point-of-sale ... but "ALL".

in parallel with work on x9.59 standards work ... a parallel
submission was made to nacha (we ghosted the submission, but it was
submitted by somebody else since we weren't nacha members at the
time):
http://www.garlic.com/~lynn/nacharfi.htm
more background
http://www.garlic.com/~lynn/x959.html#aads

nacha website
http://www.nacha.org/

which is national organization for ACH payment operations.

as part of some of the authentication work, we were called in to help
word-smith the cal. state electronic signature legislation (and then
later the federal legislation).
http://www.garlic.com/~lynn/subpubkey.html#signature

one of the industry groups participating in t