List of Archived Posts

2003 Newsgroup Postings (01/10 - 01/19)

Clustering ( was Re: Interconnect speeds )
cost of crossing kernel/user boundary
vax6k.openecs.org rebirth
vax6k.openecs.org rebirth
vax6k.openecs.org rebirth
vax6k.openecs.org rebirth
vax6k.openecs.org rebirth
vax6k.openecs.org rebirth
vax6k.openecs.org rebirth
Mainframe System Programmer/Administrator market demand?
Mainframe System Programmer/Administrator market demand?
Mainframe System Programmer/Administrator market demand?
cost of crossing kernel/user boundary
FlexEs and IVSK instruction
vax6k.openecs.org rebirth
vax6k.openecs.org rebirth
vax6k.openecs.org rebirth
vax6k.openecs.org rebirth
cost of crossing kernel/user boundary
Message (authentication/integrity); was: Re: CRC-32 collision
vax6k.openecs.org rebirth
vax6k.openecs.org rebirth
Multics preservation: good news
vax6k.openecs.org rebirth
vax6k.openecs.org rebirth
vax6k.openecs.org rebirth
vax6k.openecs.org rebirth
vax6k.openecs.org rebirth
Multics preservation: good news
Message (authentication/integrity); was: Re: CRC-32 collision
Round robin IS NOT load balancing (?)
asynchronous CPUs
Mainframe System Programmer/Administrator market demand?
Round robin IS NOT load balancing (?)
Calculating expected reliability for designed system
Round robin IS NOT load balancing (?)
mainframe
Calculating expected reliability for designed system
Calculating expected reliability for designed system
Flex Question
InfiniBand Group Sharply, Evenly Divided
InfiniBand Group Sharply, Evenly Divided
basic pki question
Timesharing TOPS-10 vs. VAX/VMS "task based timesharing"
Will Apple ever offer a newsreader?
InfiniBand Group Sharply, Evenly Divided
Horror stories: high system call overhead
Timesharing TOPS-10 vs. VAX/VMS "task based timesharing"
InfiniBand Group Sharply, Evenly Divided
InfiniBand Group Sharply, Evenly Divided
Origin of Kerberos
Top Gun
SSL & Man In the Middle Attack
Cluster and I/O Interconnect: Infiniband, PCI-Express, Gibat
Timesharing TOPS-10 vs. VAX/VMS "task based timesharing"
Cluster and I/O Interconnect: Infiniband, PCI-Express, Gibat
Wild hardware idea
If you lived as a child in the 50's, 60's or 70's,
Card Columns
Cluster and I/O Interconnect: Infiniband, PCI-Express, Gibat
MIDAS
MIDAS
Card Columns
SSL & Man In the Middle Attack
SSL & Man In the Middle Attack
Amdahl's VM/PE information/documentation sought
SSL & Man In the Middle Attack
3745 & NCP Withdrawl?
3745 & NCP Withdrawl?
Why did they make FORTRAN so hard to parse?
Disk drives as commodities. Was Re: Yamhill
Card Columns
Disk drives as commodities. Was Re: Yamhill
Card Columns
paper tape input

Clustering ( was Re: Interconnect speeds )

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Clustering ( was Re: Interconnect speeds )
Newsgroups: comp.arch,comp.sys.sgi.hardware,comp.sys.intel
Date: Thu, 02 Jan 2003 17:16:04 GMT
Alexis Cousein writes:
It'd be much more interesting to see someone from LANL (not LLNL, BTW -- they have a Power4 based setup, not ASCI Q) comment on the application scalability on the entire Q setup on a diverse set of applications -- Top500 is fine for some uses, but hardly for a comprehensive debate about computer architecture.

somewhat as an aside .... my view from the standards period (essentially going on simultaneously) was that

LANL was driving factor behind HiPPI .... wanting a industry standard (commodity priced?) for cray channel

LLNL was driving factor behined FCS ... wanting a fiber standards version of a copper serial non-blocking switch that they had installed.

SLAC was driving factor behind SCI ... comments recently posted (sequent, data general, and convex built SCI-based computers)

random ref:
http://www.garlic.com/~lynn/95.html#13

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

cost of crossing kernel/user boundary

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: cost of crossing kernel/user boundary
Newsgroups: comp.arch
Date: Thu, 02 Jan 2003 17:22:48 GMT
Emil Naepflein writes:
That is standard on most systems today because the processors support this by generating a trap when the registers were not saved and a new task wants to access floating point registers.

the place that i first saw such hardware assist was for the registers in the 3090's optional vector processor.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

vax6k.openecs.org rebirth

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vax6k.openecs.org rebirth
Newsgroups: alt.folklore.computers,comp.sys.prime
Date: Thu, 02 Jan 2003 20:03:17 GMT
Morten Reistad writes:

Timeline, from Google, Wiki, SGI, sympatico.ca etc. :

??      1981 : IBM starts ROMP
??      1981 : Stanford starts MIPS project
??      1984 : First MIPS processor implementation
April   1986 : First Fujitsu SPARC chips, 10 mips
June    1986 : Mips 2000 introduced.
October 1986 : PA-Risc introduced.
March   1987 : 4D/60 R2000 based system, 7 mips, 0.7 mflops
July    1987 : Sun announces SPARC spec officially
??      1987 : ARM, Archimedes home computer, 4 mips
??      1987 : AMD29000,
mid     1988 : Motorola 88000
October 1988 : PowerSeries R2000 based systems from SGI, 20+++ MIPS, 2+++ mflop
??      1988 : Mips R3000, 40++ mips
??      1989 : Sparcstation 1, 12.5 mips

For comparison, 6-8 mips was a pretty high end minicomputer in 1985.

CP.r (control program for 801 processor) & PL.8 (programming language for 801 processor) was presented at an internal advanced technology meeting held in pok spring of '77 (may have been spring '76, i can't find the reference at the moment).

This was followed by Fort Knox ... which was a large project to replace all the low-end & mid-range microprocessors with 801s (i.e. the low & mid range 370 microprocessos, the rochester system/3 stuff, etc) ... and other control processors, like the things what the uc.5 & jib-prime were used for). While fort knox was killed some of the work still showed up as internal control processors in other products.

Fort Knox was eventually killed ... but office products division and research started up ROMP as the basis for displaywriter follow-on (using both CP.r and PL.8 as the basis). When the displaywriter follow-on was killed, the group tried to quickly adapt ROMP to the unix workstation market (contracting with the same company that had done the PC/IX port for the PC).

misc 801, romp, fort knox postings:
http://www.garlic.com/~lynn/subtopic.html#801

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

vax6k.openecs.org rebirth

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vax6k.openecs.org rebirth
Newsgroups: alt.folklore.computers,comp.sys.prime
Date: Thu, 02 Jan 2003 20:23:45 GMT
Anne & Lynn Wheeler writes:
misc 801, romp, fort knox postings:
http://www.garlic.com/~lynn/subtopic.html#801


and while some number of the engineers on fort knox showed up on ROMP ... some also left the company showing up (at least) on AMD's 29k and HP's. one of the other internal projects going on about the same time as ROMP (16bit 801) was blue iliad (32bit 801). Blue iliad never shipped ... but one of the people that worked on it later showed up at HP ... and possibly one of the others showed up at SUN.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

vax6k.openecs.org rebirth

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vax6k.openecs.org rebirth
Newsgroups: alt.folklore.computers,comp.sys.prime
Date: Thu, 02 Jan 2003 21:10:11 GMT
Anne & Lynn Wheeler writes:
CP.r (control program for 801 processor) & PL.8 (programming language for 801 processor) was presented at an internal advanced technology meeting held in pok spring of '77 (may have been spring '76, i can't find the reference at the moment).

was spring of '77 (not '76). spring of '76 i was doing the resource manager, the stuff for ECPS (vm m'code assist for virgil/tully) and VAMPS (5-way smp). didn't start on the 16-way smp stuff until later in '76. at the same adtech meeting (spring '77) where the 801 group presented 801, cp.r, pl.8, etc. .... we presented the 16-way smp project.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

vax6k.openecs.org rebirth

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vax6k.openecs.org rebirth
Newsgroups: alt.folklore.computers,comp.sys.prime
Date: Fri, 03 Jan 2003 04:39:47 GMT
Brian Inglis writes:
Did 16 way SMP go anywhere? I know most IBM shops stopped at four-way per system, as 370 cache coherence/snooping overhead took away about 20% of each available CPU, you only ever got 0.8N usable processing, so by five-way you effectively got only four CPUs worth of processing. Bigger complexes always seemed to get partitioned into multiple systems with smaller numbers of processors on each.

standard 370 had very strong consistency memory model .... requiring tight coupling between caches. 370, 303x, 308x two-way .... basically took a ten percent performance hit .... just for the cycle time slow-down to listen for cache invalidates from one other processor. That is just for starts .... when cache line invalidate signals were actually happening ... there was additional slowdowns.

3084 was a four way ... where each cache had to listen for cache line signals from three other processors (rather than just one). Later machines started running portions of cache hardware at significantly faster cycle times than the rest of the processor infrastructure .... just to keep up with the cache line invalidate signals.

the five-way project wasn't a cache machine (so didn't suffer the cache consistency overhead issues) ... it was a 370/125. The 370/125 was physical a 9-way SMP machine .... nine positions on the memory bus with some or all of the positions occupired by microprocessors. The basic difference between the micrprocessors was what kind of microcode was loaded .... aka traditional 370/125 had one of the microprocessors loaded with 370 instruction set emulation ... and the other microprocessors were loaded with various kinds of controller and I/O functions. The five-way ... had up to five of the microprocessors loaded with 370 instruction set emulation. There was also going to be a superset of VM microcode assist that was done for virgel/tully (ECPS) ... along with effectively task queue and task switch in microcode (somewhat move akin to some of the 432 stuff than the XA SIE instruction) and much of the page subsystem offloaded to the disk controller microprocessor. misc m'code discussions:
http://www.garlic.com/~lynn/subtopic.html#360mcode

Effectively the remaining portions of VM kernel (not moved to microcode) had the old-style 360/65 OS kernel lock ... however it was unique in rather than a spin-lock ... it was a queued or bounce lock, aka if a processor microcode couldn't obtain the kernel lock .... it queued a lightweight kernel processing request against the kernel lock and went off to the microcode schedule/dispatcher to find some other work. The objective was that the virtual/kernel processing ratio was on the order of 9:1 or better (aided by various portions of the VM kernel dropped into the parallelized microcode). As long as it stayed better than 4:1 ... the workload wouldn't bottleneck on the kernel lock (and it was a very low-overhead lock since there was no spinning).

This was also the design model I used for the SMP support in the VM/370 product release. Basically all of what was in the VAMPS parallelized microcode had the necessary fine-grain locking support. There was then a single "kernel" lock for main body of low useage kernel code. If processing required the "kernel" lock ... and couldn't obtain it ... it would queue a lightweight request off the kernel lock and go to the parallelized dispatcher/scheduler to find some other work not requiring the kernel lock. I claimed that this was the maximum parallelized SMP thruput for the fewest number of code changes. misc. smp threads/posts
http://www.garlic.com/~lynn/subtopic.html#smp

As i mentioned I was doing the resource manager at the same time ... aka
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock

The resource manager had the distinction of being the first "priced" operating system code .... and i got the opportunity to work with the business people on the business rules for such pricing. However, there was a lot of code that I put into the resource manager that wasn't strictly algorithm control .... there was a lot of code that was integrity oriented (failure resistant) and also oriented towards structures supporting parallelized SMP operation. However, it went out before the standard VM/370 support shipped with SMP support. Some discussion of the integrity & benchmarking posts:
http://www.garlic.com/~lynn/submain.html#bench

When it came time to ship VM/370 release with SMP support ... it was decided that it would be a "free" release ... but containing something like 80 percent of the lines of code from the resource manager. The resource manager product for the first SMP VM/370 release continued to be charged the same as it had in the pre-SMP release version ... but it had only about 1/5th the lines of code (the rest of the code being absorbed by the still free operating system release).

16-way smp had a much weaker cache consistency memory model (than traditional mainframes) .... allowing much less inter-cache overheads. this required some additional operating system changes for things like more pervasive use of compare&swap in certain situations. it ran into other issues ... as mentioned in (executives hammered some engineers for working with us when it was realized that there was no chance of MVS supporting the machine):
http://www.garlic.com/~lynn/2002p.html#58 AMP vs SMP

Some of the degradation in scalable processors was how strong the memory model was maintained by cache hardware & associated protocols. Other issues affecting thruput was somewhat independent of the cache consistency protocols. One of the things that a lot of attention in the 3084 (4-way) time-frame was kernel storage allocation structures ... starting to align them on cache line boundaries and making them multiples of cache line sizes. The issue was that if two different data structures occupied the same cache line ... and were potentially in use by two different processes on two different processors at the same time ... there could be extremely extensive cache line trashing.

The other issues that operating system paradigm dependent .... is the locking granularity .... whether or not spin-lock paradigm was used .... or some other paradigm was used. The compare&swap instruction was the doings of charlie at cambridge scientific center ... original working on fine-grain locking for CP/67. The instruction was first invented and the mnemonic chosen to match charlie's initials (it is one of the few widely used instructions that are actually somebody's initials).

Another issue is what sort of paradigm does the kernel use to serialize/syncronize various operations across different processes. One of the last release of VM (aka for 370) ... before VM/XA significantly redid the structure for the use of the SIGP (signal processing instruction). When that release hit the streets ... the SIGP paradigm change was using ten percent of total elapsed time on both processors just for SIGP and related infrastructure processing (just on the off chance that it might be useful to tell the other processor something).

In this situation ... for two way operation ... there was the hardware loss of ten percent of both processors going to the caches listening for each others invalidate & syncronization signals ... plus this software kernel release introduced an additional ten percent of both processors going to the kernel on each processor waving to itself on the other processor (and then you get to talk about all the other normal single processor as well normal multiprocessor kernel overheads).

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

vax6k.openecs.org rebirth

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vax6k.openecs.org rebirth
Newsgroups: alt.folklore.computers,comp.sys.prime
Date: Fri, 03 Jan 2003 04:59:27 GMT
Anne & Lynn Wheeler writes:
a superset of VM microcode assist that was done for virgel/tully (ECPS) ... along with effectively task queue and task switch in microcode (somewhat move akin to some of the 432 stuff than the XA SIE instruction) and much of the page subsystem offloaded to the disk controller microprocessor. misc m'code discussions:
http://www.garlic.com/~lynn/subtopic.html#360mcode


the five-way was targeted at cms intensive environment .... and the CMS had my redo that mapped the cms filesystem into a paged mapped infrastructure. as a result all disk i/o used the page mapped semantics (i.e. for file operation and for virtual memory paging ... as well as all of the various kernel on-disk filestructures).

so all disk & file i/o became page I/O operations of one sort or another ... majority of the processing offloaded to the disk controller microprocessor. misc. page mapped postings
http://www.garlic.com/~lynn/submain.html#mmap

later when we were doing ha/cmp (high availability, cluster multiprocessor product for the 6000) we also got involved in the hippi, fcs, and sci standards activity. sci was scalable model used by (at least) sequent, data general, and convex for scalable processor configurations; recent reference ...
http://www.garlic.com/~lynn/2003.html#0 Clustering (was interconnect speeds)

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

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

vax6k.openecs.org rebirth

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vax6k.openecs.org rebirth
Newsgroups: alt.folklore.computers,comp.sys.prime
Date: Fri, 03 Jan 2003 16:10:48 GMT
jmaynard@thebrain.conmicro.cx (Jay Maynard) writes:
The S/370 architecture only allows for two CPUs. How was that going to be extended for more? (The 3084 would only allow all 4 CPUs to run in one system image in XA mode.)

easy .... as per previous post .... the underlying hardware of the 370/125 (370/115) was a 9-way ... it had up to nine microprocessors sharing the same memory bus. the normal 125 configuration only had one of the 370s loaded with the microcode to emulate 370 ... the other microprocessors had other kinds of microcode to emulate other kinds of functions (disk controller, other i/o functions, etc).

the five-way would have up to five of the microprocessors running the microcode to emulate 370 ... but with heavy modifications; a superset of both SIE instruction and ECPS (for virgil/tully) ... along with changes for parallelization in microcode including the dispatching/scheduling function in the the microcode. also the disk controller microcode had most of the page i/o offloaded to it.

so based on above from original post .... if there was going to be that much microcode changes .... how hard would it be to support five-way 370? ... when the underlying hardware was already supporting nine-way.

actually ... almost all of the function for parallelization was in the microcode .... there was a trivial amount in the kernel for the single global queue or bounce lock ... and there serialization with compare&swap for queue management .... things going on/off the dispatch queue ... things going on/off the disk i/o queue, etc.

The design was actually for 16-way .... however the underlying hardware was only 9-way ... and given that some of the microprocessors had to perform i/o control functions .... needed a minimum of four processors doing the various i/o control functions .... leaving only five slots for microprocessors executing 370 code.

as an aside, remember that the original 360/67 was designed for 4-way ... nearly 20 years before the 3084 4-way (in xa mode).

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

vax6k.openecs.org rebirth

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vax6k.openecs.org rebirth
Newsgroups: alt.folklore.computers,comp.sys.prime
Date: Fri, 03 Jan 2003 16:26:13 GMT
jmaynard@thebrain.conmicro.cx (Jay Maynard) writes:
The S/370 architecture only allows for two CPUs. How was that going to be extended for more? (The 3084 would only allow all 4 CPUs to run in one system image in XA mode.)

also ... what is the 370 SMP architecture that is sensitive to number of processors. there is the signal processor instruction. in the five-way design the whole sigp stuff was replaced with all the microcode level shared-queue management i.e. most of the kernel type logic involved in operations associated with sigp'ing other processors was pushed down into the microcode ... it was abstracted out of the software kernel model all together and moved into microcode function.

not directly related ... but there is whether all processors have access to all i/o. the tradtional 360/370 had dedicated i/o channels for each processor and the I/O controllers then had multi-path channel connections allowing each controller access to channels for each processor.

The 360/67 had a different architecture that allowed all channels to be address by all processors (in up to 4-way configuration). Such architecture for I/O channel addressing didn't show up again until XA. The limitation of lashing two 3081s together to form a 4-way 3084 was much more a hardware limitatin than a difficult architecture limitation.

Now, since for the 5-way 370/125 ... since we were doing all the microcode changes .... moving almost everything involving multiprocessing support out of the direct 370 architecture (and kernel) into the microcode ... and since the 370/125 didn't have real channels ... just other microprocessors on the same memory bus with the appropriate microcode .... there was also change to the i/o structure. As mentioned in the original post ... the interface between the processor and disks was changed from SIO/channel architecture to shared queues ... where most of the page & disk processing was offloaded into the microprocessor with the disk controller microcode. Rather than being SIO/channel there was queue of requests pending by the disk controller and there was the queue of requests that had finished.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Mainframe System Programmer/Administrator market demand?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframe System Programmer/Administrator market demand?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 03 Jan 2003 16:54:53 GMT
gsmith@NC.RR.COM (Greg Smith) writes:
Indeed. I never realized that s370/s390/z900 architecture was so 'common' that mere riff-raff could write code to emulate it.

there is some contention that much of the pu4/pu5 complexity was because of of project that four of did when i was undergraduate coming up with first PCM controller.
http://www.garlic.com/~lynn/subtopic.html#360pcm

later with amdahl/fujitsu and national/hitachi processors (as well as some of the little guys 4pi, etc, i think late 70s & early 80s saw a number of entry/mid-range clones) there were similar questions regarding driving factors in processor architecture enhancements.

one of the big issues when pr/sm origination time-frame (leading to lpars) was amdahl's macrocode. the high-end mainframes tended to be very complex horizontal microcode ... and architecture changes tended to be quite complex code undertakings. amdahl's macrocode was a 370 subset for microcode impelemtation .... making it significantly easier to track (& even enhance) architecture changes (aka amdahl's original implementation was much simpler undertaking than ibm's response with pr/sm).
http://www.garlic.com/~lynn/2000c.html#76 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2002o.html#15 Home mainframes
http://www.garlic.com/~lynn/2002o.html#18 Everything you wanted to know about z900 from IBM
http://www.garlic.com/~lynn/2002p.html#40 Linux paging
http://www.garlic.com/~lynn/2002p.html#44 Linux paging
http://www.garlic.com/~lynn/2002p.html#45 Linux paging
http://www.garlic.com/~lynn/2002p.html#46 Linux paging
http://www.garlic.com/~lynn/2002p.html#48 Linux paging

as to the low/mid range ... that market was taken over by high-end PCs and workstations for everybody starting sometime in the mid-80s .... not just the IBM 370 low/mid range (but most of the minis).
http://www.garlic.com/~lynn/2002q.html#3 Vector display systems
http://www.garlic.com/~lynn/2002j.html#66 vm marketing (cross post)

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Mainframe System Programmer/Administrator market demand?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframe System Programmer/Administrator market demand?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 03 Jan 2003 17:38:07 GMT
Anne & Lynn Wheeler writes:
as to the low/mid range ... that market was taken over by high-end PCs and workstations for everybody starting sometime in the mid-80s .... not just the IBM 370 low/mid range (but most of the minis).
http://www.garlic.com/~lynn/2002q.html#3 Vector display systems
http://www.garlic.com/~lynn/2002j.html#66 vm marketing (cross post)


the market segment started this explosion ... in the same time-frame the airforce was ordering 240 4341s ...
http://www.garlic.com/~lynn/2001m.html#15 departmental servers

TI had a project that they ordered 800 4341s for a project. STL was converting a conference room on every floor, in every tower to a 4341 room.

the orders for 4341s far outstripped the production (some rumor in part because of some intra-company issues between 4341 & 3031). clones were appearing to fill the gap. it was general market segment so there was also big increase for most minis (not just 370).

however, as all this was happening ... PCs and workstations were starting to appear ... and started to take over the market segment (transition year being about '85 ... which is about also when the nodes on the internet exceeded the nodes on the internal network).

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Mainframe System Programmer/Administrator market demand?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframe System Programmer/Administrator market demand?
Newsgroups: bit.listserv.ibm-main
Date: Fri, 03 Jan 2003 21:23:55 GMT
edgould@AMERITECH.NET (Edward Gould) writes:
Phil,

What do you feel are (is) the major reason(s) why outsourcing fails?


from a different point of view .... outsourcing really works when there is no change .... everything has been pretty much the same for the last 20-30 years.

one of the oursourcing complexities is creating a larger disconnect between the users/clients of the data processing service and the actual service ... things tend to be much more contractual and formal (and using a boyd'ism ... creates resistance and reduces agility, boyd has some number of commercial examples .... but a military was why does the army want its own close air support rather than relying on the air force).

where there is little need for agility (because of no evolving circumstances and changing requirements) ... aka a relatively static environment ... then the lack of agility has little impact.

the counter argument is outsourcing may bring higher trained data processing specialists which can more than compensate for the resistance introduced by a more formal contractual relationship.

the other classical failure is where there is active animosity between the users and the executives making the out-sourcing decision (resulting in all kinds of subversion).

boyd OODA-loops and high agility for competitive rapidly changing environments:
http://www.garlic.com/~lynn/subboyd.html#boyd

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

cost of crossing kernel/user boundary

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: cost of crossing kernel/user boundary
Newsgroups: comp.arch
Date: Sat, 04 Jan 2003 15:03:57 GMT
jfc@mit.edu (John F. Carr) writes:
On the original RS/6000 the svc/svcr instruction pair took about four cycles, compared to about zero for a direct call and return. Notably, that was less time than a pair of pipeline drains. There was a vectored system call (caller selects one of a large number of entry points) that could be used to reduce overhead for simple calls. I think atomic compare&swap was implemented as a fast system call.

compare&swap is supposed to be atomic ... non-interruptable and provide serialization in an smp environment. when original compare&swap was proposed (for 370) ... challenge by the owners of the 370 architecture was to come up with various methodologies for using compare&swap in uniprocessors environments ... which was born the description for using it for various kinds of "safe" queue updating in multi-threaded applications. the 6000/rios didn't have compare&swap primitive and didn't have multiprocessing support ... the only thing needed for simulating compare&swap for multi-threaded applications was to prevent interrupts. the fast simulation in the svc handler was a way of getting all interrupts turned off from application mode during the simulation of the instruction.

old trivia ... and of course compare&swap mnemonic was chosen because they are charlie's initials.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

FlexEs and IVSK instruction

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: FlexEs and IVSK instruction
Newsgroups: bit.listserv.ibm-main
Date: Sat, 04 Jan 2003 16:27:02 GMT
xarax@email.com (xarax) writes:
space, rather than the home address space (causing all kinds of storage overlays when in key 0 cross memory mode). All of these were IBM boo-boos that made it into the field, and subsequently fixed. (Ancient history now.)

370/125 had one in the long instructions. in all the 360 instructions, the start & end addresses of operands were checked before starting the instruction ... and aborting for things like protection, addressing, etc. the long instructions were incremental & interruptable ... you didn't check the ending address before starting ... but checked the addresses as the instruction was executing. when a long instruction was interrupted .... like for protection, addressing (or i/o, etc) ... the registers had been updated to reflect most recently processed data. the 125 had an early boo-boo where it prechecked the ending addresses of the long instructions and interrupted at that point.

some programs used mvcl with zero padding to clear storage and at the same time to check for end of memory ... the instruction should interrupt with addressing interrupt with registers set to last valid address processed. prechecking resulted in no execution at all and no register update ... and as result incorrect value for size of real storage.

story of bug in 360/67 with the virtual memory table look aside (referred to associative array at the time):
http://www.garlic.com/~lynn/2002q.html#54 cost of crossing kernel/user boundary

some other recent 125 refs:
http://www.garlic.com/~lynn/2002f.html#13 Hardware glitches, designed in and otherwise
http://www.garlic.com/~lynn/2002i.html#2 Where did text file line ending characters begin?
http://www.garlic.com/~lynn/2002i.html#9 More about SUN and CICS
http://www.garlic.com/~lynn/2002i.html#24 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#76 HONE was .. Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002j.html#64 vm marketing (cross post)
http://www.garlic.com/~lynn/2002m.html#75 New Book
http://www.garlic.com/~lynn/2002n.html#58 IBM S/370-168, 195, and 3033
http://www.garlic.com/~lynn/2002o.html#16 Home mainframes
http://www.garlic.com/~lynn/2002p.html#47 Linux paging
http://www.garlic.com/~lynn/2002p.html#58 AMP vs SMP
http://www.garlic.com/~lynn/2003.html#5 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#7 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#8 vax6k.openecs.org rebirth

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

vax6k.openecs.org rebirth

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vax6k.openecs.org rebirth
Newsgroups: alt.folklore.computers,comp.sys.prime
Date: Sat, 04 Jan 2003 16:55:12 GMT
jmaynard@thebrain.conmicro.cx (Jay Maynard) writes:
I was thinking SIGP and CONCS/DISCS, specifically. Looks like you got around both of those, although it would have required running under a specific version of VM.

i was working on ECPS with endicott for virgil/tully at the same time and that required running a specific version of vm .... a vm modified for all the ecps instructions ... and released as a product. while all the changes for ecps weren't as many as the changes for VAMPS ... they were still significant ... and required specific version of vm. ecps was the vm microcode assists/accelerator for virgil/tully (370/138 & 370/148 and then 4331, 4341, etc). An initial product strategy was to attempt to make ecps/vm part of the hardware product on all machines shipped (in much the same way done for LPARS today).

later the VAMPS architecture was translated to vanilla 158/168 multiprocessor support (w/o microcode enhancements) ... which required running a specific version of vm .... a vm modified to support multiprocessing .... and released as a product (course there is the intertwining of the resource manager which had a bunch of things down for multiprocessor environments and released prior to the vm release with full multiprocessor support .... and all that code had to be switched from the resource manager product ... to the base product).

the translation of VAMPS to vanilla 158/168 was about the same amount of code changes for specific version of vm.

I didn't see where VAMPS was all that different than what i was doing for ecps or the resource manager .... and it sure wasn't that different from the official smp support. just do it, get it into the product and ship it. much of the technique used for ecps could also be used for most of VAMPS.

for ecps, at boot ... there was a list of all the ecps instructions thru-out the kernel ... if ecps wasn't available on the machine ... all those instructions got no-oped ... and the kernel effectively dropped thru to the software instructions. if the ecps instruction was executed ... it continued after the instructions it replaced (as opposed to the following instruction). in some of the VAMPS cases ... it would have bypassed large bodies of instructions.

part of the reason that VAMPS didn't make it out was that it would have been competing in the same market segment as vigil/tully. since i was doing both ... in some of the product escalation meetings ... i got a chair on both sides of the table and had the opportunity to have extensive arguments with my opposing self as to which was better and why.

misc smp refs:
http://www.garlic.com/~lynn/subtopic.html#smp

misc. ecps refs:
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/94.html#27 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/94.html#28 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/2000.html#12 I'm overwhelmed
http://www.garlic.com/~lynn/2000c.html#50 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#76 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000e.html#6 Ridiculous
http://www.garlic.com/~lynn/2000g.html#7 360/370 instruction cycle time
http://www.garlic.com/~lynn/2001b.html#29 z900 and Virtual Machine Theory
http://www.garlic.com/~lynn/2001b.html#83 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001i.html#2 Most complex instructions (was Re: IBM 9020 FAA/ATC Systems from 1960's)
http://www.garlic.com/~lynn/2001i.html#3 Most complex instructions (was Re: IBM 9020 FAA/ATC Systems from 1960's)
http://www.garlic.com/~lynn/2002e.html#75 Computers in Science Fiction
http://www.garlic.com/~lynn/2002f.html#57 IBM competes with Sun w/new Chips
http://www.garlic.com/~lynn/2002i.html#80 HONE
http://www.garlic.com/~lynn/2002j.html#5 HONE, xxx#, misc
http://www.garlic.com/~lynn/2002l.html#51 Handling variable page sizes?
http://www.garlic.com/~lynn/2002l.html#62 Itanium2 performance data from SGI
http://www.garlic.com/~lynn/2002o.html#15 Home mainframes
http://www.garlic.com/~lynn/2002o.html#16 Home mainframes
http://www.garlic.com/~lynn/2002p.html#44 Linux paging
http://www.garlic.com/~lynn/2002p.html#48 Linux paging
http://www.garlic.com/~lynn/2003.html#4 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#5 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#6 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#7 vax6k.openecs.org rebirth

misc. VAMPS refs:
http://www.garlic.com/~lynn/2000c.html#68 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000d.html#10 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#11 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000e.html#6 Ridiculous
http://www.garlic.com/~lynn/2000e.html#7 Ridiculous
http://www.garlic.com/~lynn/2001i.html#2 Most complex instructions (was Re: IBM 9020 FAA/ATC Systems from 1960's)
http://www.garlic.com/~lynn/2001j.html#18 I hate Compaq
http://www.garlic.com/~lynn/2001j.html#19 I hate Compaq
http://www.garlic.com/~lynn/2001j.html#48 Pentium 4 SMT "Hyperthreading"
http://www.garlic.com/~lynn/2002i.html#80 HONE
http://www.garlic.com/~lynn/2002i.html#82 HONE
http://www.garlic.com/~lynn/2002o.html#16 Home mainframes
http://www.garlic.com/~lynn/2003.html#4 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#5 vax6k.openecs.org rebirth

other 4341 refs:
http://www.garlic.com/~lynn/95.html#3 What is an IBM 137/148 ???
http://www.garlic.com/~lynn/96.html#1 360/370
http://www.garlic.com/~lynn/98.html#34 ... cics ... from posting from another list
http://www.garlic.com/~lynn/98.html#49 Edsger Dijkstra: the blackest week of his professional life
http://www.garlic.com/~lynn/99.html#7 IBM S/360
http://www.garlic.com/~lynn/99.html#36 why is there an "@" key?
http://www.garlic.com/~lynn/99.html#123 Speaking of USB ( was Re: ASR 33 Typing Element)
http://www.garlic.com/~lynn/2000.html#29 Operating systems, guest and actual
http://www.garlic.com/~lynn/2000.html#90 Ux's good points.
http://www.garlic.com/~lynn/2000b.html#37 How to learn assembler language for OS/390 ?
http://www.garlic.com/~lynn/2000c.html#76 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000c.html#83 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000d.html#0 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#9 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#10 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#11 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#12 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#13 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#20 S/360 development burnout?
http://www.garlic.com/~lynn/2000d.html#82 "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
http://www.garlic.com/~lynn/2000e.html#52 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2000e.html#53 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2000e.html#57 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2001.html#21 Disk caching and file systems. Disk history...people forget
http://www.garlic.com/~lynn/2001.html#22 Disk caching and file systems. Disk history...people forget
http://www.garlic.com/~lynn/2001b.html#69 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001d.html#63 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001d.html#65 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001d.html#67 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001e.html#9 MIP rating on old S/370s
http://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001h.html#44 Wired News :The Grid: The Next-Gen Internet?
http://www.garlic.com/~lynn/2001j.html#3 YKYGOW...
http://www.garlic.com/~lynn/2001j.html#20 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001l.html#32 mainframe question
http://www.garlic.com/~lynn/2001m.html#12 Multics Nostalgia
http://www.garlic.com/~lynn/2001m.html#15 departmental servers
http://www.garlic.com/~lynn/2001n.html#39 195 was: Computer Typesetting Was: Movies with source code
http://www.garlic.com/~lynn/2002.html#11 The demise of compaq
http://www.garlic.com/~lynn/2002b.html#0 Microcode?
http://www.garlic.com/~lynn/2002d.html#7 IBM Mainframe at home
http://www.garlic.com/~lynn/2002e.html#46 What goes into a 3090?
http://www.garlic.com/~lynn/2002e.html#75 Computers in Science Fiction
http://www.garlic.com/~lynn/2002f.html#8 Is AMD doing an Intel?
http://www.garlic.com/~lynn/2002g.html#44 ibm icecube -- return of watercooling?
http://www.garlic.com/~lynn/2002h.html#52 Bettman Archive in Trouble
http://www.garlic.com/~lynn/2002i.html#7 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#19 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#22 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#23 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#27 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#29 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#30 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#37 IBM was: CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#43 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002j.html#4 HONE, , misc
http://www.garlic.com/~lynn/2002j.html#7 HONE, , misc
http://www.garlic.com/~lynn/2002j.html#67 Total Computing Power
http://www.garlic.com/~lynn/2002k.html#1 misc. old benchmarks (4331 & 11/750)
http://www.garlic.com/~lynn/2002k.html#3 misc. old benchmarks (4331 & 11/750)
http://www.garlic.com/~lynn/2002k.html#4 misc. old benchmarks (4331 & 11/750)
http://www.garlic.com/~lynn/2002n.html#58 IBM S/370-168, 195, and 3033
http://www.garlic.com/~lynn/2002n.html#59 IBM S/370-168, 195, and 3033
http://www.garlic.com/~lynn/2002n.html#63 Help me find pics of a UNIVAC please
http://www.garlic.com/~lynn/2002o.html#51 E-mail from the OS-390 ????
http://www.garlic.com/~lynn/2002o.html#74 They Got Mail: Not-So-Fond Farewells
http://www.garlic.com/~lynn/2002p.html#48 Linux paging
http://www.garlic.com/~lynn/2002q.html#27 Beyond 8+3
http://www.garlic.com/~lynn/2003.html#10 Mainframe System Programmer/Administrator market demand?

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

vax6k.openecs.org rebirth

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vax6k.openecs.org rebirth
Newsgroups: alt.folklore.computers,comp.sys.prime
Date: Sat, 04 Jan 2003 17:51:58 GMT
Anne & Lynn Wheeler writes:
was the vm microcode assists/accelerator for virgil/tully (370/138 & 370/148 and then 4331, 4341, etc). An initial product strategy was to attempt to make ecps/vm part of the hardware product on all machines shipped (in much the same way done for LPARS today).

part of this was some amount of the VM handshaking for vs1 made it into the product (i.e. if VM was going to be the only operational mode for these machines ... then it would be useful to optimize for that mode in the other operating systems).

it eventually got to the point that the best optimized VS1 with handshaking ran faster under VM ... than a compareably best optimized VS1 (for standalone, bare hardware) ran on the bare hardware (although not all of these optimzations made out the door in VS1). Still there was frequently lots of situations where the product VS1 would had higher thruput running under VM than when running on the bare hardware.

we utilized an instance of this later at SJR. SJR for a long time ran 195 with MVT ... and then eventually installed 158 running VM (and also used for MVS testing in preperation to replacing the 195 with 168).

After the 168 was installed ... the whole disk pool was setup so that all controllers were connected to both 168/mvs and 158/vm. However, we learned early never ot intermix mvs packs on vm strings & vm controllers. typical situation was when operater accidentially mounted an mvs pack on a vm string ... the data center would start getting irate calls from users that vm thruput had gone down the toilet.

the cause, of course was mvs's use of multi-track search for VTOC & PDS operations .... where worst case busy could be on the order of 1/3rd of a sec. for the transfer of a record amounting to a couple hundred bytes at the most. since the MVS users always ran in this mode of operation ... they didn't know that they there standard of living was that thruput was always in the toilet.

some number of instances happened where the mvs people would say ... oops, sorry ... but it really isn't that important to stop things and move the pack.

so the solution was to bring up a VS1 under vm ... and mount one of its packs on a MVS string and then start a vs1 multi-track search application of our own .... using few spare cycles on the loaded vm/158 system to bring the mvs/168 system to its knees (which immediately improved thruput for the vm users). That happened a couple of times ... and the mvs people got a lot more careful about mounting mvs packs on vm strings.

misc. CKD technology:

disk (or dasd) "strings" were a number of drives that shared the same control unit. in the days of 3330s .... all of these had removeable/mountable disk packs. a multi-track search .... was a controller/device i/o operation that looked for a string match. A multi-track search .... could search all 19 tracks of a 3330 w/o finding a match ... and then switch to the next cylinder and do it again. Worst case per operation was 19 revolutions at 60 revs/sec ... or slightly under 1/3rd sec. per operation. The operation had the characteristic of making both the drive and the controller busy. A shared controller might have 16 drives .... in which case, during a multi-track operation to any one drive it wasn't possible to access any of the other (possibly 15) drives.

it turns out that while vm/cms supported CKD disks ... it didn't make use of the multi-track search paradigm .... since the original days of cms in the mid-60s ... it used a fixed-block paradigm ... and if necessary emulated that on CKD devices.

one of the tso (interactive) thruput issues running on any of the operating systems that made heavy use of the CKD multi-track paradigm ... they didn't know that their thruput was always in the toilet ... because they had no reference of not operating in that mode.

while doing some work in the engineering lab ....
http://www.garlic.com/~lynn/subtopic.html#disk
I did an optimized paging access method implementation
http://www.garlic.com/~lynn/submain.html#mmap

demonstration using both (software) emulated fixed-block on CKD as well as real (3370) fixed-block devices ... that showed three times thruput increase compared to typical multi-track searce based environments ... and then worked on the case for having MVS support fixed-block devices. STL came back that even if given fully tested code for MVS ... that it was still a $26m cost to release it. Instead they started down the ECKD path ... just that cost was eventually much more than $26m ... not to mention all the subsequent hardware gyrations/costs because all disks are now really fixed-block and CKD operation has to be emulated in the hardware.

random past ckd/multi-track postings:
http://www.garlic.com/~lynn/93.html#29 Log Structured filesystems -- think twice
http://www.garlic.com/~lynn/94.html#35 mainframe CKD disks & PDS files (looong... warning)
http://www.garlic.com/~lynn/97.html#16 Why Mainframes?
http://www.garlic.com/~lynn/97.html#29 IA64 Self Virtualizable?
http://www.garlic.com/~lynn/99.html#75 Read if over 40 and have Mainframe background
http://www.garlic.com/~lynn/2000.html#86 Ux's good points.
http://www.garlic.com/~lynn/2000c.html#34 What level of computer is needed for a computer to Love?
http://www.garlic.com/~lynn/2000f.html#18 OT?
http://www.garlic.com/~lynn/2000f.html#19 OT?
http://www.garlic.com/~lynn/2000f.html#42 IBM 3340 help
http://www.garlic.com/~lynn/2000g.html#42 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
http://www.garlic.com/~lynn/2000g.html#51 > 512 byte disk blocks (was: 4M pages are a bad idea)
http://www.garlic.com/~lynn/2000g.html#52 > 512 byte disk blocks (was: 4M pages are a bad idea)
http://www.garlic.com/~lynn/2001.html#19 Disk caching and file systems. Disk history...people forget
http://www.garlic.com/~lynn/2001c.html#17 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001d.html#60 VTOC/VTOC INDEX/VVDS and performance (expansion of VTOC position)
http://www.garlic.com/~lynn/2001d.html#64 VTOC/VTOC INDEX/VVDS and performance (expansion of VTOC position)
http://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
http://www.garlic.com/~lynn/2002.html#5 index searching
http://www.garlic.com/~lynn/2002.html#6 index searching
http://www.garlic.com/~lynn/2002.html#10 index searching
http://www.garlic.com/~lynn/2002c.html#48 Swapper was Re: History of Login Names
http://www.garlic.com/~lynn/2002d.html#22 DASD response times
http://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
http://www.garlic.com/~lynn/2002f.html#8 Is AMD doing an Intel?
http://www.garlic.com/~lynn/2002g.html#13 Secure Device Drivers
http://www.garlic.com/~lynn/2002l.html#47 Do any architectures use instruction count instead of timer
http://www.garlic.com/~lynn/2002l.html#49 Do any architectures use instruction count instead of timer
http://www.garlic.com/~lynn/2002n.html#50 EXCP
http://www.garlic.com/~lynn/2002o.html#46 Question about hard disk scheduling algorithms

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

vax6k.openecs.org rebirth

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vax6k.openecs.org rebirth
Newsgroups: alt.folklore.computers,comp.sys.prime
Date: Sat, 04 Jan 2003 18:09:10 GMT
Anne & Lynn Wheeler writes:
for ecps, at boot ... there was a list of all the ecps instructions thru-out the kernel ... if ecps wasn't available on the machine ... all those instructions got no-oped ... and the kernel effectively dropped thru to the software instructions. if the ecps instruction was executed ... it continued after the instructions it replaced (as opposed to the following instruction). in some of the VAMPS cases ... it would have bypassed large bodies of instructions.

and when the standard multiprocessing support shipped ... you had binaries (text decks) for both multiprocessing and non-multiprocessing .. and kernels built with the multiprocessing binaries and kernels built with the non-mulitprocessing binaries. a multiprocessing kernel could run on a non-multiprocessor ... and a non-multiprocessing kernel could run on a multiprocessor (just use only single cpu).

in addition to the ecps methodology ... it is also straight forward to have VAMPS binaries ... and VAMPS kernel ... which would run in vanilla single processor mode if it wasn't on a VAMPS multiprocessor.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

vax6k.openecs.org rebirth

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vax6k.openecs.org rebirth
Newsgroups: alt.folklore.computers,comp.sys.prime
Date: Sat, 04 Jan 2003 18:30:21 GMT
Anne & Lynn Wheeler writes:
and when the standard multiprocessing support shipped ... you had binaries (text decks) for both multiprocessing and non-multiprocessing .. and kernels built with the multiprocessing binaries and kernels built with the non-mulitprocessing binaries. a multiprocessing kernel could run on a non-multiprocessor ... and a non-multiprocessing kernel could run on a multiprocessor (just use only single cpu).

in addition to the ecps methodology ... it is also straight forward to have VAMPS binaries ... and VAMPS kernel ... which would run in vanilla single processor mode if it wasn't on a VAMPS multiprocessor.


and for even more thread drift ....

when i originally did the fair share scheduling and the paging algorithm and the other resource manager stuff on cp/67 while an undergraduate in the late '60s ... i did all this dynamically adaptive stuff. In the translation from cp/67 to vm/370 all of that was dropped in the product.
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock

the initial standard vm/370 product went out with a table of cpuids (cpu model numbers) in the boot (dmkcpi) routine and boot/ipl did various things based on the model number.

I retrofitted all the resource manager stuff including dynamic adaptive to vm/370 ... which eventually shipped as the vm/370 resource manager (first charged-for/priced kernel software product). One of the dynamic adaptive things was to eliminate the processor model table and attempt to do everything based on determining characteristics dynamically.

part of this was that the kernel had much longer life over a broad range of products. an early version of this retrofit for vm/370 (along with 30k to 40k lines of other kernel modifications) disappeared into AT&T longlines .... and propagated there for something like ten years across a broad range of processors (both non-clones and some pcm/clones). Eventually somebody from the branch office responsible for AT&T longlines tracked me down ... since the next model of machine was XA-only .... and AT&T longlines had gotten use to this ten year old kernel that dynamically adapted to all sorts of machine models, machine configurations and loads.

the official version shipped as the resource manager was viewed with suspicion in some quarters since it no longer had the cpuid/model table ... and therefor was totally agnostic with regard to running on official 370s or pcm/clone 370s.

... and another dynamic adaptive story

also as an undergraduate I put tty/ascii terminal support into cp/67. cp/67 had this code already that dynamically attempted to identify between kinds of 2741s and 1052s ... w/o having to pre-specify what kind of terminal was on which port. I tried to integrate the tty/ascii support in so that it operated in the same way (aka dynamically adapt to the kind of terminaL). The terminal controller had a different line-scanners for different kind of terminals .... and it was possible to dynamically tell the terminal controller which line scanner to use with which line (either hard-wired lines or dial-up lines). So i got all of this working ... and proadly demo'ing it ... when one of the ibm field service people pointed out to me that while the type of line scanner was dynamically selectable ... they had taken a shortcut in the controller implementation and hardwired oscillators to specific lines.

this met that while i could dynamically switch a line from 2741 line scanner to a tty/ascii line scanner, i couldn't switch the baud rate.

this prompted us to start a project at the university to build our own terminal controller ... that supported both dynamic baud rate determination as well as dynamic terminal type determination, This also led to getting blamed for originating the pcm controller market (and some rumor also responsible for the convulated nature of the pu4/pu5 interface):
http://www.garlic.com/~lynn/subtopic.html#360pcm

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

cost of crossing kernel/user boundary

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: cost of crossing kernel/user boundary
Newsgroups: comp.arch
Date: Sun, 05 Jan 2003 13:49:08 GMT
"Andy Glew" writes:
You've said this before. What was Charlie's full name?

past answers (compare&swap mnemonic ... includes pointers to POP and programming notes):
http://www.garlic.com/~lynn/99.html#89 FIne-grained locking
http://www.garlic.com/~lynn/2001f.html#41 Test and Set (TS) vs Compare and Swap (CS)

somewhat aside .... during project athena days (half funded by dec, half funded by ibm) .... jerry saltzer was director ... charlie was asst. director (or whatever they called the position) on the ibm side ... and i forget who it was on the dec side?

when we were doing ha/cmp ... we subcontracted much of the software development to company that started out as some number of people having worked at project athena (all within half mile or so of tech sq). other past trivia
http://www.garlic.com/~lynn/2000d.html#68 "all-out" vs less aggressive designs

in the above, i watched as they pried the letters off the building ... i keep thinking that i needed to ask the guy if I could have one of the letters.

other stuff from by-gone days:
http://www.garlic.com/~lynn/subtopic.html#545tech

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Message (authentication/integrity); was: Re: CRC-32 collision

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Message (authentication/integrity); was: Re: CRC-32 collision
rate
Newsgroups: sci.crypt
Date: Sun, 05 Jan 2003 15:59:39 GMT
"Tom St Denis" writes:
I don't know why you're making a big deal of it. The distinctions are quite clear. If you want to detect medium errors then a simple integrity check is all you need. If you want to check that the messages are authentic, that is the message is intact and attributed to a specific sender, then you need a digital signature or MAC.

CRCs, FEC, HASH, detect &/or correct random errors .... and help with detecting if the integrity of the message is intact

purposeful errors can defeat simple CRCs, FEC, HASH ... with resulting loss of the ability to detect if the integrity of the message is intact.

encryption of the hash can help with integrity issues of purposeful errors.

business processes that control who has access to the encrypting key (used for encrypting the hash) .... can be used to infer who sent the message.

the act of encrypting the hash doesn't establish the sender ... it is the business process controlling who has access to the key used for the encryption that establishes the sender.

that still doesn't necessarily establish authentic in the real world .... in the real world ... an authentic message would also imply that the sender wrote the message. this is touched on various past non-repudiation threads; one scenario was the use of public key encryption in a challenge/response scenario ... the sender may be signing something that they didn't write (say as part of some sort of access control challenge/response protocol).

1) message wasn't altered in transit 2) message originated from specific sender 3) message was authored by the sender

both #2 and #3 require various kinds of business processes ... in addition to simply using an asymmetric key for encrypting a hash.

random refs:
http://www.garlic.com/~lynn/subpubkey.html#privacy x9.59, identity, authentication, and privacy

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

vax6k.openecs.org rebirth

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vax6k.openecs.org rebirth
Newsgroups: alt.folklore.computers
Date: Sun, 05 Jan 2003 22:04:32 GMT
"Charlie Gibbs" writes:
Famous Last Words #1: "Oh, don't worry about that; it'll never happen."

actually the response was i thot i had fixed all of the prg9. the other prg9 that got me was when somebody pushed stop button in the middle of that loop (or a couple other timing sequences that i had in DMKSTP) ... resulting in time-intervals that were ridiculously long ... as opposed to ridiculously short (both could result in prg9).

the other response was that i originally wrote the specific code over 25 years ago in an era when

1) kernels were only built for possibly a (or limited number of) specific machine model(s).

2) were typically decommited within five years by the vendor

this was one of the first attempts to make dynamically adaptive kernel across a really wide range of machine models (both non-clone & clone) and over a fairly wide range of time.

several thousand benchmarks went into calibrating the resource manager with fairly detailed performance data down to subprocess level ... along with a fairly detailed model of the algorithms. we would put a synthetic mixed-mode workload on that totally saturated the machine ... and then do a whole series of additional benchmarks incrementally changing the workload (adding/subtracting various kinds of processes). the resulting detailed monitor information as to the overal system execution characteristics as well as the moment to moment execution characteristics of the individual processes had to correspond to the model.

this was possibly the only product (at the time, still?) that accepted customer bug reports when the real life operation of the resource manager deviated from the algorithm specifications (traditionally the response has been "broken as designed").

random refs:
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock
http://www.garlic.com/~lynn/submain.html#bench

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

vax6k.openecs.org rebirth

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vax6k.openecs.org rebirth
Newsgroups: alt.folklore.computers
Date: Sun, 05 Jan 2003 22:44:09 GMT
jmaynard@thebrain.conmicro.cx (Jay Maynard) writes:
As it happens, this one's not that far wrong. I don't know if it happens in VM/SP, but the error only occurs on a system that breaks 7.5 MIPS on a single CPU in a tight BCTR loop, and I'm not sure any real iron ever ran in 370 mode that fast - and I really doubt that anyone ever ran the unmodified VM/370 on one that did. (The interval timer resolution, as checked by this routine, is 1/300 second.) I doubt anyone tripped over it until Hercules.

it ran on 3081Ks in 370 mode ... where DMKCPI should come up on a CPU rated 7mips for general instruction mix (so a tight BCTR loop Could have on the order of possibly twice that). It also ran on some number of 370-clones that had processors rated for general instruction mix over 7mips.

note ... however ... the resource manager in both DMKCPI and DMKSTP used the store timer instruction ... 64bit value with bit twelve defined to be a microsecond (and bit 32 was just slightly more than 1 second). Machines could have higher or lower resolution than a microsecond ... but bit twelve was a microsecond ... also two back-to-back stores were supposed to be defined as storing different values.

the location 80 timer had been used in cp/67 ... because that was the only timer on the 360/67 ... but everything would have been coverted to store clock for 370 & vm/370. There were actually three 64bit values ...

1) the TOD clock ... 2) the clock comparator .... which would generate an interrupt when the TOD clock value and the clock comparator were the same 3) the interval timer that decremented at the same rate as the TOD clock incremented

the interval timer and the tod clock had the same resolution ... 64 bits and bit 12 being one microsecond.

this 370 64-bit interval timer is different than the location 80 32-bit interval timer from 360 days. one of the reasons that the location 80 interval timer was depreciated in the 370 ... was that it updated real memory ... which required getting the memory bus and storing into real memory on every tic. 360s would have hardware failures if the timer function couldn't obtain the memory bus for the timer value updates (say because of processor and/or i/o activity).

the low-end 360s and the 370s 32bit location 80 timer were tic'ed 1/300 second ... every 3.3mills (real storage update issues). the 360/67 had a high resolution 32-bit location 80 timer that tic'ed once every 13.?microseconds (had more real-storage update issues). The 32bits counted about 14?hrs elapsed time (wether they tic'ed at 3.3millis or 13.?microseconds)

all of the 370s tic'ed their 64bit timers at well under millisecond intervals ... been awhile but i believe in the low tens or even single digit microseconds.

kernel calculations would typically pickup the resulting 64bit value ... calculate the difference between starting and end ... and then do shift right logical 12 bits ... putting microsecond in bit 0. Then if you continued with 32bit arithmatic you had a maximum value of about 4k seconds with microsecond resolution ... supplied by hardware that typically tic'ed on the order of at least tens of microseconds (for the slower speed machines ... say rated in the kips rather than mips) and for higher speed machines the tic rate was to increase to less than microseconds (although most calculations shifted out the bits less than microsecond).

So my resource manager code on a high MIP machine that tic'ed at least once a microsecond .... would have been computing the BCTR loop based on the elapsed time measured in microseconds (and count up to 4k seconds).

The problem i ran into early with the prg9 failure in the calculations was somebody pressing the stop button in the middle of the timer calculations ... and the calculations overflowing 4k seconds (stop buttom pressed for least 70 minutes or so ... and then starting up again).

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Multics preservation: good news

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Multics preservation: good news
Newsgroups: alt.os.multics,alt.folklore.computers
Date: Sun, 05 Jan 2003 22:48:12 GMT
"Shmuel (Seymour J.) Metz" writes:
360/70 (never shipped) 360/75

there were 360/60, 360/62, & 360/70 ... all designed to ship with 1mic memory. the 750nsec memory came along and the models with higher speed memory became 360/65, 360/67, and 360/75 (and 60, 62, & 70 never shipped).

note/update:

I remember reading an early document about 360/6x machine with virtual memory having one, two, and four processors. I sort of had vaque recollection that it was model number other than 360/67.

however, i've subsequently been told that 360/60 was with 2mic memory and 360/62 was with 1mic memory. both models never shipped, and were replaced with 360/65 with 750ns memory. the 360/67 then shipped as 360/65 with virtual memory ... only available in one (uniprocessor) and two processor (multiprocessor) configurations

http://www.garlic.com/~lynn/2006m.html#50 The System/360 Model 20 Wasn't As Bad As All That


--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

vax6k.openecs.org rebirth

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vax6k.openecs.org rebirth
Newsgroups: alt.folklore.computers
Date: Mon, 06 Jan 2003 01:02:23 GMT
Anne & Lynn Wheeler writes:
note ... however ... the resource manager in both DMKCPI and DMKSTP used the store timer instruction ... 64bit value with bit twelve defined to be a microsecond (and bit 32 was just slightly more than 1 second). Machines could have higher or lower resolution than a microsecond ... but bit twelve was a microsecond ... also two back-to-back stores were supposed to be defined as storing different values.

here is the official description ... but they are counting bits from the opposite end ... the microsecond bit is position 51 (but i still shift right logical 12 bits ... to move it into the low order bit position; 32bit value giving 4kseconds counted in number of microseconds:
http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/4.6.4?DT=19970613131822

specifically from above:
The CPU timer is a binary counter with a format which is the same as that of the TOD clock, except that bit 0 is considered a sign. In the basic form, the CPU timer is decremented by subtracting a one in bit position 51 every microsecond. In models having a higher or lower resolution, a different bit position is decremented at such a frequency that the rate of decrementing the CPU timer is the same as if a one were subtracted in bit position 51 every microsecond. The resolution of the CPU timer is such that the stepping rate is comparable to the instruction-execution rate of the model.

======

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

vax6k.openecs.org rebirth

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vax6k.openecs.org rebirth
Newsgroups: alt.folklore.computers
Date: Mon, 06 Jan 2003 01:32:42 GMT
given the official timer description .... the prg9 could occur if the whole bctr loop was executed in less than one microsecond elapsed time or greater than 4k seconds elapsed time (but i thot i had fixed the prg9s sometime in the past ... oh well).

a machine that could execute the bctr loop in less than one microsecond would have "stepping" of the clock at finer resolution than one microsecond .... but the shift operation would result in the timed interval being rounded down to one microsecond resolution (aka the full clock definition has ability for providing on the order of .2 nanosecond in the low order bit position).

if the current mechanism is tripping (prg9 exception) when the loop executes at a rate of 7mips and takes less than 3.3milliseconds .... then if the actual hardware clock definition was implemented ... the effective mip rate would have to be 3333 times that in order to lead to the prg9 (executing the loop in less than 1 microsecond) or a machine running at around 23,331 mips.

I know that the original code ran on machines on the order of 50kips (.05mips) ... trying to provide dynamic adaptive capability across a period of more than 30 years ... and from .05mips to 23,331mips (close to six orders of magnitude range) wouldn't seem unreasonable.

also referencing the previous document ... it lists the location 80 timer being dropped in the transition from 370 to 370/xa
http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/F.3.5?DT=19970613131822

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

vax6k.openecs.org rebirth

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vax6k.openecs.org rebirth
Newsgroups: alt.folklore.computers
Date: Sun, 05 Jan 2003 19:23:10 -0700
trying to reconstruct the location 80 timer.

the shift of the 370 cpu timer ... resulted low order bit position one microsecond and nearly 70 minutes of time for 32bit number.

the high resolution location 80 on the 360/67 ... tic the low order bit position something like 13.6microseconds and gave 14 or 15hr measurement in 32bits ....

13.6 times 70 minutes gives 15.8hr measurement.

tic'ing the 8th bit once every 1/300 sec ,,, yields a measurement interval of 15.4hrs (32bit number). that means that the high resolution timer that tic'ed bit zero ... was actually 13.02microseconds ... not 13.6microseconds.

now the location 80 timer would cause a machine check "red light" if it was unable to obtain the memory bus to update real location 80. basically there was almost a full tic window ... a update for storage would go pending with a tic .... if the next tic happened before the storage was updated for the previous tic ... the machine would red light.

we experienced this on the 360/67 at the university when we were developing the first 360 non-ibm (i.e. clone) controller.
http://www.garlic.com/~lynn/subtopic.html#360pcm

the channel interface had been reverse engineered and a channel interface board had been built for the 360/67 channel. Some of the early testing resulted in "red lighting" (aka machine check) the machine. The controller got the channel interface ... and thru it, the memory bus and was transfering data .... but held it continuously for more than a tic interval (and voila a machine check). some amount of additional engineering had to be done to make sure that the channel interface (and therefor the memory bus) was released at least once every timer tic interval.

it was much more of a problem on the 360/67 with the high resolution timer and 13.02 microsecond windows ... than on the slower speed 360s ... or the 370s ... with tics only happending every 3.3mills.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

vax6k.openecs.org rebirth

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vax6k.openecs.org rebirth
Newsgroups: alt.folklore.computers
Date: Mon, 06 Jan 2003 01:54:21 GMT
... and if it is really failing because it is using location 80 timer ... (stepping at 3.3mills) then it ain't my code .... because all of my stuff used cpu timer.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

vax6k.openecs.org rebirth

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vax6k.openecs.org rebirth
Newsgroups: alt.folklore.computers
Date: Mon, 06 Jan 2003 04:51:25 GMT
Brian Inglis writes:
It's been a decade or so since I did this, so I may have forgotten some details about how things were done, and what goes where, but weren't the ASSEMBLE files the original product release sources, e.g. VM/370, BSEPP, SEPP, HPO, XA, ESA, with all subsequent changes being source or object updates on additional MDISKs?

the resource manager had the updates for dynamically calculating the dspslice based on the timed loop ... rather than value loaded from a cpu model table in dmkcpi. i forget what i original called the update files for the initial release of the resource manager (applied to vm/370 release 3). 80 percent of the resource manager code was merged into the release 4 assemble files (as part of multiprocessing support in release 4) ... with the rest of the code staying in the resource manager. Resource manager combined with some other stuff for SEPP for release 5 (including the dmkcpi timed loop ... again update files). for what would have been vm/370 release 7 ... it was renamed vm/sp1 (with the code to DMKCPI now appearing in base assemble files as opposed to update)

the resource manager were update files ... except for two new assemble files DMKSTP ASSEMBLE and DMKSRM ASSEMBLE.

STP was taken from '60s televison advertisement ... the racer's edge.

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

Multics preservation: good news

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Multics preservation: good news
Newsgroups: alt.os.multics,alt.folklore.computers
Date: Mon, 06 Jan 2003 14:02:28 GMT
"Shmuel (Seymour J.) Metz" writes:
Weren't the 60 and 62 "microprogrammed"?

as far as i could tell 60 & 62 were same was 65 & 67 but with 1mic memory instead of 750ns memory.

sorry ... i wasn't commenting on hardwired issue .... it was that 70, 62, & 60 all had in common was that they were for 1mic memory and didn't ship .... and 75, 67, & 65 were presumably essentially the same models but with the faster memory (and whatever other changes were necessary).

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Message (authentication/integrity); was: Re: CRC-32 collision

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Message (authentication/integrity); was: Re: CRC-32 collision
rate
Newsgroups: sci.crypt
Date: Mon, 06 Jan 2003 14:10:54 GMT
Anne & Lynn Wheeler writes:
random refs:
http://www.garlic.com/~lynn/subpubkey.html#privacy x9.59, identity, authentication, and privacy


finger slip on some past non-repudiation
http://www.garlic.com/~lynn/subpubkey.html#privacy

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Round robin IS NOT load balancing (?)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Round robin IS NOT load balancing (?)
Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Date: Tue, 07 Jan 2003 03:00:51 GMT
arielgont@softhome.net (Fernando Gont) writes:
I mean, the client should try the next IP address returned by the nameserver.

there are all sorts of things in this world thst should ... however, some number of apps ... don't handle multiple A-records at all.

At least at some time in the past ... if there wasn't an example of it in a tcp/ip college text ... then some large amount of the world didn't believe it was possible.

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

asynchronous CPUs

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: asynchronous CPUs
Newsgroups: alt.os.multics,alt.folklore.computers
Date: Tue, 07 Jan 2003 20:19:36 GMT
Tom Van Vleck writes:
Recent articles that talk about how this new idea of asynchronous design could make machines faster and more efficient don't mention that the idea was used long ago. Which CPUs of yore were asynchronous and which had master clocks?

LSM (los gatos simulation machine ... or logic simulation machine ... depending on if the external sanitized version was used) ... could simulate asynchronous activity. all of the hardware simulaters following the LSM used a short cut and assumed a synchronous clock for the logic.

LSM supported clock specification ... allowing simulation of asyhncronous chips ... as well as digital/analog chips ... aka used for the original disk thinfilm read/write heads.

random past refs to LSM:
http://www.garlic.com/~lynn/2002d.html#3 Chip Emulators - was How does a chip get designed?
http://www.garlic.com/~lynn/2002g.html#55 Multics hardware (was Re: "Soul of a New Machine" Computer?)
http://www.garlic.com/~lynn/2002g.html#77 Pipelining in the past
http://www.garlic.com/~lynn/2002g.html#82 Future architecture
http://www.garlic.com/~lynn/2002j.html#26 LSM, YSE, & EVE

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Mainframe System Programmer/Administrator market demand?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframe System Programmer/Administrator market demand?
Newsgroups: bit.listserv.ibm-main
Date: Tue, 07 Jan 2003 21:26:12 GMT
Anne & Lynn Wheeler writes:
one of the oursourcing complexities is creating a larger disconnect between the users/clients of the data processing service and the actual service ... things tend to be much more contractual and formal (and using a boyd'ism ... creates resistance and reduces agility, boyd has some number of commercial examples .... but a military was why does the army want its own close air support rather than relying on the air force).

where there is little need for agility (because of no evolving circumstances and changing requirements) ... aka a relatively static environment ... then the lack of agility has little impact.

the counter argument is outsourcing may bring higher trained data processing specialists which can more than compensate for the resistance introduced by a more formal contractual relationship.

the other classical failure is where there is active animosity between the users and the executives making the out-sourcing decision (resulting in all kinds of subversion).

boyd OODA-loops and high agility for competitive rapidly changing environments:
http://www.garlic.com/~lynn/subboyd.html#boyd

... and article on the subject

Managing the Outsourcing Relationship

http://itmanagement.earthweb.com/netsys/article.php/1565251
Managing the Outsourcer Relationship January 7, 2003 By Drew Robb

Doing everything yourself may sound great, but it quickly becomes tedious and inefficient. So we outsource everything from pumping our water to ironing our shirts and educating our children, focusing instead on our core functions.


snip

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Round robin IS NOT load balancing (?)

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Round robin IS NOT load balancing (?)
Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Date: Wed, 08 Jan 2003 04:50:41 GMT
marka@isc.org (Mark Andrews) writes:
I doubt if many of the application writers have actually thought about their decision to only try one address.

when we were working with this little client/server startup on getting the server doing financial transactions (sometimes referred to now as electronic commerce) we had some say about the server to payment gateway part and could require things like multiple a-record support (and some number of other things) ... but we had little influence over the client part at the time .... other then nagging them about it and when they complained about it being too advanced ... showing examples from client code from old implementation sources.

random refs:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Calculating expected reliability for designed system

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Calculating expected reliability for designed system
Newsgroups: comp.arch
Date: Wed, 08 Jan 2003 19:33:33 GMT
jason_watkins@pobox.com (Jason Watkins) writes:
For most hardware you should be able to find out the MTBF, though it may require going to compaq's suppliers. Other than that, I know there's some usable data from the tera disk project. H&P 3rdEd also has a section that may have some numbers you can cite. I recall one signifigant finding is that controller and cabling componants were as much a problem as disks themselves.

mainframes have had erep recording for 40? years. For well over 30 years some company (r-star or something) has been collecting erep logs from customers and publishing summaries about all the stats. I got sort of caught because I had worked on some software simulation for some (hyperchannel) channel extender of i/o devices ... and when there was an unrecoverable telco error .... i faked a form of channel error ... then kicked of various error recording and and recovery actions.

when the 3090 had been in customer shops for a year ... some corporate guy tracked me down trying to figure out some skewed data from the public reports. they had projected five total errors of particular kind across all machines at all customer installations for 12 month period. the stats from the reporting company was showing that a total of something like 15 such errors had been recorded (this is not total per machine per year ... this is total across all machines for 12 months) ... and there was serious concern about the difference between the projected five and the reported 15 ... which turns out to have been the error indication i had selected. turns out that i could change the simulated error to a different kind ... and still kick-off effectively the same error recovery process.

note that while some vendors talked at:
http://web.archive.org/web/20011004023230/http://www.hdcc.cs.cmu.edu/may01/index.html

nobody was giving up any kind of numbers ... at least not in that particular market segment

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Round robin IS NOT load balancing (?)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Round robin IS NOT load balancing (?)
Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Date: Wed, 08 Jan 2003 20:03:59 GMT
Anne & Lynn Wheeler writes:

http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3


one of those brain/finger slips ... "htm" not "html":
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

mainframe

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: mainframe
Newsgroups: bit.listserv.ibm-main
Date: Thu, 09 Jan 2003 14:39:32 GMT
Terry Sambrooks writes:
At one time mainframes, at least in the IBM sense, could be produced by IBM, Amdahl, Fujitsi, and Hitachi to name but four.

at least by some, amdahl was a fujitsu subsidiary ... and NAS was a Hitachi subidiary. i was at a talk that amdahl gave on the mit campus in the early 70s ... where he really got grilling about the fujitsu content (investment, manufacturing, etc).

by the early '80s there was also a number in of 2nd tier(?) clones in the low/mid-range marketplace. recent discussions:
http://www.garlic.com/~lynn/2003.html#10 Mainframe System Programmer/Administrator market demand?
http://www.garlic.com/~lynn/2003.html#14 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#15 vax6k.openecs.org rebirth

from earlier ... non-clones/non-PCM there use to be snow white and the seven dwarfs ... or the BUNCH:
http://www.garlic.com/~lynn/2002o.html#78 Newsgroup cliques?

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Calculating expected reliability for designed system

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Calculating expected reliability for designed system
Newsgroups: comp.arch
Date: Thu, 09 Jan 2003 15:08:21 GMT
"del cecchi" writes:
To steal Lynn Wheeler's thunder, isn't that why the mainframe guys developed all that automated operator stuff? One doof deleting the wrong file, or sticking in the wrong floppy/mounting the wrong tape and you just blew the .5% (40 hours/year) for the next year. Install a bad device driver. you know the drill.

yes, well ... we were in this meeting with the guy responsible for a large financial transaction backbone ... who claimed the primary reason for one hundred percent availability for the previous six+ years was: 1) ims hot-standby, and 2) automated operator
http://www.garlic.com/~lynn/94.html#2 Schedulers
http://www.garlic.com/~lynn/99.html#71 High Availabilty on S/390
http://www.garlic.com/~lynn/99.html#107 Computer History
http://www.garlic.com/~lynn/99.html#128 Examples of non-relational databases
http://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/2000.html#22 Computer of the century
http://www.garlic.com/~lynn/2000f.html#12 Amdahl Exits Mainframe Market
http://www.garlic.com/~lynn/2001.html#43 Life as a programmer--1960, 1965?
http://www.garlic.com/~lynn/2001c.html#13 LINUS for S/390
http://www.garlic.com/~lynn/2001d.html#70 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001d.html#71 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001e.html#44 Where are IBM z390 SPECint2000 results?
http://www.garlic.com/~lynn/2001e.html#47 Where are IBM z390 SPECint2000 results?
http://www.garlic.com/~lynn/2001h.html#8 VM: checking some myths.
http://www.garlic.com/~lynn/2001k.html#14 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/2001l.html#47 five-nines
http://www.garlic.com/~lynn/2001n.html#47 Sysplex Info
http://www.garlic.com/~lynn/2001n.html#85 The demise of compaq
http://www.garlic.com/~lynn/2002.html#24 Buffer overflow
http://www.garlic.com/~lynn/2002e.html#68 Blade architectures
http://www.garlic.com/~lynn/2002h.html#73 Where did text file line ending characters begin?
http://www.garlic.com/~lynn/2002l.html#62 Itanium2 performance data from SGI
http://www.garlic.com/~lynn/2002n.html#27 why does wait state exist?
http://www.garlic.com/~lynn/2002o.html#14 Home mainframes
http://www.garlic.com/~lynn/2002p.html#54 Newbie: Two quesions about mainframes

when we were doing ha/cmp we also talked to guys developing 1-800 number system ... who were looking at a fault tolerant computer ... that would have to be taken down to do software maint/upgrade. Doing this just once a year blew a minimum of five years of budgeted/allowed outage. a replicated/fall-over solution addressed the outage for software maint/upgrade ... but also subsumed the advantage of having a fault tolerant computer.
http://www.garlic.com/~lynn/96.html#36 Mainframes & Unix (and TPF)
http://www.garlic.com/~lynn/99.html#143 OS/360 (and descendents) VM system?
http://www.garlic.com/~lynn/2001g.html#58 TECO Critique
http://www.garlic.com/~lynn/2001k.html#10 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2002e.html#67 Blade architectures

there are lots of other characteristics for well designed system. when wereworking on this thing called a payment gateway for this thing that came to be called electronic commerce ... one of the issues was diagnosing the end to end environment ... if you got a problem call, you wanted to be able to do first level problem determination within five minutes ... not have it turn into NTF (no trouble found) after three hrs.
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
http://www.garlic.com/~lynn/aadsm5.htm#asrn2

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Calculating expected reliability for designed system

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Calculating expected reliability for designed system
Newsgroups: comp.arch
Date: Fri, 10 Jan 2003 14:56:24 GMT
Anne & Lynn Wheeler writes:
when we were doing ha/cmp we also talked to guys developing 1-800 number system ... who were looking at a fault tolerant computer ... that would have to be taken down to do software maint/upgrade. Doing this just once a year blew a minimum of five years of budgeted/allowed outage. a replicated/fall-over solution addressed the outage for software maint/upgrade ... but also subsumed the advantage of having a fault tolerant computer.

... I think it was actually expected to be closer to 100 years of outage budget for scheduled maint. As systems have moved into more & more business critical operations .... the end users have become less & less tolerant of outages (if you have ever participated in weekly user datacenter confrontation ... where the users detail everything that went wrong for the past week .... they don't care why they couldn't get their work done). This has resulted in expanding the view of outages (regardless of cause) to end-to-end systemic operation.

we coined the terms disaster survivability and geographic survivability to try and highlight some of these business critical issues ... distinquishing from simpler disaster/recovery scenarios.

there was one weekend in the early '90s that a lot of people couldn't get money out of atm machines .... most of them didn't really care that the roof of the primary datacenter had collapsed with snow load ... and the backup datacenter was out because of the WTC bombing.

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Flex Question

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Flex Question
Newsgroups: bit.listserv.ibm-main
Date: Fri, 10 Jan 2003 15:24:29 GMT
pdw@MARCDATABASE.COM (Peter D. Ward) writes:
I believe Ed's reading of the rationale on Pat's I/O paper is exactly spot on. I also think Pat's conclusion, that modern Intel hardware provides an I/O subsystem meeting the throughput needs of the emulated Flex-ES CPU, will hold true even as Flex-ES moves up the CPU mippage scale.

I believe that one of the significant flex-es delivery platforms had/has been (is) sequent .... scalable numa achitecture (sci with up to 256 processors). that may have been complicated when ibm bought sequent.

at least sequent, data-general, and convex have all done scalleable numa implementations with sci.

there is both the issue of direct processor instruction emulation thruput as well as various kinds of support operations. in the standard mainframe line .... something similar can be seen in the transition from 370 to 303x and integrated channels. Even tho the 3031 and the 158 were the same microprocessor .... the 158 shared the microprocessor between 370 emulation and (integrated) channel functions. For the 303x series ... a 158 engine was taken and had the 370 emulation removed ... leaving only the channel emulation microcode and called it a 303x channel director.

In some sense, a single-processer 3031 was actually a multiprodcessor system with two 158 microprocessor engines ... one with the dedicated 370 emulation and one with the dedicated channel function (instead of both functions sharing a single microprocessor engine as in the vanilla 370/158).

Earlier 115/125 was built on the same philosophy. The 370 115/125 had a nine-position memory bus for microprocessers ... standard configuration had one microprocessor with the 370 emulation ... and from two up to eight other (same) microprocessors with other kinds of microcode programs implementing other kinds of channel, controller, and I/O functions. The only difference between 115 and 125 was that the microprocessor used in the 125 for 370 emulation function ran somewhat faster than the other microprocessors in the configuration.

One could draw a very close analogy between flex-es on an eight-way SMP ... with the 115/125 implementation ... except running at a significantly higher thruput rate.

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

InfiniBand Group Sharply, Evenly Divided

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: InfiniBand Group Sharply, Evenly Divided
Newsgroups: comp.arch
Date: Fri, 10 Jan 2003 18:16:57 GMT
young_r@encompasserve.org (Rob Young) writes:
One other method that is employed is to have a tie breaking node at a 3rd datacenter. This raises the availability. It isn't as common but is being done, no personal experience but have been told.

the large financial transaction settlement network ... mentioned recently in another thread in this n.g. ... attributing 100 percent uptime for the previous six years ... to 1) ims hotstandy and 2) automated operation ... does have third datacenter operation.

recent posts:
http://www.garlic.com/~lynn/2003.html#34 Calculating expected reliability for designed system
http://www.garlic.com/~lynn/2003.html#37 Calculating expected reliability for designed system
http://www.garlic.com/~lynn/2003.html#38 Calculating expected reliability for designed system

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

InfiniBand Group Sharply, Evenly Divided

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: InfiniBand Group Sharply, Evenly Divided
Newsgroups: comp.arch
Date: Sat, 11 Jan 2003 06:57:40 GMT
Jan Ingvoldstad <jani+news-comp@nntp.ifi.uio.no> writes:
But, as several people have put it: Don't rely on DNS for _anything_ important.

actually the whole internet relies on DNS .... there was recent news clip on a dos attack on some of the primary ... with a footnote that it was fortunate that not all of the them were gotten ... or otherwise the internet would have pretty much come to a halt. so at a macro level ... the whole internet relies on dns ... which puts it into the important level.

now ... supposedly SSL was put into place to help catch some DNS vulnerabilities.

basically both SSL and DNS have some common vulnerabilities ... basically master domain name registration databases. corrupting those can result in DNS sending out bad data. Corrupting those also means that a bad guy can go to a SSL certificate manufacturing operation ... and get a valid certificate (since the CA/certificate manufacturing checks the master domain name database as to valid applications for SSL certificates).

from a client's standpoint ... dns can 1) not supply data (a DOS attack), 2) supply bad data (aka ip-address spoof/take-over) and 3) supply good data. SSL effectively addresses case #2 ... and turns it into case #1 (or DOS attack).

SSL doesn't improve #2 into #3 (say like a forward error correcting algorithm might), it is purely a detection and toss mechanism (meaning that a bad data attack is turned into a DOS attack).

now wandering a bit (because of some recent threads in pkix and elsewhere) ... i claim that it would be possible to eliminate the current TTP certificate manufacturing (term we coined to differentiate the current SSL infrastructure from a PKI) and replace it with one where DNS distributed signed packets. The signed packets effectively are a domain name, a public key, and a signature. A browser treats the signed packets exactly like it treats an SSL certificate ... but instead of getting it from a website it gets it from DNS.

My claim is that if the signing of the packets is done with the same care as the current certificates ... there is no decrease in the level of integrity (compared to the current DNS+SSL environment) ... DOS attacks are not affected and the same bad data attacks will be detected and turned into DOS attacks ... aka every case where an ip-address is corrupted or replace ... will be detected with the DNS distributed signed packets as with SSL certificates.

The advantage is that when there isn't corrupted data ... that a SSL can be setup in single exchange .. since the client already has the server's public key before the session initiation starts (there are some amount of micro protocol efficiencies).

One of my objectives in making the proposal is an attempt to highlight the actual DNS vulnerabilities ... and some of the macro level things that might be necessary to address them.

bunch of stuff on ssl "comfort" certificates:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

some reference to early ssl related activities (this little client/server startup that was in silicon valley before moving to mountain view):
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
http://www.garlic.com/~lynn/aadsm5.htm#asrn2

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

basic pki question

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: basic pki question
Newsgroups: sci.crypt
Date: Sat, 11 Jan 2003 07:33:52 GMT
mdalbis@smartronix.com (usmcpsu) writes:
I may be dense but what is the difference between Public Key Infrastructure and Private Key Infrastructure. The material I have is no clear. Also, from what I have read, the message will be encrypted with a synnetric (secret) key which will be passed using the public ( asymmetric) key of the receiver. I have also read that the message can be encrypted using the public ( asymmetric ) key of the receiver and that a secre ( symmetric ) key will not be involved at all. I figure if this is worh knowing, it is worth knowing correctly.

asymmetric keys can be used to address an issue with key distribution.

one part of the pair can be made public ... and anybody wanting to securely and privately communicate with you can use that public key for encrypting messages ... and only you ... with the corresponding asymmetric key can decrypt it.

now sometimes because asymmetric key encryption is too heavy duty (compared to symmetric key encryption) ... a random symmetric secret key is generated (for each message/session), the message encrypted with the symmetric secret key ... and then just the symmetric secret key encrypted with the public key ... and the combined encrypted message and encrypted key are transmitted. again, only the person with the corresponding asymmetric key can read the message ... since only that key can decrypt the random symmetric secret key which is then used to decrypt the actual message. This is effectively the common SSL/HTTPS technique used by browsers for securing communication.

both cases, asymmetric cryptography is being used to address an issue in cryptography associated with key distribution.

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Timesharing TOPS-10 vs. VAX/VMS "task based timesharing"

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Timesharing TOPS-10  vs. VAX/VMS "task based timesharing"
Newsgroups: alt.folklore.computers
Date: Sat, 11 Jan 2003 15:48:07 GMT
jmfbahciv writes:
Nah. It just has to do with OS philosophies and the tradeoffs that had to be done in order to implement certain computing services. I'm not very good at it but JMF was phenomenally(sp?) good at discerning the philosophy of a piece of most code (probably not compilers). You can usually tell what kind of CPU architecture was used when an OS got its start. Which makes sense but its a knowledge that seems to be getting lost. I don't know if this knowledge is worth keeping around for implementing new stuff. Dennis and Lynn may have a better idea about how useful it is for future work.

note one of the things that i tried to do when i first started resource management back as undergraduate in the '60s with cp/67 was to separate amount of resources from the granularity of resource. cp/67 at the time ... based on certain kinds of activity ... changed both the graunularity of resource as well as the amount of resource. People found that they could get unfair resources by exhibiting certain types of activity.

i did this thing i called fair share scheduler ... but that was just the default if no other specifications were made (explicit specifications could provide all sorts of UNfair resource management).
http://www.garlic.com/~lynn/subtopic.html#fairshare

one of the objectives was to explicitly control resource consumption ... and provide granularity of resources based on task type of activity that would still conform to the resource management rules (starting to eliminate the ability for individuals to attack the resource control mechanisms by exhibiting certain types of task characteristics).

the other thing involved was starting to control page thrashing with controls on real storage allocation and competing tasks by the scheduler. this involved both the page replacement algorithm (at a micro level) and the scheduler controlling which tasks were concurrently contending (at the macro level).
http://www.garlic.com/~lynn/subtopic.html#wsclock

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Will Apple ever offer a newsreader?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Will Apple ever offer a newsreader?
Newsgroups: comp.sys.mac.comm,alt.folklore.computers
Date: Sat, 11 Jan 2003 16:18:19 GMT
Pete Fenelon writes:
WAIS was basically a front-end to the incredibly hairy Z39.50 bibliographic protocol. As I recall (WAIS' day in the sun was fairly short, I'd say it was popular for only about a year circa 92-3) you added WAIS "sources" to your local host - each "source" was a link to an indexed database somewhere on the net. WAIS clients would fire off queries to the hosts of the selected sources. Something like search engines, except you had to know where you were looking- and therefore were more likely to get relevant results. Thinking Machines seemed to be very heavily behind WAIS - presumably they had an interesting parallel search engine!

guy at thinking machines came up with wais ... moved out to cal. and started wais inc ... then sold to aol. then went up to incubator at sanfran presideo and started some other things ... including the web archeological project (i.e. snapshotting web sites over time ... and making the "old" versions available online).

wais also morphed into standards activity as x39.50 along with sigwais and sigir.

random ref:
http://www.garlic.com/~lynn/2001c.html#67 What ever happened to WAIS?

total thread drift ... one morning walking to a meeting ... i stopped and watched them pry the letters of the tmc building ... thread drift:
http://www.garlic.com/~lynn/2000d.html#64 "all-out" vs less aggressive designs
http://www.garlic.com/~lynn/2000d.html#68 "all-out" vs less aggressive designs
http://www.garlic.com/~lynn/2001n.html#17 CM-5 Thinking Machines, Supercomputers

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

InfiniBand Group Sharply, Evenly Divided

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: InfiniBand Group Sharply, Evenly Divided
Newsgroups: comp.arch
Date: Sat, 11 Jan 2003 19:35:42 GMT
Andy Glew <andy-glew-public@sbcglobal.net> writes:
Second, the credit providers might track and localize information about the likely credit card holders. Outside credit card holders might have their account information locally cached - at least they can be prevented from withdrawing more than they initially had. Outside credit card holders who flew in while disconnected might have no local account cache, but this would be better than denying all the tourists credit.

turns out that the network iteself supports something called stand-in ... where there are various rules that are definable by each institution as to what stand-in will perform under various conditions.

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Horror stories: high system call overhead

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Horror stories: high system call overhead
Newsgroups: alt.folklore.computers
Date: Sun, 12 Jan 2003 03:29:26 GMT
Roger Johnstone writes:
But the Macintosh, because it only had a fixed 128KB of RAM compared to the Lisa's 512KB or more, had all the "unnecessary" parts cut out and the entire OS and toolbox routines were rewritten in assembly language. Unfortunately, many of the OS functions that were unnecessary on a 128KB computer running a single application were things like protected memory and multitasking. Of course two years later the Mac Plus came out with 1MB of RAM, expandable to 4MB, and a new program called MultiFinder was introduced which allowed cooperative multitasking. The Mac OS didn't get protected memory though until Apple threw out their own efforts and adopted Unix, which ironically came via Steve Jobs' NeXT, the same Jobs who was behind the development of the Macintosh in the first place...

... which used mach from cmu. while project athena (where things like x-windows, kerberos, other stuff originated) was funded equally by DEC and IBM ... the cmu operation (where things like afs, andrew widgets, mach, camelot, and other things) was funded just by ibm.

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Timesharing TOPS-10 vs. VAX/VMS "task based timesharing"

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Timesharing TOPS-10  vs. VAX/VMS "task based timesharing"
Newsgroups: alt.folklore.computers
Date: Sun, 12 Jan 2003 13:33:40 GMT
jmfbahciv writes:
Did you have time slices where there was maximum value of runtime given to the job (or task or whatever you guys called yours) before putting him back on the runtime queue? Or is this something that's unique to us?

processes/tasks got queue/time slice that was the granularity unit and advisory (wall-clock) deadline to use that much resources (which was proportional to the slice). certain types of workload had smaller granularity unit and nearer in wall-clock (and everything was ordered by the advisory wall-clock).

at a point ... the scheduler calculated an incremental real-time that was proportional to the granularity of the slice plus a bunch of stuff about recent resource consumption ... and whether that was proportional greater or lesser than what the target resource consumption was. the target resource consumption could be calculated based on fair share ... or some number of other strategies. the incremental real-time value was then added to the current wall-clock and became the advisory deadline.

everything was ordered by the advisory deadlines (they weren't hard and fast deadlines like in realtime systems ... they were just basis for ordering). a large number of different scheduling strategies could co-exist simultaneously ... and then were all normalized down to the ordering of the advisory deadlines.

i started out having (implicit) idle queue, schedling/swap queue waiting for real memory, dispatchable (runtime) queue. advisory deadline was consistent ordering regardless of waiting for real memory or dispatchable. if you made too little progress ... both you immediate advistory deadline would pass ... as well as your recent rate of resource consumption.

a trivial interactive task that woke up after a long idle ... would get a very small granularity ... but also tend to have very low actual resource consumption compared to some target. as a result the calculated advisory deadline would be very near in the future.

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

InfiniBand Group Sharply, Evenly Divided

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: InfiniBand Group Sharply, Evenly Divided
Newsgroups: comp.arch
Date: Sun, 12 Jan 2003 13:46:23 GMT
young_r@encompasserve.org (Rob Young) writes:
By the way, single data center on a non-island is doable too for Disaster Avoidable (although the corner case of nuclear weapon or very large truck bomb would be a minor counter-point) , look at Sabre:


http://www.rink.com/sabre.htm

F5 tornado proof. Probably multiple fibre in multiple directions to multiple carriers with satellite uplinks, just in case.

A whole slew of Tandem boxes in there to replace the mainframe infrastructure (eventually).


diverse routing ... there is this story of a search for a bldg in certain metropolitan area that had telco access from four different directions to four different central xchange bldgs, power access from from four different directions to four different power substations, water main from opposite directions to two different water supply (big datacenters need water cooling one way or another). after all that, it turned out that they had a interesting single point of failure in the basement.

sabre has been tpf forever (well it use to be called acp). lots of airline reservation stuff can be handled by RAID equivalent for processor/systems.

random refs:
http://www.garlic.com/~lynn/99.html#17 Old Computers
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#103 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
http://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/2000f.html#20 Competitors to SABRE?
http://www.garlic.com/~lynn/2001.html#26 Disk caching and file systems. Disk history...people forget
http://www.garlic.com/~lynn/2001c.html#37 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001d.html#69 Block oriented I/O over IP
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#49 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001j.html#17 I hate Compaq
http://www.garlic.com/~lynn/2001n.html#0 TSS/360
http://www.garlic.com/~lynn/2001n.html#3 News IBM loses supercomputer crown
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#12 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002h.html#43 IBM doing anything for 50th Anniv?
http://www.garlic.com/~lynn/2002i.html#83 HONE
http://www.garlic.com/~lynn/2002j.html#83 Summary: Robots of Doom
http://www.garlic.com/~lynn/2002m.html#67 Tweaking old computers?

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

InfiniBand Group Sharply, Evenly Divided

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: InfiniBand Group Sharply, Evenly Divided
Newsgroups: comp.arch
Date: Sun, 12 Jan 2003 13:50:27 GMT
Anne & Lynn Wheeler writes:
actually the whole internet relies on DNS .... there was recent news clip on a dos attack on some of the primary ... with a footnote that it was fortunate that not all of the them were gotten ... or otherwise the internet would have pretty much come to a halt. so at a macro level ... the whole internet relies on dns ... which puts it into the important level.

aka
http://www.garlic.com/~lynn/2003.html#41

...

keeping ahead of DNS attacks:
http://zdnet.com.com/2100-1107-979650.html
By Paul Mockapetris Special to ZDNet January 8, 2003, 9:12 AM PT

COMMENTARY--The domain name system--the global directory that maps names to Internet protocol addresses-- was designed to distribute authority, making organizations literally "masters of their own domain." But with this mastery comes the responsibility of contributing to the defense of the DNS.

The distributed denial-of-service (DDoS) attacks against the DNS root servers on Oct. 21, 2002, should serve as a wake-up call. The attack was surprisingly successful--most of the root servers were disrupted by a well known attack strategy that should have been easily defeated. Future attacks against all levels of the DNS--the root at the top; top-level domains like .com, .org and the country codes; and individual high-profile domains--are inevitable.


... snip ...

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Origin of Kerberos

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Origin of Kerberos
Newsgroups: comp.protocols.kerberos,alt.folklore.computers
Date: Sun, 12 Jan 2003 16:56:19 GMT
"allem_mike" writes:
I would like to know when Kerberos has been elaborated and the number of the thirst version please.

I didn't find anything on the net so your help will be very helpfull for me.


is this asking where kerberos originated?

kerberos originated at mit project athena. projec athena was jointly funded by DEC & IBM (i think $25m each). overall director had been in 545 tech. sq on multics. there was DEC sub director (that i don't remember name) and IBM sub director ... who had also been at 545 tech. sq in the science center (who also originated the compare&swap instruction, the mnemonic are his initials).
http://www.garlic.com/~lynn/subtopic.html#545tech

my wife and I had done periodic audits of stuff at project athena. I have some recollection of one all day session walking thru the initial pass at the cross-domain authentication process.

kerberos reference page
http://www-2.cs.cmu.edu/afs/andrew.cmu.edu/usr/shadow/www/kerberos.html

note that cmu lab was ibm funding ... spawning afs, andrew toolkit/widgets, mach (in somewhat the same genre as cp/67 as a microkernel ... which has been used in number of implementations), camelot (which begat transarc)

and the mit page:
http://web.mit.edu/kerberos/www/index.html

"what is kerberos" is at the bottom of the (above) index page.

page at isi/usc:
http://www.isi.edu/gost/info/kerberos

we have some interest in certificate-less digital signature authentication
http://www.garlic.com/~lynn/x959.html#aads

in pk-init:
http://www.ietf.org/html.charters/krb-wg-charter.html

aka
http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-init-16.txt

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Top Gun

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Top Gun
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sun, 12 Jan 2003 20:32:43 GMT
review of boyd's biography made today's (sunday 1/12) book section in the washington post.

for a year he managed one of the largest (ibm mainframe?) data centers. It was possibly larger than a couple large ones that i had been in ... boeing renton datacenter (summer i spent helping set up bcs; which was then replicated at the 747 plant in everett) and the pok (ibm) data center (some 3rd shift time ... at the same time a couple of guys were crafting some code from cp/67 into mvt for initial SVS ... aka vs/2)

other boyd references:
http://www.garlic.com/~lynn/subboyd.html#boyd

other articles/reviews of the biography:
http://www.belisarius.com/
http://web.archive.org/web/20010722050327/http://www.belisarius.com/

above also includes URL pointing to the online version of the post's review (which appears on pg. 7 of the paper copy of the sunday book/world section).

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

SSL & Man In the Middle Attack

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SSL & Man In the Middle Attack
Newsgroups: comp.security.misc
Date: Mon, 13 Jan 2003 11:48:16 GMT
"NEWS.DFN.CIS" writes:
Hi, I'm a newbie

I was wondering if SSL was still vulnerable to man in the middle attack?

E.g., if some one is sitting between me and an trusted server, and intercepts our handshake during initiation of our secure conversation, isn't it possible for the middle man to intercept all messages from server to me (but not from me to server)?


server sends client a signed message along with a digital certificate. the client validates the digital certificate (i.e. it is for the server that i think i'm talking to) and then validates the signed message using the public key in the digital certificate (i.e. the server has to be the one described in the digital certificate or otherwise the signed message wouldn't verify).

client generates a random secret key, encrypts it with the server's public key (from the certificate) and sends it to the server. from then on the server and client encrypt everything using the generated random secret key. only the server specified in the validated digital certificate will be able to decrypt the random secret key (since they should be the only one with the private key capable of decrypting something that had been encrypted with the corresponding public key). the client knows the random secret key because it generated it ... the server knows the random secret key because it was able to decrypt it with the server's private key. recent refs:
http://www.garlic.com/~lynn/2003.html#19 Message (authentication/integrity); was: Re: CRC-32 collision
http://www.garlic.com/~lynn/2003.html#41 InfiniBand Group Sharply, Evenly Divided
http://www.garlic.com/~lynn/2003.html#42 basic pki question

there used to be an issue that a man-in-the-middle could play during SSL setup negotiation ... where it would fake messages as to the aggreed upon secret key encryption protocol ... and force both the client & server to select the weakest encryption protocol (with the shortest key length). then once the secret key was exchanged ... the man-in-the-middle was out of the loop ... other than attacking the encrypted messages to determine the secret key (which it had forced to the shortest possible).

other attacks on SSL infrastructure ... as opposed to SSL protocol ... is to get the client redirected to a different site by substituting a different URL. The actual SSL check is does the URL in the certificate match the URL that the client entered. If the attack can get the client to enter the URL of the man-in-the-middle (i.e. a bogus URL) ... who has a valid certificate for their site ... then the SSL protocol works to the man-in-the-middle ... who then can fakes a client to the real web site.

basically the SSL certificate protocol was to handle an ip-address take-over in the domain name infrastructure ... aka man-in-the-middle corrupted a DNS cache entry for a URL->IP-address mapping with the wrong ip-address. The client typed in the correct URL ... but was sent off to the wrong ip-address. The server at the fraudulent website would be unable to establish a correct certificate for the original URL.

However, if the attack involved getting the client's browser somehow to go to the wrong URL ... then the fraudulent website could have a valid certificate for the fraudulent URL and everything proceeds. Since frequently a client is just clicking on something ... rather than actually typing in the actual URL ... there could be lots of opportunities for incorrect URLs (even to trying to obtain domain names for the common mistypings of URLs).

the other is trying to spoof getting an issued certificate for the desired URL (a recent case was an IE problem that accepted as valid, certificates generated by individuals).

misc refs:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Cluster and I/O Interconnect: Infiniband, PCI-Express, Gibat

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Cluster and I/O Interconnect: Infiniband, PCI-Express, Gibat
Ethernet, etc.
Newsgroups: comp.arch
Date: Mon, 13 Jan 2003 21:48:02 GMT
Rick Jones writes:
Is the overhead actually in TCP and IP the protocols and their definitions, or is it in the implementations of the same and perhaps the rest of the stuff required to "interface" them to the rest of the OS and such?

lots is in tcp ... there is a minimum 7packet exchange to do setup/teardown. us of tcp (reliable session) by http (supposedly transaction ... carried significant overhead). once setup (for longer lived stuff) ... there was work getting optimized implementations with only five buffer copies (between application space and the wire). there was also the issue of header checksum ... instead of trailer checksum.

vmtp (rfc 1045) looked at doing same in 5packets

xtp looked at doing same in 3packets ... with no buffer copies and everything pipelined out the wire ... and intelligent chip could add trailor checksum on the packet as it was exiting on the wire.

random past stuff on packet exchange, buffer copies, header checksum, etc:
http://www.garlic.com/~lynn/93.html#32 Big I/O or Kicking the Mainframe out the Door
http://www.garlic.com/~lynn/94.html#00 Big I/O or Kicking the Mainframe out the Door
http://www.garlic.com/~lynn/99.html#0 Early tcp development?
http://www.garlic.com/~lynn/99.html#164 Uptime (was Re: Q: S/390 on PowerPC?)
http://www.garlic.com/~lynn/2000b.html#1 "Mainframe" Usage
http://www.garlic.com/~lynn/2000b.html#5 "Mainframe" Usage
http://www.garlic.com/~lynn/2001b.html#57 I am fed up!
http://www.garlic.com/~lynn/2001d.html#59 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001d.html#69 Block oriented I/O over IP
http://www.garlic.com/~lynn/2001e.html#24 Pre ARPAnet email?
http://www.garlic.com/~lynn/2001k.html#62 SMP idea for the future
http://www.garlic.com/~lynn/2002f.html#8 Is AMD doing an Intel?
http://www.garlic.com/~lynn/2002g.html#5 Black magic in POWER5
http://www.garlic.com/~lynn/2002g.html#17 Black magic in POWER5
http://www.garlic.com/~lynn/2002g.html#50 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002i.html#66 Unisys A11 worth keeping?
http://www.garlic.com/~lynn/2002k.html#31 general networking is: DEC eNet: was Vnet : Unbelievable

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Timesharing TOPS-10 vs. VAX/VMS "task based timesharing"

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Timesharing TOPS-10  vs. VAX/VMS "task based timesharing"
Newsgroups: alt.folklore.computers
Date: Tue, 14 Jan 2003 14:02:58 GMT
Brian Inglis writes:
Probably.

There's no available comparison -- they're all kept under tight IBM security -- the facts might shock the troops! ;^>


this was the cern mvs/cms backoff circa '74 presented at share ... however the copies available inside the company were stamped ... confidential, restircted ... aka available on a need to know basis only.

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Cluster and I/O Interconnect: Infiniband, PCI-Express, Gibat

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Cluster and I/O Interconnect: Infiniband, PCI-Express, Gibat
Ethernet, etc.
Newsgroups: comp.arch
Date: Tue, 14 Jan 2003 16:19:45 GMT
Andi Kleen writes:
Well, when the other end doesn't want you to send data faster there is nothing you can do. You have to get them to fix the problem. It is really an administrative, not a technical problem.

note that slow-start for window sizes ... was shown to be instable in any reasonable size environment ... i think the paper came out at about the same time as the orinal slow-start specification. part of the issue is that the problem tends to actually be inter-packet arrival rate. window algorithms tend to assume that the avg latency divided individual packet transmission ... and that the packets transmission will be uniformly distributed over the round-trip latency. the problem is that with things like ack piggy-backing ... that frequently bunches of acks aggregate back to the transmission end ... which opens up multiple windows simultaneously ... resulting in burst of transmissions.

rate-based pacing tends to directly adjust the inter-packet transmission interval (in effect, windowing tended to only indirectly address the primary problem). part of the lack of rate-based pacing was that many of the tcp/ip platforms during the '80s had poor timer-support facilities ... making control of inter-packet transmission intervals difficult to implement.

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Wild hardware idea

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Wild hardware idea
Newsgroups: comp.arch
Date: Wed, 15 Jan 2003 01:40:58 GMT
"Duane Sand" writes:
Seymour Cray used 10-way multithreading in the Peripheral Processor unit of the CDC 6000 series. There, the thread scheduling was fixed at one cycle in every 10; the point was to to shadow the main memory latencies on this cacheless machine.

so are the last couple generations of ibm mainframes with LPARs (logical partitions) ... hardware multithreading ... or virtual machine support in the microcode?

it started with amdahl ... putting some extensive hypervisor support into the metal (firmware?) of their machine. IBM responded with PR/SM ... which then grew into LPARs.

the high end machines have had fairly complex wide/horizontal microcode that tended to be extgremely difficult to program. amdahl had come out with an intermediate mode that they called macrocode (effectively an optimized 370 subset) which greatly simplified the development and support of new hardware features.

random lpar / pr/sm postings:
http://www.garlic.com/~lynn/98.html#45 Why can't more CPUs virtualize themselves?
http://www.garlic.com/~lynn/98.html#57 Reliability and SMPs
http://www.garlic.com/~lynn/99.html#191 Merced Processor Support at it again
http://www.garlic.com/~lynn/2000.html#8 Computer of the century
http://www.garlic.com/~lynn/2000.html#63 Mainframe operating systems
http://www.garlic.com/~lynn/2000.html#86 Ux's good points.
http://www.garlic.com/~lynn/2000b.html#50 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000b.html#51 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000b.html#52 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000b.html#61 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000b.html#62 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000c.html#8 IBM Linux
http://www.garlic.com/~lynn/2000c.html#50 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#68 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#76 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000f.html#78 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000g.html#3 virtualizable 360, was TSS ancient history
http://www.garlic.com/~lynn/2001.html#34 Competitors to SABRE?
http://www.garlic.com/~lynn/2001b.html#72 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001d.html#67 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001e.html#5 SIMTICS
http://www.garlic.com/~lynn/2001e.html#61 Estimate JCL overhead
http://www.garlic.com/~lynn/2001f.html#17 Accounting systems ... still in use? (Do we still share?)
http://www.garlic.com/~lynn/2001f.html#23 MERT Operating System & Microkernels
http://www.garlic.com/~lynn/2001h.html#2 Alpha: an invitation to communicate
http://www.garlic.com/~lynn/2001h.html#33 D
http://www.garlic.com/~lynn/2001l.html#24 mainframe question
http://www.garlic.com/~lynn/2001m.html#38 CMS under MVS
http://www.garlic.com/~lynn/2001n.html#26 Open Architectures ?
http://www.garlic.com/~lynn/2001n.html#31 Hercules etc. IBM not just missing a great opportunity...
http://www.garlic.com/~lynn/2001n.html#32 Hercules etc. IBM not just missing a great opportunity...
http://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
http://www.garlic.com/~lynn/2002c.html#53 VAX, M68K complex instructions (was Re: Did Intel Bite Off More Than It Can Chew?)
http://www.garlic.com/~lynn/2002d.html#31 2 questions: diag 68 and calling convention
http://www.garlic.com/~lynn/2002e.html#25 Crazy idea: has it been done?
http://www.garlic.com/~lynn/2002e.html#75 Computers in Science Fiction
http://www.garlic.com/~lynn/2002f.html#6 Blade architectures
http://www.garlic.com/~lynn/2002f.html#57 IBM competes with Sun w/new Chips
http://www.garlic.com/~lynn/2002n.html#6 Tweaking old computers?
http://www.garlic.com/~lynn/2002n.html#27 why does wait state exist?
http://www.garlic.com/~lynn/2002n.html#28 why does wait state exist?
http://www.garlic.com/~lynn/2002o.html#0 Home mainframes
http://www.garlic.com/~lynn/2002o.html#15 Home mainframes
http://www.garlic.com/~lynn/2002o.html#16 Home mainframes
http://www.garlic.com/~lynn/2002o.html#18 Everything you wanted to know about z900 from IBM
http://www.garlic.com/~lynn/2002p.html#4 Running z/VM 4.3 in LPAR & guest v-r or v=f
http://www.garlic.com/~lynn/2002p.html#40 Linux paging
http://www.garlic.com/~lynn/2002p.html#44 Linux paging
http://www.garlic.com/~lynn/2002p.html#45 Linux paging
http://www.garlic.com/~lynn/2002p.html#46 Linux paging
http://www.garlic.com/~lynn/2002p.html#48 Linux paging
http://www.garlic.com/~lynn/2002p.html#54 Newbie: Two quesions about mainframes
http://www.garlic.com/~lynn/2002p.html#55 Running z/VM 4.3 in LPAR & guest v-r or v=f
http://www.garlic.com/~lynn/2002q.html#26 LISTSERV Discussion List For USS Questions?
http://www.garlic.com/~lynn/2003.html#9 Mainframe System Programmer/Administrator market demand?
http://www.garlic.com/~lynn/2003.html#14 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#15 vax6k.openecs.org rebirth

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

If you lived as a child in the 50's, 60's or 70's,

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: If you lived as a child in the 50's, 60's or 70's,
Newsgroups: bit.listserv.ibm-main
Date: Wed, 15 Jan 2003 01:30:24 GMT
i just got told that there is a new strain(s) of salmonella that has shown up in the last 10-12 years ... and a result it is much more dangerous to eat one of my favorite foods ... raw cookie dough.

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Card Columns

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Card Columns
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Wed, 15 Jan 2003 13:51:08 GMT
robin writes:
Columns 73-80 were for card numbering.

cms update/source maint uses card/statement numbering in 73-80.

misc. ref:
http://www.garlic.com/~lynn/2002n.html#39 CMS update

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Cluster and I/O Interconnect: Infiniband, PCI-Express, Gibat

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Cluster and I/O Interconnect: Infiniband, PCI-Express, Gibat
Ethernet, etc.
Newsgroups: comp.arch
Date: Wed, 15 Jan 2003 14:27:26 GMT
Andi Kleen writes:
This has been fixed in modern TCPs - they employ special algorithms to avoid bursts on fast retransmit and slow start.

I don't remember the RFC numbers describing this off hand, but they exist. It is a relatively new development however.


note that backbone my wife & I were operating in '80s was doing rate-based pacing ... one of the things highlighted by NSF audit.
http://www.garlic.com/~lynn/internet.htm#0 Internet or ARPANET?

at:
http://www.garlic.com/~lynn/rfcietff.htm
3390
Increasing TCP's Initial Window, Allman M., Floyd S., Partridge C., 2002/09/31 (15pp) (.txt=36177) (Obsoletes 2414) (Updates 2581) (was draft-ietf-tsvwg-initwin-04.txt)
2581 PS
TCP Congestion Control, Allman M., Paxson V., Stevens W., 1999/04/08 (14pp) (.txt=31351) (Updated by 3390) (Obsoletes 2001) (TCP-CC)
2001 -
TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms, Stevens W., 1997/01/23 (6pp) (.txt=12975) (Obsoleted by 2581)


and in RFCs listed by section, from TERM (term->RFC#)

RFCs related to
congestion
see also performance
3451 3450 3436 3390 3309 3210 3209 3182 3181 3175 3168 3159 3124 3097 3042 2997 2996 2988 2961 2960 2914 2889 2884 2872 2861 2816 2814 2753 2752 2751 2750 2749 2747 2746 2745 2582 2581 2556 2490 2481 2414 2382 2380 2379 2309 2210 2209 2208 2207 2206 2205 2140 2098 2001 1859 1372 1254 1110 1106 1080 1018 1016 896 813 449 442 210 59 19


--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

MIDAS

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: MIDAS
Newsgroups: alt.folklore.computers
Date: Wed, 15 Jan 2003 18:24:40 GMT
"Russ Holsclaw" writes:
By the way, before Lynn chimes in on this, it should be noted that the Diagnose instruction is actually used in VM/370 (and the predecessor CP/67) as a way for a program running in a virtual machine to call functionality in the underlying VM Control Program. In this case, however, it's not running microcode, it's simply taking advantage of the fact that, as a privileged instruction, issuing the Diagnose instruction in non-privleged mode causes a special Program Check interrupt. In some ways, VM's use of the instruction is abstractly analogous to what it does with the "bare metal". Also, it uses an opcode that is otherwise reserved and thus unlikely to be implemented otherwise in future extensions to the IBM mainframe architecture.

this was a bob adair special ... he insisted on it. After I had done all this other fastpath stuff in cp/67 as undergraduate ... one of the remaining high pathlength overhead for CMS was in ccwtrans ... i/o simulation. (still at the university) I defined and implemented a x"ff" disk i/o ccw op-code (did both read&write) that representd the traditional CMS disk i/o ccw sequence ... and I also defined it to be an "immediate" simulated op-code ... i.e. it did cc=1 csw stored to the SIO (aka it held cms in non-runnable until the disk i/o transfer finished ... which eliminated the standard cms sequence of LPSW to wait, i/o interrupt from wait, etc). This addressed the remaining high pathlength overhead in the cp/67 kernel for cms.

bob adair observed that i was violating the Princ of Ops ... and that CP/67 virtual machine implementations do everything possible to preserve the architecture integrity of the 360 princ of ops to address this delima he noted that the diagnose instruction was defined as undefined and model dependent ... and constructed this framework/paradigm of a virtual machine model dependent implementation of the diagnose instruction (aka cp/67 defined diagnose insturction operation for the virtual machine model of the 360 .. aka cp/67 kernel was in effect the top level microcode of the virtual machine).

I learned a lot about KISS and the meaning of architecture from Bob. A lot of the CP/67 microkernel, compact, KISS characteristics are because of him. It wasn't always easy ... KISS is frequently significantly harder work than various of the first-take, quck&dirty solutions.

my CMS changes were remapped into diagnose instruction with the same semantics ... i.e. the diagnose for cms disk i/o would perform as a cc=1, csw stored SIO-semantics. CMS was modified that on boot to see if it was running a virtual machine model or a real machine model. It it was running a virtual machine model ... it would use the diagnose instruction flavor rather than the sio instruction flavor. when cms was changed from the "cambridge monitor system" to the "conversational monitor system" as part of the cp/67 to vm/370 transition ... the ability for cms to run on bare iron was removed.

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

MIDAS

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: MIDAS
Newsgroups: alt.folklore.computers
Date: Wed, 15 Jan 2003 18:28:05 GMT
Brian Inglis writes:
Anyone remember if Diagnose was used to access the model dependent ECPS (Extended Control Program Support) assist microcode available on some machines? It's been years^Wdecades since I browsed those sections of the source code.

nope ... ECPS was accessed by a bunch of x'B2's ...

random ref:
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Card Columns

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Card Columns
Newsgroups: alt.folklore.computers
Date: Wed, 15 Jan 2003 18:40:25 GMT
Brian Inglis writes:
IBM Assembler conventions on VM used columns 64-71 for the SID (change id): supported by the screen editor Xedit, which generated a separate delta UPDATE file, each line having the SID in 64-71, and with smaller increment sequence numbers in 72-80, from each editing session (similar to using vi with sccs/rcs auto-checkout and -in). Think the original line sequence increment was 10; can't remember what happened if you needed to add more than 9 lines between two existing lines: maybe we just didn't do that!

it started with 10 increment ... but after the source update process was put into place ... vm adopted the convention of increment by 1000. standard process (including automation by xedit) adopted procedure of replacing surronding lines ... say if you were inserting more than could fit in the available increment (in effect resequencing lines in the vacinity of the insert to accomodate the additional lines).

the SID code started with four characters because the original process used "UPDG" & "UDPT" as the first four characters of the filetype leaving up to four characters for the update name. this was expanded when auxfiles were introduced.

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

SSL & Man In the Middle Attack

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SSL & Man In the Middle Attack
Newsgroups: comp.security.misc
Date: Wed, 15 Jan 2003 19:06:31 GMT
Barry Margolin writes:
If it sends the server's real certificate, it will contain the server's public key. The client will encrypt its response with that public key, but the MITM won't be able to decrypt it, because that requires knowing the server's private key.

If the MITM sends a fake certificate, it won't be properly signed by the CA, so the client should reject it.

This is the whole point of digital certificates -- if you trust the CA, then they are unforgeable.


there are a couple of issues with digital certificates ... they aren't magic ... they are just business processes ... that have an entry from a database someplace copied into a string of bits ... and signed by a private key.

a whole table of corresponding public keys have been loaded into various browsers. when a browser gets one of these string of bits ... it can tell if the bits have been altered since the original signing ... by finding the public key (that corresponds to the private signing key) and verify the signature.

this just validates whether or not the string of bits have been altered since the (certificate) signature was originally signed.

so various exploits are:

1) somehow introduce a public key into the browser tables that shouldn't be there. one ways is a virus that modifies the browsre table. another way is get user to click on the "accept" button for unknown CA. another way is some ethically challenged party purchases the assets of some company going defunct that already has a key in standard browser table)

2. find a bug in the validation process. this is somewhat the IE bug. turns out that IE wasn't checking if a CA was really the CA. If somebody had a valid certificate signed by a valid CA ... and they then signed a fradulent certificate ... IE would accept the signing of the fraudulent certificate as if the original CA had signed it.

3. corrupt the database entry that the information in the certificate is taken from. I call this the irony or catch-22 exploit. The reason for SSL domain name certificates have been issues with the integrity of the domain name infrastructure. However, the authoritative agency for domain name ownership is the domain name infrastructures. CAs when asked to issue a SSL domain name server certificate, check with the domain name infrastructure to see if they are actually dealing with the owner of the domain name. If that answer comes back "yes", the CAs then issue the certificate. The attack that has happened on the domain name infrastructure to corrupt those database entries has been call "domain name take-over" ... you convince the domain name infrastructure to change the domain name database entry ... and then you get a certificate for that domain name. The irony is that all of the CAs in the world that are manufacturing SSL domain name server certificates (because of integrity issues of the domain name infrastructure) are actually dependent on the integrity of the domain name infrastructure for validating the information that they would put in a certificate. This can also be considered the security is only as strong as the weakest link exploit or the obfuscate the business process with a bunch of mathematical mumbo-jombo exploit. Note that the company name in the SSL certificate isn't likely to correspond to the company name that a consumer might expect ... but nobody actually examines these fields ... the protocol just does a match on the domain name field ... and the rest of the fields are ignored.

similar recent discussion:
http://www.garlic.com/~lynn/aepay10.htm#71 Invisible Ink, E-signatures slow to broadly catch on
http://www.garlic.com/~lynn/aepay10.htm#72 Invisible Ink, E-signatures slow to broadly catch on
http://www.garlic.com/~lynn/aepay10.htm#73 Invisible Ink, E-signatures slow to broadly catch on
http://www.garlic.com/~lynn/aepay10.htm#74 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aepay10.htm#75 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aepay10.htm#76 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aepay10.htm#77 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aepay10.htm#78 ssl certs
http://www.garlic.com/~lynn/aepay10.htm#79 ssl certs
http://www.garlic.com/~lynn/aepay10.htm#80 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aepay10.htm#81 SSL certs & baby steps
http://www.garlic.com/~lynn/aepay10.htm#82 SSL certs & baby steps (addenda)
http://www.garlic.com/~lynn/aepay10.htm#83 SSL certs & baby steps
http://www.garlic.com/~lynn/aepay10.htm#84 Invisible Ink, E-signatures slow to broadly catch on (addenda)

long history of threads on this issue:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

SSL & Man In the Middle Attack

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SSL & Man In the Middle Attack
Newsgroups: comp.security.misc
Date: Wed, 15 Jan 2003 19:19:49 GMT
Anne & Lynn Wheeler writes:
this just validates whether or not the string of bits have been altered since the signature was originally signed.

brain/finger slip

this just validates whether or not the string of bits have been altered since the certificate was originally signed.

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Amdahl's VM/PE information/documentation sought

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Amdahl's VM/PE information/documentation sought
Newsgroups: alt.folklore.computers
Date: Thu, 16 Jan 2003 00:54:54 GMT
i forwarded to one of the people that worked on it.

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

SSL & Man In the Middle Attack

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SSL & Man In the Middle Attack
Newsgroups: comp.security.misc
Date: Thu, 16 Jan 2003 12:19:48 GMT
Anne & Lynn Wheeler writes:
3. corrupt the database entry that the information in the certificate is taken from. I call this the irony or catch-22 exploit. The reason for SSL domain name certificates have been issues with the integrity of the domain name infrastructure. However, the authoritative agency for domain name ownership is the domain name infrastructures. CAs when asked to issue a SSL domain name server certificate, check with the domain name infrastructure to see if they are actually dealing with the owner of the domain name. If that answer comes back "yes", the CAs then issue the certificate. The attack that has happened on the domain

so the other part of the irony/catch-22

the ssl domain name certificate ... basically amounts to fields from some account record in a domain name infrastructure database (possibly asn.1 encoded and then digitally signed) ... the security of the business process really revolves around the security that the domain name infrastructure uses for those account records.

not only do ssl domain name certificates owe their existance to concerns about various integrity issues regarding the domain name infrastructure ... but the originating business process integrity of the ssl domain name certificates is dependent on the integrity of the domain name infrastructure ... one irony/catch22 is while ssl domain name certificates existance are dependent on concerns about domain name infrastructure integrity issues ... those certificates' integrity are based on the integrity of the domain name infrastructure (integrity).

so somewhat from the CA industry there are various suggestions to improve the integrity of the domain name infrastructure ... in order that the CA industry can depend on the integrity of the domain name infrastructure for the information that they manufacture into ssl domain name certificates. however, improving the integrity of the domain name infrastructure ... could also be viewed as reducing the concerns about domain name infrastructure integrity issues ... and therefor reducing the need for ssl domain name certificates.

from that standpoint ... the ca industry walks a fine line ... they want to have the integrity of the domain name infrastructure improved/sufficient so that people can trust the information in ssl domain name certificates ... but not improved so much as to obsolete the need for ssl domain name certificates.

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

3745 & NCP Withdrawl?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 3745 & NCP Withdrawl ?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 17 Jan 2003 14:25:55 GMT
ted.macneil@mobile.rogers.com (ted.macneil) writes:
I must be in the minority! The purpose of any Network Controller is to offload processing from the Host. Now, Host MIPS may appear cheap; add software costs! TCP/IP may be the best thing since sliced bread, but now 37x5 processing must be done with the more expensive mainframe cycles.

i had somehow gotten the impression that much of the pu4/pu5 design was in response to something that i worked on as an undergraduate .... first PCM controller (60s).
http://www.garlic.com/~lynn/subtopic.html#360pcm

i actually ran into a descendent of the box running in a large datacenter 4-5 years ago.

note that "network" is somewhat a misnomer .... sna lacked any network layer at all. the first instance slightly related to networking was appn; however the sna group non-concurred with the announcement ... which was held up for a couple months for escalation and announcement letter was rewritten so that there would be no confussion between sna and networking ... aka sna was oriented to managing the communication infrastructure of large number of dumb terminals.

slightly related issue was that there was some attempt long ago and far away ... to get the peachtree processer as a choice for 37xx rather than the uc.5 processor (which had significant impact on ncp implementation abilities).

there are all sorts of design and architecture trade-offs. the tcp/ip mainframe product imphlementation had an 8232 as a standard controller attachment box; however the choice of the protocol between 8232 and mainframe could have been better. that implementation could hit 44kbytes/sec consuming a full 3090 engine.

for the product, i supplied the rfc1044 support ... which used a different controller box and different choice of protocol abstraction. the rfc1044 support in the shipped produced used a very modest amount of 4341 processing hitting sustained thruput of channel speed (1mbyte/sec) ... 1/50th the cpu for 20 times the thruput (about three orders of magnitude difference).

random hsdt posts
http://www.garlic.com/~lynn/subnetwork.html#hsdt

slightly related saa, sna, & 3-tier posts:
http://www.garlic.com/~lynn/subnetwork.html#3tier

misc. rfc 1044 specific posts:
http://www.garlic.com/~lynn/93.html#28 Log Structured filesystems -- think twice
http://www.garlic.com/~lynn/96.html#14 mainframe tcp/ip
http://www.garlic.com/~lynn/96.html#15 tcp/ip
http://www.garlic.com/~lynn/96.html#17 middle layer
http://www.garlic.com/~lynn/98.html#34 ... cics ... from posting from another list
http://www.garlic.com/~lynn/98.html#49 Edsger Dijkstra: the blackest week of his professional life
http://www.garlic.com/~lynn/98.html#50 Edsger Dijkstra: the blackest week of his professional life
http://www.garlic.com/~lynn/99.html#36 why is there an "@" key?
http://www.garlic.com/~lynn/2000.html#90 Ux's good points.
http://www.garlic.com/~lynn/2000c.html#59 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000f.html#30 OT?
http://www.garlic.com/~lynn/2001d.html#63 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001d.html#65 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001h.html#44 Wired News :The Grid: The Next-Gen Internet?
http://www.garlic.com/~lynn/2001j.html#20 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2002.html#11 The demise of compaq
http://www.garlic.com/~lynn/2002i.html#43 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#45 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002j.html#67 Total Computing Power
http://www.garlic.com/~lynn/2002k.html#31 general networking is: DEC eNet: was Vnet : Unbelievable
http://www.garlic.com/~lynn/2002n.html#58 IBM S/370-168, 195, and 3033
http://www.garlic.com/~lynn/2002o.html#51 E-mail from the OS-390 ????
http://www.garlic.com/~lynn/2002q.html#27 Beyond 8+3

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

3745 & NCP Withdrawl?

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 3745 & NCP Withdrawl ?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 17 Jan 2003 14:41:43 GMT
j.grout@COMPUTER.ORG (John R. Grout) writes:
The original environment for this mailing list... BITNET... was a large point-to-point NJE network full of non-IBM systems.

the internal network was larger than the internet until possibly sometime in '85. part of the reason was that the vm/vnet effectively had gateway support in every node. part of this was that vm/vnet had a large family of nje drivers ... in addition to the native vm/vnet driver. part of the migration to NJE-only drivers could possibly be considered limit the comparison of the native vm/vnet dirvers and the NJE drivers.

major problem was that JES2 and nje had a design that improperly intermixed fields belonging to different protocol layers in a jumble in the nje header. an early problem was that slightly different versions of JES2 with slightly different NJE header formats ... in the same network ... could crash each other's mvs systems (very poor interoperability characteristics). JES2 also had a secondary problem that it didn't have ability to define all nodes in the internal network ... and a JES2 node would trash any data where either the origin or destination nodes weren't defined in the local table.

a combination of the trashing data ... and inability to support generalized interoperability ... restricted JES2 nodes to boundary positions on the internal network. the family of NJE drivers that grew up for vm/vnet included the responsibility for rewriting NJE header fields. There would be a specific NJE driver loader in VM/VNET for the line that corresponded to the JES2/NJE version level on the other end of the line. It was the responsibility of the vm/vnet NJE driver to make sure that all data flowing thru vm/vnet had the NJE header fields rewritten so they conformed to the exact JES2 version on the other end of the communication line (to avoid MVS system crashes).

it became so institutionalized that when MVS system crashes did occur ... because somebody had upgraded a MVS/JES2 system w/o notifying the VM/VNET node to change the VM/VNET NJE driver with new header rewrite rules ... it was the VM/VNET system that got blamed ... aka the fundamental problem was lack of MVS/JES2 interoperability support ... but it became so institutionalized that vm/vnet was used to keep mvs/jes2 systems from crashing ... that when mvs/jes2 did crash ... vm/vnet got blamed.

eventually they stopped shipping the native vm/vnet drivers with vm/vnet ... just shipping NJE drivers ... in part because the native vm/vnet drivers had significantly better thruput than the NJE drivers.

random bitnet/earn posts:
http://www.garlic.com/~lynn/subnetwork.html#bitnet

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Why did they make FORTRAN so hard to parse?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why did they make FORTRAN so hard to parse?
Newsgroups: alt.folklore.computers
Date: Sat, 18 Jan 2003 17:46:04 GMT
Joe Morris writes:
We read McCracken's book.

Actually, I don't have the book to check, but aside from the FMS FORTRAN language manual that was for a while my only reference material for the language, and I recall using "continuation line numbers" as I was starting to learn the language.


i have the book still ... but not there at the moment ... will check when i get back sometime next week.

other random refs:
http://www.garlic.com/~lynn/2002f.html#47 How Long have you worked with MF's ? (poll)
http://www.garlic.com/~lynn/2002f.html#48 How Long have you worked with MF's ? (poll)

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Disk drives as commodities. Was Re: Yamhill

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk drives as commodities. Was Re: Yamhill
Newsgroups: comp.arch
Date: Sat, 18 Jan 2003 21:14:27 GMT
"M. Ranjit Mathews" writes:
I've heard a disk drive that goes into an enclosure called a hard file, a disk, or a drive; I've never heard it called a DASD. What I've heard called a DASD is a 4U (or so) enclosure holding multiple "hardfile"s; an example of what I've heard called a DASD farm is a few 1,000 hardfiles in several floor standing refrigerator sized towers attached to a host.

dasd (direct access storage device) that i encountered circa '66 (2311, 2301, & 2321)

the 2311s were dasd ... both the drives (about like a dishwasher, top-loading) and the packs (removeable) were called dasd. the 2311s were followed by 2314s (also removeable packs) and then 3330s (also removeable packs). precursor to 2311 was 1301. both the 2314 and 3330s were two high drawers which would slide out and the pack be mounted or removed.

the 2301s were also dasd ... these were fixed-head per track "drum" (rotating cylinder with tracks on the outside surface of the cylinder, somewhat akin to the old edison recording cylinders but larger and instead of moving head ... there was head per track). the 2301s were followed by 2305s.

the 2321 were also dasd ... this was more like a washing machine ... with ten (removeable) bins arraigned inside the washing machine drum ... each bin contained magnetic strips. the washing machine rotated under the read/write position until the appropriate bin was in position ... then it was possible to retrieve an appropriate strip from the bin and wrap it around the read/write head. sometimes when inserting a strip back into a bin, it would catch ... and be crumpled into something that look like fan-fold configuration.

these were frequently referred to as count-key-data ... and used a seven byte addressing scheme:

BBCCHHR DASD addressing


BB ... bin         except for 2321 this field was all zero
CC ... cylinder
HH ... head
R  ... record

convention on the spinning round&brown with moveable arm actuator ... two byte "BB" bin selector was zero, two byte "CC" selected arm position .. and two byte "HH" selected one of the heads once the arm was moved into position.

some stuff:
http://www.sdisw.com/dasd_capacity.html

the exclusive dominance of the platter (aka disk) shape wasn't until the '70s.

slightly related postings:
http://www.garlic.com/~lynn/2000.html#9 Computer of the century
http://www.garlic.com/~lynn/2002.html#22 index searching
http://www.garlic.com/~lynn/2002m.html#40 Wanted: the SOUNDS of classic computing

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Card Columns

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Card Columns
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Sat, 18 Jan 2003 21:34:40 GMT
"John W. Kennedy" writes:
There were a good many US manufacturers -- Burroughs, Sperry-Rand, National Cash Register, Control Data, Honeywell, RCA, General Electric (collectively known as the "seven dwarfs") -- even Philco made a stab at it at one point, and had a FORTRAN/ALGOL hybrid language called ALTAC. But IBM held a commanding presence in the US business world almost from the first, partly because they already dominated the pre-computer punched-card-accounting business. (IBM's machines had been entirely programmable by the customer; Remington-Rand's machines had frequently needed an engineer or even a trip to the factory.)

When the 360 came out, RCA simply copied its problem-state architecture (though they had an incompatible supervisor state, requiring their own operating systems), and Honeywell's entire advertising campaign, for years, was on the theme, "We can move you from an IBM 1401 to a Honeywell system more easily than IBM can move you to a 360."


a story i heard that was attributeed to somebody from RCA testifying during the gov. anti-trust trial ... was that in the late 50s ... every computer manufactur realized that the single, most important criteria for being succesful in the computer industry was going to be a single compatible architecture across the computer line.

for various (non-technical) reasons, tj watson was the only executive that managed to get all the different manufacturing lines/plants to "toe the line" and maintain compatibility (with 360).

there was some hypothesis that if only a single vendor managed to achieve that single, most important objective ... then, in theory, that vendor could do nearly everything else wrong and still be succesful.

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Disk drives as commodities. Was Re: Yamhill

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk drives as commodities. Was Re: Yamhill
Newsgroups: comp.arch
Date: Sun, 19 Jan 2003 15:32:06 GMT
Anne & Lynn Wheeler writes:

BBCCHHR DASD addressing

BB ... bin         except for 2321 this field was all zero
CC ... cylinder
HH ... head
R  ... record

note that this is still being used today and originated before i ran into it in '66 ... so has existed for dasd addressing for going on 40 years or so.

and as previously alluded to, the use of the term DASD is at least explainable from the standpoint that spinning platters weren't the sole form factor.

misc:
http://www.os390-mvs.freesurf.fr/mvshist1.htm MVS ... long history: os/360

from above:
Shmuel's note. OS/360 was not the first operating system to require DASD. Burroughs B5000 (MCP), CDC 6600 (CIPROS), Ferranti Atlas and GE 625 (GECOS, later GCOS) all required DASD, to say nothing of IBM's own DCS.

====

and some total thread drift. the above page references:
http://izgudrojumi.lza.lv/eng/izgudrotaji/PadegsA.asp

andris padegs web page. when cambridge/charlie was trying to get compare&swap instruction into 370 ... padegs and ron smith were the "owners" of the principle of operations. it was ron smith who directed that more justification was needed than just multiprocessor atomic instruction .. that a use in uniprocessor environment was needed. as a result, cambridge came up with the various uses of compare&swap instruction for multi-threaded application (whether they ran in uniprocessor a multiprocessor environment).

random dasd refs:
http://www.vm.ibm.com/pubs/cms420/DTFSD.HTML
http://joshua.raleigh.nc.us/docs/linux-2.4.10_html/385056.html
http://www.conmicro.cx/hercules/hercload.html
http://homepages.kcbbs.gen.nz/nbree/saga.html
http://www.conmicro.cx/hercos360/blddrv.html
http://www.os390-mvs.freesurf.fr/mvs360.htm
http://www.rjbuntenconsulting.com/biography.htm
http://www.punch-card.co.uk/3701.htm
http://www.softwarehistory.org/history/important_people.html

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Card Columns

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Card Columns
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Sun, 19 Jan 2003 19:30:10 GMT
"Russ Holsclaw" writes:
I didn't intend to ruffle any feathers here. Minis have a venerable tradition, too. It just happens that their systems reflect their TTY-oriented heritage in just the same way as mainframes (and most particularly IBM ones) reflect their punched-card heritage.

UR configurations (printer, card reader, controller, etc) were on the order of the combined cost of mini plus TTYs. one might claim that minis were TTY-oriented because of cost issues.

7094/ctss had 2741 support ... as well as cp/67.

at the university i implemented tty support in cp/67 ... with a peculiar characteristic that later resulted in the following bug story (some amount of the code i did at the university was picked up and distributed as part of the standard product):
http://www.multicians.org/thvv/360-67.html
at:
http://www.multicians.org/thvv/tvv-home.html#stories

as part of the TTY support ... I attempted to extended dynamic terminal identification using the SAD command in the 2702 ... being able to change different line-scanner. 2702 short-coming was that while it was possible to dynamically associate different line-scanners with each line (both hard-wired & dial-up lines) ... they took a short cut and hired wired the oscillator to each line (could switch between the 2741 line-scanner and the tty line-scanner on the same line ... but couldn't dynamically change the baud rate).

this led to a project at the university to build our own controller (supporting automatic terminal identification and automatic baud rate identification) starting with reverse engineering the 360 channel interface and putting it into an interdata/3 ... then extended to an interdata/4 using interdata/3s as line-scanners. we since got blamed for originating the 360 pcm controller business:
http://www.garlic.com/~lynn/subtopic.html#360pcm

later it was bought up and the boxes were sold under the perkin/elmer label.

in effect ... each of the (many) controllers in a typical mainframe operation tended to be full-fledge minis in their own right

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

paper tape input

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: paper tape input
Newsgroups: alt.folklore.computers
Date: Sun, 19 Jan 2003 19:38:44 GMT
bfranchuk writes:
Coke/Pepsi is the choice of the HACKER generation. How many Tea dispensers do you know hooked up to the internet? Ben.

i was at a conference where they did initial market/beta-tested jolt ... driving a truckload out to the west coast.

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm


next, previous, index - home