I think part of the problem is, because it says MINIMUM.MODULUS, we think of it as analogous to the modulus of a hashed file. It isn't.
It's more of a hint to the system about how big the file is likely to be, and how to avoid wasting effort. So if you're creating a file and intend to load it with a lot of data, you can tell the system "don't bother creating a small file, because it's going to grow immediately. You're best off starting with X" (where X is what it's going to be when you've loaded it). A second use is where a file fluctuates rapidly in size, and you want to tell the system "don't bother shrinking it, because it's going to grow again very soon". Cheers, Wol -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 29 November 2007 15:39 To: u2-users@listserver.u2ug.org Subject: Re: [U2][UV] Dynamic File MINIMUM.MODULUS Calculation My experience seems to demonstrate that setting the MINIMUM.MODULUS to the size of the data works best, and then needs to be adjusted in much the same way a static file would need to be resized. With that said, however, for files that grow and shrink continuously during a given period, i.e. each month, I found that setting the MINIMUM.MODULUS to roughly 2/3 to 3/4 the largest size the file grew during the month to seem to allow the file to perform at a reasonable rate. This is based on trial and error. In your situation I'm hoping there are some good, hard and fast rules you can glean from this list... and good luck because I'm suspecting there aren't any because of the many and varied applications and environments involved. Karl <quote who="Perry Taylor"> > I continue to struggle with accurate calculation of MINIMUM.MODULUS > values for dynamic files. Static hashed files do not seem to be such a > challenge for me. > > Here is an example where, once again, I was woefully shy... > > ----------------------------------------------------------------------- > File name .................. CLM.RUN.STRIP.PROVDATA > Pathname ................... CLM.RUN.STRIP.PROVDATA > File type .................. DYNAMIC > Hashing Algorithm .......... GENERAL > No. of groups (modulus) .... 19618 current ( minimum 7867, 0 empty, > 8869 overflowed, 4612 badly > ) > Number of records .......... 719305 > Large record size .......... 75 bytes > Number of large records .... 6614 > Group size ................. 2048 bytes > Load factors ............... 80% (split), 50% (merge) and 80% (actual) > Total size ................. 69978112 bytes > Total size of record data .. 46331730 bytes > Total size of record IDs ... 5114218 bytes > Unused space ............... 18528068 bytes > Total space for records .... 69974016 bytes > > File name .................. CLM.RUN.STRIP.PROVDATA > Number per group ( total of 19618 groups > ) > Average Minimum Maximum StdDev > Group buffers .............. 1.74 1 15 1.19 > Records .................... 36.67 10 68 12.15 > Large records .............. 0.34 1 4 0.58 > Data bytes ................. 2361.69 350 30359 2270.12 > Record ID bytes ............ 260.69 70 491 86.71 > Unused bytes ............... 944.44 24 2068 650.69 > Total bytes ................ 3566.83 2048 30720 0.00 > > > Number per record ( total of 719305 > records ) > Average Minimum Maximum StdDev > Data bytes ................. 64.41 34 28700 353.25 > Record ID bytes ............ 7.11 2 20 1.14 > Total bytes ................ 71.52 36 28720 354.13 > ----------------------------------------------------------------------- > > I cannot seem to figure out the relationship of the current modulus to > the record sizes/counts/group size factors. When I do the math I always > come up short. > > Can someone offer some suggestions for accurate calculation of > MINIMUM.MODULUS? > > Thanks. > > Perry Taylor > ZirMed, Inc. > > CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is > for the sole use of the intended recipient(s) and may contain confidential > and privileged information. Any unauthorized review, use, disclosure or > distribution is prohibited. ZirMed, Inc. has strict policies regarding the > content of e-mail communications, specifically Protected Health > Information, any communications containing such material will be returned > to the originating party with such advisement noted. If you are not the > intended recipient, please contact the sender by reply e-mail and destroy > all copies of the original message. > ------- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ > -- Karl Pearson Director of I.T. ATS Industrial Supply, Inc. [EMAIL PROTECTED] http://www.atsindustrial.com 800-789-9300 x29 Local: 801-978-4429 Fax: 801-972-3888 "To mess up your Linux PC, you have to really work at it; to mess up a microsoft PC you just have to work on it." ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
