On Tue, Sep 27, 2022 at 08:04:11AM +0200, Markus Armbruster wrote:
> Daniel P. Berrangé <berra...@redhat.com> writes:
> > On Mon, Sep 26, 2022 at 12:59:40PM +0300, Denis Plotnikov wrote:
> >> Example of result:
> >>
> >> ./qemu/scripts/qmp/qmp-shell /tmp/qmp.socket
> >>
> >> (QEMU) query-status
> >> {"end": {"seconds": 1650367305, "microseconds": 831032},
> >> "start": {"seconds": 1650367305, "microseconds": 831012},
> >> "return": {"status": "running", "singlestep": false, "running": true}}
> >>
> >> The responce of the qmp command contains the start & end time of
> >> the qmp command processing.
>
> Seconds and microseconds since when? The update to qmp-spec.txt should
> tell.
>
> Why split the time into seconds and microseconds?
This is exactly how timestamps in QMP events are done, so we thought
we'd just follow suit
> > The mgmt app already knows when it send the QMP command and knows
> > when it gets the QMP reply. This covers the time the QMP was
> > queued before processing (might be large if QMP is blocked on
> > another slow command) , the processing time, and the time any
> > reply was queued before sending (ought to be small).
> >
> > So IIUC, the value these fields add is that they let the mgmt
> > app extract only the command processing time, eliminating
> > any variance do to queue before/after.
Right, this is precisely the motivation.
Thanks,
Roman.
