On Mon, Jun 06, 2016 at 06:48:10PM -0700, Ed Swierk wrote: > On Mon, Jun 6, 2016 at 6:07 PM, Stefan Berger <stef...@us.ibm.com> wrote: > > Ed Swierk <eswi...@skyportsystems.com> wrote on 06/06/2016 06:27:59 PM: > > > The occurrence of this excessive command duration depends on the > > > sequence of commands preceding it. One sequence is creating at least 2 > > > new keys via TPM_CreateWrapKey, then letting the TPM idle for at least > > > > How long does it take to create those keys? Maybe it will create new keys > > in the 'background' after that. > > The first few TPM_CreateWrapKey commands take roughly 300 msec. I've > seen it go as high as 80 seconds after several of those in a row. > > It makes sense that a key generation process starts up after the chip > thinks it's idle. Slowing down unrelated operations stretches the > meaning of "background", of course. And locking up the chip is > downright impolite. > > > > 30 seconds, then loading a key via TPM_LoadKey2. The next > > > TPM_FlushSpecific occasionally takes tens of seconds to > > > complete. Another sequence is creating many keys in a row without > > > pause. The TPM_CreateWrapKey operation gets much slower after the > > > first few iterations, as one would expect when the pool of precomputed > > > keys is exhausted. Then after a 35-second pause, the same TPM_LoadKey2 > > > followed by TPM_FlushSpecific sequence triggers the behavior. > > > > > > Our working theory is that this older TPM sometimes pauses to perform > > > internal garbage collection, which modern chips implement as a > > > background process. Without access to the chip's implementation > > > details it's impossible to know whether any commands are immune to > > > this behavior. So it seems safest to ignore the chip's reported > > > command durations, and use a value much higher than any observed > > > duration, like 2 minutes (which happens to be the value used for > > > TPM_UNDEFINED commands in tpm_calc_ordinal_duration()). > > On further testing of my patch, I realize that I have totally confused > timeouts and durations. I need to override the command durations > (short, medium, long) reported by the chip. The reported protocol > timeouts (a, b, c, d) are fine. > > Please consider this patch withdrawn. I'll send an updated patch shortly.
Ack. > --Ed /Jarkko ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e _______________________________________________ tpmdd-devel mailing list tpmdd-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
