From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Is a VAX a mainframe? Newsgroups: alt.folklore.computers Date: Wed, 12 Jul 2000 23:47:00 GMTmisc. other 4341 information .... because 4341 needed to be tested with disks ... the disk engineering labs got 4341s before the endicott performance testing groups (who could initially only get sporadic test shots on engineering machines).
Since I was providing support for the disk engineering & product test labs ... I actually had better access for testing 4341s than most of the endicott groups.
one of the things in the 4341 was significantly improved floating point support ... over the previous "endicott" (lower-end) machines (like the 145).
simple test run that I did for the endicott engineers (circa feb. 1979)
Following are times for floating point fortran job running same fortran
158 3031 4341
Rain 45.64 secs 37.03 secs 36.21 secs
Rain4 43.90 secs 36.61 secs 36.13 secs
also times approx;
145 168-3 91
145 secs. 9.1 secs 6.77 secs
rain/rain4 was from Lawrence Radiation lab ... and ran on cdc6600 in
35.77 secs.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Is a VAX a mainframe? Newsgroups: alt.folklore.computers Date: Wed, 12 Jul 2000 23:50:17 GMTAnne & Lynn Wheeler writes:
simple test run that I did for the endicott engineers (circa feb. 1980) ^^^^ oops, should be: 1979
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM's "ASCI White" and "Big Blue" architecture? Newsgroups: alt.folklore.computers Date: Thu, 13 Jul 2000 04:46:33 GMTlwinson@bbs.cpcn.com (lwin) writes:
Today's system is the third step of a planned dramatic increase in
computing power. The large systems are not the end but the means to
drive extremely complex computer simulations. ASCI's goal is to
develop the capability to simulate nuclear weapons' behavior to ensure
their safety and reliability over the long term. This requires the
ability to calculate what happens to billions of data points in small
fractions of a second. The 10 TeraOps supercomputer at Livermore will
consist of more than 8,000 of IBM's newest and fastest RS/6000
processors. Future plans call for acquisition of a 30 and a 100
TeraOps system.
........................
they mention 512 cabinets, which at 16 power3/cabinet = 8192 nodes
from:
http://www.cineca.it/resources/sp3/index.html
https://web.archive.org/web/20001021050132/http://www.cineca.it/resources/sp3/index.html
http://www.epcc.ed.ac.uk/direct/newsletter5/node11.html
https://web.archive.org/web/20000823134548/http://www.epcc.ed.ac.uk/direct/newsletter5/node11.html
800mflops peak per 200mhz power3 for 8192 cpus gives about 6.5tflop
announcement for 144 node / 1,152 375MHZ Power3-II chips:
http://www8.zdnet.com/eweek/stories/general/0,11011,2435011,00.html
just using simple scaling of Mhz (375/200)800mflops gives 1.5gflops times 8192 nodes 12.2tflops ... which possibly yieds the statement regarding 10 teraops?
misc asci refs:
http://www.llnl.gov/asci/
https://web.archive.org/web/20000815204903/http://www.llnl.gov/asci/
http://www.ibm.com/ibm/publicaffairs/gp/asci.html
http://www.rs6000.ibm.com/resource/features/1998/asci_oct/asci_fact.html
http://www.rs6000.ibm.com/resource/features/1998/asci_oct/
misc sp1/sp2 refs:
http://www.rs6000.ibm.com/software/sp_products/pssp.html
http://www.rs6000.ibm.com/resource/pressreleases/1999/May/sp_trillionpr.html
http://www.rs6000.ibm.com/hardware/largescale/
http://clumber.tc.cornell.edu/HyperNews/get/OtherSites.html
https://web.archive.org/web/20001205063400/http://clumber.tc.cornell.edu/HyperNews/get/OtherSites.html
http://www.mhpcc.edu/doc/faq/performance_prog.html
https://web.archive.org/web/20010119114200/http://www.mhpcc.edu/doc/faq/performance_prog.html
http://alpha.mhpcc.edu/mhpcc/mhpcc/WW155.html
https://web.archive.org/web/20010226094027/http://alpha.mhpcc.edu/mhpcc/mhpcc/WW155.html
http://www.mhpcc.edu/general/images/machines.jpg
https://web.archive.org/web/20010607215753/http://www.mhpcc.edu/general/images/machines.jpg
http://www.arc.unm.edu/Workshop/libraries/pmatlib/overview.html
https://web.archive.org/web/20000823134543/http://www.arc.unm.edu/Workshop/libraries/pmatlib/overview.html
http://pipeline.mhpcc.edu/research/ab96/ab47.html
https://web.archive.org/web/20010803043825/http://pipeline.mhpcc.edu/research/ab96/ab47.html
http://www-jics.cs.utk.edu/sp2guide/SP2_guideMay96/SP2_guideMay96.html
https://web.archive.org/web/20010228075932/http://www-jics.cs.utk.edu/sp2guide/SP2_guideMay96/SP2_guideMay96.html
http://web.eecs.utk.edu/~liang/pjct460/nhse2/7.html
some other info:
http://www.performance-computing.com/features/99091.shtml
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM's "ASCI White" and "Big Blue" architecture? Newsgroups: alt.folklore.computers Date: Thu, 13 Jul 2000 06:11:30 GMT... and some SP2 switch references ....
misc. other references ...
http://csep1.phy.ornl.gov/CSEP/SP2/SP2.html
https://web.archive.org/web/20011114100943/http://csep1.phy.ornl.gov/CSEP/SP2/SP2.html
http://www.lysator.liu.se/~oscar/sp2/
http://www.research.ibm.com/journal/sj/agerw/agerw.html
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Share - lodging (MTA) Newsgroups: bit.listserv.ibm-main Date: Thu, 13 Jul 2000 23:43:56 GMTefinnell@SEEBECK.UA.EDU (Edward J. Finnell, III , Ed) writes:
(To the dune of "Everglades" and "The MTA", and with apologies to the
Kingston Trio, which does not necessarily include IBM.)
(sparkling guitar intro)
I was born and raised around Poughkeepsie,
A programmer is what I had to be;
But IBM and its programming team
Have turned me into a debugging machine.
Running all my jobs under MVT.
Where a job can run and never be found,
And all you see are discs goin' 'round;
And when you get your output the results are nil:
If the JCL don't get you then the systems will.
I put my job in the input queue.
And watched in awe as the system blew.
When I reran the job, I felt really crushed;
I saw on my listing: INPUT STREAM DATA FLUSHED.
Running all my jobs under MVT.
CHORUS
I reran the job and ran out of space;
I reran the job with a step out of place;
I reran the job with priority 10 ... (pause)
"Will it ever return, no, it'll never return,
And its fate is still unlearned,
It may hide forever in SYS1.LINKLIB..."
(pause)
Running all my jobs under MVT.
CHORUS
Well, I couldn't get a job past the JCL hump,
So I never got a chance to read an ABEND dump,
If I could get one through, I'd have debugging fun,
'Cause the job was in the language known as PL/I.
CHORUS
Getting lots of grief from this MVT.
Running like a thief 'way from MVT.
Getting round this mess via DOS.
(rousing guitar finale)
--
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Definition of SHARE & SCIDS Requested Newsgroups: bit.listserv.ibm-main Date: Fri, 14 Jul 2000 04:16:37 GMTSteve Samson writes:
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Definition of SHARE & SCIDS Requested Newsgroups: bit.listserv.ibm-main Date: Fri, 14 Jul 2000 19:17:19 GMTAnne & Lynn Wheeler writes:
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: 4341 was "Is a VAX a mainframe?" Newsgroups: alt.folklore.computers Date: Fri, 14 Jul 2000 21:35:45 GMTAnne & Lynn Wheeler writes:
The other factor was that the 4341 channels were "faster" than the 303x channel directors.
The 3330 disk drives were typically access with count-key-data CCW sequence consisting of seek, search id-equal, tic-8, read/write . For paging and 4kblock file access the tracks were formated with 4k-byte blocks with dummy blocks inserted between the data blocks. The 3330 track had enuf room for three 4k data blocks plus 101-byte dummy blocks.
The 3330 had 19 tracks per "cylinder" (or arm position). It was possible to block "chain" transfer requests by inserting "tic" (channel program branch requests) from the end of one block transfer (read/write) to the start of the next seek request.
The mainframe transfer process has the CCWs located in main memory with the channel "fetching" a copy of the next CCW after the previous CCW had completed. The channel then passes the CCW to the control unit which decodes the operation and sends the appropriate request to the device (disk drive).
The 3330 specification called for a minimum of 110-byte "dummy" blocks in order to successfully perform a head switch and read the next record on a different track (and not incure a rotational "miss" ... i.e. the search id-equal CCW is processed after the start of the next data block). The 110-byte "dummy" block has the 3330 drive rotating while the channel is processing the tic (to the next request) CCW and the following SEEK CCW (select different head/track on the same cylinder; no actual arm motion is required).
145 (and 4341) channels were able to process the sequence (tic to next block of CCWs and seek) 100% when a 3330 was formated 101-byte dummy blocks ... and successfully transfer the next data block on a different track (w/o requiring an additional rotational delay) ... i.e. the search request for the next record ... got to the disk device before the start of data record had rotated past the head (if the start of record rotates past the head ... then the disk rotates around until the desired record comes to the head again).
158 channels would only successfully do the head switch and transfer 20%-30% of the time (70%-80% of the time, the selection would "miss" and the 3330 did an additional rotation).
All the 303x channel directors were essentially 158 channels in a different package. They tried to compensate for the problem by allowing the 303x channel director to perform limited CCW "prefetch". The mainframe channel CCW processing was defined as synchronous, sequential process ... which allowd a previous CCW to do data transfer and modify the following CCW. Any sort of prefetch would have watch carefully for CCWs being modified after the prefetch.
In any case, even with the 303x channel directors doing limited prefetch, attempting to do the head switch & read next record on any of the 3031, 3032, or 3033 models would result in 70%-80% rotational miss (the same characteristic as on the 158).
The latency problem in processing is similar but different to the increase CCW processing latency introduced in the 3830->3880 transition.
Another problem we saw on the 158 was with fixed-head disks (2505 paging "drums"). It was possible to organizing operations for 4k transfers with head-switch between record transfers ... in much the same way as with 3330s ... except in this case ... there was never any arm motion since every track on the device also had a read/write head. We had a 158 configuration with 2305 controller on the end of a 15' cable and everything worked fine. One weekend they re-organized the machine room and the 2305 controller was placed on a 75' cable (within max. specification) and performance on monday went thru the floor. It turns out that things were right at the border line and the it was starting to miss on every head switch.
Back to the 303x/4341 saga ... there was a rumor at the time that the executive responsible for 303xs attempted to address the opportunity by getting the chip fabrication plant to cut the allocation to the 4341 group by 50%.
misc. ref:
https://www.garlic.com/~lynn/95.html#8
https://www.garlic.com/~lynn/99.html#6
https://www.garlic.com/~lynn/99.html#74
https://www.garlic.com/~lynn/99.html#75
https://www.garlic.com/~lynn/99.html#209
https://www.garlic.com/~lynn/2000b.html#38
https://www.garlic.com/~lynn/2000c.html#34
https://www.garlic.com/~lynn/2000c.html#75
https://www.garlic.com/~lynn/2000c.html#76
https://www.garlic.com/~lynn/2000c.html#83
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM's "ASCI White" and "Big Blue" architecture? Newsgroups: alt.folklore.computers Date: Fri, 14 Jul 2000 21:56:32 GMTAnne & Lynn Wheeler writes:
misc. ref:
https://www.garlic.com/~lynn/2000c.html#61
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 4341 was "Is a VAX a mainframe?" Newsgroups: alt.folklore.computers Date: Sat, 15 Jul 2000 00:23:02 GMTTerry Kennedy writes:
Putting the buffer back in the controller would have also required 19 parallel data paths between each device and the controller (or a data path that ran something like 20 the head transfer rate). For a string of 32 devices ... it would have to handle something like 3220(3330 head transfer rate) ... 640(3330 head transfer rate). When I looked at the problem for high speed disk transfer ... (actually being able to transfer data in parallel on multiple heads) there was also some problem with the head positioning servo feedback loop.
Things got even more complex with "string switch". It was possible to
connect a string of devices to two different controllers ... and each
controller to hook to four different channels ... allowing access to any
specific device from up to eight different processor complexes ... an
example was:
https://www.garlic.com/~lynn/2000c.html#30
the above involved two processors per complex (total of 16 processors in the single system image complex accessing a couple hundred disks).
there were other 8-way disk configurations ... but they were single
processor operations (in fact, because the software .. PARS/ACP/TPF
lacked multiprocessor support was the reason that the single processor
3083 came out ... the 3081 originally was only going to be two
processor ... with the 3084 as a pair of 3081 for four processors)
... misc. ref:
https://www.garlic.com/~lynn/99.html#100
https://www.garlic.com/~lynn/99.html#136a
https://www.garlic.com/~lynn/2000.html#0
https://www.garlic.com/~lynn/2000.html#31
https://www.garlic.com/~lynn/2000.html#61
in any case ... string switch & track buffers in the controller would have required the track read ahead be propagated to buffers in both controllers.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 4341 was "Is a VAX a mainframe?" Newsgroups: alt.folklore.computers Date: Sat, 15 Jul 2000 00:30:26 GMTTerry Kennedy writes:
ref:
https://www.garlic.com/~lynn/2000c.html#68
the design had high-speed queued i/o where the disk controller had some latitude in dynamically choosen what requests to serve next ... based in part on having access to near real-time input as to rotation position.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 4341 was "Is a VAX a mainframe?" Newsgroups: alt.folklore.computers Date: Sat, 15 Jul 2000 04:01:01 GMTTerry Kennedy writes:
However, singleton page transfers were the ones that really exhibited the problem. I had also done prepaging ... for multiple page transfers... and a lot went into the file system logic to also do block transfers ... so things tended to be much more contiguous transfers (with head switches tending to occur between end of track and start of track) ... even tho everything was passing thru the same low-level page i/o logic.
there was also the idea of doing load balancing across all drives ... potentially getting a little bit of single page tranfer space allocation, multi-page transfer space allocation, file system allocation and misc. other system usage on every drive ("spool", aka unit record & networking temp space also used same disk format & low level i/o queuing routines ... and it was even possible to mix page "overflow" in spooling areas) according to usage & load pattern.
page access file system ref
https://www.garlic.com/~lynn/93.html#31
paging, spooling, page access file system ref
https://www.garlic.com/~lynn/2000.html#75
https://www.garlic.com/~lynn/2000b.html#43
we actually did some more detailed investigation on the load balancing, track buffering and caching that involved detailed record activity traces for production systems (there may have even been a patent or two regarding being able to reduce trace information in real time and do various types of system re-organizations on the fly).
Two notable projects involved looking at 1) large system configurations movement from 3330 drives to 3380 drives and 2) optimal use of memory chips for caches.
For the first use ... the detailed traces should a variety of activities: relatively uniform activity, very low level sporadic activity, and very high level, but bursty activity (some occurring daily, some occurring weekly, and some occurring monthly ... with little or not activity inbetween bursts). It was possible in the migration from 3330 to 3380 to re-org relatively statically allocated high activity and low activity for load balancing across all 3380 drives and at the same time to order placement within 3380 to minimize arm travel (tending to allocate from middle of the disk in bands out towards the edges). The analysis also showed that to maintain the same level of service (access rate/per megabyte of data/per second) on the 3380s as on the 3330s ... only something like 3/4 of the 3380 would contain usable data (i.e. while 3380 thruput improvement increased over the 3330, the amount of data stored on 3380 increased by a larger factor than the improvement in thruput ... filling a 3380 completely full with 3330 data resulted in lower access rate per megabyte of data per second).
misc. refs:
https://www.garlic.com/~lynn/93.html#31
https://www.garlic.com/~lynn/95.html#8
https://www.garlic.com/~lynn/99.html#6
the other use of the detailed trace data was for I/O cache modeling. Various configurations of caches were modeled for head, arm, device, controller, channel, channel group, and system. Except for full track buffer for handling particular kind of rotational miss, the models alwas showed that allocation of memory chips for caching at the system level was alwas the most efficient use of the chips. This is basically the same as the local LRU vis-a-vis global LRU argument. On the average, over all sorts of activity, it is more efficient to manage the information at the highest level than at a low level fragmented level.
The exception is for arm motion plus transfer operations. When the arm is in motion, rotational positioning information was lost. It was therefor possible to arrive at the designated arm position just after the desired record had passed under the head. If there was a full track buffer that could immediately start reading the requested track as soon as the head was synchronized ... then it was potentially possible to catch most of the desired record in cache and only have to read a few dribbles on the subsequent revolution. In part, this was possible since the seek CCW specified both the cylinder and track/head in the same operation ... so the disk knew the desired track before the arm was in position and the head had synchronized for data transfer.
The problem with global LRU caches, in a multiprogramming or multitasking environment is that misbehaving operations can "run-over" the data of well behaved operations. As a result, global LRU caches need some method for fencing off ill-behaved operations. Other than that, with all other things being equal, a global LRU strategy outperforms local LRU strategies. It then follows that using memory chips for caching at a global level is more efficient than the same number of chips distributed across local devices (full track caching isn't a "use the data again" cache ... but instead mask disk rotational latency operational caracteristics).
misc. cache/lru refs:
https://www.garlic.com/~lynn/93.html#0
https://www.garlic.com/~lynn/94.html#1
https://www.garlic.com/~lynn/94.html#14
https://www.garlic.com/~lynn/94.html#20
https://www.garlic.com/~lynn/94.html#46
https://www.garlic.com/~lynn/94.html#49
https://www.garlic.com/~lynn/94.html#51
https://www.garlic.com/~lynn/94.html#54
https://www.garlic.com/~lynn/96.html#0a
https://www.garlic.com/~lynn/96.html#0b
https://www.garlic.com/~lynn/96.html#10
https://www.garlic.com/~lynn/96.html#11
https://www.garlic.com/~lynn/98.html#6
https://www.garlic.com/~lynn/99.html#18
https://www.garlic.com/~lynn/99.html#20
https://www.garlic.com/~lynn/99.html#104
https://www.garlic.com/~lynn/99.html#237
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 4341 was "Is a VAX a mainframe?" Newsgroups: alt.folklore.computers Date: Sat, 15 Jul 2000 17:19:25 GMTAnne & Lynn Wheeler writes:
the 158 with its inboard integrated channels missed the head-switch 70-80% of the time because of timing issues in the 158 integrated channels and the (outboard) 303x channel directors had the same characteristic.
the 303x channel director was effectively a 158 somewhat repackaged w/o the microcode support for 370 instruction set. The 158 & a channel director supported up to six channels. To get sixteen channels on a 3033 required three channel directors (two directors configured with six channels and one director configured with four channels).
misc. other channel timing issue:
https://www.garlic.com/~lynn/2000c.html#65
in the above ref; to->no
removed from directly attachment to the real 370 channels ... the thruput of the overall mainframe system increased by approx. 10% (in addition to showing no measurable degradation in system response). It
i.e. no measurable degradation in system response.
refs to system response studies that were used to justify hyperchannel
& local 3270s for the IMS group (as opposed to remote 3270s which
drove response up to second).
https://www.garlic.com/~lynn/2000c.html#64
https://www.garlic.com/~lynn/2000c.html#66
i recently ran across a reference that evaluated original 3278 against 3277. a big complaint was with a dense screen rewrite of 3278 (even at 24x80) ... took one second before screen phospher persistance cleared.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 4341 was "Is a VAX a mainframe?" Newsgroups: alt.folklore.computers Date: Tue, 18 Jul 2000 11:55:54 GMTTerry Kennedy writes:
the -11 violated the global LRU ... since it was partitioned (if there were multiple 3880-11 in a configuration). It also suffered from a boundary condition problem. a standard ironwood configuration was a 16mbyte mainframe with one or two 3880-11 controllers.
The normal algorithm would fault on a page and then read it into main memory from 3380 ... as it was coming in off disk a copy would be left in the 3880-11. Eventually main memory would fill up with pages. At this point there are nearly 16mbytes of virtual pages in main memory and the same 16mbytes of virtual pages in 3880-11 cache (assuming some randomness about page allocation across two controllers).
At this point the next page fault would have to replace something in main memory and read the replacement off of disk. Since there was a high probability that every page in real memory was also in the disk cache (since it had been read thru the disk cache into main computer memory) ... the converse is also true ... there was a high probabilty that every page not in real memory is also not in disk cache (because the disk cache was about the same size or smaller than main memory, used similar LRU algorithms for management ... and a copy placed in real memory was also placed in disk cache).
That was where "no-dup" came in ... for this type of configuration ... for the cache to be effective ... needed to switch from a duplicate algorithm (i.e. pages in real memory were also in cache) to a no-dup algorithm (pages in real memory were not in cache). For ironwood it was possible to use a different CCW and the read would eliminate any copy that was in cache (and/or not place a new copy in cache if it had to read from disk). In this sort of boundary condition, a "no-dup" algorithm eliminated the problem where every page in main memory had also filled up the cache ... so there was very low probability that a page not in main memory would actually be in the cache (since the cache was full off pages also in main memory).
misc. dup/no-dup refs:
https://www.garlic.com/~lynn/93.html#12
https://www.garlic.com/~lynn/93.html#13
https://www.garlic.com/~lynn/94.html#9
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: FW: RS6000 vs IBM Mainframe Newsgroups: bit.listserv.ibm-main Date: Sat, 22 Jul 2000 02:51:21 GMTrhawkins@SINGNET.COM.SG (Ron & Jenny Hawkins) writes:
random refs:
https://www.garlic.com/~lynn/2000c.html#56
https://www.garlic.com/~lynn/2000c.html#68
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: APL version in IBM 5100 (Was: Resurrecting the IBM 1130) Newsgroups: alt.folklore.computers Date: Mon, 24 Jul 2000 13:58:47 GMTCharles Richmond writes:
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The author Ronda Hauben fights for our freedom. Newsgroups: soc.rights.human,comp.protocols.tcp-ip.domains,comp.society.futures,k12.ed.comp.literacy,alt.folklore.computers Date: Mon, 24 Jul 2000 14:05:06 GMTBernie Cosell writes:
NSF did provide funding for nsfnet portion of the backbone ... but there were significant other contributors to the backbone ... larger than that provided by NSF ... and the success of the current internet was much more based on the lack of restrictions for those other portions of the backbone ... than the nsfnet portion of the backbone with its various restrictions.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Where's all the VMers? Newsgroups: bit.listserv.ibm-main Date: Thu, 27 Jul 2000 05:35:12 GMTFrank Clarke writes:
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: S/360 development burnout? Newsgroups: alt.folklore.computers Date: Sat, 29 Jul 2000 10:54:33 GMTWilliam Lynch writes:
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Comrade Ronda vs. the Capitalist Netmongers Newsgroups: alt.folklore.computers Date: Sat, 29 Jul 2000 11:10:32 GMT"Jack Peacock" writes:
i also remember doing some work in the mid-80s in conjunction with large telescope development project (today possibly the largest land-based astronomy telescopes & university related) for remote viewing. they had a very strong policy of never accepting NSF money because of the related gov. problems & restrictions that would be introduced. they had a concerted program to obtain private funding only.
misc. refs:
https://www.garlic.com/~lynn/internet.htm
https://www.garlic.com/~lynn/2000c.html#26
https://www.garlic.com/~lynn/2000c.html#27
https://www.garlic.com/~lynn/2000c.html#28
https://www.garlic.com/~lynn/2000c.html#29
https://www.garlic.com/~lynn/2000c.html#30
https://www.garlic.com/~lynn/2000c.html#31
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: S/360 development burnout? Newsgroups: alt.folklore.computers Date: Sun, 30 Jul 2000 14:12:12 GMTTerry Kennedy writes:
115/125, 135, 138, 4331, & 4361 were boeblingen germany machines
&
145, 148, 4341, 4381 were endicott ny machines
(although both lines of machines were manufactured in both countries)
various other pieces of either machines may have been designed in other places (I don't know).
I worked with various people in endicott on the microcode accelerators on 148 ... which was also made available on other machines.
misc. refs:
https://www.garlic.com/~lynn/94.html#21
https://www.garlic.com/~lynn/2000c.html#50
https://www.garlic.com/~lynn/2000c.html#76
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: S/360 development burnout? Newsgroups: alt.folklore.computers Date: Tue, 01 Aug 2000 02:38:40 GMTwell pok did 165/168 ... and kingston did 155/158
then there was 3031, 3032, & 3033 (3031 & 3032 were sort of 158s & 168s with channel director) ... 3033 was sorta 168 mapped to new chip technology and then some enhancements. channel director for 303xs was 158 integrated channel w/o 370 instruction set.
then 811/308x ... was kingston (158) technology for next generation
then trout1.5/3090 ... was pok (3033) technology for next generation.
kingston technology tended to be closer to the knee of the price/performance curve.
pok technology tended to be further away from the knee of the curve going more for straight performance.
random refs:
https://www.garlic.com/~lynn/93.html#14
https://www.garlic.com/~lynn/95.html#3
https://www.garlic.com/~lynn/97.html#20
https://www.garlic.com/~lynn/98.html#34
https://www.garlic.com/~lynn/98.html#50
https://www.garlic.com/~lynn/99.html#7
https://www.garlic.com/~lynn/99.html#61
https://www.garlic.com/~lynn/99.html#74
https://www.garlic.com/~lynn/99.html#103
https://www.garlic.com/~lynn/99.html#108
https://www.garlic.com/~lynn/99.html#181
https://www.garlic.com/~lynn/99.html#187
https://www.garlic.com/~lynn/99.html#190
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM promotional items? Newsgroups: alt.folklore.computers Date: Tue, 01 Aug 2000 12:22:23 GMTNed Holbrook writes:
i've had some really great mugs disappear off my desk at work ... and not to be found anywhere in the building. it got so i stopped bringing really good mugs to work.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: S/360 development burnout? Newsgroups: alt.folklore.computers Date: Thu, 03 Aug 2000 03:51:03 GMTjata@aepiax.net (Julian Thomas) writes:
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Superduper computers--why RISC not 390? Newsgroups: alt.folklore.computers Date: Fri, 04 Aug 2000 12:33:13 GMTIn article <8maju6$85l@netaxs.com>, lwin wrote:
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Superduper computers--why RISC not 390? Newsgroups: alt.folklore.computers Date: Sat, 05 Aug 2000 16:38:39 GMTjmfbahciv writes:
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Superduper computers--why RISC not 390? Newsgroups: alt.folklore.computers Date: Sat, 05 Aug 2000 19:01:45 GMTglass2 writes:
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Superduper computers--why RISC not 390? Newsgroups: alt.folklore.computers Date: Sat, 05 Aug 2000 19:05:57 GMTeugene@cse.ucsc.edu (Eugene Miya) writes:
the decision was made to not to provide the funding.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: RS/6000 vs. System/390 architecture? Newsgroups: comp.sys.super,comp.arch Date: Sun, 06 Aug 2000 17:54:03 GMTnmm1@cus.cam.ac.uk (Nick Maclaren) writes:
some of the trade-offs were enhanced smarts in compiler and binder (some belief that there had been technology advances that would support such trade-offs). early 801 targets even had single protection domain and that compile and bind/load could perform various verification checks to assure integrity w/o requiring runtime protection (one specially was inline application software could directly swap address-space access registers as easily as it could change address registers ... thus compensating for small number of virtual address space objects ... all of this w/o incurring the overhead of kernel calls to maintain permissions).
RISC still seems to have objective of optimizing priace/performance including use of hardware/software trade-offs ... although advances in circuits per chip have shifted where some of those trade-offs are made.
random refs:
https://www.garlic.com/~lynn/2000.html#16
https://www.garlic.com/~lynn/2000.html#59
https://www.garlic.com/~lynn/2000b.html#54
https://www.garlic.com/~lynn/2000c.html#3
https://www.garlic.com/~lynn/2000c.html#4
https://www.garlic.com/~lynn/2000c.html#6
https://www.garlic.com/~lynn/2000c.html#9
https://www.garlic.com/~lynn/2000d.html#24
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Secure Operating Systems Newsgroups: sci.crypt Date: Sun, 06 Aug 2000 18:02:03 GMTmacckone@aol.comnjunk123 (Mack) writes:
in other situations the security perimeter and policies are supposed to be implemented and maintained by the computer, its operating system and applications.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Secure Operating Systems Newsgroups: sci.crypt Date: Mon, 07 Aug 2000 02:20:35 GMTEric Lee Green writes:
Note however, IBM also developed TSS/360 for the 360/67 and early versions had about the same response characteristics for four users as you mentioned for early multics with eight users.
vm/370 on 370/168 in the mid-70s would typically support several hundred users.
vm/370s implementation of isolation resulted in it be used in a large number of high security installations.
random refs:
https://www.garlic.com/~lynn/2000.html#1
https://www.garlic.com/~lynn/2000.html#81
https://www.garlic.com/~lynn/2000b.html#77
https://www.garlic.com/~lynn/2000c.html#27
https://www.garlic.com/~lynn/2000c.html#30
multics home page
https://www.multicians.org/
see site histories section in the above
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: RS/6000 vs. System/390 architecture? Newsgroups: comp.sys.super,comp.arch Date: Mon, 07 Aug 2000 15:27:24 GMTnmm1@cus.cam.ac.uk (Nick Maclaren) writes:
I argued in the '70s about the protection domain trade-off and the small number of virtual address objects. The reply was a combination of compiler, loader/binder, and new "closed" operating system targeted for small single task/user environments. The ancilliary discussion about reduced instruction count/complexity to fit in small silicon foot-print.
In the late '80s the discussion revolved around not supporting cache consistency for multiple processor applications and simple single cycle instructions ... which would also somewhat simplify the job of the compiler in achieving hardware/software trade-offs. Even tho we had done a lot of SMP work ... the lack of availability of cache consistency was one of the things that forced my wife and I into doing cluster-based work with the chips (as opposed to variouus SMP things).
The 801 people seemed to feel very strongly about it at the time ... at least in the discussions i participated in.
misc. refs:
https://www.garlic.com/~lynn/95.html#5
https://www.garlic.com/~lynn/2000c.html#4
https://www.garlic.com/~lynn/2000c.html#21
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: S/360 development burnout? Newsgroups: alt.folklore.computers Date: Mon, 07 Aug 2000 16:03:36 GMTAnne & Lynn Wheeler writes:
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Adventure Games (Was: Navy orders supercomputer) Newsgroups: alt.folklore.computers Date: Wed, 09 Aug 2000 14:44:22 GMTCharles Richmond writes:
misc. ref:
https://www.garlic.com/~lynn/99.html#52
https://www.garlic.com/~lynn/99.html#83
https://www.garlic.com/~lynn/99.html#84
https://www.garlic.com/~lynn/99.html#169
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Assembly language formatting on IBM systems Newsgroups: alt.sys.pdp10,alt.folklore.computers Date: Wed, 09 Aug 2000 15:00:10 GMTmy sophomore year at wsu ... i got hired to write a 360 version of a 1401 "MPIO" that did the front-end tape<->reader/punch/printer for 709.
it was eventually 2000 cards ... maybe 1600 assembler statements. it took 30 minutes to assemble on 64kbyte 360m30 under ospcp6 ... using my own monitor, interrupt handler, input/output supervisor, storage allocation, etc.
version down with os supervisor services (dcb macros, get/put, etc) took over an hour to assemble. in the supervisor services version ... there were five DCB macros ... and you could tell by the flashing lite pattern when the assembler hit a DCB macro ... which took six minutes elapsed time per DCB macro (56 - 30 minutes just for five dcb macros).
somebody told me later that the person doing the mnemonic lookup (assembler code to instruction) had been given a spec that said they only had 256bytes to implement the lookup. Since the mnemonic codes & the code wouldn't fit in 256bytes ... the table went out on disk ... and every mnemonic decode required disk accesses.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: S/360 development burnout? Newsgroups: alt.folklore.computers Date: Wed, 09 Aug 2000 15:03:55 GMTjata@aepiax.net (Julian Thomas) writes:
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Assembly language formatting on IBM systems Newsgroups: alt.sys.pdp10,alt.folklore.computers Date: Thu, 10 Aug 2000 14:08:32 GMTjcmorris@jmorris-pc.MITRE.ORG (Joe Morris) writes:
the thing it didn't do well was handle csect/dsect information. I found later when working on a detailed analysis of TSS code structure vis-a-vis VM/370 code structure ... that one of the things the TSS assembler spit-out was the csect/dsect number for each storage reference (i.e. start of listing somewhere had the csect & dsect names mapped to an "ID" ... and each displacement field on the left-side of the listing had the csect/dsect ID prefixing the storage displacement. For dsects ... it allowed generation of variable names with structure qualifiers in an unambiguous manner.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: S/360 development burnout? Newsgroups: alt.folklore.computers Date: Fri, 11 Aug 2000 15:39:31 GMTEric Fischer writes:
random piece of info ... jean worked at ibm boston programming center (also in 545 tech sq, with cambridge science center, multics etc). BPC produced an online pli-based interactive product that ran under os/360 (somewhat akin to the original apl/360 ... but pli instead of apl). BPC was eventually shutdown and some number of the people attached/housed with CSC.
I would sometimes bring my kids in when i stopped by work on weekends ... frequently jean was the only other person at the offices on the weekend ... and she would come looking for me to complain about the kids because they were yelling & laughing chasing each other up & down the halls
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: S/360 development burnout? Newsgroups: alt.folklore.computers Date: Sat, 12 Aug 2000 22:38:11 GMTjata@aepiax.net (Julian Thomas) writes:
henry went on to kingston to work on hippi tied into the page store
bus.
Were those the days when Andy Heller periodically blew into town?
possibly ... but it was before I spent much of any time with andy.
it was period around some kind of memos ... i think starting with a T?
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Future hacks [was Re: RS/6000 ] Newsgroups: comp.arch Date: Mon, 14 Aug 2000 15:02:01 GMTKetil Z Malde writes:
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 360 CPU meters (was Re: Early IBM-PC sales proj.. Newsgroups: alt.folklore.computers,comp.sys.ibm.pc.hardware.systems Date: Mon, 21 Aug 2000 17:55:35 GMTjata@aepiax.net (Julian Thomas) writes:
getting the cpu meter to stop running when nobody was using the system ... but the system was still available for use was important part of being able to offer 24x7 time-sharing services.
also, i noticed that there was some software versions that put in
timer-interrupts to wake-up at regular sub-second intervals
... approx. what the meter coasting interval was
https://www.garlic.com/~lynn/99.html#86
when we were doing the first 360 plug-compatible control unit ... we
ran into a problem with the location 80 timer (on the '67) when we
held the cpu bus for too long a period
https://www.garlic.com/~lynn/93.html#16
https://www.garlic.com/~lynn/96.html#30
random refs:
https://www.garlic.com/~lynn/93.html#31
https://www.garlic.com/~lynn/94.html#15
https://www.garlic.com/~lynn/97.html#7
https://www.garlic.com/~lynn/99.html#76
https://www.garlic.com/~lynn/99.html#195
https://www.garlic.com/~lynn/2000.html#81
https://www.garlic.com/~lynn/2000b.html#61
https://www.garlic.com/~lynn/2000c.html#48
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: TCP/IP Suite of Protocols - dumb question ... Newsgroups: comp.protocols.tcp-ip Date: Mon, 21 Aug 2000 18:52:29 GMTgibboncore writes:
random references:
https://www.garlic.com/~lynn/internet.htm
https://www.garlic.com/~lynn/rfcietff.htm
https://www.garlic.com/~lynn/2000b.html#0
https://www.garlic.com/~lynn/2000b.html#1
https://www.garlic.com/~lynn/2000b.html#6
https://www.garlic.com/~lynn/2000b.html#9
https://www.garlic.com/~lynn/2000c.html#26
https://www.garlic.com/~lynn/2000c.html#27
https://www.garlic.com/~lynn/2000d.html#16
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 360 CPU meters (was Re: Early IBM-PC sales proj.. Newsgroups: alt.folklore.computers,comp.sys.ibm.pc.hardware.systems Date: Mon, 21 Aug 2000 19:31:48 GMTmostly offtopic, very slightly related ... mailing list discussion related to redefining UTC (specifically with respect to leap seconds):
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Al Gore: Inventing the Internet... Newsgroups: alt.folklore.military Date: 21 Aug 2000 16:19:05 -0700juergen.nieveler@web.de (Juergen Nieveler) writes:
US gov. (presumably all agencies) was pushing/specifying GOSIP in the
late 80s & early 90s, i.e. specifically not internet and specifically
not tcp/ip; in fact, to some extent the internet triumphed despite
specific government dictates specifying non-internet &
non-tcpip. misc. ("gosip", which was/is not! internet & not! tcp/ip)
refs:
https://www.garlic.com/~lynn/2000b.html#0
https://www.garlic.com/~lynn/2000b.html#1
https://www.garlic.com/~lynn/2000b.html#4
https://www.garlic.com/~lynn/2000b.html#5
https://www.garlic.com/~lynn/2000b.html#10
https://www.garlic.com/~lynn/2000d.html#19
misc. Postel reference
http://wwwvms.utexas.edu/~glen/postel/
https://web.archive.org/web/20020202134046/http://wwwvms.utexas.edu/~glen/postel/
some discussions on arpanet, nsfnet, internet, etc:
https://www.garlic.com/~lynn/internet.htm
references on the internal network being larger than the
arpa/nsf/inter up until the mid-80s
https://www.garlic.com/~lynn/2000c.html#29
random other refs:
https://www.garlic.com/~lynn/99.html#33
https://www.garlic.com/~lynn/99.html#39
https://www.garlic.com/~lynn/99.html#112
https://www.garlic.com/~lynn/2000c.html#30
https://www.garlic.com/~lynn/2000c.html#31
discussion of some of the networking activities going on about same
time as nsfnet & early "internet"
https://www.garlic.com/~lynn/2000c.html#26
other misc. refs:
https://www.garlic.com/~lynn/rfcietff.htm
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Charging for time-share CPU time Newsgroups: alt.folklore.computers Date: Tue, 22 Aug 2000 13:47:27 GMTLars Poulsen writes:
following reference
https://www.garlic.com/~lynn/94.html#18
I had built an MFT (w/hasp) that got it down from about 30 seconds to 12.9 seconds elapsed time.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Charging for time-share CPU time Newsgroups: alt.folklore.computers Date: Tue, 22 Aug 2000 13:58:10 GMTLars Poulsen writes:
Before watfor & hasp, it would be on the order of minute elapsed time per student job. watfor/watfiv w/hasp system could avg. under a second elapsed time per student job ... even including the job schedule up front time ... something like a 100 improvement in thruput
misc. refs:
https://www.garlic.com/~lynn/99.html#93
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Charging for time-share CPU time Newsgroups: alt.folklore.computers Date: Wed, 23 Aug 2000 17:36:03 GMTjcmorris@jmorris-pc.MITRE.ORG (Joe Morris) writes:
when we got watfor ... the project was dropped.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Charging for time-share CPU time Newsgroups: alt.folklore.computers Date: Mon, 28 Aug 2000 02:59:28 GMTrea@bofh.org.uk (Robert Allison) writes:
Early CP/67 kernel had a number of areas that consumed excess CPU utilization. As these areas were addressed, free storage management became a major remaining factor ... frequently accounting for 20% of kernel pathlength.
Release 3 of CP/67 introduced "subpool" storage management logic. Detailed traces of the system was made and subpool logic created pools for the most common sizes (in some cases ... similar storage sizes were rounded up to the closest defined subpool size). Subpool block sizes were managed LIFO (push/pop). On allocation, a block would be allocated from the top of the list for the corresponding storage size. On de-allocation a block would be placed on the head of the list for the corresponding storage size. If block of the corresponding size wasn't on the subpool list, a block would be allocated from the standard structure.
The subpool structure started out empty ... but as blocks of stroage (of the appropriate size) were returned and made available, they would be placed in the appropriate subpool list. This required that all allocation requests (in the subpool size ranges) were rounded up to the next subpool size (in order that generally allocated blocks could be returned to subpools). There was also a cleaning/reset process that took all available blocks from all subpools and merged them back into the standard storage allocation infrastructure.
Subpool allocation could be done in 12-14 instructions and in typical system would be used for 90-95% of storage allocation requests. This reduced the storage allocation/deallocation on typical systems from 20% of kernel cpu utilization to about 2% of kernel cpu utilization.
The subpool introduction in CP/67 Release 3 negated much of the purpose of the SLT RPQ instruction ... since there was little use of extensive searching in the system.
There was a later enhancement to the subpool logic for the two-processor 3081 ... so that storage was allocated on cache lines and in cache line increments. This represented a measurable reduction in inter-cache chatter (and corresponding improvement in performance).
random refs:
https://www.garlic.com/~lynn/93.html#0
https://www.garlic.com/~lynn/93.html#4
https://www.garlic.com/~lynn/93.html#26
https://www.garlic.com/~lynn/94.html#1
https://www.garlic.com/~lynn/94.html#2
https://www.garlic.com/~lynn/94.html#4
https://www.garlic.com/~lynn/94.html#7
https://www.garlic.com/~lynn/98.html#19
https://www.leeandmelindavarian.com/Melinda#VMHist
&
Analysis of Free-storage Algorithms, B. Margolin, IBM Systems Journal 10, 283-304, 1971
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Navy orders supercomputer Newsgroups: alt.folklore.computers Date: Mon, 28 Aug 2000 04:08:30 GMT"Charlie Gibbs" writes:
One time this happened ... they had taken a "break" for dinner because something had gone wrong. While they were gone ... I did a card copy of all their stuff and started analyzing it to figure out 1) why they would need stand-alone time ... and 2) what was making things go wrong.
I figured out a way that I could do most of the system build/generation procedure with current production system ... splitting it into multiple job steps ... so that if something went wrong ... rather than restarting one 8-10 hr job ... only needed to restart a 10-20 minute job. Also figured out how to re-organize the system build process to optimize placement of datasets and members to improve system thruput.
random refs:
https://www.garlic.com/~lynn/94.html#18
https://www.garlic.com/~lynn/94.html#53
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Navy orders supercomputer Newsgroups: alt.folklore.computers Date: Mon, 28 Aug 2000 04:33:39 GMTminor addition ref regarding separation of system & application
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Navy orders supercomputer Newsgroups: alt.folklore.computers Date: Mon, 28 Aug 2000 14:28:55 GMTjmfbahciv writes:
I had started doing hand-built "in-queue" SYSGENs starting with MFT11.
I would manually break all the stage2 SYSGEN steps into individual
components, provide "JOB" cards for each step and then effectively run
the "stand-alone" stage2 SYSGEN in the standard, production job-queue.
I would also carefully reorder the steps/jobs in stage2 (as well as
reordering MOVE/COPY statements for PDS member order/placement) so as
to appropriately place data on disk for optimal disk arm-seek
performance.
In the following report, the "bare-machine" times of 12.9 sec/job was
typically over 30 seconds/job for a MFT14 built using standard
"stand-alone" SYSGEN process (effectively increase in arm-seek elapsed
time). Also, the standard OS "fix/maintenance" process involved
replacing PDS-members which resulted in destroying careful member
placement. Even with an optimally built system, "six months" of OS
maintenance would resort in performance degrading to over 20 secs/job.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Navy orders supercomputer Newsgroups: alt.folklore.computers Date: Mon, 28 Aug 2000 14:52:57 GMTAnne & Lynn Wheeler writes:
random references:
https://www.garlic.com/~lynn/93.html#0
https://www.garlic.com/~lynn/93.html#1
https://www.garlic.com/~lynn/93.html#2
https://www.garlic.com/~lynn/93.html#4
https://www.garlic.com/~lynn/93.html#5
https://www.garlic.com/~lynn/93.html#28
https://www.garlic.com/~lynn/93.html#29
https://www.garlic.com/~lynn/94.html#01
https://www.garlic.com/~lynn/94.html#0
https://www.garlic.com/~lynn/94.html#1
https://www.garlic.com/~lynn/94.html#2
https://www.garlic.com/~lynn/94.html#4
https://www.garlic.com/~lynn/94.html#5
https://www.garlic.com/~lynn/94.html#7
https://www.garlic.com/~lynn/94.html#9
https://www.garlic.com/~lynn/94.html#14
https://www.garlic.com/~lynn/94.html#15
https://www.garlic.com/~lynn/94.html#21
https://www.garlic.com/~lynn/94.html#22
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM 650 (was: Re: IBM--old computer manuals) Newsgroups: alt.folklore.computers Date: 30 Aug 2000 16:26:35 -0600ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) writes:
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM 650 (was: Re: IBM--old computer manuals) Newsgroups: alt.folklore.computers Date: 30 Aug 2000 16:53:45 -0600jsaum@world.std.com (Jim Saum) writes:
normally there was a one-to-one mapping between a physical device and a i/o address.
Doing one i/o operation at a time (even on a 2305) ... between the end of one operation and the time the CPU started the next operation ... you tended to loose a half revolution. A 2305 setup for 4k pages would have three 4k pages per track where the starting position of each page/record was at the same rotational position on each track.
With RPS and (2305) multiple exposures .... it was possible to schedule requests such that the page transfer thruput of the 2305 was near media transfer speed (300 pages/sec) instead of 130 page transfer per second (because of lost rotational delay).
I had a battle to try and get multiple exposure support for the 3350 fixed-heads ... which would have allowed the 3350 to do data transfer from a fixed head track overlapped with disk arm motion (i.e. with only a single address per physical 3350 device ... it wasn't possible to initiate a new operation until the previous had finished ... and if the device was in the process of moving the arm, it wouldn't be possible to start a fixed head data transfer until the arm motion had completed).
The feature was billed as enhanced paging support ... however there was a competing project (called Vulcan) to deploy an electronic drum paging device. The Vulcan project managed to get the multiple exposuure support for 3350 killed. Along the way, there was a huge upsurge in the orders for processor memory ... so much so that it totally saturated the memory chip producing fabs' capacity ... which totally dried up availability of memory components for a vulcan product (at which point the vulcan project was disbanded but it was too late to revive 3350 multiple exposuure support)
misc. refs:
https://www.garlic.com/~lynn/99.html#8
https://www.garlic.com/~lynn/95.html#8
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: NCP Help (re (D)ARPANET) Newsgroups: comp.protocols.tcp-ip Date: 30 Aug 2000 17:09:12 -0600Art Berggreen writes:
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: NCP v TCP/IP Newsgroups: comp.protocols.tcp-ip Date: 30 Aug 2000 17:12:15 -0600from discussion on NCP v TCP/IP earlier this year:
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Is Al Gore The Father of the Internet? Newsgroups: alt.folklore.computers,talk.politics.misc,alt.os.linux Date: 04 Sep 2000 10:22:07 -0600Lars Poulsen writes:
misc. refs:
https://www.garlic.com/~lynn/internet.htm#7
https://www.garlic.com/~lynn/2000c.html#26
https://www.garlic.com/~lynn/2000d.html#43
EARN was the major educational & R&D network outside of the US at the time of NSFNET1 ... and as far as I know was all corporate funded.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: iAPX-432 (was: 36 to 32 bit transition Newsgroups: alt.folklore.computers,comp.arch Date: 04 Sep 2000 15:34:10 -0600if i remember right from a intel presentation at sigops (before it starting moving around and was at asilomar) ... one of the hardest problems they had was with the 432 having so much function in hardware ... finding bugs wasn't so bad ... but testing fixes was a real hard problem.
Eric Smith <eric-no-spam-for-me@brouhaha.com> writes:
Seriously, though, there's no reason why debugging the OS for a
capability machine is any harder than for a conventional machine.
You're looking at it the wrong way around. Rather than viewing
it as having a single wall between system and user code, view it as
having such walls at every interface between domains.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Is Al Gore The Father of the Internet? Newsgroups: alt.folklore.computers,talk.politics.misc,alt.os.linux Date: 04 Sep 2000 15:52:24 -0600Floyd Davidson writes:
CSNET (Computer Science NETwork) is funded by NSF, and is an attempt
to connect all computer science research institutions in the U.S. It
does not have a physical network of its own, but rather is a set of
common protocols used on top of the ARPANET (Department of Defense),
TeleNet (GTE), and PhoneNet (the regular phone system). The
lowest-cost entry is through PhoneNet, which only requires the
addition of a modem to an existing computer system. PhoneNet offers
only message transfer (off-line, queued, files). TeleNet and ARPANET
in allow higher-speed connections and on-line network capabilities
such as remote file lookup and transfer on-line, and remote login.
NSFNET1 backbone ... i believe was a contract for $11.2m for a faster
backbone to interconnect a number of specific locations. I've heard
rumors that the contract only covered 1/4th to 1/10th of the cost of
what corporations were actually putting into NSFNET1 to make it a
success. That was aside from all the other networks that were
deploying at the time.
random refs:
https://www.garlic.com/~lynn/internet.htm
https://www.garlic.com/~lynn/2000c.html#26
https://www.garlic.com/~lynn/2000d.html#43
https://www.garlic.com/~lynn/internet.htm#22
https://www.garlic.com/~lynn/99.html#40
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Is Al Gore The Father of the Internet? Newsgroups: alt.folklore.computers,talk.politics.misc,alt.os.linux Date: 04 Sep 2000 16:00:29 -0600Lars Poulsen writes:
in the same message there was references to other entities (in the 80s
and 90s) that used internet protocol and didn't have the same AUPs as
https://www.garlic.com/~lynn/2000c.html#26
the above reference lists some of the AUPs from the period from different networks and i've included some of the text of those AUPs.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition) Newsgroups: alt.folklore.computers,comp.arch,comp.sys.super Date: 05 Sep 2000 09:41:21 -0600"Dik T. Winter" writes:
the next time was the 801/risc was going to be used in a project called Fort Knox. Most of the low-end 360-370 processors were microcoded engines of one sort or another. Fort Knox was going to replace all of these microcoded engines with a common 801/risc engine. The 370 instruction set would then be emulated on the 801. This program was eventually canceled (although one might cliam that the current AS/400 implementation using power/pc is some sense a fort knox outcome).
There were misc. other 801/risc chip projects ... in this era most of them never shipped as product; things like blue iliad, etc.
The next 801/risc that i encountered was ROMP ... which was going to be used in an office machine, displaywriter follow-on product. This product got conceled but the project morphed into deliverying the hardware as a unix platform ... which came out as the PC/RT.
The power was the 801/RIOS chip set as a follow-on UNIX product to the PC/RT.
There has been a number of generations of 801/rios ... current i believe is power3.
Somewhat in parallel with power2 ... there began a joint project, somerset, with various other companies to produce a power/pc ... which begat 601, 603, 604, 620(?), 630, etc.
misc. refs:
https://www.garlic.com/~lynn/98.html#26
https://www.garlic.com/~lynn/2000.html#16
random refs:
https://www.garlic.com/~lynn/94.html#22
https://www.garlic.com/~lynn/94.html#47
https://www.garlic.com/~lynn/95.html#5
https://www.garlic.com/~lynn/95.html#6
https://www.garlic.com/~lynn/95.html#9
https://www.garlic.com/~lynn/95.html#11
https://www.garlic.com/~lynn/97.html#5
https://www.garlic.com/~lynn/98.html#25
https://www.garlic.com/~lynn/98.html#42
https://www.garlic.com/~lynn/99.html#64
https://www.garlic.com/~lynn/99.html#66
https://www.garlic.com/~lynn/99.html#136a
https://www.garlic.com/~lynn/2000.html#59
https://www.garlic.com/~lynn/2000b.html#54
https://www.garlic.com/~lynn/2000c.html#3
https://www.garlic.com/~lynn/2000c.html#4
https://www.garlic.com/~lynn/2000c.html#9
https://www.garlic.com/~lynn/2000c.html#12
https://www.garlic.com/~lynn/2000c.html#21
https://www.garlic.com/~lynn/2000d.html#2
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition) Newsgroups: alt.folklore.computers,comp.arch,comp.sys.super Date: 05 Sep 2000 09:52:03 -0600pontius@btv.MBI.com.invalid (Dale Pontius) writes:
3033 started out as remap of 168 design to faster chip technology ... which also had about ten times the circuit density per chip. However, the straight forward remap wouldn't have used the higher circuit density and would have only resulted in only about a 20% performance increase over the 168. Work then began on redoing selected portions of the 168 design to take advantage of intra-chip performance ... which resulted in the 3033 being nearly a 4.5-5mip machine (compared to 3.5mip or so for the 168-3).
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: iAPX-432 (was: 36 to 32 bit transition Newsgroups: alt.folklore.computers,comp.arch Date: 05 Sep 2000 10:47:23 -0600"Alan T. Bowler" writes:
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Is Al Gore The Father of the Internet? Newsgroups: alt.folklore.computers,talk.politics.misc,alt.os.linux Date: 05 Sep 2000 11:11:14 -0600seebs@plethora.net (Peter Seebach) writes:
randoms refs:
https://www.garlic.com/~lynn/2000b.html#0
https://www.garlic.com/~lynn/2000b.html#59
https://www.garlic.com/~lynn/2000d.html#16
https://www.garlic.com/~lynn/2000d.html#43
https://www.garlic.com/~lynn/internet.htm
also most of the internet growth in the 80s was the availability of LANs and the tcp/ip stack on workstations and PCs. Prior to that point, internet had been mainframes and minicomputers with point-to-point connections. The number of workstations and PCs far outnumbered the number of mainframes and minicomputers that had been the networking nodes.
random refs:
https://www.garlic.com/~lynn/99.html#38c
the internal corporate network (all mainframes) reached 1000 nodes at
least a year before the "internet":
https://www.garlic.com/~lynn/99.html#110
The internal corporate network (distinct from bitnet, earn, etc) reached 2000 nodes about the same time the "internet" reached 1000 nodes.
After that there was an explosive growth in internet nodes ... not because of the NSFNET1 backbone (which only directly interconnected a rather trivial number of nodes), but because of LANs, workstations, and PCs all showing in the internet configuration.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: "all-out" vs less aggressive designs Newsgroups: alt.folklore.computers,comp.arch,comp.sys.super Date: 05 Sep 2000 19:54:32 -0600eugene@george.arc.nasa.gov (Eugene Miya) writes:
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition) Newsgroups: alt.folklore.computers,comp.arch,comp.sys.super Date: 05 Sep 2000 20:15:06 -0600"Dik T. Winter" writes:
AIX was a port of system V version 3 done on top of the "VRM". The displaywriter group had done a lot of code in PL.8 (the original risc programming language from the 70s) and in the morph to PC/RT built something called the VRM (written in pl.8) with a virtual machine abstraction layer.
The company that had earlier done the port of system V for IBM to the IBM/PC was hired to do a similar port (using version 3) to the PC/RT ... but instead of porting to the bare hardware ... they were tasked to port to the VRM abstraction layer. That is one of the reasons that all of the AIX device drivers were non-standard.
The other offering for universities was AOS ... a port of BSD4.3 to the PC/RT.
The two systems had totally different compilers.
random refs:
https://www.garlic.com/~lynn/99.html#64
https://www.garlic.com/~lynn/99.html#65
https://www.garlic.com/~lynn/99.html#129
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: standard BASIC (was: S/360 development burnout?) Newsgroups: alt.folklore.computers Date: 06 Sep 2000 09:27:03 -0600Arargh! writes:
The IPL I/O sequence would then tic/branch to the first CCW. Frequently the first CCW was something that read additional CCWs to some location and the 2nd CCW would tic/branch to those CCWs. Eventually the sequence of CCWs would finish and the IPL sequence would load the PSW that had been read originally.
The CCW sequence would have read some set of instructions/program into some storage location. The PSW contained the various processor state information and the instruction counter/pointer.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Is Al Gore The Father of the Internet?^ Newsgroups: alt.folklore.computers,talk.politics.misc,alt.os.linux Date: 06 Sep 2000 09:46:25 -0600Floyd Davidson writes:
The development of IP was done later ... by a number of university people. While it is clear that the original work was arpa funded ... it isn't clear to what extent arpa was providing funding for the later IP work (or even the TCP work).
misc. refs:
https://www.garlic.com/~lynn/internet.htm#1
https://www.garlic.com/~lynn/internet.htm#3
https://www.garlic.com/~lynn/internet.htm#5
https://www.garlic.com/~lynn/internet.htm#6
https://www.garlic.com/~lynn/internet.htm#11
https://www.garlic.com/~lynn/internet.htm#26
https://www.garlic.com/~lynn/internet.htm#27
https://www.garlic.com/~lynn/internet.htm#28
https://www.garlic.com/~lynn/internet.htm#29
although from the following it is clear that DARPA at the time recognized the need for being able to interconnect ARPANET and the other networks.
excerpt from some 1980 email at
https://www.garlic.com/~lynn/internet.htm#31
Sunshine, Carl A., "Interconnection of computer networks,"
Computer Networks 1, North-Holland Publishing Company, 1977,
pp. 175-195.
It took some time for me to read and understand it, but I think it
was worth the effort and I recommend it. At roughly the same time
that paper was published, DARPA and their associates began work on
a specific approach for coherent interconnection of the myriad nets
surrounding ARPANET. One result of their work is a large volume of
documentation recording the design options that were taken and the
reasons for taking them. If you're interested I can send you some
of the pertinent documentation (most of which I have in soft copy),
but there's a lot of it.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: "all-out" vs less aggressive designs Newsgroups: alt.folklore.computers,comp.arch,comp.sys.super Date: 06 Sep 2000 13:26:28 -0600eugene@cse.ucsc.edu (Eugene Miya) writes:
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: "all-out" vs less aggressive designs Newsgroups: alt.folklore.computers,comp.arch,comp.sys.super Date: 06 Sep 2000 16:59:39 -0600Anne & Lynn Wheeler writes:
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: When the Internet went private Newsgroups: alt.folklore.computers,talk.politics.misc,alt.os.linux Date: 07 Sep 2000 12:50:05 -0600I think that at least some amount of NREN eventually devolved into the government going to vendors and asking them to design and build a demonstration on their own nickle.
About that time, I had just come back from giving some talks in singapore ... and a group of vendors were going over.
The singapore government had invited every vendor that participated in the US high speed networking initiative to singapore to duplicate the US installation ... the big difference (that wasn't lost on any of the vendors) was the singapore government was paying the vendors (instead of asking that it be donated for free) for all the equipment and setup. The vendors may have actually recovered enuf on the singapore initiative to not only cover that cost but the cost of participating in the US initiative as well
anyway misc. from the archives:
Subject: "Bush administration, Gore spar over U.S. gigbit net"
Source: Network World, 3/11/91, pg 6, Ellen Messemer
The congressional hearing debate was on the federal role in NREN
o the Nat'l Education and Research Network will be the Interstate of the 1990s
- to revolutionize communications like the Interstate system of roads
did for transportation
- NREN will have gigabit capacity (a billion bits/second and more)
o Allan Bromley, White House science adviser, testified last week
- government will pay for the research
- the private sector should pay for the building of it
- he asked Congress for $658M for a new computer research project
"Grand Challenges: High Performance Computing and Communications"
. $92M would be used for an NREN prototype
- Gore's proposals inappropriate because it's inflexible
. it locks in funding levels
. rapid change in technology dictate changes in plans
o Sen. Albert Gore has sponsored the High Performance Computing Act
- it calls for the gov't to fund NREN over 5 years
- he sidestepped a direct confrontation with Bromley
. his bill needs White House and bipartisan support
- but he says the administration:
. is trying to avoid Congressional participation
"<They're> saying just allocate the money and get out of the way"
. may not have the dedication to see the project through
"Irrational things could happen" to derail the program
- a 5-year program
"sends an unmistakable signal to industry of the program's seriousness"
o Bromley: although the Administration makes no promises on future funds
"I can guarantee you <we are> committed to this as an initiative"
- as much as a billion may be committed over the next 5 years
- participants in the initiative would include:
. DARPA - Defense Advanced Research Projects Agency (research)
. Department of Energy (research)
. NASA - Nat'l Aeronautics and Space Administration
. NIST - Nat'l Institute of Standards and Technology
. NIH - Nat'l Institutes of Health
. EPA - Environmental Protection Agency
o the Gore bill calls for:
- $988M over 5 years
- NSF, DARPA, Energy Dept., NIST and NASA participation
o agrees of agreement include that NREN should:
- evolve from todays NSFnet
. the National Science Foundation Network has a top speed of 45M bps
- be available to education, gov't, and the private sector
o testimony on the need for NREN came from:
. Cornell Univ. Theory Center, Apple, Eli Lilly, MIT, US Sprint
...
Source: Network World, 12/9/91, pg 4, Ellen Messemer
'CEOs push Bush to broaden goals of program'
- the CEOs were from AT&T, Data General, Apple, DEC, IBM, Sun, H-P
- they're members of Computer Systems Policy Project - CSPP
o chief executive officers from 12 US corporations asked for broadening
- the NREN program should be expanded to support commercial applications
and distributed computing
- there's currently too much emphasis on technology useful to science
and not enough on that for businesses
"We're challenging the government to go beyond what they've proposed"
Apple's John Sculley
o National Research and Education Network is a planned gigabit network
- both the White House and Congress have put forth funding proposals
- Sen. Gore's bill was passed recently and awaits Bushs signature
- the White House proposal spends too much on hardware development
. when software is the real challenge: CEOs
- make NREN a nationwide commercial and consumer network
. and use client/server technology
o the initiative is "well-conceived" but "esoteric": H-Ps John Young
- create a complex net of distributed systems
- enabling access to distributed government and industry databases
- and tackle security issues which are already a problem on Internet
Other non-technical issues need to be addressed as well
- copyrights on database information
- billing and accounting via multiple providers
o "We're talking about extending the notion of clients and servers
across a broad base" Joel Birnbaum, H-P VP of R&D
- network management might have to be decentralized and distributed
o the CEOs don't expect the government to build NREN
"The private sector is perfectly capable of building the products.
But the design of NREN and the issue of where the government decides to
spend its $1 billion in seed money will influence industrys willingness
to invest" Sculley
o CSPP has concerns also about government involvement
- current plans are that NSF involve Dept. of Energy, NASA and others
- the Nat'l Science Foundation has responsibility for Internet & NREN
- CSPP doubts gov't ability to manage both agencies and private sector
activities
readme on the NREN implementation plan mid-92
--------
README:
--------
This describes the files containing the DRAFT NSF Interagency Interim
NREN Implementation Plan. Since the Interagency Interim NREN is based
on the evolution of the existing Federal Agencies' research and
education networks (e.g. ESnet, NSI, NSFNET, and TWBnet) this document
may prove to be valuable background reading when contemplating NSF's
next NSFNET Backbone services solicitation in addition to the NSFNET -
NREN realtionship and subsequent plans. The original set of these
documents can be acquired via FTP from EXPRES.CISE.NSF.GOV. For the
FTP session please log in as anonymous and use your e-mail address for
the password. Once logged in change directory to recompete ("cd
recompete"). We have included three versions of the Plan: a postscript
version with embeded figures (which doesn't work on many Apple
LaserWriters), an ascii version (we strongly recommend the
postscript version), and a postscript version without the figures
embedded (they are found in the directory as separate postscript
files). Please direct all questions and/or comments to one of the
authors (Bob Aiken = raiken@nsf.gov, Peter Ford = peter@goshawk.lanl.gov,
Hans-Werner Braun = HWB@sdsc.edu or Steve Wolff = steve@nsf.gov).
" FTP EXPRES.CISE.NSF.GOV"
" cd recompete"
" get ...."
Plan Versions:
impl.ps -- postscript version of the implementation plan with figures
impl.nofig.ps -- postscript version of the implementation plan without
figures (Figures for document in separate postscript files)
impl.ascii -- ascii version (using dvi2tty)
Figures:
net.num.ps -- graph of number of networks on NSFNET backbone
newlevel.ps -- toplogy diagram showing the existing heirarchy of networks
nex.ps -- Network access point based internetwork diagram
nsfnet.ps -- 1991 NSF backbone map, provided by ANS
Thanks
Bob Aiken
Note: It may be possible to print the impl.ps file on a LaserWriter
II if you submit it as the first job after restarting the printer.
note the DOD transition from TCP/IP to ISO international protocols in
the attached.
[ netinfo/nic-pubs.txt ] [ 4/93 ]
PUBLICATIONS OF INTEREST TO
INTERNET USERS
When the DDN Network Information Center (DDN NIC) contract moved from
SRI Network Information Systems Center to GSI/Network Solutions, Inc.,
the responsibility of housing and making available, some files and
documents moved too. The purpose of this file is to clarify what each
site currently has. Sometimes, both sites have provide an online copy
of a file or type of file.
DDN NIC FILES AND DOCUMENTS:
These documents are available on-line for anonymous FTP from the NIC
host. The NIC host is nic.ddn.mil at 192.112.36.5.
1. DDN NEW USER GUIDE
A "how-to" guide to the DDN for network users, including use of
network tools such as electronic mail and file transfer. Published
by the former NIC, December 1985, and revised (DRAFT) September 1991.
Online filename -- netinfo/nug.doc.
Should be available in hardcopy from Defense Technical Information Center
(DTIC) when the final version is approved by Defense Information
Systems Agency (DISA) in 1992.
2. DDN PROTOCOL IMPLEMENTATIONS AND VENDORS GUIDE
A list of vendor-supplied software and hardware DDN protocol
implementations, including TCP/IP, X.25, and OSI implementations.
Published by the former NIC, August 1990. Online filename --
netinfo/vendors-guide.doc.
3. GOVERNMENT OPEN SYSTEMS INTERCONNECTION PROFILE (GOSIP)
The Federal Information Processing Standard (FIPS) describing the
Federal government's policy, including the DoD transition from TCP/IP
to ISO international protocols.
The package contains the Federal Register announcement of the FIPS,
the GOSIP profile itself, the OSD directive to proceed with the policy
within DoD, and the GOSIP FIPS draft.
Online filenames --
protocols/gosip-fips-draft.txt FIPS PUB GOSIP draft
protocols/gosip-fedreg.txt Federal Register Announcement
protocols/gosip-v1.docs The most recent version of the
GOSIP document
protocols/osdir-7-87.txt OSD Directive to adopt OSI protocols
--
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: When the Internet went private Newsgroups: alt.folklore.computers,talk.politics.misc,alt.os.linux Date: 07 Sep 2000 12:57:26 -0600... another (partial) file from the archives ... severely edited to get the size down ... only small part of the ISP listing.
host: ftp.nisc.sri.com
directory: netinfo
file: internet-access-providers-us.txt
date: December 1992
This file is Chapter 4 of the book "Internet: Getting Started," a book
that tells what the Internet is and how to join it. "Internet:
Getting Started" (ISBN 0-13-327933-2) is published by Prentice-Hall.
It can be ordered directly from Prentice-Hall by calling 515-284-6751,
and is also available in many bookstores.
CHAPTER 4
SERVICE PROVIDERS
Advanced Network and Services, Inc. (ANS) and ANS CO+RE
800 456 8267
+1 313 663 2482
info@ans.net
Services: Network connections. ANS CO+RE is a wholly owned, taxable
subsidiary of ANS. ANS is a not-for-profit organization.
AlterNet
800 488 6384
+1 703 204 8000
alternet-info@uunet.uu.net
Services: Network connections; a product of UUNET Technologies.
Infolan
George Abe
+1 310 335 2600
abe@infonet.com
Services: Network connections.
MSEN, Inc.
Owen Scott Medd
+1 313 998 4562
info@msen.com
Services: Network connections, dialup IP, dialup e-mail.
NSFNET:
Referrals available from:
NSF Network Services Center
+1 617 873 3400
nnsc@nnsc.nsf.net
or
Merit Network, Inc.
+1 313 936 3000
nsfnet-info@merit.edu
Performance Systems International, Inc. (PSI)
800 827 7482
+1 703 620 6651
info@psi.com
Services: Network connections; dialup IP; dialup e-mail.
SprintLink
Bob Doyle
+1 703 904 2167
rdoyle@icm1.icp.net
Services: Network connections.
4.2. Providers of Dialup Services
America Online, Inc.
800 827 6364
+1 703 8933 6288
info@aol.com
Area Served: US and Canada
Services: Dialup e-mail.
Anterior Technology
+1 415 328 5615
info@radiomail.net
Area Served: San Francisco bay area
Services: Dialup e-mail; RadioMail.
Big Sky Telegraph
800 982 6668 (in Montana only)
+1 406 683 7338
jrobin@csn.org
Area Served: Montana
Services: Dialup e-mail.
BIX 800 695 4775
+1 617 354 4137
TJL@mhis.bix.com
Area Served: Area code 617; local dialup connections outside 617
available through TYMNET.
Services: Dialup e-mail.
CERFnet
800 876 2373
+1 619 455 3900
help@cerf.net
Services: Network connections, national dialup IP, dialup e-mail.
Channel 1
+1 617 864 0100
whitehrn@channel1.com DRAFT 4
Area Served: Massachusetts
Services: Dialup e-mail.
CLASS
Cooperative Agency for Library Systems and Services
800 488 4559
class@class.org
Area Served: US
Services: Dialup access for libraries in the US.
Community News Service
+1 719 579 9120
klaus@cscns.com
Area Served: Colorado Springs, CO (719 area code)
Services: Dialup e-mail.
CompuServe Information System
800 848 8990
+1 614 457 0802
postmaster@csi.compuserve.com
Services: Dialup e-mail.
The Cyberspace Station
+1 619 944 9498 ext. 626
help@cyber.net
Area Served: San Diego, CA
Services: Dialup e-mail
Express Access Online Communications Service
+1 301 220 2020
info@digex.com
Services: Dialup e-mail in the Northern VA,
Baltimore MD, Washington DC areas
(area codes 202, 310, 410, 703).
EZ-E-Mail
+1 603 672 0736
info@lemuria.sai.com
Area Served: US and Canada
Services: Dialup e-mail.
Halcyon
+1 206 426 9298
info@remote.halcyon.com
Area Served: Seattle, WA
Services: Dialup e-mail.
HoloNet
+1 510 704 0160
info@holonet.net
Area Served: Berkeley, CA (area code 510)
Services: Dialup e-mail.
Institute for Global Communications (IGC)
+1 415 442 0220
support@igc.apc.org
Services: Dialup e-mail; affiliated with PeaceNet, EcoNet, and
ConflictNet; member of the Association for Progressive Communications
(APC).
IDS World Network
+1 401 884 7856
sysadmin@ids.net
Area Served: East Greenwich, RI; northern RI
Services: Dialup e-mail.
JvNCnet
Sergio F. Heker
Allison Pihl
800 358 4437
+1 609 258 2400
market@jvnc.net
Services: Network connections, national dialup IP, dialup e-mail.
MCI Mail Engineering
800 444 6245
+1 202 833 8484
2671163@mcimail.com
3248333@mcimail.com
Services: Dialup e-mail.
MindVox
+1 212 988 5987
info@phantom.com
Area Served: New York City (area codes 212, 718)
Services: Dialup e-mail.
MSEN, Inc.
Owen Scott Medd
+1 313 998 4562
info@msen.com
Area Served: U.S.
Services: Network connections, dialup IP, dialup e-mail.
New Mexico Technet
+1 505 345 6555
reynolds@technet.nm.org
Area Served: New Mexico
Services: Dialup e-mail.
Old Colorado City Communications
+1 719 632 4848
dave@oldcolo.com
Area Served: Colorado
Services: Dialup e-mail.
Seattle Online
+1 206 328 2412
bruceki@online.com
Area Served: Seattle, WA
Services: Dialup e-mail.
Panix Public Access Unix
Alexis Rosen
alexis@panix.com
+1 212 877 4854
or
Jim Baumbach
jsb@panix.com
+1 718 965 3768
Area Served:New York City, NY (area codes 212, 718)
Services: Dialup e-mail.
Performance Systems International, Inc. (PSI)
800 827 7482
+1 703 620 6651
info@psi.com Services: Network connections, dialup IP, dialup e-mail.
Portal Communications, Inc.
+1 408 973 9111
cs@cup.portal.com
info@portal.com
Area Served: Northern California (area codes 408, 415)
Services: Dialup e-mail.
Sugar Land Unix
+1 713 438 4964
info@NeoSoft.com
Area Served: Texas (Houston metro area)
Services: Dialup e-mail.
UUNET Technologies, Inc.
800 488 6384
+1 703 204 8000
info@uunet.uu.net
Services: Network connections, dialup e-mail; Alternet is a product of
UUNET Technologies.
Whole Earth 'Lectronic Link (WELL)
+1 415 332 4335
info@well.sf.ca.us
Area Served: San Francisco Bay Area (area code 415)
Services: Dialup e-mail.
The World
+1 617 739 0202
office@world.std.com
Area Served: Boston, MA (area code 617)
Services: Dialup e-mail.
--
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: When the Internet went private Newsgroups: alt.folklore.computers,talk.politics.misc,alt.os.linux Date: 07 Sep 2000 16:23:17 -0600... part of another document from the archives ... severely abridged
ISOC-ANNOUNCEMENT 1/27/92
The Internet Society
Abstract
The purpose of this document is to provide a brief description of the
Internet Society and its goals and objectives. It will function as a
professional society to facilitate, support and promote the evolution
and growth of the Internet as a global research communications
infrastructure. The suggestions and recommendations of all parties
interested in the Internet are solicited to assist in making the
Internet Society robust, productive and structured to meet the needs
of its members.
misc. posts mentioning bitnet &/or EARN
https://www.garlic.com/~lynn/subnetwork.html#bitnet
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: When the Internet went private Newsgroups: alt.folklore.computers,talk.politics.misc,alt.os.linux Date: 07 Sep 2000 17:16:26 -0600following is the list of NSFNET sites ... the sites funded by NSF for NSFNET.
Request: nsfnet Topic: sites Updated: 9 January 1992 Subject: NSFNET sites NSFNET BACKBONE SITES On-line now (November 1991) Argonne Nat'l Lab Cornell Nat'l Supercomputer Facility Georgia Inst. of Tech. U. of Maryland Massachusetts Inst. of Tech. U. of Michigan Nat'l Ctr. for Atmospheric Res. Nat'l Ctr. for Supercomputing Appl. U. of Nebraska Pittsburgh Supercomputing Ctr. Princeton U. Rice U. San Diego Supercomputer Ctr. Stanford U. U. of Utah U. of Washington--
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: When the Internet went private Newsgroups: alt.folklore.computers,talk.politics.misc,alt.os.linux Date: 07 Sep 2000 17:17:44 -0600again from the archives the first part of the bill ... i can post the whole thing if anybody is interested
NIS.NSF.NET> [NSFNET] NRENBILL.TXT
The House-Senate compromise version of S. 272, the High-Performance
Computing Act, passed the House on November 20, 1991, the Senate on
November 22, 1991, and was signed by the President on December 9,
1991.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: When the Internet went private Newsgroups: alt.folklore.computers,talk.politics.misc,alt.os.linux Date: 07 Sep 2000 17:19:10 -0600recognizing the realities of what was going in the commercial internet world
FILIBUSTER ON NATIONAL COMPETITIVENESS ACT ENDED
Prior Proposed Restrictions on Purposes of NREN Removed
Washington, DC By unanimous consent order issued at 2:59 p.m., Mar 15, the
filibuster to defeat S.4, the National Competitiveness Act of 1994, led by
Ranking Member of the Senate Committee on Commerce, Science, and
Transportation, Sen. John C. Danforth, was terminated. The terms of the
consent order did not affect any matter pertaining to title VI of the
Committee modification introduced by Sen. Hollings Mar 7, 1993.
As the bill now stands, title VI, Information Technology Applications,
removes restrictions on the purposes of the National Research and
Education Network (Network Program) previously contained in the bill (S.4)
reported by the full Committee last summer. Those restrictions prohibited
network capabilities in the experimental test bed networks that were
available from commercial networks operated by the private sector (Sec.
611(a)(2)(B). They also eliminated restrictions intended to take effect
within 18-months on the use of test bed networks to provide commercial
network services that could be provided by using commercially available
network services (Sec. 611(d)).
The substitute amendment now includes language amending sec. 102 of the
High-Performance Computing Act of 1991 to require that program funds
"shall develop, provide access to, or use communications networks through
the acquisition of commercially available network services or through
contracting for customized services when such acquisition cannot satisfy
agency requirements." (Sec. 102(g)). Sen. Hollings explained at the time
of introducing the substitute amendment that the bill "includes language
on one key provision--the section ensuring that Federal support for
computer networks does not create unfair competition to commercial phone
companies, while still providing that Federal agencies remain free to
operate their own internal mission networks."
A vote on the bill was scheduled for Wednesday morning, Mar 16, 1994.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: When the Internet went private Newsgroups: alt.folklore.computers,talk.politics.misc,alt.os.linux Date: 07 Sep 2000 18:29:55 -0600... here is NREN description from 1996 ... a source of funds for institutions to pay for (commercial) Internet connectivity.
NREN will use the Internet to provide information resource connection
not only to universities, research centers and government agencies, but
also to secondary and elementary schools. The bill provides $2.9 billion
over a five year period towards the NREN. The High-Performance
Computing and High Speed Networking Applications Act of 1993, sponsored
by Rep. Richard Bouche, expands the Gore bill to also include access to
health care facilities and schools at all levels.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Is Al Gore The Father of the Internet?^ Newsgroups: alt.folklore.computers,talk.politics.misc,alt.os.linux Date: 07 Sep 2000 20:46:57 -0600Floyd Davidson writes:
NFSNET was a "backbone" with a dozen or so locations. Ref:
https://www.garlic.com/~lynn/2000d.html#73
Original NSFNET1 RFP was for a T1 speed backbone interconnecting those
locations. In the following the reference to the NSF technical
audit was at the time the bids had been submitted for NSFNET1.
https://www.garlic.com/~lynn/internet.htm#0
NSFNET2 was for an upgrade of the backbone from T1 to T3. My wife and I were the red-team for the technology bake-off for NSFNET2. The blue team had 20 or so people from at least seven locations around the world. At the final evaluation (maybe 35-45 people in the room), I presented first for about an hour. Then the representative for the blue team got to present. About 10 minutes into the blue team presentation it became so evident that their solution wasn't very competitive, the executive running the show (who apparently had pre-decided on the outcome based on non-technical issues) ... pounded the table and told everybody in the run that he would lay down in front of a garbage truck before he would allow any but the blue team proposal to go forward. At that point my wife and I (and a couple others) got up and left the meeting.
Gore's NREN bill
https://www.garlic.com/~lynn/2000d.html#74
was supposedly to pump additional money into computing (HPCC) and communication (NREN) R&D.
It isn't clear that a whole lot of NREN money was actually spent for
other than funding gov, education, etc. access to "the internet".
https://www.garlic.com/~lynn/2000d.html#75
https://www.garlic.com/~lynn/2000d.html#70
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: When the Internet went private Newsgroups: alt.folklore.computers,talk.politics.misc,alt.os.linux Date: 07 Sep 2000 22:02:16 -0600misc NIIT from the archives, it would be classed a NREN thing ... but commercially funded
NEW NETWORK ALLOWS MASS DATA GATHERING By DAVID BANK Mercury News
Staff Writer
A consortium of computing and communications companies eager to show
off practical applications for the emerging ''information
superhighway'' unveiled a new network Tuesday to allow far-flung
computer users to instantly collect vast reams of data and then work
on it together as if they were sitting side-by-side. The
demonstration was the first part of a plan by the National Information
Infrastructure Testbed, or NIIT, to create specialty networks in the
environmental, health care and education fields -- prototypes of the
superhighway that eventually can be sold to private industry or
government agencies. In each field, computer users will be able to
quickly retrieve information from data bases spread across the
country, sort and analyze it according to their needs and share it
with other users around the country, using voice and video as well as
data. The goal is to move the information superhighway from the
potential to reality by proving it can meet pressing social needs --
and make money. ''This is definitely a commercial venture,'' said Jim
Lewis, marketing manager at Synoptics Communications Inc. in Santa
Clara, who showed off the new network at the Supercomputing '93 trade
show in Portland, Ore. Scientists claim the first application, the
Earth Data System, would make it easier for researchers to study
global climate change, deforestation, world agricultural production
and the effects of floods, hurricanes and other natural calamities.
The consortium, formed last September and funded by the companies, is
one of many efforts to catch the wave of enthusiasm for the
superhighway concept. The companies, including American Telephone &
Telegraph Co., Hewlett-Packard Co., Digital Equipment Corp., Pacific
Bell and Sun Microsystems Inc. in addition to Synoptics, set aside
competition to develop common standards for the new information
networks. Next year, the consortium plans to create a medical
information system to store patient records and allow doctors in
different hospitals to share such things as X-rays. After that, the
group plans an interactive educational network. The Earth Data System
provides virtually instant access to Landsat satellite images of the
Earth in a variety of forms. Then, researchers could add a variety of
related data, such as photographs of the same area taken on the
ground, field notes by researchers on the ground and voice recordings
of local information. The data also includes weather statistics,
salinity levels and fishing yields. Its designers claim the network
is able to move the equivalent of 1,900 pages of text per second, fast
enough for researchers to quickly share large computer files, such as
satellite photos. The idea is to allow researchers to work together by
simultaneously moving voice, video and data. In addition to solving
real-life problems, the demonstrations also are designed to work out
the technical, financial and legal snags facing the information
superhighway. For example, the Earth Data System combines information
that is free to the public with archives that must be purchased. Lewis
said security and the integration of data from differing formats also
present challenges.
MERCURY CENTER ID: me46571i Transmitted: 93-11-17 06:07:19 EST
...
NATIONAL INFORMATION INFRASTRUCTURE TESTBED
(NIIT)
invites you to a discussion on
Applying Information Technologies To Improving Healthcare Delivery
WHEN: Wednesday, September 28, 1994 (7:30 am - 8:30 am)
WHERE: Information Superhighway Summit, Red Lion Inn,
San Jose, Califoria
BREAKFAST WILL BE SERVED
On September 20, 1994, NIIT will unveil the first nationwide
medical information network to demonstrate how information
technologies can provide tangible healthcare benefits today. This
first demonstration will take place in Washington, D. C., in front
of the U.S. Congress, the Federal Administration, Healthcare
Industry and Members of the Media. NIIT would like to share:
-lessons learned in building the nationwide
high speed network using ATM
-healthcare benefits achievable today by applying
information technologies
Gues speakers will inclue Dr. Dominic Orr, Vice President of
Technology for SynOptics Communication, and Leslie Sandberg,
Executive Director for the Institute for Telemedicine, Center for
the New West. Both SynOptics and Ms. Sandberg, as Chair of the
NIIT Healthcare Working Group, were instrumental in the deployment
of the nationwide medical network.
Please RSVP to 800-299-9973 by September 23, 1994, as space is
limited.
--
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: When the Internet went private Newsgroups: alt.folklore.computers,talk.politics.misc,alt.os.linux Date: 08 Sep 2000 10:02:14 -0600from 5/29/94 "Kahaner" report regarding Singapore's NII
An essential ingredient in IT2000 is a National Information
Infrastructure, which hopes, by 2005, to interconnect computers in
virtually every home, office, school, and factory, and Singapore will
probably be the first country to be fully fiber to the home. Many
aspects of Singapore's NII will appear similar to those stated in US
plans, a high capacity backbone, adherence to standards for networks as
well as interfaces and environments, system management and security,
distributed computing services, layers of services, and a few
significant initial application products. In the case of Singapore these
applications include personalized electronic newspaper, media
marketplace, distance learning, etc., and others are mentioned, as well
as applications of direct value to commercial customers such as a
network for procurement, construction, legal network, electronic road
pricing, intelligent job placement, on-line income tax info, computerized
patenting, geographical information, etc. Many other applications are
in the planning or prototype stage. For example, while I was there, an
article appeared stating that the NCB and the National University will
develop a digital audio archiving/retrieval system to convert
Singapore's National Archives 14,000 oral history recordings into
digital form. Other projects include communication protocols and
software to link pen-based mobile computers on ambulances with computer
systems in hospitals.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: When the Internet went private Newsgroups: alt.folklore.computers,talk.politics.misc,alt.os.linux Date: 08 Sep 2000 10:03:02 -0600another except from a later "Kahaner" report (severely edited)
Building Japan's Information Superhighway
By Joel West (for CRITO)
February 1995
If you want to know about U.S. plans for an "information
superhighway," one of the best places to find out is Japan.
Seemingly obscure U.S. proposals that are little-noticed here
are cited in Japanese newspapers, magazines, books and
speeches on Japan's own plans to build a nationwide digital
communications network.
Such a network -- usually referred to as a National
Information Infrastructure (NII) -- would be Japan's largest
public works project since the construction of the shinkansen
in the 1960's, so the possibilities are being debated by
leading industrial companies, corporate think tanks, academia
and several government ministries. The debate seems to have
little to do with the questions of how or why such a network
would be used, but instead-largely reacting to the recent
U.S. NII plans -- is driven by technological competitiveness
and a desire by electronics manufacturers to find new large
and as yet untapped markets.
As with all important issues involving national policy
in Japan, bureaucratic rivalry is central to both the process
and likely end result of the NII debate. Also involved is the
mutual dependence and rivalry between ministries and industry
as they seek to gain both support and wrest leadership from
each other.
This brief paper summarizes the policy-making processes
at work in the contemporary Japanese NII debate. Because much
of the debate is an explicit reaction to U.S. NII plans, it
also highlights a few of the major contrasts between those plans.
Key Elements of the Process
===========================
The discussion of Japan's digital communications future
is actually framed in terms of three inseparable code
phrases: multimedia, information infrastructure and fiber
optics. At one end, "multimedia"- the anticipated convergence
of audio, video and computing-has been the great anticipated
growth market for Japan's large electronics companies for
many years. They have developed both new products- such as
Sony's handheld Data Discman and Fujitsu's home PC series FM
Towns-and hyped existing products as part of an anticipated
"multimedia revolution."
The link from multimedia to an information
infrastructure is straightforward. Only multimedia content-
home movies (video on demand), interactive video games,
interactive education, and so on-requires the bandwidth to
justify a nationwide digital telecommunications network
supplanting the existing telephone network. Such a network
is the cornerstone of the plans of Japan (and other nations)
for an "information society" in which information is conveyed
digitally between citizens, business and government, rather
than via mail, fax, telephone or television.
Meanwhile, Japan has already decided that this
multimedia system will be delivered via a fiber optic
network. In the U.S., current plans call for a hybrid system
for itself based on fiber optics and coaxial cable, because
existing coaxial cable TV lines serve the vast majority of
U.S. homes.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Coloured IBM DASD Newsgroups: alt.folklore.computers Date: 09 Sep 2000 11:20:37 -0600jcmorris@jmorris-pc.MITRE.ORG (Joe Morris) writes:
random refs:
https://www.garlic.com/~lynn/99.html#42
https://www.garlic.com/~lynn/99.html#43
https://www.garlic.com/~lynn/99.html#52
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition) Newsgroups: comp.arch,comp.sys.super,alt.folklore.computers Date: 10 Sep 2000 09:13:31 -0600The 3033 64mbyte gave rise to the 16mbyte constrained memory problem. Various kinds of operations (like I/O CCWs) had to be below the 16mbyte line. Some of the early (3033) implementations managing virtual storage ... tended to severely aggravate the 16mbyte constrained memory performance problem ... because of the way they selected virtual memory pages "below" and "above" the (16mbyte) line for replacement (severely reducing the real performance effectiveness of the additional real storage, sometimes almost page-thrashing below the line with very light paging activity above the line).
There were lots of situations where pages above the line had to be moved to below the line ... leading to games where the "above" the line area could have pages pushed into it, almost as a kind of paging device.
misc. other 3033-related refs:
https://www.garlic.com/~lynn/2000c.html#35
https://www.garlic.com/~lynn/2000c.html#83
https://www.garlic.com/~lynn/2000c.html#84
some related problem is that during that period there were operating system "microcode assists" being built for the mid-range machines (4341, 4381, etc). The mid-range machines frequently had a 10:1 emulation ration (between microcode instructions and 370 instructions). Dropping operating system code into microcode was close to a 1:1 mapping (much of the operating system code that got dropped into microcode was status test&update with branching ... which maps easily into the microcode engine instruction set ... and would give a 10:1 performance improvement).
The higher-end horizontal microcode machines with lots of hard-wiring for running 370 instructions ... and things usually expressed in machine cycles per 370 instructions. The 165 was 2.1 machine cycles per 370 instructions and the 168 was 1.6 cycles per 370 instructions.
The bare-bones remapping of 168 to new chip technology would have just been 20% improvement because of the faster chips (and would have had the same number of cycles per 370 instruction). I don't ratio the eventual 3033 ratio ... but I would expect it to have been less that the 1.6:1 168 ratio (which would have added to the 3033 mip rate).
Effectively, most of the operating system microcode assists that were
seen on the mid-range machines would see little if any performance
improvement on the high-end machines (because they were effectively
already running 370 instructions at machine speed, & might even in
some cases be slower). This was even more aggravated on 3081 with
pageable microcode (i.e. the bare-bones 370 instructions ran at
machine cycle speed ... but the more complex "microcode operations"
actually might have to be "paged" in&out of microcode store).
https://www.garlic.com/~lynn/94.html#21
https://www.garlic.com/~lynn/2000d.html#7
https://www.garlic.com/~lynn/2000d.html#20
https://www.garlic.com/~lynn/2000d.html#31
https://www.garlic.com/~lynn/2000d.html#61
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Closed versus Stealth Newsgroups: comp.security.firewalls Date: 10 Sep 2000 17:48:52 -0600"Kevin OMeara" writes:
stealth is when nothing comes back ...
index/refs for RFCs can be found at
https://www.garlic.com/~lynn/rfcietff.htm
ref: rfc1122.txt, pg 39, section 3.2.2.1 (see "3" below).
3.2.2.1 Destination Unreachable: RFC-792
The following additional codes are hereby defined:
6 = destination network unknown
7 = destination host unknown
8 = source host isolated
9 = communication with destination network
administratively prohibited
10 = communication with destination host
administratively prohibited
11 = network unreachable for type of service
12 = host unreachable for type of service
A host SHOULD generate Destination Unreachable messages with
code:
2 (Protocol Unreachable), when the designated transport
protocol is not supported; or
3 (Port Unreachable), when the designated transport
protocol (e.g., UDP) is unable to demultiplex the
datagram but has no protocol mechanism to inform the
sender.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/