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

[Yonit Halperin]

On 04/19/2012 02:58 PM, Marc-André Lureau wrote:
> On Thu, Apr 19, 2012 at 9:30 AM, Yonit Halperin<yhalperi at redhat.com>  wrote:
>> The latency factor is in my TODO (see cover letter).
>> I use ioctl(socket, TIOCOUTQ) in order to find how many bytes are pending in
>> the tcp snd buffer, in addition to the size of the message.
>> So I calculate the bandwidth by (message_size + ioctl(socket,
>> TIOCOUTQ))/ack_time.
>> When I add the latency, it will be (message_size + ioctl(socket, TIOCOUTQ))
>> / (ack_time - latency)
>>
>> This measurement can be affected by other links, but I think it is what we
>> want ->  the actual bandwidth available for the channel.
>
> Don't we want to measure only downlink bandwidth/conditon separately
> from uplink? What you suggest takes into account a lot of parameters
> from both side. I still fail to see what exactly it represents. Imho,
> it doesn't need TIOCOUTQ or latency. A top with N bytes sent "in
> burst" is all it takes, no?
>
>
We want to measure the effective traffic rate from the server to the 
client. It is not really important if the bottle neck is the uplink of 
the server, or the downlink of the client.
Since the relevant spice channel is mostly uni-directional, and the ack 
message from the client is small, the ping-pong time can give us 
(latency-server + latency-client), and subtracting it from the ack time 
will allow us to measure the traffic rate.
TIOCOUTQ is essential in order to know, as much as you can, how much 
data has been sent to the client since you started the time measuring.
I didn't understand your comment  "A top with N bytes sent "in
 > burst" is all it takes, no?"
In the future, we plan to have bandwidth shaping capabilities per 
channel (Maybe via libvirt and tc), so it is necessary to measure the 
traffic per channel.