Conference vaxaxp::vmsnotes

    
>    ACP_WINDOW=255 looks bogus to me. If they really need that much then
>    they should get some defragmentation happening. I would suggest that
>    taking the default of 7 would be more generally appropriate.
>

The following is from an older note in the VMSTUNING conference that would 
disagree with .2 regarding acp_window. Anyone from VMS Engineering care to 
comment based on more current info ??

Thanks

Arlan


             <<< VMSDEV::NOTESD$:[NOTES$LIBRARY]VMSTUNING.NOTE;2 >>>
                                 -< VMSTUNING >-
================================================================================
Note 1221.2              Improving Window Turn Rate ...                   2 of 4
VMSDEV::HALLYB "Fish have no concept of fire."        9 lines   8-SEP-1992 10:06
                         -< Files-11 showing its age >-
--------------------------------------------------------------------------------
    As I recall, a retrieval pointer can only cover 65K blocks.  
    So 7 retrieval pointers can only cover 458K blocks or so.
    If you have a random file larger than that, you will likely see
    many window turns.
    
    .1 has the right idea.  Set ACP_WINDOW to 50 or so.  the value of 7
    dates from 1978 when a megabyte of memory was a lot.
    
      John 

    I don't think John was right in his entry in VMSTUNING.  I don't
    remember the Files-11 details but I believe there are at least 2 forms
    of retrieval pointers.  The old, small form may be what John referred
    to.
    
    A quick test creating a large file and looking at the retrieval pointers
    with  du/head/bl=en=0 x.x  shows at the end:
    
    
    Map area
        Retrieval pointers
            Count:    2053948        LBN:    2056532
            Count:    1584632        LBN:     470608
            Count:     361420        LBN:      67220
    

    re .3
    
    Well I'm not from VMS Engineering but...
    
    In the file header (on disk format) the mapping information has a
    variable format which helps to increase the amount of mapping
    information that can be stored in one file header i.e. before one needs
    an extension header. Each retrieval pointer (comprising a starting
    logical block number and a count of blocks) (ideally) maps one fragment
    of a file and can be represented in a format different from other
    pointers in the same file header, with the format being chosen
    appropriate to the size of the fragment (i.e. count of blocks).
    
    It is my recollection that within living memory a new on disk retrieval
    pointer format was added that allowed a larger count of blocks in one
    retrieval pointer (rather than requiring multiple retrieval pointers to
    represent even a single large fragment). [Of course that just pushes the
    problem further away - far enough away for any app I've ever encountered.]

    The in memory format could conceivably have changed since John wrote
    his note but certainly as at V6.2 (what I have installed) the in memory
    format is just vanilla longwords for block count and starting LBN.
    Logical design would suggest that this "uncompressed" fast access
    format would have been there from day 1 but I can't confirm that.
    
    What is not clear is whether the XQP is capable of merging retrieval
    pointers when it converts from on disk format to in memory format - but
    this is essentially irrelevant now that the on disk format supports a
    larger fragment per retrieval pointer.
    
    Even if the note is correct, requiring 255 retrieval pointers due to a
    64K blocks per retrieval pointer limit translates to a *very* large file.
    [Actually it looks to me that the on disk limit would have been 16384
    blocks but that still makes a large file.]
    
    And finally it must be noted that this SYSGEN parameter is setting the
    default for all opened files. Doing so will in general be highly
    wasteful (albeit that memory is not exactly scarce these days). For any
    particular file that is millions of blocks long that one file can be
    opened overriding the default.

    Prior to OpenVMS VAX V6.0 the WCB entry consisted of a 24-bit field
    pointing to the starting LBN of the extend, and a 16-bit field as the
    count. 16-bits translates to 65535 blocks, and with the default window
    size of 7 you could map 458745 blocks at any one time without incurring
    window turns. Also note, that the maximum window size was 79 for
    pre-V6.0.
    
    OpenVMS V6.x and later does not have this problem. The size of both
    fields have been increased to 31 bits. A 31-bit field can map
    2147483648 blocks per pointer, which should suffice.
    
    Bottom line: assuming you run a somehow modern version of the OS,
    get rid of the ACP_WINDOW=255.
    
    /cmos

    re .6
    
    Even for the pre-V6.0 64K blocks per in memory pointer limit, a default
    window size of, say, 70 would be likely inappropriate. That is saying
    that typically the files they open are 4 million blocks long which
    seems highly unlikely.