anchor.diff:  
   ===  How fast is fast?
   
  -Chronicle is design to persist messages and replay them in micro-second time.  Simple messages are as low as 0.4 micro-seconds.
  +Chronicle is designed to persist messages and replay them in micro-second time.  Simple messages are as low as 0.4 micro-seconds.
   Complex messages might take 10 micro-seconds to write and read.
   
   Chronicle is designed to sustain millions of inserts and updates per second. For burst of up to 10% of your main memory, you can sustain rates of 1 - 3 GB/second written.
   e.g. A laptop with 8 GB of memory might handle bursts of 800 MB at a rate of 1 GB per second.
   A server with 64 GB of memory might handle a burst of 6.5 GB at a rate of 3 GB per second.
   
  -If your key system is not measuring latency in micro-seconds and throughput in thousands per second, it is not that fast.  It may well be fast enough however. ;)
  +If your key system is not measuring latency in micro-seconds and throughput in thousands per second, it is not that fast. It may well be fast enough however. ;)
   
   === How does it scale?
   
  
positive.code: 
  === Could you please us more about the way they use CQ ?
  
  Where CQ is compelling is it's no-flow control model.  CQ is designed to not slow the producer if you have a slow consumer.  Instead you need to give it plenty of disk space as your buffer.  Disk space is cheaper than main memory and is cheaper than heap space. You can buy a system with multiple 16 TB SSD drives today. No one would consider having a JVM heap with 100 TB.
  
  A couple of prime examples are
  
  
negative.code: 
  Chronicle has an advantage over other queuing systems that the consumer can be any amount behind the producer (up to the free space on your disk)
  Chronicle has been tested where the consumer was more than main memory behind the producer.  This reduced the maximum throughput by about half.
  Most systems, in Java, where the queue exceeds the size of main memory cause the machine to become unusable.
  
  Note: the Consumer can stop, restart and continue with minimal impact to the producer, if the data is still in main memory.
  
  Having a faster disk sub-system helps in extreme conditions like these.
  Chronicle has been tested on a laptop with an HDD with a write speed of 12 MB/s and an over-clocked hex core i7 PCI-SSD card, which sustained a write speed of 900 MB/s.
  
  === Can Chronicle Queue be used like RMI?
  
  