[AFS3-std] Re: AFS-3 64-bit time I-D

[Simon Wilkinson]

On 11 Mar 2011, at 17:03, Andrew Deason <adeason@sinenomine.net> wrote:

> On Fri, 11 Mar 2011 15:01:44 +0000
> Simon Wilkinson <simon@sxw.org.uk> wrote:
>=20
>> However, I'm less sure about the time resolution variable. This means =20=

>> that we are in effect tripling the size of every time payload in AFS. =20=

>> I'd be interested in a far more detailed discussion of the pros and =20
>> cons for including this variable. In particular, will this information =20=

>> really change sufficiently rapidly that it needs to be included with =20
>> every single piece of time data? Does it give us benefits that =20
>> specifying a per-service granularity using capability bits won't?
>=20
> 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 fro=
m a source with higher granularity, though? I'm really interested in specifi=
c 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 l=
evel of granularity provides that for all values (and rounds down items that=
 come from higher granularity sources)

S.
>=20