OS2World OLD-STATIC-BACKUP Forum

OS/2 - Technical => Networking => Topic started by: Saijin_Naib on 2008.02.08, 05:50:12

Title: eCS MPTS Mystical Driver Settings :P
Post by: Saijin_Naib on 2008.02.08, 05:50:12
Hey, there was a discussion concerning the OS/2 network stack and all the many configuration options and what they mean/do. Apparently, there is next to no documentation concerning what they mean and their effect. I figured I would post some screenshots here and see if you guys could give me some pointers about what to change or not. Thanks!
Title: Re: eCS MPTS Mystical Driver Settings :P
Post by: RobertM on 2008.02.08, 06:06:46
Hi,

If you have those settings (different settings show up depending on NIC and driver installed), hitting F1 should bring up something about them...

I'll check through the docs David sent me the link for tomorrow when I am at the office...

-Robert
Title: Re: eCS MPTS Mystical Driver Settings :P
Post by: Saijin_Naib on 2008.02.08, 11:11:06
Thanks Robert. It tells me that I have pressed range or tells me the min/max values. Im tempted to crank everything to max, but I am fairly certain that will break stuff. Let me know if you get any insight into all this stuff :P
Title: Re: eCS MPTS Mystical Driver Settings :P
Post by: RobertM on 2008.02.08, 20:35:06
Quote from: Saijin_Naib on 2008.02.08, 11:11:06
Thanks Robert. It tells me that I have pressed range or tells me the min/max values. Im tempted to crank everything to max, but I am fairly certain that will break stuff. Let me know if you get any insight into all this stuff :P

Hi Saijin,

Check this link out:
http://www.os2world.com/component/option,com_smf/Itemid,63/topic,743.msg4065/#msg4065

I'm still trying to find more info...

Note, as I indicated in that post (at the link), bringing certain values too high while a large amount of memory is being used for thread handling, JFS or HPFS386 caches, etc, will lead to a crash... so play with them gingerly until you, I or someone else figures out the correlation in memory needs and usage of each...

-Robert
Title: Re: eCS MPTS Mystical Driver Settings :P
Post by: Saijin_Naib on 2008.02.09, 03:12:43
Yep, just read over that now Robert. I've downloaded the 2 PDF files and I will attempt to take a look and see what I can get outta this. The only problem is, as you've mentioned, NETIO is not a great benchmark, and things like the SpeakEasy speedtest are balanced against us due to our Firefox rendering issues and outdated/hacked Flash. Even so, I think I am going to use the SO speedtest to measure my performance gains/losses with configuration, because that is the performance (internet usage) that I am really after. I cant get PEER working properly so Netbios performance is not a primary concern yet.

Here is the result of the inetcfg -g all dump.
Title: Re: eCS MPTS Mystical Driver Settings :P
Post by: djcaetano on 2008.02.09, 03:42:20
Quote from: Saijin_Naib on 2008.02.09, 03:12:43
Yep, just read over that now Robert. I've downloaded the 2 PDF files and I will attempt to take a look and see what I can get outta this. The only problem is, as you've mentioned, NETIO is not a great benchmark,

Let's say it has limitations because it was not created to test multiple requests at the same time.
But its results are a start, and it is not dependent of anything other than network cable, NIC, NIC driver and protocol stack.
  Anyway, NETIO is opensource, so it's possible to modify it to test multiple requests network speed. It will require some knowledge on multithread, though.

Quote from: Saijin_Naib on 2008.02.09, 03:12:43
and things like the SpeakEasy speedtest are balanced against us due to our Firefox rendering issues and outdated/hacked Flash. Even so, I think I am going to use the SO speedtest to measure my performance gains/losses with configuration, because that is the performance (internet usage) that I am really after. I cant get PEER working properly so Netbios performance is not a primary concern yet.

  Well, I remember I had read something when configuring netbios... and it was this WarpStock presentation...

  http://www2.warpstock.org/2002/files/OliverMark-TCPBEUI.pdf

  Maybe it can help you as it had helped me.
Title: Re: eCS MPTS Mystical Driver Settings :P
Post by: Saijin_Naib on 2008.02.09, 03:56:56
Alright, so should I use NETIO as loopback or to my roomate to test what my changes have wrought? Also, thanks for the PDF, Im going to thumb through it and see what I come up with.
Title: Re: eCS MPTS Mystical Driver Settings :P
Post by: djcaetano on 2008.02.09, 13:44:58
Quote from: Saijin_Naib on 2008.02.09, 03:56:56
Alright, so should I use NETIO as loopback or to my roomate to test what my changes have wrought?

  As said before, although it's not a perfect measure, it is a good start. :)

Quote from: Saijin_Naib on 2008.02.09, 03:56:56
Also, thanks for the PDF, Im going to thumb through it and see what I come up with.

   It is nice to start to understand some NetBIOS / NetBEUI parameters. I had just found
a "text" where I compiled the most important variable names and some explanations.
Unfortunately, it is not complete, but it's also a good start. :)

  Note: Peer-to-Peer networks are those *there is not* a Domain Controller (e.g. a server
that manages passwords). In lmhosts section, much of data only makes sense when
using a Domain Controller (which was my case, when I compiled this information).

\IBMCOM\PROTOCOL.INI
[tcpbeui_nif]
- NAMESFILE: Maximum entries on RFCNAMES.LST. Try 100.
- DOMAINSCOPE: TCP/IP domain (something.com)
- LOCALSCOPE: NetBIOS domain (WORKGORUP or something alike)
- PRELOADCACHE: YES
- NAMECACHE: 1000
- NODETYPE: H-Node
- NBNSADDR: NBNS / WINS machine address
- NBNSBACKADDR: NBNS / WINS backup machine address
- NBDDADDR: NBNS / WINS machine address
- NBDDBACKADDR: NBNS / WINS backup machine address
- ENABLEDNS: 2

In the NETBEUI_nif section of the PROTOCOL.INI file there are three
capacity parameters:
SESSIONS
NCBS
NAMES
that correspond to capacity variables x1, x2 and x3, on the Netx
statements in the [networks] section in the IBMLAN.INI file.


\IBMCOM\RFCNAMES.LST
- Each machine name between double quotes, a space and each machine IP.
"MACHINE1" 192.168.0.2
"MACHINE2" 192.168.0.3
...
- In the client, there is the need of domain name and controller IP.
"WORGROUP" 192.168.0.1

\MPTN\ETC\HOSTS
- IPs, complete machine names and alias (only name, without tcp/ip domain)


\IBMLAN\IBMLAN.INI
[browser]
- maintainserverlist: YES
[requester]
othdomains: other netbios domains you want to be shown in the Network Neighborhood Browser.



------
- NetBIOS Names (lmhosts - Windows)
Master Browser Group Name: domain [1Eh]
Name to other clients contact the Master Browser: domain [1Dh]
Group name for Workgroup announcements: [\0x01\0x02__MSBROWSE__\0x02\0x01]
Domain Controller: domain [1Bh] (unique name)
                   domain [1Ch] (group name)


16th byte      Usage         Used by IBM
<computername>[00h]    Workstation service    Yes
<computername>[03h]    Messenger service    Yes
<computername>[1Fh]    NetDDE service       No
<computername>[20h]    Server service       Yes
<username>[03h]    Messenger Service    Yes
<domain_name>[1Dh]    Master Browser       No *
<domain_name>[1Bh]    Domain Master Browser    No *
<domain_name>[00h]    Domain name       Yes
<domain_name>[1Ch]    Domain Controllers    No
<domain_name>[1Eh]    Browser srv elections    No
* Used if Master Browser installed

A typical LMHOSTS file could look like this:
#
# A sample LMHOSTS file
#
9.3.1.21 ITSCSV00 #PRE #DOMAIN:ITSCAUS
9.3.1.14 ITSCFS00 #PRE #additional server
9.3.1.21 ITSCAUS #PRE #DC IP assigned to the domain name
#

Be aware that, when using LMHOSTS in a Windows 95 TCP/IP
environment, the workgroup name must be different to the domain name.
For example, when you have the names the same, and the LMHOSTS file
looks like the following (xxx and zzz stand for IP addresses):

xxx.xxx.xxx.xxx BADM80 #PRE #DOM:BOBSUPPORT
xxx.xxx.xxx.xxx "BOBSUPPORT \0x00" #PRE
zzz.zzz.zzz.zzz NTINTERDC #PRE #DOM:NTINTERDOM

the scenario fails.

When the names are different and the order of LMHOSTS is changed as
follows:

xxx.zxx.xxx.zxx "BOBSUPPORT \0x00" #PRE
xxx.xxx.xxx.xxx BADM80 #PRE #DOM:BOBSUPPORT
zzz.zzz.zzz.zzz NTINTERDC #PRE #DOM:NTINTERDOM

the scenario works.

The reasons for these are as follows:
= In our failed login, where the domainname=workgroupname, we
broadcast and register the workgroup BOBSUPPORT. At this point,
everything on the local subnet is BOBSUPPORT, and the NetBIOS name
BOBSUPPORT is resolved to a hardware address of zeroes. Because of
this, the LMHOSTS file is never consulted for the IP address of
BOBSUPPORT and never gets the proper domain suffix. Windows 95
then sends an Arp request for the hardware address for the IP
address of xxx.xx.xxx.xx, which in the LMHOSTS is BADM80, the
primary domain controller for BOBSUPPORT, with no suffix.

= In our successful login, there is no attempt to resolve BOBSUPPORT
until domain logon validation. There is nothing in the Arp cache
telling Windows 95 where BONSUPPORT is located (as opposed to a
broadcast), so it must attempt to resolve it. Per B-node resolution, it
first broadcasts and then consults LMHOSTS file. Since it's not
looking for BADM80, it goes to the next entry, BOBSUPPORT, and not only
gets the proper IP address, but the proper domain suffix.


Another solution is to add one extra entry to the LMHOSTS file and install
the Neighborhood Browser Enabler on the domain controller server. The
Windows 95 client tries to find a domain name with the 16th-byte [1Ch], but
by default an OS/2 Warp Server does not know how to answer to this query.
If a NetBIOS name contains any special characters, the name must be
surrounded by double quotes. The LMHOSTS file would look like this:

#
# A working sample LMHOSTS. file when using network
# connections over a router
# The three lines work as decleared below:
# The DC is registered with the domain name
# The domain itself is registered with the DC IP address
# The domain name is registered with 16th byte (or character) 1Ch
9.3.1.140 WS_SRV01 #PRE #DOM:WS_DOM01
9.3.1.140 WS_DOM01 #PRE
9.3.1.140 "WS_DOM01 \0x1C" #PRE

# Additional domain definition
9.3.1.21 ITSCSV00 #PRE #DOM:ITSCAUS
9.3.1.21 ITSCAUS #PRE
9.3.1.21 "ITSCAUS \0x1C" #PRE

# Additional servers for extra file resources
9.3.1.59 ITSCFS00
9.3.1.14 ITSCPS00
9.3.1.21 ITSCSV00
#

Be Careful with the LMHOSTS File
If you define an incorrect IP address for a server in the LMHOSTS file,
you cannot connect to the server. If the domain controller IP address is
not defined correctly, you cannot even log on to the domain.