(not really delays anymore)
If you are looking for the precise distance between the frozen edge and the open edge, this can be seen in the footer of the homepage on the client.
Nyzo uses a fixed, 7-second block duration. The "open edge" is the latest block that is available for the blockchain to process. When the cycle is functioning optimally, it will freeze blocks so quickly that there will be a period of waiting between the freezing of a block and the time at which the next block becomes the open edge. This means that the frozen edge will be 0 or 1 blocks behind the open edge at all times.
When the cycle stalls or is not producing blocks quickly enough, the frozen edge can fall far behind the open edge. Previously, such a state would cause new transactions to be delayed by approximately the amount of time between the end timestamp of the frozen edge and the end timestamp of the open edge.
The web wallet was modified to eliminate this delay, and the initial design of the client avoided the delay. When the frozen edge is far behind the open edge, past timestamps are used to compensate. Transactions are always created with timestamps just past the current frozen edge. While this may seem to be an odd manipulation, the mechanics of the blockchain do allow this, and there is nothing to be gained by timestamping transactions with the current timestamp instead of a timestamp in the past.
The ability of the cycle to process transactions in a timely manner is critical to the utility of the system. The verifier-removal process introduced in version 508 helps to ensure the health of the cycle and maintain processing throughput, but we would be naive to assume that stalls or slowdowns will not occur in the future.
Also, any verification of transaction timestamps to prevent the submission of past timestamps would require a consensus process essentially equivalent to the block consensus process. So, the only reasonable way to ensure exclusion of past-timestamped transactions is to freeze blocks quickly.
This does raise the question of what transaction timestamps mean in Nyzo. Simply, a transaction timestamp is the timestamp that the sender of the transaction chose to assign to the transaction, nothing more and nothing less. This timestamp determines block membership. If a transaction is incorporated into the blockchain, then we can trust (as much as we trust the blockchain) that the transaction was produced before or close to the verification timestamp of the block. However, there has never been a guarantee that a transaction included in a block was produced before the end timestamp of that block.
Additionally, this raises the question of what real consequence there is to the blockchain falling behind. This is not a desirable situation, but the state of the blockchain being behind is not the truly undesirable part of the situation; it is only a symptom of prolonged processing difficulties by the cycle. The other issues — consensus delays that reduce blockchain transaction throughput and dropped transactions due to sentinel blocks — these are the problems about which we should truly be concerned.
Finally, this raises a question of whether the concept of a block duration is even useful. The answer to this is a resounding yes, as a fixed block duration allows a default and fallback behavior of timestamping a transaction with its actual creation time. This is an easy-to-understand and easy-to-implement design that allows for fast transaction processing most of the time without requiring those creating transactions to have any knowledge of the current state of the blockchain.