FWIW ( thinking out loud and way out of turn ) : with the addition of GPU and ABP type work, E@H now conceptually behaves like several distinct projects - 'classic' CPU GW, CPU ABP, and CPU/GPU ABP. This has probably leapt well over the assumptions & design of earlier BOINC algorithms which may not readily fudge/adjust to suit now. Does BOINC logic abstract this by using separate workflow/stream types ( CPU, GPU, and GPU/CPU ) ??
There's a matrix here :
[pre] WU Type vs Asset CPUGPU GWYESNO plain ABPYESNO CUDA ABPYESYES ?future?NOYES[/pre]So here a GPU work request for E@H is really a CPU+GPU request, not to be substituted with a CPU only unit.
To make sense and be efficient the algorithm would need to know the ratio of CPU's ( or cores ) to GPU's in a given machine - 8 to 1 in my i7 - and the relative expected timing disparity of the WU types.
So you'd lump a module in b/w the bit that currently requests work from the server and the bit that currently examines the loading of the assets ??
[ ducks and dives for cover, anticipating mortar fire from developers .... ]
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
OK, here's the screenshots, 16/01/2010 9.37am ( local time ) :
16/01/2010 9.39am ( after an update - I can't now remember why I was updating ) :
20/01/2010 3.32pm ( 'high priority' has appeared ) :
20/01/2010 7.04pm ( here I think I re-sorted the list, ascending, as per the 'Report deadline' column. I'd twigged that completion was now an issue ) :
21/01/2010 10.22am ( ditto ascending, as per the 'Report deadline' column from now on ) :
21/01/2010 2.00pm ( BOINC has well and truly twigged it's way stretched on the GW's, the ABP's have later deadlines than most of the GW's. It must have been about now that I selected 'no new work', having seen it pick up some further ABP units. ) :
21/01/2010 9.29pm ( it did just GW's for the next 10 or so days ) :
And just now @ 03/02/2010 6.17pm :
Cheers, Mike.
( edit ) Now I remember : I was initially looking at how the tasking was going with the various ABP types floating around then. Only after a while I realised the over-downloading was happening.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
20/01/2010 7.04pm ( here I think I re-sorted the list, ascending, as per the 'Report deadline' column. I'd twigged that completion was now an issue ) :
Looking at the triangle in the column header, you actually sorted by application - the manager may have preserved 'order of arrival' within blocks of the same application name, but I wouldn't count on it.
I find that it's easiest to see what's going on if you remove all sorting, and just view the raw list as nature intended - except you can't.
So, Regedit at the ready and BOINC Manager closed....
Navigate to HKEY_CURRENT_USER\Software\Space Sciences Laboratory, U.C. Berkeley\BOINC Manager\TasksGrid
Delete values for "SortColumn" and "SortAscending" (or reinstate default values of dword:ffffffff and dword:00000001 respectively).
This was with 6.10.29. It basicly went nuts. Over downloaded again, then starting kicking some WUs into high priority with a later due date over ones with an earlier due date. Very strange.
Anyway, I was thinking (can be dangerous at time), perhaps it should be considered to make the GW & ABP truely seperate projects (seperate URLs) vs seperate applications. Just a thought.
I don't know what went wrong on my system, but upgrading to 6.10.18 thumped it into downloading E@H work again. MY in progress Lieden and Collatz tasks were reset but I don't know if that's indicative of anything beyond not setting checkpoints or not.
I don't know what went wrong on my system, but upgrading to 6.10.18 thumped it into downloading E@H work again. MY in progress Lieden and Collatz tasks were reset but I don't know if that's indicative of anything beyond not setting checkpoints or not.
Hi, I noticed this greedy behavior with BOINC 6.10.29 on SETI and only on rigs using CUDA.
Using 6.10.15 & 18, for a while, also with CUDA or CAL(Brook), but now acts normal in work-fetching. This took a few weeks, though.
Could be CUDA, interfering with the work-fetch algoritm. . . All the projects have a very similar work-fetch-quotum, but non of the projects, behaves according to this.
Mike, we could use you observational and analytic skills on this one. What are your estimated/actual runtimes for each of ABP2/CUDA and GW/CPU, as calculated by BOINC Manager? How much do they change, and in what direction, as a task of each type exits? And how many of each type are currently bloating your 'ready' list? I have a guess as to what's happening, but I'd like to see unbiased observations first.
We also need to make sure that the (currently somewhat bastardised) Einstein server isn't sending more than you request. Could you bear to turn on the [work_fetch_debug] logging flag, and try to make sense of the results?
The i7 has been restarted and is so far behaving as expected, I've got activated - similiarly no surprises, yet. I'll get back if/when any interesting analysis arises ( thank you Gundolf and Richard ).
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
6.10.11 IIRC einstien and
)
6.10.11 IIRC einstien and collatz????) were +-86k on one debt, zero on the other. Currently:
collatz (GPU only) has +55k STD, -14k cuda debt
einstien has 0's across the board
leiden has -55k STD, -108k LTD, -240 cuda debt
And no the cuda debt and LTD don't add up.
FWIW ( thinking out loud and
)
FWIW ( thinking out loud and way out of turn ) : with the addition of GPU and ABP type work, E@H now conceptually behaves like several distinct projects - 'classic' CPU GW, CPU ABP, and CPU/GPU ABP. This has probably leapt well over the assumptions & design of earlier BOINC algorithms which may not readily fudge/adjust to suit now. Does BOINC logic abstract this by using separate workflow/stream types ( CPU, GPU, and GPU/CPU ) ??
There's a matrix here :
[pre] WU Type vs Asset
CPU GPU
GW YES NO
plain ABP YES NO
CUDA ABP YES YES
?future? NO YES[/pre]So here a GPU work request for E@H is really a CPU+GPU request, not to be substituted with a CPU only unit.
To make sense and be efficient the algorithm would need to know the ratio of CPU's ( or cores ) to GPU's in a given machine - 8 to 1 in my i7 - and the relative expected timing disparity of the WU types.
So you'd lump a module in b/w the bit that currently requests work from the server and the bit that currently examines the loading of the assets ??
[ ducks and dives for cover, anticipating mortar fire from developers .... ]
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
OK, here's the screenshots,
)
OK, here's the screenshots, 16/01/2010 9.37am ( local time ) :
16/01/2010 9.39am ( after an update - I can't now remember why I was updating ) :
20/01/2010 3.32pm ( 'high priority' has appeared ) :
20/01/2010 7.04pm ( here I think I re-sorted the list, ascending, as per the 'Report deadline' column. I'd twigged that completion was now an issue ) :
21/01/2010 10.22am ( ditto ascending, as per the 'Report deadline' column from now on ) :
21/01/2010 2.00pm ( BOINC has well and truly twigged it's way stretched on the GW's, the ABP's have later deadlines than most of the GW's. It must have been about now that I selected 'no new work', having seen it pick up some further ABP units. ) :
21/01/2010 9.29pm ( it did just GW's for the next 10 or so days ) :
And just now @ 03/02/2010 6.17pm :
Cheers, Mike.
( edit ) Now I remember : I was initially looking at how the tasking was going with the various ABP types floating around then. Only after a while I realised the over-downloading was happening.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Before I start accepting work
)
Before I start accepting work again : how do I turn on this '[work_fetch_debug] logging flag' ?? :-)
I'll set connect = 0.0 ( 'always on' broadband )
and extra work = 0.25
Cheers, Mike.
( edit ) Darn, the scheduler logs don't go back to before 18/01/2010 .....
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: Before I start
)
Add 1 to the section of your cc_config.xml file.
If you don't have any, create one with this content:[pre]
1
[/pre]Gruß,
Gundolf
PS: The [pre][/pre] tag doesn't insert a newline at other projects.
Computer sind nicht alles im Leben. (Kleiner Scherz)
RE: 20/01/2010 7.04pm (
)
Looking at the triangle in the column header, you actually sorted by application - the manager may have preserved 'order of arrival' within blocks of the same application name, but I wouldn't count on it.
I find that it's easiest to see what's going on if you remove all sorting, and just view the raw list as nature intended - except you can't.
So, Regedit at the ready and BOINC Manager closed....
Navigate to
HKEY_CURRENT_USER\Software\Space Sciences Laboratory, U.C. Berkeley\BOINC Manager\TasksGridDelete values for "SortColumn" and "SortAscending" (or reinstate default values of dword:ffffffff and dword:00000001 respectively).
Same problem occured several
)
Same problem occured several days ago. Link
This was with 6.10.29. It basicly went nuts. Over downloaded again, then starting kicking some WUs into high priority with a later due date over ones with an earlier due date. Very strange.
Anyway, I was thinking (can be dangerous at time), perhaps it should be considered to make the GW & ABP truely seperate projects (seperate URLs) vs seperate applications. Just a thought.
I don't know what went wrong
)
I don't know what went wrong on my system, but upgrading to 6.10.18 thumped it into downloading E@H work again. MY in progress Lieden and Collatz tasks were reset but I don't know if that's indicative of anything beyond not setting checkpoints or not.
RE: I don't know what went
)
Hi, I noticed this greedy behavior with BOINC 6.10.29 on SETI and only on rigs using CUDA.
Using 6.10.15 & 18, for a while, also with CUDA or CAL(Brook), but now acts normal in work-fetching. This took a few weeks, though.
Could be CUDA, interfering with the work-fetch algoritm. . .
All the projects have a very similar work-fetch-quotum, but non of the projects, behaves according to this.
RE: Mike, we could use you
)
The i7 has been restarted and is so far behaving as expected, I've got activated - similiarly no surprises, yet. I'll get back if/when any interesting analysis arises ( thank you Gundolf and Richard ).
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal