anchor.diff:  = Frequently Asked Questions about Chronicle
  -
  -=== What is Single Chronicle Queue?
  +Neil Clifford
  +:toclevels: 1
  +:css-signature: demo
  +:toc-placement: preamble
  +:icons: font
  +
  +This document provides information for some common questions about Chronicle Queue.
  +
  +== What is Single Chronicle Queue?
   
   Single Chronicle Queue is designed to be easier to work with compared with
   the previous vanilla and indexed Chronicle versions.
  
positive.code: - storing key information in the header so that there is no longer the requirement that the writers and readers be configured the same.
  - not needing to know the size of the message.
  
  === What is the performance like?
  
  Single Chronicle (single file per cycle) supports sub-microsecond latencies. If you use Wire, the typical latencies tend to be around one micro-second.  You can still use raw writing of bytes if you need maximum performance.
  
  === 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 do this dynamically.
   - use a Pauser such as a `LongPauser` to control how a thread backs off if there is nothing to do.  There is a `PauseMonitor` to allow you to periodically print how busy each thread is.
  
  === What is Chronicle designed for?
  
  Chronicle is design to record everything of interest in the logger and persisted IPC.
  A key requirement of low latency systems is transparency, and you can record enough information to enable a monitoring system to recreate the state of the monitored system.  This allows downstream systems to record any information they need, and perform queries without having to touch the critical system.
  
  Chronicle works best in `SEDA` style event-driven systems, where latency is critical, and you need a record of exactly what was performed, and  when. All this can be done without expensive network sniffing/recording systems.
  
  === How does Chronicle Queue use memory?
  
  Chronicle Queue is designed to use virtual memory which can be much larger than main memory (or the heap). This is done without a significant impact on your system, and allows you to access the data at random, quickly.
  
  
negative.code: - readers can wait to only read acknowledged messages.
  - throttling and traffic shaping.
  
  == Does Chronicle Queue support UDP replication?
  
  No. Chronicle Queue is designed to be both reliable and deterministic.  UDP is not designed for this.  A hybrid UDP/TCP system is possible in the future.
  
  == How do I know the consumer is up to date?
  
  For the tailer, either replicated or not replicated, you can assume you are up-to-date when either `isPresent()` is `false`, or your read method returns `false`
  
  == What are the differences between the `files directory-listing.cq4t` and `metadata.cq4t` ?
  
  They are almost the same, except `files directory-listing.cq4t` was in earlier versions of Chronicle Queue, while `metadata.cq4t` is applicable for Chronicle Queue 5.0 onwards.
  
  
  == Performance between Disk and RAM. Should we specify faster RAM or a faster disk to Chronicle improve read/write performance?
  
  Chronicle recommends lots of high-speed RAM. This is because Chronicle uses the page cash and RAM is in effect a cache to the disk. 
  
  There are two cases where having a high-speed disk will give you a real benefit:
  
  ==== 1. Data rate
  If the rate of data that you are writing exceeds the disk write speed. In most applications this is unlikely to occur.
  
  ==== 2. Page cache miss
  For Chronicle queues which write and read messages lineally across memory, we mitigate this situation with the use of the Chronicle pre-toucher. The pre-toucher ensures that the page is loaded into the page cache before being written into the queue. 
  
  For Chronicle Map, it is somewhat more complicated because Chronicle Map reads and writes your entries with random access across both the memory and disk. In this situation, if the entire map can be held within the page cash, then a read, or write, to the map will not have to access the disk. The operating system will work in the background ensuring that entries written to the page cache are propagated to the disk, but this is done via the operating system and is not on the critical path. 
  
  It follows that if you have quite a few maps, especially large maps, and your page cash is not large enough to hold all of these maps, then a read, or write, to a random entry may cause a cache miss. This in turn would cause a disk read or write. If you were going to install high-speed SSDs, Chronicle recommends that you use them to store the Chronicle maps and leave the slower cheap disks for the Chronicle queues. In addition, you should avoid using network attached storage, as this usually offers worst performance than local disks.
  
  '''
  <<../README.adoc#,Back to ReadMe>>
  