We ran experiments with lazy consistency enabled and
disabled and observed that the
transaction latency/throughput were the same.
Very small stall rates have little impact on transaction cost since other costs
dominate. Each fetch involves
a roundtrip with the reply being a big message (4KB); in contrast, a stall
results in a small message roundtrip.
On an ATM network, a stall takes 300 
secs, a fetch from the server cache
is approximately 650 secs (using U-Net numbers), and a disk access is around
16 msec.
For example, consider HOTSPOT with a 5-entry multistamp and
assume 50% of fetches hit in the cache.
Using the stall rate
of 2% shown in Figure 4, we
have an increase in the cost of running transactions of
less than 0.08%; with the simple optimization discussed in
Section 6.4, we get a stall rate of only 0.8% (see
Figure 8), and the increase is less than 0.03%.
Lazy consistency also has little cost in space or message size. A multistamp entry requires approximately 12 bytes of storage, and multistamps typically contain fewer entries than a given bound (e.g., in HOTSPOT, a 20-entry multistamp actually contains approximately 10 entries). Therefore, multistamps are cheap to send in messages and the memory requirements for storing them are low. The memory cost for other data structures are also low since we add only a small amount of information over what is needed for concurrency control purposes.
We compared the abort rate with and without lazy consistency and discovered that it did not change. This indicates that in these workloads invalidation requests are almost always due to false sharing rather than true sharing, and that transactions would rarely observe inconsistencies in our base system. Nevertheless, lazy consistency is worth supporting since it provides a much cleaner semantics to programmers: they can count on never seeing inconsistencies.