Martin Stone Davis wrote:
Ken Corson wrote:
Martin Stone Davis wrote:
Martin Stone Davis wrote:
We start at the top of the list, and see who is going to make our
will the fastest. Since our lawyer is "backed off" at the moment,
we go with our chef.
important: "at the moment" . How big do we cons
On Monday 17 November 2003 06:56 pm, Toad wrote:
> On Mon, Nov 17, 2003 at 02:47:59PM -0500, Ken Corson wrote:
> > Martin Stone Davis wrote:
> > >Martin Stone Davis wrote:
> > >>We start at the top of the list, and see who is going to make our will
> > >>the fastest. Since our lawyer is "backed of
> > I prefer m0davis method since it matches up better with NGR. NGR
> > learns times needed.. Not the ugly QR binary on/off stuff.
> As I stated
> > in another mail.. NGR indeed seems to be able to (as it is
> intendedc
> > to) utilize time consumed for different tasks to do a
> better job w
On November 19, 2003 07:44 am, Ed Tomlinson wrote:
> On November 19, 2003 03:51 am, Niklas Bergh wrote:
> > > On November 18, 2003 08:52 am, Martin Stone Davis wrote:
> > > > We already back-off due to QR, so we already have a way of telling
> > > > when every node is going to be ready. The issue
On November 19, 2003 03:51 am, Niklas Bergh wrote:
> > On November 18, 2003 08:52 am, Martin Stone Davis wrote:
> > > We already back-off due to QR, so we already have a way of telling
> > > when every node is going to be ready. The issue here is
> >
> > adding that
> >
> > > back-off time to the
> On November 18, 2003 08:52 am, Martin Stone Davis wrote:
> > We already back-off due to QR, so we already have a way of telling
> > when every node is going to be ready. The issue here is
> adding that
> > back-off time to the estimate() so that we can tell if the best
> > strategy for a gi
On November 18, 2003 08:52 am, Martin Stone Davis wrote:
> We already back-off due to QR, so we already have a way of telling when
> every node is going to be ready. The issue here is adding that back-off
> time to the estimate() so that we can tell if the best strategy for a
> given query is to w
On November 17, 2003 08:49 pm, Martin Stone Davis wrote:
> Toad wrote:
> > On Mon, Nov 17, 2003 at 03:42:46PM -0800, Martin Stone Davis wrote:
> >>Ken Corson wrote:
> >>>Martin Stone Davis wrote:
> Martin Stone Davis wrote:
> >We start at the top of the list, and see who is going to make ou
>What you are suggesting will result in fast queries getting faster, and
>slow queries timing out - but producing considerable CPU load in the
>process. Is this a good thing?
Fred is already using much CPU.. Yet a drop of CPU usage of this (small)
size would probably not be noticed.
But yes.. You
On Mon, Nov 17, 2003 at 03:42:46PM -0800, Martin Stone Davis wrote:
> Ken Corson wrote:
> >Martin Stone Davis wrote:
> >
> >>Martin Stone Davis wrote:
> >>
> >>>We start at the top of the list, and see who is going to make our
> >>>will the fastest. Since our lawyer is "backed off" at the moment,
On Mon, Nov 17, 2003 at 03:35:37PM -0600, Salah Coronya wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Niklas Bergh wrote:
>
> |>|>> This has nothing to do with load balancing, but should improve
> |>|>> routing, while increasing CPU usage by some unknown amount. Thoughts?
> |>|
>
On Mon, Nov 17, 2003 at 02:47:59PM -0500, Ken Corson wrote:
> Martin Stone Davis wrote:
> >Martin Stone Davis wrote:
> >>We start at the top of the list, and see who is going to make our will
> >>the fastest. Since our lawyer is "backed off" at the moment, we go
> >>with our chef.
>
> important
> |>> This has nothing to do with load balancing, but should improve
> |>> routing, while increasing CPU usage by some unknown amount. Thoughts?
> |
> |
> | Actually this has A LOT to do with load balancing, indirectly.
> | Given that the requestor should have a timeout capability, how
> | would t
Martin Stone Davis wrote:
Martin Stone Davis wrote:
We start at the top of the list, and see who is going to make our will
the fastest. Since our lawyer is "backed off" at the moment, we go
with our chef.
important: "at the moment" . How big do we consider this "moment" to
be ? 100ms , 5 seconds
14 matches
Mail list logo
