anchor.diff:  - you have either one input, or you can always determine the order the inputs were consumed.
   - you have not changed the software (or all the software is stored in the queue)
   
  -If you want to be able to upgrade your system you want o replay for the output.
  +If you want to be able to upgrade your system you want to replay for the output.
   
   Replaying from the output means;
   
  
positive.code: 
  === Using high resolution timings across machines.
  
  On most systems `System.nanoTime()` is roughly the number of nano-second since the system last reboot (although different JVMs may behave differently)  This is the same across JVM on the same amchine, but wildly different between machines.  The absolute difference machines is meaningless, however the information can be used to detect outliners. i.e. you can't determine what the best latency is, but you can determine how far off the best latencies you are.  This is useful if you are focussing on the 99%ile latencies for example.  We have a class called `RunningMinimum` to obtain timings from different machines while compensating for a drift in the nanoTime between machines. The more often you take measurements the more accurate this running minimum is.
  
  === Compacting logs
  
  Chronicle Queue manages storage by cycle. You can add a `StoreFileListener` which will notify you when a file is added and when it is no longer retained.  You can move, compress or delete all the message for a day at once.
  
  == Chronicle Queue vs Kafka
  
  Chronicle Queue is designed to support over an order of magnitude the throughput with an order of magnitude lower latency of Kafka.  While Karfa is faster than many of the alternatives it doesn't support both throughputs over million events per second and low latency e.g. 1 - 20 micro-seconds at the same time.
  
  Chronicle Queue attempts to handle more volume from a single thread, to a single partition and thus avoid the need for the complexity and downsides of having partitions.  Note: Chronicle Engine supports partitioning of queues across machines, though not the partitioning of a queue.
  
  Unlike Karfa which uses a broker which uses the operating system's file system and cache.  Chronicle Queue relies entirely on the file system and cache.
  
  === Similar product guides
  
  
negative.code: 
  === Compression
  
  Replication for Chronicle Queue supports Chronicle Wire Enterprise. This supports a real time compression which calcuates the deltas for individual objects as they are written. This can reduce the size of messages bto 1/10th or better without the need for batching i.e without introducing significant latency.
  
  Queue also supports LZW, Snappy and GZIP compression however these add non-triviallatency.  These are only useful if you have have strick limitations on network bandwidth.
  
  === Delivery Mode Semantics
  
  Chronicle Queue supports a number of symantics.
  
  - every message is replayed on restart
  - only new messages are played on restart.
  - restart from any known point using the index of the entry.
  - replay only messages you have missed. This is supported directly using the methodReader/methodWriter builders.
  
  === Detailed tracing of timings.
  
  Chronicle Queue supports explicit or implicit nano-second resolution timing for messages as they pass end to end over across your system. We support using nanotime across machine without the need for specialist hardware.
  
  .Enabling high resolution timings
  [source, Java]
  