anchor.diff:  
   === Compression
   
  -Replication for Chronicle Queue support 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 significnat latency.
  -
  -Queue also supports LZW, Snappy and GZIP compression however these add non-trival latency.  These are only useful if you have have strick limitations on network bandwidth.
  +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 symantics.
  -
  -- every message are replayed on restart
  +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 message you have missed. This is supported directly using the methodReader/methodWriter builders.
  +- replay only messages you have missed. This is supported directly using the methodReader/methodWriter builders.
   
   === Detailed tracing of timings.
   
  -Chronicle Queue supprot explicit or implicit nano-second resolution timing for messages as they pass end to end over across you system. We support using nanotime across machine without the need for specialist hardware.
  +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]
  
positive.code:                 .write("trader").text("peter")));
  ----
  
  You can write raw data which is self describing (the types will always be correct, position is the only indication as to the meaning of those values)
  
  [source, Java]
  ----
  
negative.code: It should detemine how flow control works.
  
  Chronicle Queue is a "Producer Centric" solution and does everything possible to never push back on the producer or tell it to slow down.
  As such it is a power tool as a big buffer between your system and an upstream producer you have little or no control over.
  
  === Market Data
  
  When you receive market data from a publisher you don't have the option to push back on the producer for long if at all. 
  A few of our users consume data from CME OPRA. This produces peaks of 10 million events per second and these are sent as UDP packets 
  without any retry. If you miss or drop a packet it is lost.  You have to consume and record those packets as fast they come to you
  with very little buffering in the network adapter to save you time.
  
  For market data in particular real time means around *1 micro-second*, it doesn't mean intra-day.
  
  Chronicle Queue is fast and efficient enough it has been used to increase the speed that data is passed between threads, 
  in addition, it also keeps a record of every message passed.
  
  === Compliance Systems
  
  Complicated Systems are required by more and more systems these days.  Everyone has to have them but no one wants to be slowed down by them.
  By using Chronicle Queue to buffer data between monitored system and the compliance system, you don't need to worry about the impact 
  of complicated recording for your monitored systems.
  
  Again, Chronicle Queue can support millions of events per second per server and access data which has been retained for years.
  
  === Messaging
  
  Chronicle Queue supports low latency IPC between JVMs on the same machine ~ 1 micro-second, and between machines with a typical latency of 10 micro-seconds for
  modest throughputs of a few hundred thousands. Chronicle Queue supports throughputs over a millions of events per second with stable micro-seconds latencies.
  
  === Metrics
  
  