[url]http://www.stevedunn.ca/[/url] <----------------<<<[/quote][/quote][/quote] ------------------------------------------------------------------ Say hi to my cat -- [url]http://www.stevedunn.ca/photos/toby/[/url] [allowsmilie] => 1 [showsignature] => 0 [ipaddress] => [iconid] => 0 [visible] => 1 [attach] => 0 [infraction] => 0 [reportthreadid] => 0 [isusenetpost] => 1 [msgid] => [ref] => [htmlstate] => on_nl2br [postusername] => Stephen M. Dunn [ip] => stephen@stevedu [isdeleted] => 0 [usergroupid] => [membergroupids] => [displaygroupid] => [password] => [passworddate] => [email] => [styleid] => [parentemail] => [homepage] => [icq] => [aim] => [yahoo] => [msn] => [skype] => [showvbcode] => [showbirthday] => [usertitle] => [customtitle] => [joindate] => [daysprune] => [lastvisit] => [lastactivity] => [lastpost] => [lastpostid] => [posts] => [reputation] => [reputationlevelid] => [timezoneoffset] => [pmpopup] => [avatarid] => [avatarrevision] => [profilepicrevision] => [sigpicrevision] => [options] => [akvbghsfs_optionsfield] => [birthday] => [birthday_search] => [maxposts] => [startofweek] => [referrerid] => [languageid] => [emailstamp] => [threadedmode] => [autosubscribe] => [pmtotal] => [pmunread] => [salt] => [ipoints] => [infractions] => [warnings] => [infractiongroupids] => [infractiongroupid] => [adminoptions] => [profilevisits] => [friendcount] => [friendreqcount] => [vmunreadcount] => [vmmoderatedcount] => [socgroupinvitecount] => [socgroupreqcount] => [pcunreadcount] => [pcmoderatedcount] => [gmmoderatedcount] => [assetposthash] => [fbuserid] => [fbjoindate] => [fbname] => [logintype] => [fbaccesstoken] => [newrepcount] => [vbseo_likes_in] => [vbseo_likes_out] => [vbseo_likes_unread] => [temp] => [field1] => [field2] => [field3] => [field4] => [field5] => [subfolders] => [pmfolders] => [buddylist] => [ignorelist] => [signature] => [searchprefs] => [rank] => [icontitle] => [iconpath] => [avatarpath] => [hascustomavatar] => 0 [avatardateline] => [avwidth] => [avheight] => [edit_userid] => [edit_username] => [edit_dateline] => [edit_reason] => [hashistory] => [pagetext_html] => [hasimages] => [signatureparsed] => [sighasimages] => [sigpic] => [sigpicdateline] => [sigpicwidth] => [sigpicheight] => [postcount] => 2 [islastshown] => [isfirstshown] => [attachments] => [allattachments] => ) --> NBUF limits on all OpenServer versions - SCO

NBUF limits on all OpenServer versions - SCO

Hi all, After some searches on google, it seems that the value for NBUF in these systems is limited to around 450MB. If the above is correct, is there anyone that knows why this limit wasn't increased with 5.0.7? Technical explanation appreciated. If incorrect how do we change it to be above that limit as some of my colleagues would like to be able to do it. Thanks all Frederico Fonseca ema il: frederico_fonseca at syssoft-int.com...

  1. #1

    Default NBUF limits on all OpenServer versions

    Hi all,


    After some searches on google, it seems that the value for NBUF in
    these systems is limited to around 450MB.

    If the above is correct, is there anyone that knows why this limit
    wasn't increased with 5.0.7?
    Technical explanation appreciated.

    If incorrect how do we change it to be above that limit as some of my
    colleagues would like to be able to do it.


    Thanks all




    Frederico Fonseca
    ema il: frederico_fonseca at syssoft-int.com
    Frederico Fonseca Guest

  2. #2

    Default Re: NBUF limits on all OpenServer versions

    In article <ccqkkvkqv0q7i217f7oitvj6o4b2b7lc6e4ax.com> [email]real-email-in-msg-spamemail.com[/email] writes:
    $After some searches on google, it seems that the value for NBUF in
    $these systems is limited to around 450MB.
    $
    $If the above is correct, is there anyone that knows why this limit
    $wasn't increased with 5.0.7?
    $Technical explanation appreciated.

    I don't know the kernel innards; only someone like Bela or John
    would be able to post an answer that is based on definitive
    knowledge of this (and quite probably also definitive knowledge
    of engineering discussions about what things ought to be changed
    in various OS releases).

    But here's a guess. Most data structures include both the data
    itself (the buffer, in this case), plus some kind of administrative
    overhead - linked lists, information about just what actually is in
    the data (like whether the buffer in question is dirty, which block on
    which device has its contents in this buffer), and so on.

    Most system limits in binary computers are powers of two.
    512 MB is a power of two. Each buffer is 1 kB, plus whatever
    the overhead is. Multiply that by 450 000 (the limit for NBUF)
    and I'm guessing you'll get slightly under 512 MB.

    Now, why there's a 512 MB limit ... dunno. There's a 4 GB
    addressing limit on the 80386. Yes, this has been increased in
    more recent CPUs, but OSR5 is fundamentally a 386 OS, and
    while the minimum system requirement is a Pentium, it also states
    that customized versions will run on 386 machines, so the kernel
    must still be 386 code with support for later CPUs. So this
    512 MB probably relates to some kind of memory layout that
    was designed in the 386 days. This layout may be so deeply
    ingrained in the kernel that it would be a major undertaking to
    increase the maximum value of NBUF, or maybe it would break
    device drivers that were written based on that layout, or something
    like that.

    Like I said, just a guess.
    --
    Stephen M. Dunn <stephenstevedunn.ca>
    >>>----------------> [url]http://www.stevedunn.ca/[/url] <----------------<<<
    ------------------------------------------------------------------
    Say hi to my cat -- [url]http://www.stevedunn.ca/photos/toby/[/url]
    Stephen M. Dunn Guest

  3. #3

    Default Re: NBUF limits on all OpenServer versions

    Frederico Fonseca wrote:
    > After some searches on google, it seems that the value for NBUF in
    > these systems is limited to around 450MB.
    >
    > If the above is correct, is there anyone that knows why this limit
    > wasn't increased with 5.0.7?
    > Technical explanation appreciated.
    >
    > If incorrect how do we change it to be above that limit as some of my
    > colleagues would like to be able to do it.
    The limit remains 450MB.

    Buffer cache buffers are allocated out of kernel virtual addresses which
    can be "direct mapped". These are addresses in the C0000000-DFFFFFFF
    range. Kernel virtual addresses in this range can be converted to
    physical addresses by subtracting C0000000; and conversely, physical
    addresses below 20000000 can be converted to kernel virtual addresses by
    adding C0000000. (Of course there are macros that should be used. You
    wanted the technical details...)

    The total range in question is 1/2 gigabyte. The actual limit of 450MB
    was arbitrarily set to leave some direct-map space for other uses. It
    could probably be pushed up to 475MB or something like that, but I
    doubt you would find such a small increment helpful.

    Why is the direct map important here? HBAs usually need to know the
    physical address of a transfer buffer, since the DMA hardware speaks
    physical addresses. Converting an virtual address to a physical address
    is very cheap for addresses in the direct map. It's expensive for other
    addresses, requiring the kernel to walk data structures looking for the
    translation. HBA drivers typically use the cheap macros instead of the
    expensive data-structure-walking functions; especially since the buffer
    cache is designed to always give them a direct-map buffer address.

    Expanding beyond the direct map would require one of:

    (1) another bounce-buffer scheme where the buffer cache would always
    pass direct-map addresses to the HBA driver, then copy the data
    elsewhere (as is already done for HBA drivers that do ISA DMA to
    addresses < 16MB); or

    (2) new protocols between HBA drivers and the buffer cache, so the
    buffer cache would know which buffers never to deliver to a
    particular HBA. This would also require updated HBA drivers to
    take advantage of the new scheme.
    >Bela<
    Bela Lubkin Guest

  4. #4

    Default Re: NBUF limits on all OpenServer versions

    On Mon, 25 Aug 2003 20:58:48 +0100, Frederico Fonseca
    <real-email-in-msg-spamemail.com> wrote:
    >Hi all,
    >
    >
    >After some searches on google, it seems that the value for NBUF in
    >these systems is limited to around 450MB.
    >
    >If the above is correct, is there anyone that knows why this limit
    >wasn't increased with 5.0.7?
    >Technical explanation appreciated.
    >
    >If incorrect how do we change it to be above that limit as some of my
    >colleagues would like to be able to do it.
    >
    >
    >Thanks all
    >
    >
    >
    >
    >Frederico Fonseca
    >ema il: frederico_fonseca at syssoft-int.com
    Bela and Steve,

    Thank you both for your answers.
    The tech bit is good enough and does clarify the reasons why.


    Thanks.

    Frederico Fonseca


    Frederico Fonseca
    ema il: frederico_fonseca at syssoft-int.com
    Frederico Fonseca Guest

Similar Threads

  1. OpenServer 5.0.6
    By Roberto in forum SCO
    Replies: 4
    Last Post: November 26th, 04:21 PM
  2. What will happen to OpenServer...
    By brian in forum SCO
    Replies: 6
    Last Post: September 10th, 12:27 AM
  3. SCO OpenServer 5.0.5 Error
    By Jean-Pierre Radley in forum SCO
    Replies: 3
    Last Post: July 15th, 12:02 AM
  4. Replies: 2
    Last Post: July 8th, 09:40 PM
  5. How do I increase NBUF safely?
    By Andrey Bondar in forum SCO
    Replies: 1
    Last Post: June 25th, 02:32 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •