> -----Original Message-----
> From: stef...@apache.org [mailto:stef...@apache.org]
> Sent: maandag 8 april 2013 16:11
> To: comm...@subversion.apache.org
> Subject: svn commit: r1465647 - /subversion/site/publish/docs/release-
> notes/1.8.html
>
> Author: stefan2
> Date: Mon Apr 8 14:11:21 2013
> New Revision: 1465647
>
> URL: http://svn.apache.org/r1465647
> Log:
> Update the release notes in light of r1465622. We will no longer
> time out in zero-copy mode but naive use of this option will still
> have adverse effects on quality of service.
>
> * publish/docs/release-notes/1.8.html
> (svnserve): replace the bit about timeouts;
> add a note about cache dependency
>
> Modified:
> subversion/site/publish/docs/release-notes/1.8.html
>
> Modified: subversion/site/publish/docs/release-notes/1.8.html
> URL: http://svn.apache.org/viewvc/subversion/site/publish/docs/release-
> notes/1.8.html?rev=1465647&r1=1465646&r2=1465647&view=diff
> ==========================================================
> ====================
> --- subversion/site/publish/docs/release-notes/1.8.html (original)
> +++ subversion/site/publish/docs/release-notes/1.8.html Mon Apr 8
> 14:11:21 2013
> @@ -1560,13 +1560,16 @@ CPU load. Future clients may be able, ho
> </p>
>
> <p>When the server is given the <tt>--client-speed N</tt> parameter,
> -it will assume that <tt>all</tt> clients are able to process data rates
> -of N Gbit/s; N being a non-negative integer. With N>0, the server will
> +it will assume that most clients are able to process data at rates of
> +N Gbit/s; N being a non-negative integer. With N>0, the server will
> take various shortcuts to reduce internal processing overhead. On the
> -downside, it must employ strict time-outs to prevent clients from
> -interfering with each other: In any 1 second interval, a client must process
> -incoming data with at least 2% of the specified speed - or the server
> -may time out and abort the operation.
> +downside, a hanging client may cause server performance to degrade for
> +other clients. Setting N to values above 100 is legal but will often
> +result in a net performance loss.
> +</p>
Would it help if we would use Mbit here, to allow other types of improvements
later?
In general I'm committing over the internet and I don't think these speeds make
any sense here in the forseeable future, while I could see us optimizing
between ADSL (1-20 Mbit down, 0.25-4 up) and fiber (20-300 Mbit synchronous) in
future versions.
I don't see a more than one GBit connection to a server anywhere in sight for
workstations, except for very specific network setups. (Server-server might go
to 10 Gbit/s in the near future, but that is not a common workstation scenario)
If we switch to Mbits/s as value we should still be able to talk about more
than a Pbit/s using a normal integer.
Bert
