On Mon, Apr 8, 2013 at 6:00 PM, Bert Huijben <b...@qqmail.nl> wrote: > > > > -----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? >
Good point! > 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. > Changed in r1466918. One thing we might do in future is to select default network data compression levels depending on the --client-speed parameter. > 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 your server suffers from frequent stampedes (100 users trying to checking out the latest release at the same time in a LAN), that option can help you to reduce the server load a bit. > 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. > Thanks for the review! -- Stefan^2. -- *Join one of our free daily demo sessions on* *Scaling Subversion for the Enterprise <http://www.wandisco.com/training/webinars>* * *
