Keyboard Shortcuts
Likes
Search
VM/370 Hercules Optimisation
|
Dave, Huh? To quote the manual: "The 4341?Processor generates less?total?interference with instruction execution than intermediate-scale?System/360 and System/370?processors because the?amount?of time required?to transfer?a?byte?of?data?between?processor storage?and?the channel data buffer during?an?I/O operation?is?much?less?(64?bytes are transferred?in?4 microseconds?in the?4341 Processor?versus?4?bytes transferred to or?from?processor storage in?.54 microseconds?in the?Model 148,?for example)." If 4 bytes are transferred in half a microsecond, that means 64 bytes could be transferred in 32 microseconds, versus 4 microseconds on a 4341... Joe On Thu, Jan 30, 2020 at 3:47 AM Dave Wade <dave.g4ugm@...> wrote:
|
|
Dave, The 2305 uses a block multiplexor channel ... "The 2835 storage Control and 2305 Fixed Head Storage Module form a large capacity, high -speed direct access storage facility for general purpose data storage and system residence.?It?attaches to the central processing unit through a block multiplexor channel, and operates under direct program control of the CPU." Joe On Thu, Jan 30, 2020 at 3:47 AM Dave Wade <dave.g4ugm@...> wrote:
|
|
On Thu, Jan 30, 2020 at 09:47 AM, Dave Wade wrote:
On the low end 43xx boxes in effect the channel is implemented using some of the main CPU so device that generate high IO can degrade CPU performance…I guess, in the context of hercules, we are looking for the device which required the fewest S/370 CPU cycles so that most of the work is done in?x86-64 land, but also one where the engineers didn't have to build in any weird waits or timing stuff into the CP drivers. So it doesn't matter if the device was as slow as a dog in real life - as long as it delivers the requested block to the s/370 and VM/370 doesn't care if the interrupt (or whatever) happens VERY quickly. Also, perhaps there were some file system ASSISTS? Does that suggest anything to anyone? |
|
"I guess, in the context of hercules, we are looking for the device which required the fewest S/370 CPU cycles so that most of the work is done in?x86-64 land, but also one where the engineers didn't have to build in any weird waits or timing stuff into the CP drivers." If you look at the actual Hercules code, you can see that there is virtually no difference in how the various types of DASD are implemented... Joe On Thu, Jan 30, 2020 at 6:37 AM adriansutherland67 <adrian@...> wrote: On Thu, Jan 30, 2020 at 09:47 AM, Dave Wade wrote: |
开云体育Joe, Interesting! Contrast that with the top of page 65:- ? GENERAL OPERATION OF THE CHANNELS The channels in the 4341 Processor are microcode and hardware controlled. They are integrated channels and, thus, share the use of certain hardware with the instruction processing function, such as the arithmetic logic unit, byte shifter, and control storage. ? The small 43xx were notorious for poor IO performance under heavy load reputedly because of this…. ? Dave ? From: [email protected] <[email protected]> On Behalf Of Joe Monk
Sent: 30 January 2020 12:02 To: [email protected] Subject: Re: [h390-vm] VM/370 Hercules Optimisation ? Dave, ? Huh? To quote the manual: ? "The 4341?Processor generates less?total?interference with instruction execution than intermediate-scale?System/360 and System/370?processors because the?amount?of time required?to transfer?a?byte?of?data?between?processor storage?and?the channel data buffer during?an?I/O operation?is?much?less?(64?bytes are transferred?in?4 microseconds?in the?4341 Processor?versus?4?bytes transferred to or?from?processor storage in?.54 microseconds?in the?Model 148,?for example)." ? I dont?see how that can degrade CPU performance for high I/O. In fact, in a high I/O situation, wouldnt?it help?? ? If 4 bytes are transferred in half a microsecond, that means 64 bytes could be transferred in 32 microseconds, versus 4 microseconds on a 4341... ? Joe ? On Thu, Jan 30, 2020 at 3:47 AM Dave Wade <dave.g4ugm@...> wrote:
|
|
So according to this guide there were VMASSISTS in ECPS:VM ?... Joe On Thu, Jan 30, 2020 at 9:37 AM adriansutherland67 <adrian@...> wrote: On Thu, Jan 30, 2020 at 01:31 PM, Joe Monk wrote: |
开云体育Back when I was in college, the administrative center was run on a 4341, and a 4331 was what supported all the campus’ student computing needs. ?I worked in the lab as an RJE operator.I think back then it was mostly DOS/VSE with POWER for the campus systems, and then later VM/360 with DOS/VSE running as a VM and eventually MUSIC as another VM for our first interactive computing for the students. ? I’m pretty sure the Admin 4341 was running MVS along with CICS. I liked MUSIC a lot, but the overall load was WAY more than the machine could handle and RJE job turnaround went up to 24 hours and beyond. ?I burned a lot of midnight oil keeping the printer fed so that the wait times didn’t just keep escalating. Whether that could be attributed to 43x1 channel performance would be interesting to discover. Fun times. Scott
|
开云体育Adrian For CMS its pretty much the same!. That’s the who benefit of channels. You send the SIOs to the channel and the channel and controllers work out what to do. Dave ? From: [email protected] <[email protected]> On Behalf Of adriansutherland67
Sent: 30 January 2020 15:38 To: [email protected] Subject: Re: [h390-vm] VM/370 Hercules Optimisation ? On Thu, Jan 30, 2020 at 01:31 PM, Joe Monk wrote:
Cool - and in terms of CP (or VM/370) code is there much difference? |
开云体育Joe, ? Not really much to do with IO. Hercules implements these as was mentioned earlier. Shadow Table Bypass is only relevant when running a guest OS that use virtual memory. CMS only runs with DAT off … ? Dave ? From: [email protected] <[email protected]> On Behalf Of Joe Monk
Sent: 30 January 2020 15:49 To: [email protected] Subject: Re: [h390-vm] VM/370 Hercules Optimisation ? So according to this guide there were VMASSISTS in ECPS:VM ?... ? ? Joe ? On Thu, Jan 30, 2020 at 9:37 AM adriansutherland67 <adrian@...> wrote:
|
|
On Thu, 30 Jan 2020 at 15:57, Dave Wade <dave.g4ugm@...> wrote:
Was Adrian thinking that a page fault* would be the cause of the I/O?? Presumably if one accesses an address from within CMS that is not, at that moment, mapped to real memory it is CP, not CMS, that handles the page fault? * is there an IBM name for this as there seems to be for most other things.? |
|
On Thu, Jan 30, 2020 at 04:46 PM, Steven Fosdick wrote:
Was Adrian thinkingProbably overthinking! It sounds like at best we are talking about marginal differences. Anyway I have my Dockerfile working so I will try some speed tests with different configs over the weekend. Thanks for all the advice :-) |
开云体育Steven, ? I think it was Joe who mentioned the assists. To be honest while I think for CMS, VM is the “bees knees”, when you try to run MVS in a VM the wheels can fall off the car because of the need to maintain shadow page tables. So in VM/370 all guests run real problem state and even when running V=R they don’t have access to real page zero. All interrupts get passed to CP not the Guest. CP then has to either simulate them or reflect them to the OS. For an OS like CMS which runs DAT off this isn’t a huge problem. When running multiple users who “IPL CMS” things are improved because each user does share most of the CMS nucleus as a “Discontigous Saved Segment”, a piece of read only memory that usually sits at the top of memory and so tends to stay in real store. Again this usually isn’t relevant for Hercules because we typically only have one user but the CMS in all the releases available for download are built like that. ? On the other hand MVS wants to do its own paging, so every time MVS changes the page tables, an interrupt is generated and VM has to update its shadow page tables. There are several ways to reduce this overhead. If you are only running one copy of MVS you can dedicate some low store to it, and so run it as V=R. ?but if you have multiple machines obviously only one can be v=r. The assists are really useful here. Some releases of “OS” also have handshake features that allows the OS to pass information to CP and reduce the overhead. ? Someone mentioned poor performance with MUSIC, well I suspect what killed MUSIC under VM was the paging overhead… ? … on the other hand some releases of DOS reputedly ran better under VM because the OS paging could be disabled, and the CP paging was much better… ? For those interested GC20-1821 has more info… ? ? but the some of the facilities described in there are SEPP or BSEPP which we don’t have/// ? Dave ? ? ? From: [email protected] <[email protected]> On Behalf Of Steven Fosdick
Sent: 30 January 2020 16:47 To: [email protected] Subject: Re: [h390-vm] VM/370 Hercules Optimisation ? On Thu, 30 Jan 2020 at 15:57, Dave Wade <dave.g4ugm@...> wrote:
? Was Adrian thinking that a page fault* would be the cause of the I/O?? Presumably if one accesses an address from within CMS that is not, at that moment, mapped to real memory it is CP, not CMS, that handles the page fault? ? * is there an IBM name for this as there seems to be for most other things.?
|
My experience was that MUSIC performed really well under VM provided it had enough memory and even better still if it was locked in storage. It was possible to support over a hundred users on MUSIC running on VM doing edit/compile/run cycles with the same sort of machine resources that would be crawling when a quarter of that number of CMS users were doing similar work. If it was attempted to have both of these categories of users working at the same time, the MUSIC users really suffered, despite all sorts of attempts to give preferential treatment to the VM userid running MUSIC. There were all sorts of dire warnings in the MUSIC administrator guide to not allow VM to page MUSIC, but in practice we found the effects were not quite as bad as the warnings suggested they would be, at least when the CMS users weren't beating on it. This was on an Amdahl 5870 (AP) with 64MB of real storage, VM/HPO and a virtual storage size of 12MB for MUSIC (because the VM sysprog wasn't willing to risk giving it 16MB). Regards, Peter Coghlan. |
|
toggle quoted message
Show quoted text
-----Original Message-----was possible to support over a hundred users on MUSIC running on VM doingworking at the same time, the MUSIC users really suffered, despite all sorts ofI am pretty sure Rutherford Appleton Labs got over 100 users on their Fujitsu box under HPO but they did tweak the microcode and some of the assists. I think we ran about 60 on a 4381 model 3 under HPO and performance was fine. There were all sorts of dire warnings in the MUSIC administrator guide tonot allow VM to page MUSIC, but in practice we found the effects were notquite as bad as the warnings suggested they would be, at least when the CMSI think their experience might be with smaller hardware than that described below. This was on an Amdahl 5870 (AP) with 64MB of real storage, VM/HPO and aThat is rather a different beast to a 4341 which typically had 4MB of memory. With HPO's "improved" scheduler and the availability of all that store that box would be pretty slick. Note:- you needed HPO to support more that 16Mb of memory. It's a bit of a fudge because programs can only see 16Mb but there are spare bits in the page table which allows the pages to be mapped to store above the 16Mb line. VM/370 has no concept of this. I suppose it might be possible to add it, but given we don't get lots of VMs running it doesn't help much. I don't see why he would not give MUSIC 16Mb provided its only virtual not real. If it was V=R it is no wonder CMS performed badly. CP needs a chunk of real for the VMBLOCKS for VMS.... Regards,Whilst a lot does not apply to VM/370 a copy of Jeff Savit's "VM and CMS : Performance and Fine Tuning" 503&cm_sp=mbc-_-ISBN-_-used makes interesting reading. Perhaps I should try Music on the P390. Dave G4UGM |
|
> To be honest while I think for CMS, VM is the “bees knees”, when you try to run MVS in a VM the wheels can fall off the car > because of the need to maintain shadow page tables. I run MVS as a guest of VM.? In fact that is the only way I run it.? It runs great, and I am not sure why there is so much misinformation about the 'negative aspects' of running this way.? To be sure, if I had 30 other CMS users online on the same system competing with MVS and a few batch jobs and some TSO users, then there would definitely be some serious issues.? But we're all basically single users on our systems.? We have no one else to compete with and even if there were one or two others it would be negligible. For me at least, the advantages of having CMS and TSO side by side are worth some reduction in MVS throughput.? Ok, so my 2000 line batch assembly takes 8 seconds instead of 6.? I can wait.? I can submit jobs from CMS to MVS; they come in through MVS's card reader, and I can get my job output spooled back to my CMS virtual reader when the job is completed.? Or I can use TSO all the way for the same process. I do run MVS in a 8 MB virtual machine.? I have CP generated for an 8 MB V=R area.? This allows me to run STBYPASS (Shadow Table Bypass) and avoid that overhead.? This support is present in Sixpack 1.3 (I know, I installed it there for you, Dave).? And as a V=R guest, CCW translation can be turned off for MVS, thereby saving another good bit of overhead.? Many of the new ECPS:VM assists that I introduced in 2017 and 2018 (in Hyperion and SDL Hyperion only) were geared to specifically assist guests like MVS.? ECPS:VM now works with STBYPASS and it now assists several expensive instructions like LRA, STOSM, and more, that MVS issues in abundance.? And even if you can't run STBYPASS (because you don't have Sixpack 1.3 or are running MVS V=V), the newer ECPS:VM support also assists shadow and page table validations. Let's don't complain about it!? Let's get out there and try it.? I think you'll be pleasantly surprised. Regards, Bob |
开云体育On 1/30/20 1:47 AM, Dave Wade wrote:
The S/158 processor could run as a channel or CP as well.? In fact, the 3033 used 158 engines running in pure channel mode under the covers.? |
Our Amdahl didn't have any assists unfortunately (and we used to get a whole lot of grief with mail coming in over the EARN link from Rutherford with reversed domain addresses...) It could move EARN/MAIL/LISTSERV traffic without missing a beat, plus a wholeThis was on an Amdahl 5870 (AP) with 64MB of real storage, VM/HPO and aThat is rather a different beast to a 4341 which typically had 4MB of bunch of people reading and writing mail in CMS (which was really XEDIT under the covers) and a few running Waterloo Script but it started to feel it when there was a classful of students doing VSFORTRAN compiles or submitting SAS jobs. The AP was added when it was decided to move the MUSIC users (142 terminals minus whatever number weren't working on any particular day) onto it. The MUSIC users were mostly using VSFORTRAN too after migrating from the less resource hungry WATFIV. Unfortunately, I never saw any tools in HPO for looking at what memory above 16MB was doing. We used to have something called Explore/VM which probably could but the license for that was cancelled just before I got to play with it :-( The previous sysprog had been unable to get CPWATCH to work on HPO and had abandoned it. MUSIC was not running V=R on the Amdahl. I think the 12MB may have been a legacy from when it previously ran V=R on a 4381 before it was moved to the Amdahl. I do recall a moan about something along the lines of I/O only being possible from the lower 16MB so if MUSIC had 16MB, it would likely be all paged in most of the time due to the large number of users on MUSIC so what would that leave the CMS users to do I/O from. Maybe he was afraid of having MUSIC performing too well in case all his CMS users got moved on to it! Should be worth a go. It really scoots along on Hercules even on an old Alpha so it should be quite happy on a P390. Regards, Peter Coghlan |
开云体育Bob, ? I said “can fall of”! Of course in our situation , running 360 and 370 operating systems with typically a trivial workload on hardware that out performs anything that the original software ever ran on by a factor of around 10 its unlikely that we will experience the sort of problems small sites experienced on 4330, 4340 and 4360 mid-range boxes. ? I well remember the issues IBM had on their PROFS experience days. These involved a classroom of business folks role playing to experience how PROFS could help. When the days first started, they got everyone to log on at the same time. The poor little 4361 (I think it was a 61) was not happy with this and sulked. “IND LOAD” showed horrific expansion factors. The eventual “fix” was to get the users to describe their role, and then logon, in turn. This spread the load out and 4361 was then a happy little bunny. ? So even with 20 or so the little box struggled when the all logged on at once… ? … but spread the load out and it was fine…. ? Dave ? From: [email protected] <[email protected]> On Behalf Of Bob Polmanter
Sent: 30 January 2020 20:58 To: [email protected] Subject: Re: [h390-vm] VM/370 Hercules Optimisation ?
|
|
>I said “can fall of”! Of course in our situation , running 360 and 370 operating systems with typically a trivial workload on >hardware that out performs anything that the original software ever ran on by a factor of around 10 its unlikely that we will >experience the sort of problems small sites experienced on 4330, 4340 and 4360 mid-range boxes.
Dave, I understand. System performance became something of a career thing for me back in the day.? We did run MVS as a guest under VM/SP HPO in a production environment on a 16MB 4381, and as the system programmer I had to make it work and make it run well, or else.? We ran MVS in an 8 MB V=R space, using PMA? (Preferred Machine Assist, remember that?).? The CMS users got the other 8 MB.? We had a couple of hundred CMS users in the directory but most of the time we would have 40-60 logged on at most, and probably a lot of them were idle.? MVS always had a large batch load active, but hardly any TSO activity fortunately (for the system). The bane of my existence was a statistical product called SAS, which for us ran under CMS.? The mathematicians and programming staff at my site loved it, but it was nothing but a headache for me.? The thing was a pig, a pile of bloated compiled code and it sent our paging rate skyrocketing.? After a few years the SAS people did get a large portion of their product into shared segments and that helped tremendously.? But it was a CPU hog even still. Later still, we eventually got 32MB on the 4381 and that helped a lot.?? All good stuff. Regards, Bob |