Re: Compression figures, anyone?
I made a mistake in my numbers, reading seconds as minutes, and have added AMATERSE just to round off the mix. Just shouldn't respond when the fridge is calling. ICEGENER copy NO Compression 108 trks 0.09 secs SMS Compression 76 Trks, 0.32 secs ISPZIP Compression 8 trks 1.18 secs AMATERSE Compression 9 trks 2.03 secs Cheers, Paul Gillis -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Compression figures, anyone?
G'day Greg, Thought I would take the opportunity to run a quick test on a z800. Copying a 108 track SMF dataset. 1. Using ICEGENER without compression 9 CPU seconds into 108 tracks. 2. Using ICEGENER with compression 30 CPU seconds into 76 tracks. 3. Using ISPZIP compression 78 CPU seconds into 8 tracks. As usual you get what you pay for and the more compression you want the more expensive it is in CPU terms. From the Cambridge Online Dictionary. Compressible, the third meaning is, To make a computer file use less space when it is stored in the memory of a computer or on a disk, by using a special program: Compressable is not known. It's now Beer O'clock, Cheers, Paul Gillis What I was really fishing for was user experiences with using DFSMS compressed extended-format sequential data sets. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Compression figures, anyone?
Paul Gillis wrote: G'day Greg, Thought I would take the opportunity to run a quick test on a z800. Copying a 108 track SMF dataset. 1. Using ICEGENER without compression 9 CPU seconds into 108 tracks. 2. Using ICEGENER with compression 30 CPU seconds into 76 tracks. 3. Using ISPZIP compression 78 CPU seconds into 8 tracks. Thanks for that very interesting info, Paul - as well as the dictionary lookups! (Obviously the best part of your timekeeping was exhibited in your sign-off.) OT: Thanks also to an off-list responder - verizon.net blocks emails from my IP address because it is thought to be a source of SPAM. And YAPG (Yet Another Paul G. - Gil) was pretty right on in another thread about what I was looking for in having zip files supported. Cheers, Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Compression figures, anyone?
Hi. My semi-facetious remark about ZIP archives got me wondering about what sort of compression ratios users of compressed extended-format data sets are getting. Zipping text can get 75% to 90% compression (ie. reducing the data to 25% to 10% of its size). How's that compare? Of course, no matter what the size reduction is, I'd expect it to use a lot less CPU time than a zipping app. So, anyone care to share? TIA, Greg P. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Compression figures, anyone?
Greg, I used to get about 80% when zipping SMF data, haven't done that for a while and never considered the CPU cost as I had to get the data under 2Gb. The reasons are now obsolete. The zip engine I used on MVS was ISPZIP from ASE. I may still have the performance numbers somewhere. Cheers, Paul Gillis Subject: Compression figures, anyone? Hi. My semi-facetious remark about ZIP archives got me wondering about what sort of compression ratios users of compressed extended-format data sets are getting. Zipping text can get 75% to 90% compression (ie. reducing the data to 25% to 10% of its size). How's that compare? Of course, no matter what the size reduction is, I'd expect it to use a lot less CPU time than a zipping app. So, anyone care to share? TIA, Greg P. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Compression figures, anyone?
I just completed an exercise using PKZIP on the mainframe for SMF data several 24-hour periods for SMF types 30 (subtypes 4 and 5 only), 70, 72, and some others. The compression percentage achieved was upwards of 90%, taking what was a 4GB data file down to about 250MB. This pre-processing eased significantly the data-transfer bandwidth and elapsed-time consideration for moving the large amount of SMF data from an MVS machine to Windows for SAS/Windows processing. Scott Barry SBBWorks, Inc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Compression figures, anyone?
On Fri, 5 Sep 2008, Greg Price wrote: Hi. My semi-facetious remark about ZIP archives got me wondering about what sort of compression ratios users of compressed extended-format data sets are getting. From my reading, SMS uses LZW type compression. I guess that is what ZIP uses as well. Zipping text can get 75% to 90% compression (ie. reducing the data to 25% to 10% of its size). How's that compare? Of course, no matter what the size reduction is, I'd expect it to use a lot less CPU time than a zipping app. How much money are you willing to lose on this? In our testing on a z800 (may be better now), SMS compression was too expensive in terms of CPU to implement in a general case. SMS compression is likely implemented in millicode, so it will not be __significantly__ faster than an optimal HLASM implementation LZW, which I assume ZIP has. So, anyone care to share? TIA, Greg P. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Q: What do theoretical physicists drink beer from? A: An EIN stein. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Compression figures, anyone?
Paul Gillis wrote: Greg, I used to get about 80% when zipping SMF data, haven't done that for a while and never considered the CPU cost as I had to get the data under 2Gb. The reasons are now obsolete. The zip engine I used on MVS was ISPZIP from ASE. I may still have the performance numbers somewhere. Cheers, Paul Gillis Hi Paul, Yes, I've seen that software used to great effect for years, also. And I see that Scott has posted about the advantages of zipping SMF data. All great stuff, and I concur completely. What I was really fishing for was user experiences with using DFSMS compressed extended-format sequential data sets. And if that doesn't trigger a response, perhaps we can start a thread about compressable (as I recall seeing in an IBM manual) vs compressible (the spelling a spell-checker (MSWord?) okays). As I may have said, I would expect the latest and greatest z hardware to be able to deliver compression ratios comparable to zipping in only a fraction of the CPU time. Maybe the CPU time aspect is hard to measure, and I don't think zipping is that much of an expensive process anyway, but I _am_ hoping that someone can report of the level of compression being achieved. If I tell people that using compressable extended-format is a superior solution to zipping files in terms of overall computer resources (with disk space being a large part of that), am I telling fibs? Cheers, Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
