From: "Brent V" <brent@(email surpressed)>
Subject: Disabling FU
   Date: Sat, 23 Jan 2004 13:59:42 -0800
Msg# 445
View Complete Thread (8 articles) | All Threads
Last Next
Is there a way to disable the fu button for particular people or particular
jobs?  We have people who are submitting long jobs who don't want it
accendentally reqeueued or dumped.  Is this possible?
-Brent V.
 ATD, The Orphanage



   From: Greg Ercolano <erco@(email surpressed)>
Subject: Re: Disabling FU
   Date: Sat, 23 Jan 2004 14:45:20 -0800
Msg# 446
View Complete Thread (8 articles) | All Threads
Last Next
Brent V wrote:
[posted to rush.general]

Is there a way to disable the fu button for particular people or particular
jobs?  We have people who are submitting long jobs who don't want it
accendentally reqeueued or dumped.  Is this possible?

	Yes; see 'disablefu' in the rush/etc/rush.conf file:

disablefu 0

	Just change that '0' to a '1', and the fu button will be disabled
	for normal users.

	rush admins configured in 'permit' will still be able to use it.

	See the docs here:
	http://www.seriss.com/rush-current/rush/rush-conf.html#DisableFu

--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Cel: (Tel# suppressed)
Fax: (Tel# suppressed)

   From: Greg Ercolano <erco@(email surpressed)>
Subject: Re: Disabling FU
   Date: Sat, 23 Jan 2004 15:13:24 -0800
Msg# 447
View Complete Thread (8 articles) | All Threads
Last Next
We have people who are submitting long jobs who don't want it
accendentally reqeueued or dumped.

	BTW, you can prevent your job from being bumped by other
	high priority 'killer' jobs (jobs running with 'k' priority)
	by submitting your job with almighty priority ('a' priority),
	eg:

Cpus: +any=10@100a

	So if some other job is added to the queue with a higher
	'killer priority', it won't be able to bump your job's frames.

	Use of 'k' and 'a' priority can also be controlled via the
	rush.conf file; see the docs on the 'permit' command:
	http://www.seriss.com/rush-current/rush/rush-conf.html#Permit

--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Cel: (Tel# suppressed)
Fax: (Tel# suppressed)

   From: "jackemuk" <jackemuk@CobaltFX.com>
Subject: Re: Disabling FU
   Date: Sat, 23 Jan 2004 15:28:05 -0800
Msg# 449
View Complete Thread (8 articles) | All Threads
Last Next
Greg,

How come the newsgroup mailings are coming via void@(email surpressed)?

The FROM is from you, but the TO has been changed to "void".

I was trying to make a filter in Outlook Express and noticed it...

-g

p.s. I'm using explorer...
----- Original Message ----- 
From: "Greg Ercolano" <erco@(email surpressed)>
To: <void@(email surpressed)>
Sent: Friday, January 23, 2004 3:13 PM
Subject: Re: Disabling FU


> [posted to rush.general]
> 
> >> We have people who are submitting long jobs who don't want it
> >> accendentally reqeueued or dumped.  
> 
> BTW, you can prevent your job from being bumped by other
> high priority 'killer' jobs (jobs running with 'k' priority)
> by submitting your job with almighty priority ('a' priority),
> eg:
> 
> Cpus: +any=10@100a
> 
> So if some other job is added to the queue with a higher
> 'killer priority', it won't be able to bump your job's frames.
> 
> Use of 'k' and 'a' priority can also be controlled via the
> rush.conf file; see the docs on the 'permit' command:
> http://www.seriss.com/rush-current/rush/rush-conf.html#Permit
> 
> -- 
> Greg Ercolano, erco@(email surpressed)
> Rush Render Queue, http://seriss.com/rush/
> Tel: xxx-xxx-xxxx
> Cel: xxx-xxx-xxxx
> Fax: xxx-xxx-xxx
> 

   From: Greg Ercolano <erco@(email surpressed)>
Subject: Re: Disabling FU
   Date: Sat, 23 Jan 2004 16:18:27 -0800
Msg# 450
View Complete Thread (8 articles) | All Threads
Last Next
jackemuk wrote:
How come the newsgroup mailings are coming via void@(email surpressed)?

	I think it's to hide the To:rush.general address from
	the newsgroup.

	Because the mail gateway and newsgroup intercommunicate,
	it prevents crosstalk in the headers that can lead to
	bounces going around in circles. Or something like that ;)

I was trying to make a filter in Outlook Express and noticed it...

	Set your mail filter to check for the "Reply-To" field
	to be the rush.general return addy. That's what I have
	in my filter; I'm looking at it now.

--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Cel: (Tel# suppressed)
Fax: (Tel# suppressed)

   From: Steve Kochak <steve@(email surpressed)>
Subject: Re: Disabling FU
   Date: Sat, 23 Jan 2004 15:16:03 -0800
Msg# 448
View Complete Thread (8 articles) | All Threads
Last Next
<rant>
I would like the option to disable the FU option for users that clearly don't understand that they are not the most important people in the company and that everyone's job is important.
</rant>

- Steve

Brent V wrote:
Is there a way to disable the fu button for particular people or particular
jobs?  We have people who are submitting long jobs who don't want it
accendentally reqeueued or dumped.  Is this possible?
-Brent V.
 ATD, The Orphanage




   From: Greg Ercolano <erco@(email surpressed)>
Subject: Re: Disabling FU
   Date: Sat, 23 Jan 2004 16:26:34 -0800
Msg# 451
View Complete Thread (8 articles) | All Threads
Last Next
Steve Kochak wrote:
<rant>
I would like the option to disable the FU option for users that clearly don't understand that they are not the most important people in the company and that everyone's job is important.
</rant>

	I'll be implementing the annoying users detector in the
	next release; the program logic is:

		if ( user.BeingAnnoying() )
		    { RebootHostBelongingTo(user); }

	;)

	You should let peer pressure work for you; when a problem
	comes up, simply audit the logs to see who knocked their
	priority up beyond what they should, and advertise it to
	everyone who was affected.

	This only works if there's a clear policy for setting
	priorities.

	Basically, work with the 'problem users' to find out why
	they keep breaking the policy, and modify the policy until
	it works for everyone.

	But a clear policy for priority has to be established, or
	anarchy will always result.

	I can help you if these users are posing challenging responses
	to the existing policy.

	Normally the users who break policy have some driving reason,
	because the current policy isn't working, and often the pressures
	on them are legitimate.

	It's a matter of coming up with a policy that takes into account
	the demands of production. Find out what the demands are, and then
	determine a policy that works, and advertise it clearly in a web
	page and/or email.

	It's the only way to bring sanity.
	This means, however, having a good understanding of the priority
	mechanism (staircasing priorities, when to use high, low, and
	killer priorities)

	If you need help, bring me into the conversations, and I can
	help you come up with a policy.


--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Cel: (Tel# suppressed)
Fax: (Tel# suppressed)

   From: "Stefan Andersson" <sanders3d@(email surpressed)>
Subject: Re: How do I force a machine with multiple CPUs to use only one CPU for
   Date: Mon, 08 May 2006 10:56:56 -0400
Msg# 1285
View Complete Thread (8 articles) | All Threads
Last Next
Can't you use the "-thread 1" or something similar in the render
script? That way it would force the render to just use one thread.

regards
stefan


On 8 May 2006 14:51:44 -0000,  <> wrote:
 a specific type of job?
From: Jon Herman <jonh@(email surpressed)>
Message-ID: <1284-rush decimal general at seriss decimal com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Path: seriss.com
Xref: seriss.com rush.general:1284
Reply-To: rush decimal general at seriss decimal com
Errors-To: erco@(email surpressed)

[posted to rush.general]

I would like to be able to create a rush group that would limit the
number of CPUs to be used in a specific job.

Here's my problem: I need to be able to use all of the CPUs on a host
for rendering with XSI, but I also need to be able to use those same
muli-cpu hosts with an application that work using only one CPU.

So, I'd like to retain the multiple processors for XSI jobs, but use a
single processor for another type of job, on the same set of hosts. I
know I can describe the host's CPUs in the rush.conf file, but is there
a way to make rush think the host only has one processor when it's using
a specific group?

Best,

Jon Herman
Troublemaker Studios



--
-------------------[ tear off and keep ]-------------------
http://os3d.blogspot.com/
http://www.flickr.com/photos/sanders3d/