[Spice-devel] [PATCH v2 spice-protocol 2/2] Add qos related messages

[Yonit Halperin]

On 04/18/2012 08:34 PM, Marc-André Lureau wrote:
> On Tue, Apr 17, 2012 at 12:11 PM, Yonit Halperin<yhalperi at redhat.com>  wrote:
>> If the client's channel has SPICE_COMMON_CAP_QOS_QUERY,
>> the server's channel can send SPICE_MSG_QOS_QUERY to the client.
>> In response, the client is expected to send back SPICE_MSG_QOS_ACK
>> immediately after it receives the message following the query, and
>> before handling this message. The server can deduce
>> the network condition using the ack arrival time.
>
> Why the server would have to wait for a reasonably sized message?
> Couldn't it send the number of bytes the client should receive before
> replying ack?
>
> So instead of:
> ->  QOS_QUERY
> ->  1 MSG
> <- QOS_ACK
>
> It would be
> ->  QOS_QUERY(nbytes)
> ->  nbytes of various messages 1 or n
> <- QOS_ACK
>
> That would make it a bit more flexible than having to wait or produce
> a reasonable sized message perhaps. For example, if the message is
> just slightly too small we could either add padding, or queue it with
> another message. In the case of video frames, we could wait for the
> second frame before sending?

Hi,
I tried to do it, but it is not straightforward since the time it takes 
to send those messages will also include their preparation time in the 
server and their processing time in the client. I wrote about it in the 
cover letter:

"I decided not to send it (yet?), but I also worked on monitoring the 
time it takes the client to ack windows of messages (with 
SPICE_MSGC_ACK),  when those messages are sent relatively fluently, and 
when we aggregate several windows if the total size of the messages is 
too small.
The time that passes since a window starts till we receive an ack for it 
includes both the preparation time of the messages in the server, and 
the time it takes to the client to process the messages.
Thus, comparing this time to the QOS_QUERY time, could have given us 
some sort of estimation for the cpu state of the client and server"

Yonit.
>
> regards
>