Marc-André Lureau píše v St 18. 04. 2012 v 19:47 +0200: > 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. > > 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!) >
Just my $0.02: it seems to me that only the time it takes to client (or receiving side more generally - think about record channel or guest to client copy & paste) to receive data. If the client time is trustworthy then it could look like this: 1. sender starts sending data 2. receiver starts receiving and notes t_0 3. throughout the download, the client notes stuff like reordered and resent packets 4. receiver gets last packet and notes t_1 5. in the last ACK receiver sends t = t_1 - t_0, download speed variation (if download takes sufficiently long) and packet reordering rate (which indicate network jitter) and packet loss --> sending side has all the informations about line quality, summarized when client time pace is not to be trusted, then: -> sender starts sending, notes t_0 <- clients sends first ACK right when first packet arrives, server notes t_1 when the ACK arrives -> server continues sending data till end of message <- client sends final ACK, serve notes t_2 t_ping = t_1 - t_0 can be used to determine latency (and jitter when there are more pings like this available), t_bw = t_2 - t_1 then determines bandwidth. If t_bw is not significantly larger than t_ping, the message is too small to determine bandwidth reliably. David -- David Jaša, RHCE SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 _______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
