home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The Mother of All Windows Books
/
CD-MOM.iso
/
cd_mom
/
drivers
/
netcard
/
ub
/
readme2.txt
< prev
next >
Wrap
Text File
|
1991-09-05
|
10KB
|
173 lines
; Sample PROTOCOL.INI for UBNEPS
; ------------------------------
; This is a sample PROTOCOL.INI file for the Ungermann-Bass NDIS MAC driver
; for NICps/2 cards ("UBNEPS"). The [UBNEPS] section shows examples of UBNEPS
; configuration parameter settings. Comments at the end of the file explain
; these parameters and give their default, minimum and maximum values.
; The [protocol manager] and [netbeui] sections aren't meant to be complete
; or realistic examples, except for the "BINDINGS = UBNEPS" line in the
; [netbeui] section.
;
;[protocol manager]
; DRIVERNAME = PROTMAN$
;
;[netbeui]
; DRIVERNAME = NETBEUI$
; BINDINGS = UBNEPS
; SESSIONS = 32
; NCBS = 100
;
;[UBNEPS]
; Note that many of these parameters have default values (which are
; given below under "Comments about UBNEPS parameters"). A parameter need not
; be specified in your PROTOCOL.INI if its default value is satisfactory.
DriverName = UBNEPS$
; SlotNumber = 4
MaxTransmits = 6
; TransmitBuffers = 2
ReceiveBufSize = 600
MaxMulticast = 16
ReceiveMethod = ReceiveLookahead
ReceiveBuffers = 64
; Comments about UBNEPS parameters:
; --------------------------------
; DriverName:
; This parameter's value must be UBNEPS$, or, in the case where
; multiple adapters are installed, UBNEPS$ for the first adapter's
; DriverName, UBNEPS2$ for the second one, UBNEPS3$ for the third, and
; so on.
; SlotNumber: (Min = 1; Max = 8.)
; This parameter is needed only when multiple NICps/2 adapters, and
; multiple instances of the UBNEPS driver, are installed. Even then,
; this parameter is required only if it is necessary to override the
; default association between driver instances and adapters. By default,
; the UBNEPS driver instance that comes first in PROTOCOL.INI will be
; associated with the NICps/2 adapter in the lowest numbered slot, the
; UBNEPS driver instance that comes second will be associated with the
; NICps/2 adapter in the second lowest numbered slot, and so on.
; MaxRequests: (Default = 6; Min = 1; Max = 10.)
; This specifies the maximum number of "GeneralRequest"s that can be
; simultaneously outstanding.
; MaxTransmits: (Default = 8; Min = 1; Max = around 400.)
; This specifies the number of "TransmitChain"s that the MAC driver
; guarantees to accept without giving an "OUT_OF_RESOURCE" response.
; TransmitBuffers: (Default = 2; other choice = 4.)
; This specifies the number of transmit buffers that will be
; allocated in the adapter's memory.
; MaxMulticast: (Default = 16; Min = 0; Max = 255.)
; This specifies the maximum number of multicast addresses that can
; be in effect simultaneously. (NOTE that there's no 's' on the end of
; this keyword.)
; ReceiveBufSize: (Default = 600; Min = 256; Max = 1514.)
; This specifies the size of the receive buffers the MAC driver will
; use. This should be large enough to hold the normal expected received
; frame. It need not be large enough to hold the largest expected frame.
; The MAC driver will handle large frames in multiple receive buffers.
; The value of ReceiveBufSize must be even.
; ReceiveMethod: (Default = ReceiveLookahead;
; other choices: ReceiveChain, AdapterBuffered
; and ReceiveChain, HostBuffered
; This determines the method of received frame delivery the MAC
; driver will use. The possibilities are described below. Which one
; is best to use depends mainly on how the Protocol driver you're using
; works. Use number (1) if you don't know anything about the Protocol
; driver.
; (1) ReceiveMethod = ReceiveLookahead
; When a received frame is available and Indications are On, the
; MAC driver will call the Protocol driver's "ReceiveLookahead" routine.
; "ReceiveLookahead" will be given the total length of the frame and a
; pointer to the "lookahead" data in a receive buffer in the adapter's
; RAM. The Protocol driver must copy the frame (possibly using the MAC's
; "TransferData" routine) before returning from "ReceiveLookahead". When
; "ReceiveLookahead" returns, the MAC driver frees the receive buffers
; in the adapter's RAM for use in receiving more frames.
; This method works well if the Protocol driver is able to copy the
; frame to the Protocol driver's client's buffers at the time "Receive-
; Lookahead" is called. It is also a good method if the Protocol driver
; always copies frames into internal buffers of its own.
; (2) ReceiveMethod = ReceiveChain, AdapterBuffered
; When a received frame is available and Indications are On, the MAC
; driver will call the Protocol driver's "ReceiveChain" routine, passing
; it an "RxBufDescr" which points to the frame in the receive buffers in
; the adapter's RAM. The Protocol driver can either (a) immediately copy
; the frame or (b) save a copy of the "RxBufDescr" and leave the frame
; in the buffers in the adapter's RAM, to be copied at a later time. In
; case (b), the Protocol driver must copy the frame as soon as possible
; and call the MAC's "ReceiveRelease" function to make the buffers in
; the adapter's RAM available for receiving more frames.
; This method of operation can be the most efficient. It's a little
; better than the "ReceiveLookahead" method if the Protocol driver can
; copy the frame immediately, because the overhead of calling "Transfer-
; Data" is avoided. Also, it has the advantage over "ReceiveLookahead"
; that the Protocol driver doesn't have to copy the frame immediately --
; the frame can be left for a short time in the adapter's buffers. But
; if frames are left in the adapter's buffers long, it will run out of
; buffers and start losing frames. Also, there's the overhead of calling
; "ReceiveRelease" to consider.
; (3) ReceiveMethod = ReceiveChain, HostBuffered
; When a received frame is available and Indications are On, the MAC
; driver will copy the frame from the receive buffers in the adapter's
; RAM into receive buffers in the Host memory and call the Protocol
; driver's "ReceiveChain" routine, passing it an "RxBufDescr" which
; points to the Host-memory buffers. The Protocol driver can copy the
; frame immediately or leave it in the Host-memory buffers. It must
; eventually call the MAC driver's "ReceiveRelease" routine to free the
; Host-memory buffers for reuse. The buffers in the adapter's RAM are
; made available for receiving more frames as soon as "ReceiveChain"
; returns.
; In this mode, the MAC driver allocates receive buffers in the Host
; memory. These buffers are allocated at driver INIT time. Their number
; and size are determined by the "ReceiveBuffers" and "RcvBufSize" para-
; meters. The only advantage of this mode is that in it the MAC driver
; provides a possibly large amount of long-term frame buffering in which
; a Protocol driver can leave received frames until it can deliver them
; to its clients. This advantage comes at the cost of the space devoted
; to the Host-memory buffers. This is an inefficient mode if the
; Protocol driver always copies frames into its own internal receive
; buffers or if it can quickly copy frames from the adapter's buffers to
; its client's buffers.
; ReceiveBuffers: (Default = 32; Min = 16; Max = 512.)
; This specifies the number of receive buffers that the MAC driver
; will allocate in the Host memory. This parameter is meaningful only
; if "ReceiveMethod = ReceiveChain, HostBuffered" is specified. For
; other values of "ReceiveMethod", no receive buffers will be allocated
; in the Host memory -- the "ReceiveBuffers" parameter will be ignored.
; PermanentAddr: The value is a string of 12 ASCII hexadecimal digits,
; for example: PermanentAddr = "00DD01AABBCC"
; This parameter provides a way to override the "Permanent Station
; Address" that's built into the adapter's ROM. Note that this parameter
; is normally not needed, and shouldn't be used. The NDIS specification
; strongly discourages configuring the "Permanent Station Address".
;
; How Much Host Memory UBNEPS Uses
; --------------------------------
; You can compute the amount of PC memory UBNEPS will use. It depends
; on the "ReceiveMethod" you select and on the values you choose for the
; "MaxRequests", "MaxTransmits", "MaxMulticast", "ReceiveBuffers", and
; "ReceiveBufSize" parameters. The total space used will be the sum of
; the following five items.
; (1) For driver code and data: 10210 (2566 data + 7644 code)
; (2) For request queueing: 16 + MaxRequests * 22
; (3) For transmit queueing: 16 + (MaxTransmits - TransmitBuffers) * 146
; (4) For multicast addresses: 4 + (MaxMulticast * 16)
; (5) For receive buffers: 16 + ReceiveBuffers * (ReceiveBufSize + 8)
; Item (5) does not apply unless you use "ReceiveMethod = ReceiveChain,
; HostBuffered". Item (3) does not apply if the value of "MaxTransmits"
; is less than or equal to the value of "TransmitBuffers".
; The total you compute may not be exactly correct but it should be
; close. The reasons for inexactness are: (a) the value for item number
; (1) will vary with different versions of the drivers; and (b) the
; other items may take up a little more space than the formulas imply,
; because of the need to allocate buffers and other data structures at
; doubleword-aligned or paragraph-aligned boundaries.
; Under DOS, all the space used by the driver is allocated in one
; contiguous piece. It will be in "conventional" memory (that is, in
; the first 640K) if the driver is loaded by a normal "DEVICE=" line in
; CONFIG.SYS, or in "upper" memory (above 640K) if the driver is loaded
; by "DEVICEHIGH=" or by "LOADHI". Note that if the total memory used
; is large (because of a large value for item (5)), there may not be
; room to load the driver into "upper" memory.
; Under OS/2, item (1) is allocated in low memory, and the other
; items are allocated in high memory if possible.