armand.welsh at sscims.com
Tue Dec 19 17:50:35 GMT 2000
sorry, you said your ping time was twice that of a normal one.
The WINS service, when used to access shares, is still, not very likely the
cause. WINS is slower than DNS, and depending on your NBT-NodeType, the
name lookup via wins can take longer. For a standard workstation, running
is an H-Node (hybrid node, the default), the standard name lookup process,
inherently causes WINS lookups to take longer.
the workstation follows a process to locate the machine in wins, and this
process, pretty much ensures fast lookups for the name resolution of the
prefered name hosting service. The name lookup order depends on how you are
looking up the host name.
Order for request via winsock is:
hosts file, dns lookup, nbt cache, WINS server, B-node broadcast, lmhosts
Order for request via NetBIOS is:
nbt cache, WINS server, B-node broadcast, lmhosts file, hosts file, dns
If you use the Run function for explorer to browse the machine, because of
the way the new explorer shell is designed, with internet capabilities, I
believe the winsock type lookup is used.
I think the best way to get snappy name lookups is to have both WINS and DNS
on the local lan, and have DNS lookup in WINS. Then have the workstations
setup with the local domain name, and a search order, to include the local
domain. In this way, you can get fast name lookups when you try to ping or
traceroute, etc... and still have wins do the lookups for the netbios
querries. If most of your querries go through DNS, you will have faster
This does not, however, address your time for the netbios session(TCP port
139). Once the NetBIOS name lookup is completed(udp 137), the machine
attaches to the share, and listing the contents of the share is slow. This
is definately a timing issue. try Microsoft Knowledge Base article Q158474
to see if there is something here that you can tweek to improve performance.
Either way, I think to resolve your issue, you are going to need a packet
sniffer, so you can watch what is happening.
Since you have a cisco catalyst, you might want to look at the broadcast
storm protection. It's possible that it might be shutting down the port
temporarly to protect for broadcast storms. Just disable this feature on
the appropriate ports to see if it helps, or hurts. Also, you can see what
the port utilization is, to verify that you don't have a bandwidth issue.
-> -----Original Message-----
-> From: Charles Crawford [mailto:ccrawford at atsengineers.com]
-> Sent: Tuesday, December 19, 2000 9:13 AM
-> To: Welsh, Armand
-> Cc: Samba Listserve (E-mail); Samba-Ntdom Listserve (E-mail);
-> Samba-Technical Listserve (E-mail)
-> Subject: RE: network resources
-> ok, I understand all of this, but my primary issue is not
-> the ping issue,
-> but rather the mapped drives. The response from the Samba
-> shares is what is
-> very slow. The ping requests are pretty fast (<3ms) but the
-> response from
-> the Samba shares is sometimes nonexistant. Sometimes, I
-> cannot connect to a
-> share, but can ping with no problem.
More information about the samba-technical