On 04/18/2012 08:47 PM, Marc-André Lureau wrote:
Hi
On Wed, Apr 18, 2012 at 7:34 PM, Marc-André Lureau
<marcandre.lur...@gmail.com> wrote:
It would be
-> QOS_QUERY(nbytes)
-> nbytes of various messages 1 or n
<- QOS_ACK
Further questions about this, how can the server really determine the
bandwidth? (I suppose this is the goal)
There might be data queued on the upstream link, and then latency and
other factors are affecting the result.
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.
It could perhaps be more reliable if the messages would be:
-> QOS_QUERY(nbytes)
-> nbytes of various messages data
<- QOS_ACK(N Bps)
Btw, those messages should be symmetric, so we could measure
upload/download (it's always fun to reinvent the wheel!
Currently all the channels are mainly asymmetric (maybe except for the
usb). Specifically, for the display channel, which is currently the only
consumer of bandwidth data, the upload statistics are the most important
ones. In the future we may want to implement it in the client side as
well (for record channel, and usb), and add the symmetric messages.
Yonit.
_______________________________________________
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
