just found out Linux>> per Linux guy>> 1492 is the mtu size he sees from his image?? is there not a specification on Linux or ?? where you specify it as a Gig Ethr ?
----- Forwarded by Ron Wells/AGFS/AGFin on 04/13/2010 03:39 PM ----- From: Ron Wells/AGFS/AGFin To: IBM Mainframe Discussion List <IBM-MAIN@bama.ua.edu> Date: 04/13/2010 03:15 PM Subject: Re: LINUX on the MAINFRAME does anyone have any base numbers they could share... (example) We are shaking down z/VM 5.4-rsu0901-own lpar-4gig central/1.5 expanded..(1) IFL All following Linux images are at SP3/(1) webshhere7(server pack unknow) / (1)DB2Connect Linux and couple others as test/devl images ...2gig for each image Vswitch set for (1)OSA-E Gig .. Hypersockets used between the Linux images/VM and z/OS(running in seperate lpar ). The outbound traffic-OSAGig connect to a AS400(s) test at this point DB2 servers.. Was thinking something in Linux definition that could slow things down>> like it's definition for OSAgig.? From: Anne & Lynn Wheeler <l...@garlic.com> To: IBM-MAIN@bama.ua.edu Date: 04/13/2010 02:40 PM Subject: Re: LINUX on the MAINFRAME Sent by: IBM Mainframe Discussion List <IBM-MAIN@bama.ua.edu> mpac...@gmail.com (Mark Pace) writes: > That is a very good point, John. Memory management on Linux for the > mainframe is counter-intuitive. When running under zVM you want as little > memory as you can get away with, not as much as you can get. Most any > question you can think of has probably been covered ad-nausea on the > Linux-390 list. this was discovered in the early 70s when apl\360 was ported to cp67/cms for cms\apl. The apl\360 storage management and garbage collection algorithm allocation a new storage location on every assignment. It very quickly cycled thru all available workspace ... until it had exhausted storage and then did garbage collection ... and then repeated. This wasn't too bad with 16kbyte-32kbyte real storage workspaces that were swapped in total every time ... but became disastrous in large virtual memory paged environment. The apl\360 storage management and garbage collection had to be redone for cms\apl for large virtual memory paged environment. I pointed this out again later in 70s with vs2 (svs & then mvs) ... regarding running a "LRU" page replacement algorithm (least recently used) in a virtual machine under a "LRU" page replacement algorihtm (managing virtual machine memory as virtual paged memory). The scenario was that the guest operating system in the virtual machine would be trying to use the (virtual machine) page that had least recently been used ... while the underlying vm operating system would have been removing those very same virtual pages from real storage. There could be extremely pathelogical characteristics where the virtual guest operating system was always selecting the next virtual machine page to use ... that vm370 had just selected to be removed from memory. misc. past posts mentioning having done page replacement algorithms as undergraduate in the 60s. http://www.garlic.com/~lynn/subtopic.html#wsclock recent posts mentioning getting pulled into academic dispute over page replacement algorithms in the early 80s (involving whether or not to give somebody a stanford phd based on thier work in the area): http://www.garlic.com/~lynn/2010f.html#85 16:32 far pointers in OpenWatcom C/C++ http://www.garlic.com/~lynn/2010g.html#22 Mainframe Executive article on the death of tape http://www.garlic.com/~lynn/2010g.html#42 Interesting presentation http://www.garlic.com/~lynn/2010g.html#68 What is the protocal for GMT offset in SMTP (e-mail) header the above mentions taking nearly a year to get management approval to respond ... even tho it involved work that I had done as an undergraduate (probably some petty punishment as opposed to management taking sides in the academic dispute ... it was also after having brought down the wrath of the MVS organization on my head). -- 42yrs virtualization experience (since Jan68), online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- Email Disclaimer This E-mail contains confidential information belonging to the sender, which may be legally privileged information. This information is intended only for the use of the individual or entity addressed above. If you are not the intended recipient, or an employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution, or the taking of any action in reliance on the contents of the E-mail or attached files is strictly prohibited. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
