[OpenAFS] 1.3.6000 integrated logon?
Kevin Coffman
kwc@citi.umich.edu
Fri, 19 Mar 2004 10:43:58 -0500
This is a multi-part message in MIME format.
------=_NextPart_000_000E_01C40D9F.2C0A9A30
Content-Type: text/plain;
charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
I'm at home today, so I can't do much to help diagnosing. The problem I =
saw
was a 30-60 delay after double-clicking the tray icon before the dialog
appeared. Switching between tabs from tokens to drive mappings takes =
30-60
seconds or more. Redrawing the dialog box has a similar delay. I =
didn't do
a network trace, but I did look at CPU. afscreds is using CPU, but it's =
not
like it is pegged (2 to 9% usage).
-----Original Message-----
From: Jeffrey Altman [mailto:jaltman@columbia.edu]=20
Sent: Friday, March 19, 2004 9:42 AM
To: Stephen Joyce
Cc: Kevin Coffman; openafs-info@openafs.org
Subject: Re: [OpenAFS] 1.3.6000 integrated logon?
Stephen Joyce wrote:
FWIW, I've seen that very slow behavior too, but figured it was =
something
I'm doing wrong... (the new versions, .5299 and .6000, also seem to
consistently crash, with the question about sending a crash report to =
MS,
every time I stop the service.) I see this on WinXPsp1 with only MS
patches and OpenAFS installed.
First, the crash is most likely in the new power
management thread. The thread is not always=20
shutting down before the service control thread
finishes. I thought I had that fixed.
As for the slow dialogs I am not sure. Is there
any additional information you can provide? =20
What do you mean by slow? Delays while entering
text? Delays from the time the "OK" button is
pressed until the tokens are obtained? =20
One point of information is that in OpenAFS I=20
discovered a very bad race condition between=20
processes or threads on the same machine within
ktc_SetToken() or ktc_GetToken() calls. Each
call must perform two steps a pioctl() and an
RPC. It is possible for two processes making
calls at the same time to be stair stepped=20
resulting in undesireable results. Therefore,
I added a global mutex around the pairs of calls
to ensure that only one thread/process is=20
attempting to perform an operating at a time.
This will introduce a very slight delay because
the Obtain Tokens thread is competing with=20
another thread within afscreds.exe which is
also performing the pioctl()/RPC call combinations
to obtain token status information. However,=20
I cannot imagine the delay is all that great.
Does a network trace reveal anything interesting?
Jeffrey Altman
------=_NextPart_000_000E_01C40D9F.2C0A9A30
Content-Type: text/html;
charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><SPAN class=3D144373715-19032004><FONT face=3DArial color=3D#0000ff =
size=3D2>I'm at=20
home today, so I can't do much to help diagnosing. The problem I =
saw was a=20
30-60 delay after double-clicking the tray icon before the dialog=20
appeared. Switching between tabs from tokens to drive mappings =
takes 30-60=20
seconds or more. Redrawing the dialog box has a similar =
delay. I=20
didn't do a network trace, but I did look at CPU. =
afscreds is=20
using CPU, but it's not like it is pegged (2 to 9% =
usage).</FONT></SPAN></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> =
Jeffrey Altman=20
[mailto:jaltman@columbia.edu] <BR><B>Sent:</B> Friday, March 19, 2004 =
9:42=20
AM<BR><B>To:</B> Stephen Joyce<BR><B>Cc:</B> Kevin Coffman;=20
openafs-info@openafs.org<BR><B>Subject:</B> Re: [OpenAFS] 1.3.6000 =
integrated=20
logon?<BR><BR></FONT></DIV><FONT face=3D"Bitstream Cyberbit">Stephen =
Joyce=20
wrote:<BR></FONT>
<BLOCKQUOTE =
cite=3DmidPine.GSO.4.58.0403190841340.9669@titan.physics.unc.edu=20
type=3D"cite"><PRE wrap=3D""><FONT face=3D"Bitstream Cyberbit">FWIW, =
I've seen that very slow behavior too, but figured it was something
I'm doing wrong... (the new versions, .5299 and .6000, also seem to
consistently crash, with the question about sending a crash report to =
MS,
every time I stop the service.) I see this on WinXPsp1 with only MS
patches and OpenAFS installed.
</FONT></PRE></BLOCKQUOTE><BR>First, the crash is most likely in the new =
power<BR>management thread. The thread is not always =
<BR>shutting down=20
before the service control thread<BR>finishes. I thought I had =
that=20
fixed.<BR><BR><BR>As for the slow dialogs I am not sure. Is =
there<BR>any=20
additional information you can provide? <BR><BR>What do you mean =
by=20
slow? Delays while entering<BR>text? Delays from the time =
the "OK"=20
button is<BR>pressed until the tokens are obtained? <BR><BR>One =
point of=20
information is that in OpenAFS I <BR>discovered a very bad race =
condition=20
between <BR>processes or threads on the same machine =
within<BR>ktc_SetToken()=20
or ktc_GetToken() calls. Each<BR>call must perform two steps a =
pioctl()=20
and an<BR>RPC. It is possible for two processes making<BR>calls =
at the=20
same time to be stair stepped <BR>resulting in undesireable =
results. =20
Therefore,<BR>I added a global mutex around the pairs of calls<BR>to =
ensure=20
that only one thread/process is <BR>attempting to perform an operating =
at a=20
time.<BR>This will introduce a very slight delay because<BR>the Obtain =
Tokens=20
thread is competing with <BR>another thread within afscreds.exe which=20
is<BR>also performing the pioctl()/RPC call combinations<BR>to obtain =
token=20
status information. However, <BR>I cannot imagine the delay is =
all that=20
great.<BR><BR>Does a network trace reveal anything =
interesting?<BR><BR>Jeffrey=20
Altman<BR><BR><BR></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_000E_01C40D9F.2C0A9A30--