On busy VPS and shared host with limited resources, the time between when a messages is sent to the tcpip send or receive queue and when it is sent in the case of send queue, or when it is processed (ProcessMessage) can be in excess of 30 seconds. This delay introduces a skew in AdjustedTime.
For the receive queue, the post processing uses the receive time prior to entering the queue to calculate TimeOffset rather than Now() which currently includes the delay in the queue.
For the send queue, the queued message is altered to update the nTime of the message to the actual time it is being sent rather than the time at which it was queued
Was tested on an hp 370 G6 24 core 3ghz 192gb host with the daemon launched with -par=2 to restrict the resources of the daemon. Logging was added pre-patch to document the delay through the queue and was observed for both send and receive to be occasionally > 30 seconds when the daemon was busy following the tip or during reorgs when the cup utilization for the assigned core approached 100%. Significant queue delay occurs most often in the receive queue (several times a minute) and infrequently in the send queue ( 1 observation in several hours of testing ).
Checklist:
Go over all the following points, and put an x in all the boxes that apply.
- [X ] I have performed a self-review of my own code
- [X ] I have commented my code, particularly in hard-to-understand areas
- I have added or updated relevant unit/integration/functional/e2e tests
- I have made corresponding changes to the documentation
- I have assigned this pull request to a milestone (for repository code-owners and collaborators only)
