anchor.diff:  
   === 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.
  +Where CQ is compelling is its 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
   
  
positive.code: Here is a link to an article with an example of a process writing 1 TB in 3 hours: https://vanilla-java.github.io/2017/01/27/Chronicle-Queue-storing-1-TB-in-virtual-memory-on-a-128-GB-machine.html
  
  This shows how much slower it gets as the queue grows.
  Even after it is 1 TB in size on a machine with 128 GB, it write 1 GB under 2 seconds pretty consistently.
  
  While this doesn't cause a technical problem, we are aware this does concern people who also find this "weird", and we plan to have a mode which reduces virtual memory use (even if a little slower for some use cases).
  
  === With a tight reader loop I see 100% utilization, will there be processing capability left for anything else ?
  
  Two approaches for reducing CPU usage are;
  
   - combine tasks into the same thread. EventGroup in chronicle-threads helps to this dynamically.
   - use a Pauser such as a LongPauser to control how a thread backs off if there is nothing to do.  Note: There is a PauseMonitor to allow you to print how busy each thread is periodically.
  
  === What was the library originally designed for?
  
  
negative.code: 
  ===  How fast is fast?
  
  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. ;)
  
  === How does it scale?
  
  