pcp
[Top] [All Lists]

Re: [patch] speed pmie startup

To: Nathan Scott <nathans@xxxxxxxxxx>, Lukas Berk <lberk@xxxxxxxxxx>
Subject: Re: [patch] speed pmie startup
From: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Wed, 22 Apr 2015 08:21:53 +1000
Cc: pcp developers <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <852862416.3748569.1429589380945.JavaMail.zimbra@xxxxxxxxxx>
References: <852862416.3748569.1429589380945.JavaMail.zimbra@xxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
On 21/04/15 14:09, Nathan Scott wrote:
...It turned out
those delays were due to some places where we do 'now = now + 1sec'
- see attached patch.  Do you know the reason behind adding in that
one second difference there?  (and is it safe to remove, or reduce,
as the patch does?)

I do not know why they are there. Seppo would be the only hope of answering that.

But I can guess ... there was some initial concerns about pmie's fetch scheduling getting behind, so fetchs are scheduled to happen at some time that has already passed, and adding some arbitrary slop in the start up gave a chance to parse the config file and get set up before the first fetch.

But we've done considerable work in the interim to improve the general handling of the "scheduling getting behind" situation, so I don't think the +1sec is needed at all ... so I'd suggest dropping the first + 0.000000001 and the while second block if (!archives) { ... } can also go.

I just tried this, but there are other QA failures (from -g pmie), namely 260 and 518 ... 260 looks like it would be OK with some tweaking, but I'm not sure about 518.

Probably needs some more investigation.

<Prev in Thread] Current Thread [Next in Thread>