[96] in Kakapo Windows Team
Re: status update on slow startup times and afs connections
daemon@ATHENA.MIT.EDU (Philip R Thompson)
Thu Sep 18 17:34:28 2003
Message-Id: <5.2.1.1.2.20030918173119.00c46f30@po9.mit.edu>
Date: Thu, 18 Sep 2003 17:34:25 -0400
To: "Thomas L. Thornton" <tomt@mit.edu>, contact-container-admins@mit.edu
From: Philip R Thompson <phils@MIT.EDU>
Cc: kakapo@mit.edu, ferrara@mit.edu
In-Reply-To: <200309181605.h8IG5QOE019032@the-rim.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sure we can test it.
Slap that on to dusp-test and possibly some specific machines in the dusp
container.
-Phil
At 12:05 PM 9/18/2003 -0400, Thomas L. Thornton wrote:
>This follows up on a thread "AFS &/or XP issues" we started almost a
>month ago. Two issues of interest to the win.mit.edu container
>administrator continue to exist and deserve this report:
>
> 1. Some XP machines spend ten or more minutes during reboot in the
> "Applying computer settings" state;
>
> 2. Sometimes AFS takes several tries before successfully restarting
> the service.
>
>There is much mail about these misbehaviors, and Casetracker numbers
>probably associated with the above, respectively, are:
> 1. 404542, 408880
> 2. 410179, 411090, 417061, 418345, 418352, 426296, 428304
>
>In August we noticed an erroneous service-restart setting missing from
>installer, fixed it in our code base and we expect this problem to
>disappear upon our next AFS release. Over the past three weeks we
>have found a couple more possible reasons for service failure. We
>have delayed packaging these fixes expecting to address the long
>reboot time problem.
>
>The long reboot problem has been particularly burdensome. Paul asked
>MS PSS about this weeks ago. They got back to us last week, saying
>that the slowdown can be addressed by adding netman to AFS service
>dependencies in the registry. Alas, testing this indicates no
>improvement.
>
>Meanwhile we brainstormed on possible workarounds like reordering the
>listing of network providers, disabling the "Network Connections"
>service, looking for interactions with WebDAV or the WebClient
>service, the ShellSvcGroup and the GP that sets "Always wait for the
>network at computer startup and logon." No luck with any of these.
>
>In June by Microsoft advice, we rewrote the code for determining which
>LAN adapter to use. The old code uses an undocumented API. According
>to Microsoft, this API should not be used, and will go away in the
>future. However, their suggested alternative is unimplemented on W2K,
>so for the currently-deployed AFS we made two code paths and expected
>XP and later OSs to work via the documented and supported API.
>
>As a last resort Paul and Joe built a service that uses only the old
>API. Testing the old API service on XP machines eliminated the boot
>delay. The service seems to function normally (e.g.users' tokens are
>acquired, the home directory is available, etc.) and with machine
>startup times comparable to W2K.
>
>Therefore, now we *may* have a workaround, with two big
>qualifications. First caveat, this must be temporary - the service
>uses the undocumented API that may break with any future SP or OS.
>Second, it has been tested on only IS machines and a couple in FSS, so
>needs some more field testing before we package and deploy it.
>
>Chad Dupuis, Dan Stratila, Phil Thompson, could you volunteer a test
>on each of your slowest-booting machines? Please let me know.
>
>-Tom
