Re: DHCP too slow - trying to cache
- From: "John Roberts" <john@xxxxxxxxxxxxx>
- Date: Wed, 24 Aug 2005 11:47:32 +0100
Hi Paul,
> Note that you haven't told us anything, including the OS version, what
> QFEs are applied, etc. about the device...
Windows CE 5.0 and the latest QFE roll-ups are applied. The device is a
wi-fi television remote control designed to be used in the home. To prolong
the battery life, the wi-fi connection is to be kept off as much as possible
and in an ideal situation, the wi-fi connection should be able to connect
promptly to give a good user experience. For example, imagine the user wants
to find out the weather on their remote. They pick it up and go to the
weather application which goes and fetches it. This should be as prompt as
possible but at the moment, I'm seeing 30 seconds or more when DHCP is
used - particularly on ad-hoc ICS connections. I realise there are other
processes that contribute to this time but DHCP seems to be taking the
lion's share - if I measure the time taken between the physical transport
layer being established on the wi-fi network (NDIS Media Connect) and the
Address Change notification (NotifyAddrChange API). This is 20-30 seconds
with DHCP and 2-4 seconds with static IP.
One question I have is whether this 20-30 second time is normal both when a
new IP address is obtained and when there should be an IP address cached?
I've tried a variety of DHCP servers (those embedded in different wi-fi
routers and those on Windows 2000 and Windows XP when ICS is used). Times
are variable but always longer than I'd hoped.
> It's legal, but not maintainable, in my opinion. What assures that the
> address you have will never be issued to some other device? If the lease
> expires and you then show up on the network using an address that you
> shouldn't have, you might find someone else using it and you'll have real
> problems. Even if you've reconnected before the lease expires, once it
> does expire, you may have a problem, as the DHCP server will call that
> address fair game, again. If you can accurately duplicate the lease
> behavior in DHCP, then you won't have a conflict problem, but that's a
> pretty significant chunk of code.
I'm pretty confident I can limit the use of the address to be within the
original lease without writing too much code. After that time, I will simply
use DHCP again for the next connection to avoid using an IP address beyond
the lease time.
> In that case, why not always use static addressing?
End users will be able to use static IP but we anticipate most of our users
will not have the networking know-how to set this up. This is a consumer
device and we are trying to make setup as simple as possible.
> What are the characteristics of the 802.11 connection? WEP? WAP? EAP?
Just WEP or unsecured connections. Although establishing the connection does
take some time, it is fairly good at about 4 seconds.
> All of those things can take various amounts of time to work through
> before you can communicate with the rest of the network. Are you sure
> that you're fairly assigning the blame to DHCP?
Comparing the results with static IP, I'm sure that DHCP is a problem.
Thanks for your interest!
- John
.
- Follow-Ups:
- Re: DHCP too slow - trying to cache
- From: Paul G. Tobey [eMVP]
- Re: DHCP too slow - trying to cache
- References:
- DHCP too slow - trying to cache
- From: John Roberts
- Re: DHCP too slow - trying to cache
- From: Paul G. Tobey [eMVP]
- DHCP too slow - trying to cache
- Prev by Date: Deployment with Windows CE 5.0 & Visual Studio 2005 Beta 2
- Next by Date: RE: Recording wave files
- Previous by thread: Re: DHCP too slow - trying to cache
- Next by thread: Re: DHCP too slow - trying to cache
- Index(es):
Relevant Pages
|
