On Tue, Sep 27, 2022 at 03:31:12PM +0200, Renaud Allard wrote:
> On 1/16/19 19:09, Otto Moerbeek wrote:
> > On Wed, Jan 16, 2019 at 01:25:25PM +0000, Stuart Henderson wrote:
> >
> > > On 2019/01/04 08:09, Otto Moerbeek wrote:
> > > > On Thu, Dec 27, 2018 at 09:39:56AM +0100, Otto Moerbeek wrote:
> > > >
> > > > >
> > > > > Very little feedback so far. This diff can only give me valid feedback
> > > > > if the coverage of systems and use cases is wide. If I do not get
> > > > > more feedback, I have to base my decisions on my own testing, which
> > > > > will benefit my systems and use cases, but might harm yours.
> > > > >
> > > > > So, ladies and gentlemen, start your tests!
> > > >
> > > > Another reminder. I like to make progress on this. That means I need
> > > > tests for various use-cases.
> > >
> > > I have a map based website I use that is quite good at stressing things
> > > (high spin% cpu) and have been timing from opening chromium (I'm using
> > > this for the test because it typically performs less well than firefox).
> > > Time is real time from starting the browser set to 'start with previously
> > > opened windows' and the page open, until when the page reports that it's
> > > finished loading (i.e. fetching data from the server and rendering it).
> > >
> > > It's not a perfect test - depends on network/server conditions etc - and
> > > it's a visualisation of conditions in a game so may change slightly from
> > > run to run but there shouldn't be huge changes between the times I've
> > > run it - but is a bit more repeatable than a subjective "does the browser
> > > feel slow".
> > >
> > > 4x "real" cores, Xeon E3-1225v3, 16GB ram (not going into swap).
> > >
> > > I've mixed up the test orders so it's not 3x +++, 2x ++, 3x + etc in
> > > order,
> > > more like +++, -, '', -, ++ etc.
> > >
> > > +++ 90 98 68
> > > ++ 85 82
> > > + 87 56 71
> > > '' 76 60 69 88
> > > - 77 74 85
> > > -- 48 86 77 67
> > >
> > > So while it's not very consistent, the fastest times I've seen are on
> > > runs with fewer pools, and the slowest times on runs with more pools,
> > > with '' possibly seeming a bit more consistent from run to run. But
> > > there's not enough consistency with any of it to be able to make any
> > > clear conclusion (and I get the impression it would be hard to
> > > tell without some automated test that can be repeated many times
> > > and carrying out a statistical analysis on results).
> > >
> >
> > Thanks for testing. To be clear: this is with the diff I posted and not the
> > committed code, right? (There is a small change in the committed code
> > to change the default to what 1 plus was with the diff).
> >
> > -Otto
> >
>
> Hello,
>
> Given that code is in base for about 4 years, shouldn't be the man page
> modified to add an explanation for those ++--? Or is there a reason why it's
> not documented?
>
> Best Regards
>
No, this is for internal/development use only and might be removed any time.
It's undocumented on purpose.
-Otto
