View Single Post
Old 2017-02-28, 14:57   #1202
ramgeis
 
ramgeis's Avatar
 
Apr 2013

11101002 Posts
Default

Quote:
Originally Posted by Madpoo View Post
I have every reason to believe your issue is due to your unique circumstances.

You have 2 cpus with assignments... one of them only has 4 active assignments while the other has 710,618 assignments.

Part of that little table does an average age of all your assignments which it does by using the SQL avg() function for the difference in minutes between date assigned and now, divided by 1440.0 (to show the average diff in days to a precision of x.xx).

Your particular issue is that it's easily overflowing the ability of SQL to average an int over that many rows (int is the default cast for datediff, I'm guessing).

I'm questioning the usefulness of showing the average assignment age for that many (or even at all). It seems of questionable utility...

I could cast the datediff to bigint before inside avg() ... your average TF assignment age (of which there are 710,606 right now) is 36.88 days. Does that help you in any way? LOL
No, I'm not interested in the average assignment age either. LOL... I actually just want to know the number of current assignments for each type.

Your explanation also matches my observations where the error suddenly showed up and didn't go away for some weeks and then again for some days everything was fine before it happened again.

BTW, the 7xxxxx assignments of the second "cpu" are those from manual testing. And the reason why they are so many is mainly because the manual GPU assignment page ignores the requested bit level to factor to and sets it considerably higher (e.g. 74 instead of the requested 70). As I TF them only to 70 (as intended) they are waiting to expire (should happen soon).
ramgeis is offline   Reply With Quote