perfsonar-user - Re: [perfsonar-user] Problems debugging pscheduler: "Run was preempted."
Subject: perfSONAR User Q&A and Other Discussion
List archive
- From: Brian Candler <>
- To: "" <>
- Subject: Re: [perfsonar-user] Problems debugging pscheduler: "Run was preempted."
- Date: Thu, 5 Sep 2019 10:17:23 +0100
- Domainkey-signature: a=rsa-sha1; c=nofws; d=pobox.com; h=subject:from:to :references:message-id:date:mime-version:in-reply-to :content-type; q=dns; s=sasl; b=ZFhsNec/EbU0DsVUEpB+W56VSdjmeXXs BBoCkRlXeTndnBxu6NaeUW26OjRh7MRAjLh+Yn/nTg1piKf6V3S/GeQuTcU3OCLX yygQ+mi1N94EPpCe6qqI+KOn2CKdrLrAU2LCRmhm9um+N3L/ioe/JshR4jRi57JA Eoa+KUeS3u0=
On 05/09/2019 09:45, Brian Candler
wrote:
As for
point (1), even if priority is only supposed to be used for
conflicting tests, I still don't understand yet why the priority
was being set differently for my inbound and outbound tests.
I think I found it: priority.script in /etc/pscheduler/limits.conf. It sets priority 5 if "requester" is in "friendlies", which in turn is "local-interfaces". I presume that the "requester" is the lead participant; and even though I typed the command on the local host, it chooses the --source of the test as the lead participant. Note: the reference documentation for the throughput test plugin doesn't say explicitly that the --source is also the lead participant. However it says here:For many tests run by perfSONAR, a --source switch which specifies where the test should originate and is also the lead participant: So it's true for "many tests". I'd say this leads to surprising behaviour for the end user. It means that a throughput test which consumes my outbound bandwidth always gets a higher priority than a test which consumes my inbound bandwidth. This is regardless of whether the test was created by me, or by some random remote user. What I would *expect* is that any test that I have created (inbound or outbound) would get priority over any test submitted by a random remote user (inbound or outbound). Anyway, that's a different issue altogether, and not really a
major problem, although it might be nice to document it clearly as
a consequence of the pscheduler design. Regards, Brian Candler. |
- [perfsonar-user] Problems debugging pscheduler: "Run was preempted.", Brian Candler, 09/01/2019
- Re: [perfsonar-user] Problems debugging pscheduler: "Run was preempted.", Brian Candler, 09/05/2019
- Re: [perfsonar-user] Problems debugging pscheduler: "Run was preempted.", Brian Candler, 09/05/2019
- Re: [perfsonar-user] Problems debugging pscheduler: "Run was preempted.", Mark Feit, 09/05/2019
- Re: [perfsonar-user] Problems debugging pscheduler: "Run was preempted.", Casey Russell, 09/05/2019
- Re: [perfsonar-user] Problems debugging pscheduler: "Run was preempted.", Brian Candler, 09/05/2019
- Re: [perfsonar-user] Problems debugging pscheduler: "Run was preempted.", Brian Candler, 09/05/2019
- Re: [perfsonar-user] Problems debugging pscheduler: "Run was preempted.", Casey Russell, 09/05/2019
- Re: [perfsonar-user] Problems debugging pscheduler: "Run was preempted.", Brian Candler, 09/05/2019
- Re: [perfsonar-user] Problems debugging pscheduler: "Run was preempted.", Brian Candler, 09/05/2019
- Re: [perfsonar-user] Problems debugging pscheduler: "Run was preempted.", Casey Russell, 09/05/2019
- Re: [perfsonar-user] Problems debugging pscheduler: "Run was preempted.", Brian Candler, 09/05/2019
Archive powered by MHonArc 2.6.19.