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

[Yonit Halperin]

On 04/22/2012 04:23 PM, Marc-André Lureau wrote:
> On Sun, Apr 22, 2012 at 10:39 AM, Yonit Halperin<yhalperi at redhat.com>  wrote:
>>   "A top with N bytes sent
>
> This is the simpler mechanism I have in mind: the client receives a
> "start mark" knowing N bytes are following that were sent directly (in
> "burst"). Once the N bytes are received the client can report the time
> it took to receives those, or the bandwidth. Tbh, I am still not
> convinced by the proposal you made, to measure somehow only one
> direction bandwidth but take overall latency in whatever
> state/buffering/timing in both uplink and downlink..
>
t1-t0 = l1 + f*b + l2
where t0=server_send_time t1=server_receive_ack_time
l1+l2 =up_latency + down_latency = roundtrip time
f=bandwidth
b=sent data size

Of course, this is theoretic, and in reality there are overheads related 
to the protocol, cpu, etc. Thus, the computed f is smaller than the real 
throughput. However, for spice purposes, the exact value is not 
critical, and an estimation that is smaller than the real value is 
preferred over the opposite.
In addition, an estimation of the latency is something we may also want 
to use in the future, e.g., for tuning the size of the playback 
de-jitter buffer, etc.

Regarding your suggestion:
Taking a burst of "N bytes" is problematic with the current serial 
implementation of the server and the client: (process_message, 
send_message), (proccess_message, send_message),.... ---> 
(receive_message, process_message), (receive_message, process_message)
We can look at the time it took to the client to receive the message 
following the qos message, if its size is big enough to make the size of 
the data already pending in the tcp stack neglectable.