Status rendering speed N/A

Message boards : Number crunching : Status rendering speed N/A
Message board moderation

To post messages, you must log in.

AuthorMessage
Speedy

Send message
Joined: 25 May 06
Posts: 208
Credit: 676,104
RAC: 0
Message 4753 - Posted: 2 Mar 2007, 5:28:05 UTC

I\'ne noticed over the past couple of days that in the status window, parts waiting to be rendered is woeking fine, but the speed wich they are been rendered at eg: 28.8/per minute is showing as N/A. Is this ment to be the case?

Cheers
ID: 4753 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Janus
Volunteer moderator
Project administrator
Avatar

Send message
Joined: 16 Jun 04
Posts: 4570
Credit: 2,100,463
RAC: 8
Message 4759 - Posted: 2 Mar 2007, 11:05:00 UTC - in response to Message 4753.  
Last modified: 2 Mar 2007, 11:05:32 UTC

I\'ne noticed over the past couple of days that in the status window, parts waiting to be rendered is woeking fine, but the speed wich they are been rendered at eg: 28.8/per minute is showing as N/A. Is this ment to be the case?

I\'m currently working on figuring out a better way to produce this figure as the old way consumed quite some amount of DB resources.

This is tightly connected with the suggestion in this thread (Status bars on progress page) since the current passive status monitoring system can be replaced entirely by an active monitoring system that performs much better.
As with the other thread, I\'ll wait with the implementation of this untill there\'s no work in the renderqueue.
ID: 4759 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Speedy

Send message
Joined: 25 May 06
Posts: 208
Credit: 676,104
RAC: 0
Message 4780 - Posted: 2 Mar 2007, 21:01:22 UTC - in response to Message 4759.  

Thanks for the info

Cheers
ID: 4780 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Janus
Volunteer moderator
Project administrator
Avatar

Send message
Joined: 16 Jun 04
Posts: 4570
Credit: 2,100,463
RAC: 8
Message 4944 - Posted: 9 Mar 2007, 9:48:01 UTC
Last modified: 9 Mar 2007, 9:50:56 UTC

The status system has now been updated and has indeed proven to run amazingly much faster than the passive system.
Another interesting thing is that where the old system could only monitor the status right now, the new one is able to provide a history of how the status has been each hour since it was started. At some point in the future this may be useful to draw some usage graphs.
ID: 4944 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
[B^S] sTrey
Avatar

Send message
Joined: 23 Mar 05
Posts: 49
Credit: 13,306
RAC: 0
Message 4950 - Posted: 9 Mar 2007, 16:41:18 UTC

These posts about the status system imply (to me) that work is flowing. Is it? All I get for the past day or two is \"no work from project\"

(and this is on a 2GB machine, though that should be irrelevant as no memory-hungry jobs show in the queue atm)
ID: 4950 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Michael

Send message
Joined: 3 Mar 07
Posts: 1
Credit: 1,719
RAC: 0
Message 4951 - Posted: 9 Mar 2007, 18:03:14 UTC - in response to Message 4950.  
Last modified: 9 Mar 2007, 18:07:47 UTC

These posts about the status system imply (to me) that work is flowing. Is it? All I get for the past day or two is \"no work from project\"

(and this is on a 2GB machine, though that should be irrelevant as no memory-hungry jobs show in the queue atm)

2GB here also and no jobs for almost same amount of time.


3/9/2007 10:54:19 AM|BURP|Sending scheduler request: To fetch work
3/9/2007 10:54:19 AM|BURP|Requesting 17280 seconds of new work
3/9/2007 10:54:24 AM|BURP|Scheduler RPC succeeded [server version 509]
3/9/2007 10:54:24 AM|BURP|Deferring communication for 2 min 25 sec
3/9/2007 10:54:24 AM|BURP|Reason: no work from project
3/9/2007 10:56:55 AM|BURP|Sending scheduler request: To fetch work
3/9/2007 10:56:55 AM|BURP|Requesting 17280 seconds of new work
3/9/2007 10:57:00 AM|BURP|Scheduler RPC succeeded [server version 509]
3/9/2007 10:57:00 AM|BURP|Deferring communication for 27 min 8 sec
3/9/2007 10:57:00 AM|BURP|Reason: no work from project
3/9/2007 11:24:13 AM|BURP|Sending scheduler request: To fetch work
3/9/2007 11:24:13 AM|BURP|Requesting 17280 seconds of new work
3/9/2007 11:24:18 AM|BURP|Scheduler RPC succeeded [server version 509]
3/9/2007 11:24:18 AM|BURP|Deferring communication for 1 hr 52 min 8 sec
3/9/2007 11:24:18 AM|BURP|Reason: no work from project
ID: 4951 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Professor Desty Nova
Avatar

Send message
Joined: 21 Mar 05
Posts: 97
Credit: 294,357
RAC: 3
Message 4952 - Posted: 9 Mar 2007, 19:35:08 UTC

From the Front Page:

Mar 07, 2007
This weekend (starting saturday the 10th, 08:00 UTC) there will be 24 hours of downtime to correct an issue where big sessions requiring large amounts of memory can block smaller sessions from getting started. To flush the render queue no more sessions will be accepted for rendering until after the downtime.



Professor Desty Nova
Researching Karma the Hard way
ID: 4952 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote

Message boards : Number crunching : Status rendering speed N/A