On 04/19/2012 02:58 PM, Marc-André Lureau wrote:
On Thu, Apr 19, 2012 at 9:30 AM, Yonit Halperin<yhalp...@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.
_______________________________________________
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
