On 11 Mar 2011, at 17:03, Andrew Deason <[email protected]> wrote:
> On Fri, 11 Mar 2011 15:01:44 +0000 > Simon Wilkinson <[email protected]> wrote: > >> However, I'm less sure about the time resolution variable. This means >> that we are in effect tripling the size of every time payload in AFS. >> I'd be interested in a far more detailed discussion of the pros and >> cons for including this variable. In particular, will this information >> really change sufficiently rapidly that it needs to be included with >> every single piece of time data? Does it give us benefits that >> specifying a per-service granularity using capability bits won't? > > No, I don't think that is sufficient. A service can support > 100ns-granular time, but say it reads a time value from disk from a > structure that represents time in seconds. In what circumstances would you be comparing this value with one derived from a source with higher granularity, though? I'm really interested in specific use cases here. We're talking about adding a significant overhead here - I think we need to clearly understand the benefits. > If you transmit that time (or > a time derived from it), it is inferred from the other side that it has > 100ns granularity if this is done just with a per-service cap bit, which > is incorrect. You could easily require that an implementation that advertises a specific level of granularity provides that for all values (and rounds down items that come from higher granularity sources) S. > _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
