| Author |
Message |
clyclopedic
Guest
|
 Posted:
Sun Jan 09, 2005 10:15 pm Post subject:
performance pessimization |
|
|
I'm trying to duplicate a problem in a software application seen only at
certain customer sites. My theory is that severe network latency -
specifically DNS latency - is necessary to reproduce it. I have a little
Active Directory domain set up in virtual machines. Is there a way I can
configure its DNS so that there is a considerable latency in name
resolution? I thought of a couple of approaches:
1) Start some CPU-bound process on the Domain Controller. CON: the delay
won't be predictable
2) A colleague suggested inserting a proxy of some kind that would hold the
request for a period of time before sending it to the real DNS. CON: writing
such a proxy might be a lot of work
anything else?
TIA |
|
| Back to top |
|
 |
Herb Martin
Guest
|
| Posted:
Sun Jan 09, 2005 10:31 pm Post subject:
Re: performance pessimization |
|
|
"clyclopedic" <nonexist@spamless.com> wrote in message
news:uN8r8Zm9EHA.1400@TK2MSFTNGP11.phx.gbl...
| Quote: | I'm trying to duplicate a problem in a software application seen only at
certain customer sites. My theory is that severe network latency -
specifically DNS latency - is necessary to reproduce it. I have a little
Active Directory domain set up in virtual machines. Is there a way I can
configure its DNS so that there is a considerable latency in name
resolution? I thought of a couple of approaches:
|
We might do better (or completely fail) at your real
problem but lets try to answer your actual questions....
| Quote: | 1) Start some CPU-bound process on the Domain Controller. CON: the delay
won't be predictable
|
Well, the trick would be to do this on the DNS server
(and if it happens to be a DC that is really just a semi-
accident.)
You also have to deal with the issue that the server
probably runs at a very high priority for servicing
network requests and then tuning it so it works at
all but not tooooo fast.
| Quote: | 2) A colleague suggested inserting a proxy of some kind that would hold
the
request for a period of time before sending it to the real DNS. CON:
writing
such a proxy might be a lot of work
|
It is not trivial but it is fairly quick if you want something
simple in Perl (because the libraries already exist for all
of the pieces and you just plug it together.)
| Quote: | certain customer sites. My theory is that severe network latency -
specifically DNS latency - is necessary to reproduce it. I have a little
Active Directory domain set up in virtual machines. Is there a way I can
|
Are these somewhat random customers so we cannot just
help them FIX the DNS?
Even if you were servicing 1000's or customers you might
just write a FAQ about how they might have a brain dead
DNS or common problems they can fix.....
--
Herb Martin
| Quote: | anything else?
TIA
|
|
|
| Back to top |
|
|
clyclopedic
Guest
|
| Posted:
Sun Jan 09, 2005 11:38 pm Post subject:
Re: performance pessimization |
|
|
"Herb Martin" <news@LearnQuick.com> wrote in message
news:O$gdCkm9EHA.1392@tk2msftngp13.phx.gbl...
| Quote: | "clyclopedic" <nonexist@spamless.com> wrote in message
news:uN8r8Zm9EHA.1400@TK2MSFTNGP11.phx.gbl...
I'm trying to duplicate a problem in a software application seen only at
certain customer sites. My theory is that severe network latency -
specifically DNS latency - is necessary to reproduce it. I have a little
Active Directory domain set up in virtual machines. Is there a way I can
configure its DNS so that there is a considerable latency in name
resolution? I thought of a couple of approaches:
We might do better (or completely fail) at your real
problem but lets try to answer your actual questions....
1) Start some CPU-bound process on the Domain Controller. CON: the delay
won't be predictable
Well, the trick would be to do this on the DNS server
(and if it happens to be a DC that is really just a semi-
accident.)
You also have to deal with the issue that the server
probably runs at a very high priority for servicing
network requests and then tuning it so it works at
all but not tooooo fast.
|
So.. 1a) reduce the priority of the DNS server running on the DC.
| Quote: | 2) A colleague suggested inserting a proxy of some kind that would hold
the
request for a period of time before sending it to the real DNS. CON:
writing
such a proxy might be a lot of work
It is not trivial but it is fairly quick if you want something
simple in Perl (because the libraries already exist for all
of the pieces and you just plug it together.)
|
I can do Perl. Would I have to study the DNS protocol or just take binary
data in and shoot binary data out?
| Quote: | certain customer sites. My theory is that severe network latency -
specifically DNS latency - is necessary to reproduce it. I have a little
Active Directory domain set up in virtual machines. Is there a way I can
Are these somewhat random customers so we cannot just
help them FIX the DNS?
|
They are somewhat random. The problem is hinted at in this Microsoft SDK
article:
http://msdn.microsoft.com/library/en-us/gdi/prntspol_9fjn.asp
where it says "This can take a while".
| Quote: | Even if you were servicing 1000's or customers you might
just write a FAQ about how they might have a brain dead
DNS or common problems they can fix.....
|
We have documented a horrible work-around: On the client, remove all your
network printers, then later reinstall them. Yuk. |
|
| Back to top |
|
|
Herb Martin
Guest
|
| Posted:
Mon Jan 10, 2005 4:47 am Post subject:
Re: performance pessimization |
|
|
| Quote: | It is not trivial but it is fairly quick if you want something
simple in Perl (because the libraries already exist for all
of the pieces and you just plug it together.)
I can do Perl. Would I have to study the DNS protocol or just take binary
data in and shoot binary data out?
|
Probably just take the request, hold it and resend.
The hardest thing would be dealing with multiple
requests during the time involved -- you have to
multithread it or at least queue up the requests.
Last time I did it, I used the POE libraries which
are a LARGE piece to understand but worth it if
you need them (but I was writing a multiplexor
for DNS RBL lookups -- you ask it a question, and
it distributes the request to multiple real servers,
catches the answers, weights them, and as soon as
it reaches a threshold gives positive or waits for
negatives from to say NO.)
The Perl DNS stuff itself is really easy if you do
perl more than just a few lines -- and you don't
have to re-write the requests like I did. Even then
I was using strictly the Perl DNS library calls to
move things around and never had to mess much
with the underlying DNS request itself.
| Quote: | We have documented a horrible work-around: On the client, remove all your
network printers, then later reinstall them. Yuk.
|
There isn't any DNS mention in that article you gave
so I really don't know yet where your problem is
originating.
We help a LOT of people here with the funky DNS
(intermittent etc.) and so your clients may be suffering
from one of those problems which is maybe the root
cause of your issue.
Maybe I can help you if you want to pursue it.
--
Herb Martin
"clyclopedic" <nonexist@spamless.com> wrote in message
news:el6wYIn9EHA.2608@TK2MSFTNGP10.phx.gbl...
| Quote: |
"Herb Martin" <news@LearnQuick.com> wrote in message
news:O$gdCkm9EHA.1392@tk2msftngp13.phx.gbl...
"clyclopedic" <nonexist@spamless.com> wrote in message
news:uN8r8Zm9EHA.1400@TK2MSFTNGP11.phx.gbl...
I'm trying to duplicate a problem in a software application seen only
at
certain customer sites. My theory is that severe network latency -
specifically DNS latency - is necessary to reproduce it. I have a
little
Active Directory domain set up in virtual machines. Is there a way I
can
configure its DNS so that there is a considerable latency in name
resolution? I thought of a couple of approaches:
We might do better (or completely fail) at your real
problem but lets try to answer your actual questions....
1) Start some CPU-bound process on the Domain Controller. CON: the
delay
won't be predictable
Well, the trick would be to do this on the DNS server
(and if it happens to be a DC that is really just a semi-
accident.)
You also have to deal with the issue that the server
probably runs at a very high priority for servicing
network requests and then tuning it so it works at
all but not tooooo fast.
So.. 1a) reduce the priority of the DNS server running on the DC.
2) A colleague suggested inserting a proxy of some kind that would hold
the
request for a period of time before sending it to the real DNS. CON:
writing
such a proxy might be a lot of work
It is not trivial but it is fairly quick if you want something
simple in Perl (because the libraries already exist for all
of the pieces and you just plug it together.)
I can do Perl. Would I have to study the DNS protocol or just take binary
data in and shoot binary data out?
certain customer sites. My theory is that severe network latency -
specifically DNS latency - is necessary to reproduce it. I have a
little
Active Directory domain set up in virtual machines. Is there a way I
can
Are these somewhat random customers so we cannot just
help them FIX the DNS?
They are somewhat random. The problem is hinted at in this Microsoft SDK
article:
http://msdn.microsoft.com/library/en-us/gdi/prntspol_9fjn.asp
where it says "This can take a while".
Even if you were servicing 1000's or customers you might
just write a FAQ about how they might have a brain dead
DNS or common problems they can fix.....
We have documented a horrible work-around: On the client, remove all your
network printers, then later reinstall them. Yuk.
|
|
|
| Back to top |
|
|
clyclopedic
Guest
|
| Posted:
Mon Jan 10, 2005 5:21 am Post subject:
Re: performance pessimization |
|
|
"Herb Martin" <news@LearnQuick.com> wrote in message
news:uYF641p9EHA.1300@TK2MSFTNGP14.phx.gbl...
| Quote: | There isn't any DNS mention in that article you gave
so I really don't know yet where your problem is
originating.
We help a LOT of people here with the funky DNS
(intermittent etc.) and so your clients may be suffering
from one of those problems which is maybe the root
cause of your issue.
Maybe I can help you if you want to pursue it.
|
In a sense, pursuing the root cause would be counter-productive here. It is,
of course, the noblest thing we do as software geeks to find the root causes
of problems and eliminate them. But there's no way I can hope to address the
number of possible causes of latency in an OpenPrinter() call that hits the
network. Local network administrators are going to have to do that. If the
network is down altogether, OpenPrinter() seems to come back pretty quickly,
so I'm thinking DNS latency could be one of any number of possible scenarios
where OpenPrinter() appears to hang. My goal for this application is to
convert the philosophy of eager initialization it was written with to lazy
initialization, so that it hits the network only when absolutely necessary.
If I can eliminate OpenPrinter() altogether in cases where the application
isn't called upon to print, and show with a slow-network test platform that
this eliminates an exposure to network latency, then I can convince myself
and my testers that I've finally made some progress. And customers will
never see any problem in my application, no matter how funky their network
(unless they try to actually print something to an inaccessible network
printer). |
|
| Back to top |
|
|
William Stacey [MVP]
Guest
|
| Posted:
Mon Jan 10, 2005 11:05 am Post subject:
Re: performance pessimization |
|
|
You could use a .Net call like Dns.GetHostByName() before or after your
failed OpenPrinter() call to get a sense how long the Dns resolver is taking
by that machine on that network for said host name. Naturally, you can also
use dig, netdig, nslookup to on those problem networks to see if DNS is in
fact the issue and your getting consistent timeouts or something else. This
smells more like a Browser issue, but would need to know more about how
OpenPrinter() is implemented. Is that your own method or a Win32 api?
--
William Stacey, MVP
http://mvp.support.microsoft.com
"clyclopedic" <nonexist@spamless.com> wrote in message
news:OOtx#Hq9EHA.3592@TK2MSFTNGP09.phx.gbl...
| Quote: | "Herb Martin" <news@LearnQuick.com> wrote in message
news:uYF641p9EHA.1300@TK2MSFTNGP14.phx.gbl...
There isn't any DNS mention in that article you gave
so I really don't know yet where your problem is
originating.
We help a LOT of people here with the funky DNS
(intermittent etc.) and so your clients may be suffering
from one of those problems which is maybe the root
cause of your issue.
Maybe I can help you if you want to pursue it.
In a sense, pursuing the root cause would be counter-productive here. It
is,
of course, the noblest thing we do as software geeks to find the root
causes
of problems and eliminate them. But there's no way I can hope to address
the
number of possible causes of latency in an OpenPrinter() call that hits
the
network. Local network administrators are going to have to do that. If the
network is down altogether, OpenPrinter() seems to come back pretty
quickly,
so I'm thinking DNS latency could be one of any number of possible
scenarios
where OpenPrinter() appears to hang. My goal for this application is to
convert the philosophy of eager initialization it was written with to lazy
initialization, so that it hits the network only when absolutely
necessary.
If I can eliminate OpenPrinter() altogether in cases where the application
isn't called upon to print, and show with a slow-network test platform
that
this eliminates an exposure to network latency, then I can convince myself
and my testers that I've finally made some progress. And customers will
never see any problem in my application, no matter how funky their network
(unless they try to actually print something to an inaccessible network
printer).
|
|
|
| Back to top |
|
|
William Stacey [MVP]
Guest
|
| Posted:
Mon Jan 10, 2005 11:10 am Post subject:
Re: performance pessimization |
|
|
Also a NetMon trace would help you a lot to see what is going on. This may
be the fastest way to see the issue and to prove to others what the issue
really is.
--
William Stacey, MVP
http://mvp.support.microsoft.com
"William Stacey [MVP]" <staceywREMOVE@mvps.org> wrote in message
news:eJ8mHMt9EHA.2788@TK2MSFTNGP10.phx.gbl...
| Quote: | You could use a .Net call like Dns.GetHostByName() before or after your
failed OpenPrinter() call to get a sense how long the Dns resolver is
taking
by that machine on that network for said host name. Naturally, you can
also
use dig, netdig, nslookup to on those problem networks to see if DNS is in
fact the issue and your getting consistent timeouts or something else.
This
smells more like a Browser issue, but would need to know more about how
OpenPrinter() is implemented. Is that your own method or a Win32 api?
--
William Stacey, MVP
http://mvp.support.microsoft.com
"clyclopedic" <nonexist@spamless.com> wrote in message
news:OOtx#Hq9EHA.3592@TK2MSFTNGP09.phx.gbl...
"Herb Martin" <news@LearnQuick.com> wrote in message
news:uYF641p9EHA.1300@TK2MSFTNGP14.phx.gbl...
There isn't any DNS mention in that article you gave
so I really don't know yet where your problem is
originating.
We help a LOT of people here with the funky DNS
(intermittent etc.) and so your clients may be suffering
from one of those problems which is maybe the root
cause of your issue.
Maybe I can help you if you want to pursue it.
In a sense, pursuing the root cause would be counter-productive here. It
is,
of course, the noblest thing we do as software geeks to find the root
causes
of problems and eliminate them. But there's no way I can hope to address
the
number of possible causes of latency in an OpenPrinter() call that hits
the
network. Local network administrators are going to have to do that. If
the
network is down altogether, OpenPrinter() seems to come back pretty
quickly,
so I'm thinking DNS latency could be one of any number of possible
scenarios
where OpenPrinter() appears to hang. My goal for this application is to
convert the philosophy of eager initialization it was written with to
lazy
initialization, so that it hits the network only when absolutely
necessary.
If I can eliminate OpenPrinter() altogether in cases where the
application
isn't called upon to print, and show with a slow-network test platform
that
this eliminates an exposure to network latency, then I can convince
myself
and my testers that I've finally made some progress. And customers will
never see any problem in my application, no matter how funky their
network
(unless they try to actually print something to an inaccessible network
printer).
|
|
|
| Back to top |
|
|
Herb Martin
Guest
|
| Posted:
Mon Jan 10, 2005 4:16 pm Post subject:
Re: performance pessimization |
|
|
| Quote: | In a sense, pursuing the root cause would be counter-productive here. It
is,
of course, the noblest thing we do as software geeks to find the root
causes
of problems and eliminate them. But there's no way I can hope to address
the
number of possible causes of latency in an OpenPrinter() call that hits
the
network.
|
Of course that makes sense but I really doubt that it
is in DNS -- unless that DNS is misconfigured.
| Quote: | Local network administrators are going to have to do that. If the
network is down altogether, OpenPrinter() seems to come back pretty
quickly,
so I'm thinking DNS latency could be one of any number of possible
scenarios |
Only if the DNS is misconfigured -- or their
name resolution in general -- is this going to
add much for Microsoft networks.
| Quote: | where OpenPrinter() appears to hang. My goal for this application is to
convert the philosophy of eager initialization it was written with to lazy
initialization, so that it hits the network only when absolutely
necessary. |
What do you actually do? Print drivers for some company?
| Quote: | If I can eliminate OpenPrinter() altogether in cases where the application
isn't called upon to print, and show with a slow-network test platform
that
this eliminates an exposure to network latency, then I can convince myself
and my testers that I've finally made some progress. And customers will
never see any problem in my application, no matter how funky their network
(unless they try to actually print something to an inaccessible network
printer).
|
--
Herb Martin
"clyclopedic" <nonexist@spamless.com> wrote in message
news:OOtx#Hq9EHA.3592@TK2MSFTNGP09.phx.gbl...
| Quote: | "Herb Martin" <news@LearnQuick.com> wrote in message
news:uYF641p9EHA.1300@TK2MSFTNGP14.phx.gbl...
There isn't any DNS mention in that article you gave
so I really don't know yet where your problem is
originating.
We help a LOT of people here with the funky DNS
(intermittent etc.) and so your clients may be suffering
from one of those problems which is maybe the root
cause of your issue.
Maybe I can help you if you want to pursue it.
In a sense, pursuing the root cause would be counter-productive here. It
is,
of course, the noblest thing we do as software geeks to find the root
causes
of problems and eliminate them. But there's no way I can hope to address
the
number of possible causes of latency in an OpenPrinter() call that hits
the
network. Local network administrators are going to have to do that. If the
network is down altogether, OpenPrinter() seems to come back pretty
quickly,
so I'm thinking DNS latency could be one of any number of possible
scenarios
where OpenPrinter() appears to hang. My goal for this application is to
convert the philosophy of eager initialization it was written with to lazy
initialization, so that it hits the network only when absolutely
necessary.
If I can eliminate OpenPrinter() altogether in cases where the application
isn't called upon to print, and show with a slow-network test platform
that
this eliminates an exposure to network latency, then I can convince myself
and my testers that I've finally made some progress. And customers will
never see any problem in my application, no matter how funky their network
(unless they try to actually print something to an inaccessible network
printer).
|
|
|
| Back to top |
|
|
clyclopedic
Guest
|
| Posted:
Tue Jan 11, 2005 2:24 am Post subject:
Re: performance pessimization |
|
|
"William Stacey [MVP]" <staceywREMOVE@mvps.org> wrote in message
news:eJ8mHMt9EHA.2788@TK2MSFTNGP10.phx.gbl...
| Quote: | You could use a .Net call like Dns.GetHostByName() before or after your
failed OpenPrinter() call to get a sense how long the Dns resolver is
taking
by that machine on that network for said host name.
|
A couple weeks ago I stumbled on a way to sort-of duplicate the problem -
OpenPrinter() takes about 16 seconds. My scenario is probably not anything
like any of the customer situations, but I'm still happy to have *any* kind
of duplication of the problem. I should try to stay focused and work on my
lazy initialization plan, but I couldn't resist trying your suggestion. I
added a call to gethostbyname(). It took only 19 microseconds. So *in this
scenario* DNS apparently is not the major contributor to the latency. Which
kinda shoots a hole in my theory, but in some sense doesn't matter.
| Quote: | Naturally, you can also
use dig, netdig, nslookup to on those problem networks to see if DNS is in
fact the issue and your getting consistent timeouts or something else.
This
smells more like a Browser issue,
|
There is no browser involved.
| Quote: | but would need to know more about how
OpenPrinter() is implemented. Is that your own method or a Win32 api?
|
OpenPrinter() is a Win32 API:
http://msdn.microsoft.com/library/en-us/gdi/prntspol_9qnm.asp
which can be called directly, or indirectly and unknowingly as through the
EnumPrinters() API I posted about before.
| Quote: | --
William Stacey, MVP
http://mvp.support.microsoft.com
"clyclopedic" <nonexist@spamless.com> wrote in message
news:OOtx#Hq9EHA.3592@TK2MSFTNGP09.phx.gbl...
"Herb Martin" <news@LearnQuick.com> wrote in message
news:uYF641p9EHA.1300@TK2MSFTNGP14.phx.gbl...
There isn't any DNS mention in that article you gave
so I really don't know yet where your problem is
originating.
We help a LOT of people here with the funky DNS
(intermittent etc.) and so your clients may be suffering
from one of those problems which is maybe the root
cause of your issue.
Maybe I can help you if you want to pursue it.
In a sense, pursuing the root cause would be counter-productive here. It
is,
of course, the noblest thing we do as software geeks to find the root
causes
of problems and eliminate them. But there's no way I can hope to address
the
number of possible causes of latency in an OpenPrinter() call that hits
the
network. Local network administrators are going to have to do that. If
the
network is down altogether, OpenPrinter() seems to come back pretty
quickly,
so I'm thinking DNS latency could be one of any number of possible
scenarios
where OpenPrinter() appears to hang. My goal for this application is to
convert the philosophy of eager initialization it was written with to
lazy
initialization, so that it hits the network only when absolutely
necessary.
If I can eliminate OpenPrinter() altogether in cases where the
application
isn't called upon to print, and show with a slow-network test platform
that
this eliminates an exposure to network latency, then I can convince
myself
and my testers that I've finally made some progress. And customers will
never see any problem in my application, no matter how funky their
network
(unless they try to actually print something to an inaccessible network
printer).
|
|
|
| Back to top |
|
|
William Stacey [MVP]
Guest
|
| Posted:
Tue Jan 11, 2005 3:31 am Post subject:
Re: performance pessimization |
|
|
| Quote: | This
smells more like a Browser issue,
There is no browser involved.
|
Sorry, I meant the NetBios Browser. Config issues can cause that to be dog
slow. NetMon would help show.
The security stuff could be the slow issue too when negotiating the
connection - not sure.
--
wjs |
|
| Back to top |
|
|
clyclopedic
Guest
|
| Posted:
Tue Jan 11, 2005 9:22 am Post subject:
Re: performance pessimization |
|
|
You mean NetMon from Nullsoft? It just displays a constant
computername
0ms
On another note, I do observe these messages in the system event log:
--------
The system failed to register pointer (PTR) resource records (RRs) for
network adapter
with settings:
Adapter Name : {4AE7C400-474A-4702-9986-2481949F53DB}
Host Name : vm2
Adapter-specific Domain Suffix : yada.cer
DNS server list :
172.17.1.18, 172.25.1.14
Sent update to server : None
IP Address : 172.16.19.50
The reason the system could not register these RRs during the update
request was because of a system problem. You can manually retry DNS
registration of the network adapter and its settings by typing "ipconfig
/registerdns" at the command prompt. If problems still persist, contact your
DNS server or network systems administrator. For specific error code, see
the record data displayed below.
0000: 29 23 00 00
--------
The system failed to register network adapter with settings:
Adapter Name : {4AE7C400-474A-4702-9986-2481949F53DB}
Host Name : vm2
Adapter-specific Domain Suffix : yada.cer
DNS Server list :
172.17.1.18, 172.25.1.14
Sent update to server : None
IP Address(es) :
172.16.19.50
The cause of this DNS registration failure was because the DNS update
request timed out after being sent to the specified DNS Server. This is
probably because the authoritative DNS server for the name being updated is
not running.
You can manually retry registration of the network adapter and its settings
by typing "ipconfig /registerdns" at the command prompt. If problems still
persist, contact your network systems administrator to verify network
conditions.
0000: b4 05 00 00
---------
These messages occur when I have my test system set up in its 'sick'
configuration, where latency is manifest.
The 'yada.cer' part is the domain suffix of a little domain of VMWARE
virtual machines on my laptop that this one virtual machine was, for a time,
a part of. However, I have the network identification set so that its a
member of workgroup WORKGROUP, and not a member of a domain.
"William Stacey [MVP]" <staceywREMOVE@mvps.org> wrote in message
news:e%23xbjy19EHA.936@TK2MSFTNGP12.phx.gbl...
| Quote: | This
smells more like a Browser issue,
There is no browser involved.
Sorry, I meant the NetBios Browser. Config issues can cause that to be
dog
slow. NetMon would help show.
The security stuff could be the slow issue too when negotiating the
connection - not sure.
--
wjs
|
|
|
| Back to top |
|
|
William Stacey [MVP]
Guest
|
| Posted:
Tue Jan 11, 2005 12:00 pm Post subject:
Re: performance pessimization |
|
|
Network Monitor from MS on your Servers.
--
William Stacey, MVP
http://mvp.support.microsoft.com
"clyclopedic" <nonexist@spamless.com> wrote in message
news:uyb7$y49EHA.3260@TK2MSFTNGP14.phx.gbl...
| Quote: | You mean NetMon from Nullsoft? It just displays a constant
computername
0ms
On another note, I do observe these messages in the system event log:
--------
The system failed to register pointer (PTR) resource records (RRs) for
network adapter
with settings:
Adapter Name : {4AE7C400-474A-4702-9986-2481949F53DB}
Host Name : vm2
Adapter-specific Domain Suffix : yada.cer
DNS server list :
172.17.1.18, 172.25.1.14
Sent update to server : None
IP Address : 172.16.19.50
The reason the system could not register these RRs during the update
request was because of a system problem. You can manually retry DNS
registration of the network adapter and its settings by typing "ipconfig
/registerdns" at the command prompt. If problems still persist, contact
your
DNS server or network systems administrator. For specific error code, see
the record data displayed below.
0000: 29 23 00 00
--------
The system failed to register network adapter with settings:
Adapter Name : {4AE7C400-474A-4702-9986-2481949F53DB}
Host Name : vm2
Adapter-specific Domain Suffix : yada.cer
DNS Server list :
172.17.1.18, 172.25.1.14
Sent update to server : None
IP Address(es) :
172.16.19.50
The cause of this DNS registration failure was because the DNS update
request timed out after being sent to the specified DNS Server. This is
probably because the authoritative DNS server for the name being updated
is
not running.
You can manually retry registration of the network adapter and its
settings
by typing "ipconfig /registerdns" at the command prompt. If problems still
persist, contact your network systems administrator to verify network
conditions.
0000: b4 05 00 00
---------
These messages occur when I have my test system set up in its 'sick'
configuration, where latency is manifest.
The 'yada.cer' part is the domain suffix of a little domain of VMWARE
virtual machines on my laptop that this one virtual machine was, for a
time,
a part of. However, I have the network identification set so that its a
member of workgroup WORKGROUP, and not a member of a domain.
"William Stacey [MVP]" <staceywREMOVE@mvps.org> wrote in message
news:e%23xbjy19EHA.936@TK2MSFTNGP12.phx.gbl...
This
smells more like a Browser issue,
There is no browser involved.
Sorry, I meant the NetBios Browser. Config issues can cause that to be
dog
slow. NetMon would help show.
The security stuff could be the slow issue too when negotiating the
connection - not sure.
--
wjs
|
|
|
| Back to top |
|
|
clyclopedic
Guest
|
| Posted:
Wed Jan 12, 2005 7:06 am Post subject:
Re: performance pessimization |
|
|
I'm not at liberty to run netmon on the servers. However, I did run NetCap
on the Windows 2000 client machine where I can sort of reproduce the
problem. The records are clustered in threes separate in time by about the
same 16 second interval that I see at the OpenPrinter() API level. Im not
sure what's important in the records, but here are some selected fields from
one cluster of frames - frames 9, 10, and 11. Certain names and numbers have
been obfuscated.
9 37.625000 NNNNNNNNNNNN NNNNNNNNNNNN NBT NS: Query (Node Status) resp. for
COMPUTER <00>, Requested name doesn't exist NN.NN.N.NN NNN.NN.NN.NN IP
FRAME: Base frame properties
FRAME: Time of capture = 1/11/2005 12:41:17 PM
FRAME: Time delta from previous physical frame: 16109375 microseconds
FRAME: Frame number: 9
FRAME: Total frame length: 98 bytes
FRAME: Capture frame length: 98 bytes
FRAME: Frame data: Number of data bytes remaining = 98 (0x0062)
ETHERNET: EType = Internet IP (IPv4)
ETHERNET: Destination address = NNNNNNNNNNNN
ETHERNET: 0....... = Individual address
ETHERNET: .0...... = Universally administered address
ETHERNET: Source address = NNNNNNNNNNNN
ETHERNET: .0...... = Universally administered address
ETHERNET: Ethernet Type : 0x0800 (Internet IP (IPv4))
IP: Protocol = UDP - User Datagram; Packet ID = 32399; Total IP Length = 84;
Options = No Options
IP: Version = IPv4; Header Length = 20
IP: 0100.... = IP Version 4
IP: ....0101 = Header Length 20
IP: Type of Service = Normal Service
IP: 000..... = Precedence - Routine
IP: ...0.... = Normal Delay
IP: ....0... = Normal Throughput
IP: .....0.. = Normal Reliability
IP: ......0. = Normal Monetary Cost
IP: Total Length = 84 (0x54)
IP: Identification = 32399 (0x7E8F)
IP: Fragmentation Summary = 0 (0x0)
IP: .0.............. = May fragment datagram if necessary
IP: ..0............. = Last fragment in datagram
IP: ...0000000000000 = Fragment Offset 0 (0x0000)
IP: Time to Live = 125 (0x7D)
IP: Protocol = UDP - User Datagram
IP: Checksum = 61279 (0xEF5F)
IP: Source Address = NN.NN.N.NN
IP: Destination Address = NNN.NN.NN.NN
UDP: Src Port: NETBIOS Name Service (137); Dst Port: NETBIOS Name Service
(137); Length = 64 (0x40)
UDP: Source Port = NETBIOS Name Service
UDP: Destination Port = NETBIOS Name Service
UDP: Total length = 64 (0x40)
UDP: UDP Checksum = 0xD390
NBT: NS: Query (Node Status) resp. for COMPUTER <00>, Requested name
doesn't exist
NBT: Transaction ID = 33102 (0x814E)
NBT: Flags Summary = 0x8583 - Resp.; Query; Requested name doesn't exist
NBT: 1............... = Response
NBT: .0000........... = Query
NBT: .....1.......... = Authoritative Answer
NBT: ......0......... = Datagram not truncated
NBT: .......1........ = Recursion desired
NBT: ........1....... = Recursion available
NBT: .........0...... = Reserved
NBT: ..........0..... = Reserved
NBT: ...........0.... = Not a broadcast packet
NBT: ............0011 = Requested name doesn't exist
NBT: Question Count = 0 (0x0)
NBT: Answer Count = 0 (0x0)
NBT: Name Service Count = 0 (0x0)
NBT: Additional Record Count = 0 (0x0)
NBT: Resource Record Name =COMPUTER <00>
NBT: Resource Record Type = Null
NBT: Resource Record Class = Internet Class
NBT: Time To Live(Seconds) = 0 (0x0)
NBT: RDATA Length = 0 (0x0)
10 37.765625 NNNNNNNNNNNN NNNNNNNNNNNN NBT NS: Query (Node Status) resp. for
COMPUTER <00>, Requested name doesn't exist NN.NN.N.NN NNN.NN.NN.NN IP
FRAME: Base frame properties
FRAME: Time of capture = 1/11/2005 12:41:17 PM
FRAME: Time delta from previous physical frame: 140625 microseconds
FRAME: Frame number: 10
FRAME: Total frame length: 98 bytes
FRAME: Capture frame length: 98 bytes
FRAME: Frame data: Number of data bytes remaining = 98 (0x0062)
ETHERNET: EType = Internet IP (IPv4)
ETHERNET: Destination address = NNNNNNNNNNNN
ETHERNET: 0....... = Individual address
ETHERNET: .0...... = Universally administered address
ETHERNET: Source address = NNNNNNNNNNNN
ETHERNET: .0...... = Universally administered address
ETHERNET: Ethernet Type : 0x0800 (Internet IP (IPv4))
IP: Protocol = UDP - User Datagram; Packet ID = 18884; Total IP Length = 84;
Options = No Options
IP: Version = IPv4; Header Length = 20
IP: 0100.... = IP Version 4
IP: ....0101 = Header Length 20
IP: Type of Service = Normal Service
IP: 000..... = Precedence - Routine
IP: ...0.... = Normal Delay
IP: ....0... = Normal Throughput
IP: .....0.. = Normal Reliability
IP: ......0. = Normal Monetary Cost
IP: Total Length = 84 (0x54)
IP: Identification = 18884 (0x49C4)
IP: Fragmentation Summary = 0 (0x0)
IP: .0.............. = May fragment datagram if necessary
IP: ..0............. = Last fragment in datagram
IP: ...0000000000000 = Fragment Offset 0 (0x0000)
IP: Time to Live = 126 (0x7E)
IP: Protocol = UDP - User Datagram
IP: Checksum = 11102 (0x2B5E)
IP: Source Address = NN.NN.N.NN
IP: Destination Address = NNN.NN.NN.NN
UDP: Src Port: NETBIOS Name Service (137); Dst Port: NETBIOS Name Service
(137); Length = 64 (0x40)
UDP: Source Port = NETBIOS Name Service
UDP: Destination Port = NETBIOS Name Service
UDP: Total length = 64 (0x40)
UDP: UDP Checksum = 0xDBC3
NBT: NS: Query (Node Status) resp. for COMPUTER <00>, Requested name
doesn't exist
NBT: Transaction ID = 33102 (0x814E)
NBT: Flags Summary = 0x8583 - Resp.; Query; Requested name doesn't exist
NBT: 1............... = Response
NBT: .0000........... = Query
NBT: .....1.......... = Authoritative Answer
NBT: ......0......... = Datagram not truncated
NBT: .......1........ = Recursion desired
NBT: ........1....... = Recursion available
NBT: .........0...... = Reserved
NBT: ..........0..... = Reserved
NBT: ...........0.... = Not a broadcast packet
NBT: ............0011 = Requested name doesn't exist
NBT: Question Count = 0 (0x0)
NBT: Answer Count = 0 (0x0)
NBT: Name Service Count = 0 (0x0)
NBT: Additional Record Count = 0 (0x0)
NBT: Resource Record Name =COMPUTER <00>
NBT: Resource Record Type = Null
NBT: Resource Record Class = Internet Class
NBT: Time To Live(Seconds) = 0 (0x0)
NBT: RDATA Length = 0 (0x0)
11 37.812500 NNNNNNNNNNNN NNNNNNNNNNNN DNS 0xE177:Std Qry Resp. Auth. NS is
yada.yada.com. of type SOA on class INET addr. : Name does not exist
NNN.NN.N.NN NNN.NN.NN.NN IP
FRAME: Base frame properties
FRAME: Time of capture = 1/11/2005 12:41:17 PM
FRAME: Time delta from previous physical frame: 46875 microseconds
FRAME: Frame number: 11
FRAME: Total frame length: 136 bytes
FRAME: Capture frame length: 136 bytes
FRAME: Frame data: Number of data bytes remaining = 136 (0x0088)
ETHERNET: EType = Internet IP (IPv4)
ETHERNET: Destination address = NNNNNNNNNNNN
ETHERNET: 0....... = Individual address
ETHERNET: .0...... = Universally administered address
ETHERNET: Source address = NNNNNNNNNNNN
ETHERNET: .0...... = Universally administered address
ETHERNET: Ethernet Type : 0x0800 (Internet IP (IPv4))
IP: Protocol = UDP - User Datagram; Packet ID = 0; Total IP Length = 122;
Options = No Options
IP: Version = IPv4; Header Length = 20
IP: 0100.... = IP Version 4
IP: ....0101 = Header Length 20
IP: Type of Service = Normal Service
IP: 000..... = Precedence - Routine
IP: ...0.... = Normal Delay
IP: ....0... = Normal Throughput
IP: .....0.. = Normal Reliability
IP: ......0. = Normal Monetary Cost
IP: Total Length = 122 (0x7A)
IP: Identification = 0 (0x0)
IP: Fragmentation Summary = 16384 (0x4000)
IP: .1.............. = Cannot fragment datagram
IP: ..0............. = Last fragment in datagram
IP: ...0000000000000 = Fragment Offset 0 (0x0000)
IP: Time to Live = 61 (0x3D)
IP: Protocol = UDP - User Datagram
IP: Checksum = 54283 (0xD40B)
IP: Source Address = NNN.NN.N.NN
IP: Destination Address = NNN.NN.NN.NN
UDP: Src Port: Domain Name Server (53); Dst Port: Unknown (1278); Length =
102 (0x66)
UDP: Source Port = Domain Name Server
UDP: Destination Port = 0x04FE
UDP: Total length = 102 (0x66)
UDP: UDP Checksum = 0xFD8D
DNS: 0xE177:Std Qry Resp. Auth. NS is yada.yada.com. of type SOA on class
INET addr. : Name does not exist
DNS: Query Identifier = 57719 (0xE177)
DNS: DNS Flags = Response, OpCode - Std Qry, AA RD RA Bits Set, RCode -
Name does not exist
DNS: 1............... = Response
DNS: .0000........... = Standard Query
DNS: .....1.......... = Server authority for domain
DNS: ......0......... = Message complete
DNS: .......1........ = Recursive query desired
DNS: ........1....... = Recursive queries supported by server
DNS: .........000.... = Reserved
DNS: ............0011 = Name does not exist
DNS: Question Entry Count = 1 (0x1)
DNS: Answer Entry Count = 0 (0x0)
DNS: Name Server Count = 1 (0x1)
DNS: Additional Records Count = 0 (0x0)
DNS: Question Section: COMPUTER.yada.yada.com. of type Host Addr on
class INET addr.
DNS: Question Name: COMPUTER.yada.yada.com.
DNS: Question Type = Host Address
DNS: Question Class = Internet address class
DNS: Authority Section: yada.yada.com. of type SOA on class INET addr.
DNS: Resource Name: yada.yada.com.
DNS: Resource Type = Start of zone of authority
DNS: Resource Class = Internet address class
DNS: Time To Live = 1800 (0x708)
DNS: Resource Data Length = 45 (0x2D)
DNS: Primary Name Server: hidden.censored.com.
DNS: Responsible Authorative Mailbox: admin.yada.com.
DNS: Version number = 8401811 (0x803393)
DNS: Refresh Interval = 907 (0x38B)
DNS: Retry interval = 401 (0x191)
DNS: Expiration Limit = 604800 (0x93A80)
DNS: Minimum TTL = 1800 (0x708) |
|
| Back to top |
|
|
clyclopedic
Guest
|
| Posted:
Fri Jan 14, 2005 8:22 am Post subject:
Re: performance pessimization |
|
|
I think you may have a keen sense of smell. The problem may be related to
"Slow Computer Browsing from Multihomed Clients"
http://support.microsoft.com/?kbid=288801
because if I disable NetBIOS over TCP/IP on one of the two network adapters
(one is VPN), then the problem goes away. I tried adding a third network
adapter, networked to another virtual machine, but that didn't make the
problem any worse, as I had hoped.
"William Stacey [MVP]" <staceywREMOVE@mvps.org> wrote in message
news:e%23xbjy19EHA.936@TK2MSFTNGP12.phx.gbl...
| Quote: | This
smells more like a Browser issue,
There is no browser involved.
Sorry, I meant the NetBios Browser. Config issues can cause that to be
dog
slow. NetMon would help show.
The security stuff could be the slow issue too when negotiating the
connection - not sure.
--
wjs
|
|
|
| Back to top |
|
|
Herb Martin
Guest
|
| Posted:
Fri Jan 14, 2005 9:02 am Post subject:
Re: performance pessimization |
|
|
"clyclopedic" <nonexist@spamless.com> wrote in message
news:#bA6p$d#EHA.3368@TK2MSFTNGP10.phx.gbl...
| Quote: | I think you may have a keen sense of smell. The problem may be related to
"Slow Computer Browsing from Multihomed Clients"
http://support.microsoft.com/?kbid=288801
because if I disable NetBIOS over TCP/IP on one of the two network
adapters
(one is VPN), then the problem goes away. I tried adding a third network
adapter, networked to another virtual machine, but that didn't make the
problem any worse, as I had hoped.
|
There is a good chance that during the VPN connection
active time, the WINS server setting if you use one is
OVERRIDING the local setting.
This means you have to wait for the REMOTE to fail
first.
This can be defeated but you have to be careful.
--
Herb Martin
| Quote: |
"William Stacey [MVP]" <staceywREMOVE@mvps.org> wrote in message
news:e%23xbjy19EHA.936@TK2MSFTNGP12.phx.gbl...
This
smells more like a Browser issue,
There is no browser involved.
Sorry, I meant the NetBios Browser. Config issues can cause that to be
dog
slow. NetMon would help show.
The security stuff could be the slow issue too when negotiating the
connection - not sure.
--
wjs
|
|
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in