On Mon, Aug 1, 2011 at 1:53 PM, Andrew Deason <[email protected]> wrote: > On Mon, 1 Aug 2011 13:32:46 -0400 > Derrick Brashear <[email protected]> wrote: > >> On Mon, Aug 1, 2011 at 1:28 PM, Andrew Deason <[email protected]> wrote: >> >> >> b) the granularity >> > >> > This one I still have no idea on. I see reasons for both sides. >> >> So is there a reason an extended union with the various stamp >> granularities would be a nonstarter? In particular I'd suggest the >> draft strongly discourage >> sending a larger timestamp than actual information supports (e.g. >> don't use bits to send precision you don't have, rather than >> trailing-zero-padding a >> larger than needed number) > > Well, the objection to just having 64-bit seconds and 32-bit nanoseconds > is "space", and a union tag is an extra 32 bits... If we had a "100 NS > granularity" tag, then we'd have 100-ns granularity in 96 bits, whereas > now we could have 1-ns granularity in 96 bits. Unless there's some other > scheme you're thinking of that somehow makes this more efficient?
for the worst case, it's worse. for the best case, it's better. but i suppose it may not be worth it given that the worst case will become more prevalent over time. > I had some kind of variable-length scheme that encoded the granularity > in the 'unused' bits of the value for coarser granularities, but I'm > pretty sure that only saved space for the *TimeRes types, and doesn't > really help for 'plain' times. and those are going to be a majority, i think. -- Derrick _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
