scott_j_f...@yahoo.com (Scott Ford) writes: > Still old adage the channels are slower than the process, hence > usually a bottleneck. My past life before development I was a Comm guy > ,hardware and software..saw of lot of bottlenecks
re: http://www.garlic.com/~lynn/2013m.html#94 SHARE Blog: News Flash: The Mainframe (Still) Isn't Dead http://www.garlic.com/~lynn/2013m.html#96 SHARE Blog: News Flash: The Mainframe (Still) Isn't Dead http://www.garlic.com/~lynn/2013m.html#99 SHARE Blog: News Flash: The Mainframe (Still) Isn't Dead original mainframe tcp/ip product was implemented in vs/pascal ... but had some other issues ... getting approx. 44kbytes/sec using nearly full 3090 processor. I did the enhancements to support rfc1044 and in some tuning tests at cray research got sustained channel speed throughput between cray and 4341, using only modest amount of 4341 processor (possibly 500 times improvement in bytes moved per instruction executed). misc. past posts mentioning rfc1044 http://www.garlic.com/~lynn/subnetwork.html#1044 In late 80s, I was the asked to be on technical advisory board for XTP protocol ... communication group tried hard to prevent my being on the XTP/TAB ... one of the objectives was elimination of serialization and sync points with various kinds of protocol processing hardware chips to make things flow continuously asynchronously (w/o any buffer copies)... and cut total system processor pathlength to 500 instructions or less per packet. http://en.wikipedia.org/wiki/Xpress_Transport_Protocol above claims that XTP didn't employ congestion avoidance ... but I had wrote spec. for adaptive rate-based congestion control http://www.garlic.com/~lynn/xtprate.html past posts mentioning xtp http//www.garlic.com/~lynn/subnetwork.html#xtphsp old email with overview of xtp http://www.garlic.com/~lynn/2009q.html#eamil881113 mention of xtp for us submarines http://www.garlic.com/~lynn/2011c.html#email890801b part of the influence in XTP design was some of people from silicon graphics that had worked on their graphics protocol engine that had high performance pipelined design as data flowed out of system continuously through asyncronously processing pipelined stages. besides mention in the wiki article, some amount was sponsored out of llnl/sandia ... gone 404 ... but lives on at the wayback machine http://web.archive.org/web/20020209014400/http://www.ca.sandia.gov/xtp/ the above does mention rate control (adaptive rate control addresses congestion avoidance). say 8gbit/sec FCS ... 2gbyte/sec aggregate ... say 256k 4k records/sec in each direction, 512k aggregate ... at 500 instructions/record ... say 1/4 BIPS, 1BIPS then handles 2M IOPS. this mentions meeting on cluster scaleup early Jan1992 in Ellison's conference room http://www.garlic.com/~lynn/95.html#13 end of Jan1992, cluster scaleup is transferred and we are told we can't work on anything with more than four processors ... and we decide to leave. later, two of the other people at the Ellison meeting have also left and joined small client/server startup and are responsible for something called "commerce server". We are brought in as consultants because they want to do payment transactions on the server; the startup had invented this technology called SSL they want to use, the result is now frequently called "electronic commerce". One of the things that had to be done was map "SSL" technology to payment business processes. part of this included doing something called "payment gateway" that sits on the internet and handles traffic between "commerce servers" (on the internet) and the "payment networks" ... some past posts http://www.garlic.com/~lynn/subnetwork.html#gateway -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
