The "rule of thumb" for OpenIFS, found out the hard way, is: For Intel chips that have hyperthreading, DON'T use hyperthreading.
That will immediately double the amount of time taken to complete a model, so it's a waste of time.

The "rule of thumb" for OpenIFS, found out the hard way, is: For Intel chips that have hyperthreading, DON'T use hyperthreading.

OK, I can confine it to a machine that doesn't have HT (or else run a hyper-threaded machine on 50% of the cores in BOINC Manager).
But again, since we can't select the type of tasks, that will limit us on how many we can run. It will be a bit inefficient to mix OpenIFS with the other types.

It would help if they only make available for download one type or another at a time, and we can then set up accordingly.

The "rule of thumb" for OpenIFS, found out the hard way, is: For Intel chips that have hyperthreading, DON'T use hyperthreading.
That will immediately double the amount of time taken to complete a model, so it's a waste of time.

I do not mean to be a pain but I have to ask if that means a.) "DON'T schedule more threads than you have physical cores," b.) "DON'T have enabled Hyper-Threading in your BIOS," or c.) "DON'T have ANY symmetric multi-threading from ANY vendor enabled in your BIOS."

I do not mean to be a pain but I have to ask if that means a.) "DON'T schedule more threads than you have physical cores," b.) "DON'T have enabled Hyper-Threading in your BIOS," or c.) "DON'T have ANY symmetric multi-threading from ANY vendor enabled in your BIOS."

I would choose a there.

The "rule of thumb" for OpenIFS, found out the hard way, is: For Intel chips that have hyperthreading, DON'T use hyperthreading.

OK, I can confine it to a machine that doesn't have HT (or else run a hyper-threaded machine on 50% of the cores in BOINC Manager).
But again, since we can't select the type of tasks, that will limit us on how many we can run. It will be a bit inefficient to mix OpenIFS with the other types.

It would help if they only make available for download one type or another at a time, and we can then set up accordingly.

I would agree here. I really wish we could choose what projects we'd like to run. Perhaps this can be like WCG with ability to select how many tasks are downloaded from a specific project per machine?
...also this was a Xeon w3530, not that it makes much difference, but at least turbo boost takes it over 3 ghz. Boinc's estimation for hadam4_a1sc_209710_6_853_011942351 is right around 8 days.
I found a few Sandy bridge and ivy bridge i5's in my collection of 'junk' so if OpenIFS don't do well with hyperthreading those can be thrown together relatively easily. I refuse to get rid of hardware that still works well, even if I physically don't have the room to assemble it all.

lazlo_vii

My computers are plain vanilla machines. The 2 that I used for the big June run have Intel processors, with 4 real, and 4 hyperthreaded.
I leave the latter running for the system to use, but BOINC is set to 50%, so only 4 get used, hopefully the real cores.
And I don't run other projects.

With 4 cores, I get 4 tasks, run them, then get 4 more, etc. No stockpiling for later.

With the OpenIFS, I was getting just under 1 hour and 15 minutes per set of 4.
When I tried with 8 at once, it went to 2 hours and just under 30 minutes.
When I mentioned this to the project person, he said that "they" don't use hyperthreaded cores because there was a lot of internal data shuffling.

**********************

The lack of an option to choose which model types to run, was discussed at length with the Oxford people, and the project manager told me that they had ideas for managing the OpenIFS in conjunction with the other types.
Which is where I dropped the matter.

Since then, I've been told that they have an interest in running more of them, but that was "all on the back burner".

Les,

Thank you for being clear. Just so you know, there is no difference between "real" and "hyper" cores. The difference is how the resources of the core get divided up by the jobs being run. Yo can see this for yourself by looking at the output of:

:~$ cat /proc/cpuinfo | egrep 'processor|core id'

The output should make it plain that all the "HyperCores" are really just a second "name tag" for each of the "real" cores. It's like going to a fast food place and seeing a man with two different name tags taking orders and serving drinks at the same time. In reality if there are no drinks to fill he takes orders faster and if there are no orders to take he fills drinks faster and he only has one real name.

Thanks for that. I've always put that into the "latter" basket to work out. If possible.
But I see now that I'm right in not trying to use them.
"One thing at a time." :)