Request from the DAB, 6903/04 TPFs

Kendrak

[H]ard|DCer of the Year 2009
Joined
Aug 29, 2001
Messages
21,141
I need to get some info on TPF on these large WU. In an effort to make the deadlines come inline with the expectations of a speedy return of these WU we need TPF.

I will be adding my own data to this thread soon (tomorrow)

Special request: a single 12 core AMD chip.




Project: ____
Average time/frame: ________ {in hh:mm:ss}
CPU: _______ @ ____ GHz
# of CPU sockets:
# of Physical cores:

# of FAH CPU processes:
# of FAH GPU Clients:

RAM GB installed:
RAM Type: {DDR/DDR2/DDR3}
RAM Speed:

OS name/kernel version
Client:
Running in VM: {Yes/No}
 
Last edited:
Project: 6904
Average time/frame: 01:02:21
CPU: X5570 @ 3.2 ghz
# of CPU sockets: 2
# of Physical cores: 8 cores/16 threads

# of FAH CPU processes: 1
# of FAH GPU Clients: 0

RAM GB installed: 6
RAM Type: DDR3
RAM Speed: 1333mhz CAS 8

OS name/kernel version: Linux 2.6.39.2
Client: 6.34
Running in VM: No
 
Last edited:
Project: 6904
Average time/frame: 00:57:45 {in hh:mm:ss}
CPU: 980X @ 4.4 GHz
# of CPU sockets: 6
# of Physical cores: 12

# of FAH CPU processes: 1
# of FAH GPU Clients: 0

RAM GB installed: 6
RAM Type: DDR3 2000
RAM Speed: 2005Mhz 8-8-8-24-1T

OS name/kernel version Ubuntu 10.10 2.6.35.30 generick-ck
Client: v7
Running in VM: {No}

Project: 6904
Average time/frame: 00:58:25 {in hh:mm:ss}
CPU: 980X @ 4.37 GHz
# of CPU sockets: 6
# of Physical cores: 12

# of FAH CPU processes: 1
# of FAH GPU Clients: 0

RAM GB installed: 6
RAM Type: DDR3 2000
RAM Speed: 2005Mhz 8-8-8-24-1T

OS name/kernel version Ubuntu 10.10 2.6.35.30 generick-ck
Client: v7
Running in VM: {No}

Project: 6904
Average time/frame: 00:59:12 {in hh:mm:ss}
CPU: 970 @ 4.2 GHz
# of CPU sockets: 6
# of Physical cores: 12

# of FAH CPU processes: 1
# of FAH GPU Clients: 0

RAM GB installed: 6
RAM Type: DDR3 1800
RAM Speed: 1954Mhz 8-8-8-27-1T

OS name/kernel version Ubuntu 10.10 2.6.35.30 generick-ck
Client: v7
Running in VM: {No}

Project: 6904
Average time/frame: 01:02:30 {in hh:mm:ss}
CPU: 970 @ 4.05 GHz
# of CPU sockets: 6
# of Physical cores: 12

# of FAH CPU processes: 1
# of FAH GPU Clients: 0

RAM GB installed: 6
RAM Type: DDR3 1600
RAM Speed: 1920Mhz 9-9-9-27-1T

OS name/kernel version Ubuntu 10.10 2.6.35.30 generick-ck
Client: v7
Running in VM: {No}

Project: 6903
Average time/frame: 00:39:45 {in hh:mm:ss}
CPU: 980X @ 4.4 GHz
# of CPU sockets: 6
# of Physical cores: 12

# of FAH CPU processes: 1
# of FAH GPU Clients: 0

RAM GB installed: 6
RAM Type: DDR3 2000
RAM Speed: 2005Mhz 8-8-8-24-1T

OS name/kernel version Ubuntu 10.10 2.6.35.30 generick-ck
Client: v7
Running in VM: {No}

Project: 6903
Average time/frame: 00:40:13 {in hh:mm:ss}
CPU: 980X @ 4.37 GHz
# of CPU sockets: 6
# of Physical cores: 12

# of FAH CPU processes: 1
# of FAH GPU Clients: 0

RAM GB installed: 6
RAM Type: DDR3 2000
RAM Speed: 2005Mhz 8-8-8-24-1T

OS name/kernel version Ubuntu 10.10 2.6.35.30 generick-ck
Client: v7
Running in VM: {No}

Project: 6903
Average time/frame: 00:42:57 {in hh:mm:ss}
CPU: 970 @ 4.2 GHz
# of CPU sockets: 6
# of Physical cores: 12

# of FAH CPU processes: 1
# of FAH GPU Clients: 0

RAM GB installed: 6
RAM Type: DDR3 1800
RAM Speed: 1954Mhz 8-8-8-27-1T

OS name/kernel version Ubuntu 10.10 2.6.35.30 generick-ck
Client: v7
Running in VM: {No}

Project: 6903
Average time/frame: 00:43:13 {in hh:mm:ss}
CPU: 970 @ 4.05 GHz
# of CPU sockets: 6
# of Physical cores: 12

# of FAH CPU processes: 1
# of FAH GPU Clients: 0

RAM GB installed: 6
RAM Type: DDR3 1600
RAM Speed: 1920Mhz 9-9-9-27-1T

OS name/kernel version Ubuntu 10.10 2.6.35.30 generick-ck
Client: v7
Running in VM: {No}
 
Last edited:
Project: 6903
Average time/frame: 00:21:15
CPU: Magny Cours 6134 @ 2.3 GHz
# of CPU sockets: 4
# of Physical cores: 32

# of FAH CPU processes: 1
# of FAH GPU Clients: 0

RAM GB installed: 16
RAM Type: DDR3 1333
RAM Speed: 1333Mhz CAS 9

OS name/kernel version Ubuntu 10.04/2.6.32
Client: 6.34
Running in VM: {No}

==============================================

Project: 6904
Average time/frame: 00:29:17
CPU: Magny Cours 6134 @ 2.3 GHz
# of CPU sockets: 4
# of Physical cores: 32

# of FAH CPU processes: 1
# of FAH GPU Clients: 0

RAM GB installed: 16
RAM Type: DDR3 1333
RAM Speed: 1333Mhz CAS 9

OS name/kernel version Ubuntu 10.04/2.6.32
Client: 6.34
Running in VM: {No}

=============================================

Project: 6903
Average time/frame: 00:17:40
CPU: Magny Cours 6166HE @ 1.8 GHz
# of CPU sockets: 4
# of Physical cores: 48

# of FAH CPU processes: 1
# of FAH GPU Clients: 0

RAM GB installed: 16
RAM Type: DDR3 1333
RAM Speed: 1333Mhz CAS 9

OS name/kernel version Ubuntu 10.10/2.6.35 or Arch/2.6.36
Client: 6.34
Running in VM: {No}

============================================

Project: 6904
Average time/frame: 00:24:16
CPU: Magny Cours 6166HE @ 1.8 GHz
# of CPU sockets: 4
# of Physical cores: 48

# of FAH CPU processes: 1
# of FAH GPU Clients: 0

RAM GB installed: 16
RAM Type: DDR3 1333
RAM Speed: 1333Mhz CAS 9

OS name/kernel version Ubuntu 10.10/2.6.35 or Arch/2.6.36
Client: 6.34
Running in VM: {No}
 
Project: 6903
Average time/frame: 42:42 {in hh:mm:ss}
CPU:980x @ 4.4 GHz
# of CPU sockets:1
# of Physical cores: 6 (12 threads w/ HT on)

# of FAH CPU processes:1
# of FAH GPU Clients: 0

RAM GB installed:6
RAM Type: {DDR/DDR2/DDR3} DDR3
RAM Speed:1750

OS name/kernel version: Linuxforge image
Client: Linux 6.34
Running in VM: {Yes/No} Yes VirtualBox, Host is Win 7 64-bit
 
Project: 6904
Average time/frame: 00:17:40
CPU: Magny Cours ES @ 2.6 GHz
# of CPU sockets: 4
# of Physical cores: 48

# of FAH CPU processes: 1
# of FAH GPU Clients: 0

RAM GB installed: 16
RAM Type: DDR3 1333
RAM Speed: 1333Mhz CAS 9

OS name/kernel version Ubuntu 11.04
Client: 6.34
Running in VM: {No}
 
Last edited:
Project: 6903
Average time/frame: 0:48:41 {in hh:mm:ss}
CPU: i7-2600k @ 4.7 GHz
# of CPU sockets: 1
# of Physical cores: 4cores/8threads

# of FAH CPU processes: 1
# of FAH GPU Clients: 0

RAM GB installed: 8
RAM Type: DDR3
RAM Speed: 2133

OS name/kernel version: Ubuntu 11.04/2.6.32
Client: 6.34
Running in VM: No

__________________

Same setup as above,

Projects: 6903
TPF's : 48:52, 48:48, 48:59, 48:48


Didn't see any quad cores, so I thought I'd post... ;)
 
Project: 6903
Average time/frame: 0:48:41 {in hh:mm:ss}
CPU: i7-2600k @ 4.7 GHz
# of CPU sockets: 1
# of Physical cores: 4cores/8threads

# of FAH CPU processes: 1
# of FAH GPU Clients: 0

RAM GB installed: 8
RAM Type: DDR3
RAM Speed: 2133

OS name/kernel version: Ubuntu 11.04/2.6.32
Client: 6.34
Running in VM: No

__________________

Same setup as above,

Projects: 6903
TPF's : 48:52, 48:48, 48:59, 48:48


Didn't see any quad cores, so I thought I'd post... ;)

How did you even GET a 6903 on quad core? I thought 12 threads minimum to be detected before the assignment server downloads a 6903(4)... 49mins TPFon a single CPU?
Please check your wu..thanks;)
 
And there is the problem with using threads/cores fo WU placement.
 
What do you want, a screenshot from HFM? Ok :D
fejjo4.jpg


How do I get them on a quad core? Check OCN... the answers are inside ;)

If you guys got some 2600k's doing big bigadvs, it would help your cause against EVGA...
 
What do you want, a screenshot from HFM? Ok :D
fejjo4.jpg


How do I get them on a quad core? Check OCN... the answers are inside ;)

If you guys got some 2600k's doing big bigadvs, it would help your cause against EVGA...

You do realise that that is against the EULA and that PG could zero out your entire points total?

OCN should be careful, PG does not take kindly to teams promoting such deviousness.
We prefer to earn our points the [H]ard way
 
You do realise that that is against the EULA and that PG could zero out your entire points total?

OCN should be careful, PG does not take kindly to teams promoting such deviousness.
We prefer to earn our points the [H]ard way

Unless I am mistaken this has already been done for thubans in the past...
The client is not in any way altered... its the OS that has been fooled.

So while not making PG happy I do not see how it breaks the EULA...
I prefer 48core attacks though...
 
Deviousness... lol.

This has been discussed at length. PG has not said it is against the rules. It may be "frowned" upon, but the units are getting done well within the deadlines. Patriot is correct. AMD x6's and Sandy i5's have been using this for regular bigadvs.

You prefer the hard way, eh? Perhaps it's that you want to keep the $$$ systems on the top 20.
 
Same thing was discussed here in this subforum a few months ago, it is NOT against the EULA.....PG has said they prefer 8+ core systems (which would also effectivley rule out the i7's if you read the "suggestion" literally) , they said they are not stopping it, but preference is towards 8 core systems for big adv, not much has been said on the -big beta's , but I assume the response will be pretty much the same.

You do realise that that is against the EULA and that PG could zero out your entire points total?

OCN should be careful, PG does not take kindly to teams promoting such deviousness.
We prefer to earn our points the [H]ard way
 
Doubt it, i have 2 dual hexcore machines and i can't make the top 20

My 24hr average right now is 150k, so I guess I could crack your top 20 with my 2600k's...

At any rate, this was a thread for 6903 numbers. I posted the ones I got for information purposes. I'm not here to discuss the "ethics" :p As if running them on a system that can complete them with lots of time to spare is unethical... or devious...
 
How do I get them on a quad core? Check OCN... the answers are inside ;)

If you guys got some 2600k's doing big bigadvs, it would help your cause against EVGA...
Being the author of referred workaround I find your post somewhat funny :)

Though I regret to see credit was not given where credit was due.

Back to subject --
Project: 6904
Average time/frame: from 00:17:02 to 00:17:50, depending on WU and DLB engagement

CPU: AMD Opteron ES @ 2.5 GHz
# of CPU sockets: 4
# of Physical cores: 48

# of FAH CPU processes: 1
# of FAH GPU Clients:

RAM GB installed: 32
RAM Type: DDR3-1333
RAM Speed: 7-7-7-21, NB @ 2.2 GHz

OS name/kernel version: Fedora 14, custom kernel, Kraken
Client: 6.34
Running in VM: No

Project: 6904
Average time/frame: from 00:17:10 to 00:18:00, depending on WU and DLB engagement

CPU: AMD Opteron 6174 @ 2.474 GHz
# of CPU sockets: 4
# of Physical cores: 48

# of FAH CPU processes: 1
# of FAH GPU Clients:

RAM GB installed: 32
RAM Type: DDR3-1199
RAM Speed: 6-7-5-20, NB @ 2.02 GHz

OS name/kernel version: Fedora 14, custom kernel, Kraken
Client: 6.34
Running in VM: No

Kendrak, I'll try catching either of the machines between WUs and running the unit
on a single processor.

Also, let me see if I can dig P6903 data out (haven't seen them in a while).

What is the purpose of gathering this data? Establishing WU qualification minima?
Deadlines?
 
Does anyone have a single 12 core AMD chip?

R-type does... although any of us with more can just do 12 threads and get you numbers... what speed do you want it at?

Being the author of referred workaround I find your post somewhat funny :)

Though I regret to see credit was not given where credit was due.

Probably more OCN's fault than anything.. if there are more google results linking there and they don't give credit...

Back to subject --

What is the purpose of gathering this data? Establishing WU qualification minima?
Deadlines?

Instead of fixing cpu recognition and allowing only things with the proper core count PG wants to cut deadlines back... the problem faced now is a single hex will be chopped from all bigadv if they want to keep a fast clocked sandy quad out...
 
Instead of fixing cpu recognition and allowing only things with the proper core count PG wants to cut deadlines back... the problem faced now is a single hex will be chopped from all bigadv if they want to keep a fast clocked sandy quad out...
Are you sure?

Don't get me wrong. I'm all for reducing (or eliminating) artificial WU qualification and relying
only on performance (read: if you can make it, I don't care how many cores or threads you
have, how much memory, what your clocks are et al.).

What I'm getting at -- in order for that to work, donors would need to be given ability to
somehow pick and choose (yes) WUs they _believe_ they can get the most out of*,**.

And I don't disagree with that either!

The potential issue I see is that project currently lacks appropriate infrastructure to make
it happen.

*) BOINC, for instance, has capability of letting you pick simulation apps you wish to use
**) otherwise donors may receive WUs they won't be able to complete in due time
 
Are you sure?

Don't get me wrong. I'm all for reducing (or eliminating) artificial WU qualification and relying
only on performance (read: if you can make it, I don't care how many cores or threads you
have, how much memory, what your clocks are et al.).

What I'm getting at -- in order for that to work, donors would need to be given ability to
somehow pick and choose (yes) WUs they _believe_ they can get the most out of*,**.

And I don't disagree with that either!

The potential issue I see is that project currently lacks appropriate infrastructure to make
it happen.

*) BOINC, for instance, has capability of letting you pick simulation apps you wish to use
**) otherwise donors may receive WUs they won't be able to complete in due time

I am 100% performance driven as well lol... I would love to pick and choose projects...and honestly... 6903 and 6904 would not be them... I am here to help find a cure for cancer and a few mental diseases... let those who want to go after influenza ...

But if stanford does that... it becomes many little projects under one hood... oh wait thats what it is :rolleyes:... I doubt they would ever relinquish the power of picking projects to push out...

I am concerned now if they try to keep those who are able out because they don't meet the core count.... that those with the thread count would be given units they couldn't complete...
 
I doubt they would ever relinquish the power of picking projects to push out...
Letting donors pick projects doesn't automatically imply giving up control.

Project would still have the power to manipulate deadlines and rewards (being able to
make certain projects more appealing and others, obviously, less appealing*). Project's
goals would not be impeded.

*) results would not be immediate (think of time it would take donors to react) but control
(though indirect!) would still be in project's "hands"
 
I am concerned now if they try to keep those who are able out because they don't meet the core count.... that those with the thread count would be given units they couldn't complete...

With v7 they do have a way to use processor recognition rather than core count they had it implemented in early beta testing of v7 but disabled it, it is still a little bit buggy. in the future they will probably use it to help determine who gets what WU. Until then they really do not have much choice other than limiting the time out for the bigadv WU's there are some people running the big bigadv on i7 2500 and Phenom II X6 processors using tear's patch and really slowing the project down. And there attitude is that if Stanford did not want them folding them they would shorten the deadline. And they are pretty blatant about it, they do not care about the project just the points. So they are really leaving Stanford no choice.
I really do not care if they shorten it to the point to where I can not complete the 6903 / 6904 if that is what they need to do to speed up the project to where they want it / need it. I could always reverse the patch. ;) but my guess is they are going to provide a flag that will block them.
 
using 2500k's, and Thubans are a bad idea for 690*'s, 2600k on the other hand does the unit quicker than some 6c/12t CPU's out there......

With v7 they do have a way to use processor recognition rather than core count they had it implemented in early beta testing of v7 but disabled it, it is still a little bit buggy. in the future they will probably use it to help determine who gets what WU. Until then they really do not have much choice other than limiting the time out for the bigadv WU's there are some people running the big bigadv on i7 2500 and Phenom II X6 processors using tear's patch and really slowing the project down. And there attitude is that if Stanford did not want them folding them they would shorten the deadline. And they are pretty blatant about it, they do not care about the project just the points. So they are really leaving Stanford no choice.
I really do not care if they shorten it to the point to where I can not complete the 6903 / 6904 if that is what they need to do to speed up the project to where they want it / need it. I could always reverse the patch. ;) but my guess is they are going to provide a flag that will block them.
 
With v7 they do have a way to use processor recognition rather than core count they had it implemented in early beta testing of v7 but disabled it, it is still a little bit buggy. in the future they will probably use it to help determine who gets what WU.
That can be manipulated externally as well.

Grandpa_01 said:
Until then they really do not have much choice other than limiting the time out for the bigadv WU's there are some people running the big bigadv on i7 2500 and Phenom II X6 processors using tear's patch and really slowing the project down.
Even more reason not to qualify machines based on arbitrary specs.

Grandpa_01 said:
And there attitude is that if Stanford did not want them folding them they would shorten the deadline. And they are pretty blatant about it, they do not care about the project just the points.
Sorry Grandpa, as I said on other occasions, points were created to be the incentive
and have become quite a strong incentive. Implying that points aren't supposed to matter
is an act of hypocrisy to me.
The moment project expects donors to be ultimate philanthropists, point-rewards should
be _ditched_. Simple consequence, no?

Grandpa_01 said:
So they are really leaving Stanford no choice.
No need for drama.
I perceive shortening preferred deadlines as _normal_ reaction.

"We'd like project X to move faster. Therefore we'll shorten pref deadline thus
raising desired minimal ,,swarm'' speed to Y days per unit."

Economy will adjust if it's given appropriate capabilities.

"Oh, my rig's production drops significantly with project X now. I won't fold it anymore".

It's that simple, really.
 
That can be manipulated externally as well.

If anybody can do it you can but that is the closest thing they have to a fix now and it may or may not be implemented.



Even more reason not to qualify machines based on arbitrary specs.

They are currently working on a benchmark system that benchmarks the users machine, but from what I understand it will be a while before it is ready.

Sorry Grandpa, as I said on other occasions, points were created to be the incentive
and have become quite a strong incentive. Implying that points aren't supposed to matter
is an act of hypocrisy to me.
The moment project expects donors to be ultimate philanthropists, point-rewards should
be _ditched_. Simple consequence, no?

Here you are talking about a morality issue. There has been guidelines given by Stanford some have chosen to ignore them. That is personal choice, is it right or wrong to say I do not care what you want I will do as I wish. And no I do not want an answer to that. I know it is human nature to go for the carrot.

No need for drama.
I perceive shortening preferred deadlines as _normal_ reaction.

"We'd like project X to move faster. Therefore we'll shorten pref deadline thus
raising desired minimal ,,swarm'' speed to Y days per unit."

Economy will adjust if it's given appropriate capabilities.

"Oh, my rig's production drops significantly with project X now. I won't fold it anymore".

It's that simple, really.

Here I agree I was not being dramatic just stating the obvious if they want to speed up the project they currently have only 1 choice.
 
lets stick to the original post every body, looks like we deviating from that.

we can always open a new post for these discussions :)
 
Grandpa_01 said:
I know it is human nature to go for the carrot.
Yet, knowing that, project decided to provide/offer said carrot. See my point yet?
 
Does anyone have a single 12 core AMD chip?

I have a single 6174 working on a 6904 WU right now. Two frames done and the times are 01:17:04. I will post later tonight after a few more frames have been completed.
 
P6903 data follow.

Project: 6903
Average time/frame: from 00:12:30 to 00:13:10, depending on WU and DLB engagement

CPU: AMD Opteron ES @ 2.5 GHz
# of CPU sockets: 4
# of Physical cores: 48

# of FAH CPU processes: 1
# of FAH GPU Clients:

RAM GB installed: 32
RAM Type: DDR3-1333
RAM Speed: 7-7-7-21, NB @ 2.2 GHz

OS name/kernel version: Fedora 14, custom kernel, Kraken
Client: 6.34
Running in VM: No

Project: 6903
Average time/frame: from 00:12:30 to 00:13:05, depending on WU and DLB engagement

CPU: AMD Opteron 6174 @ 2.474 GHz
# of CPU sockets: 4
# of Physical cores: 48

# of FAH CPU processes: 1
# of FAH GPU Clients:

RAM GB installed: 32
RAM Type: DDR3-1199
RAM Speed: 6-7-5-20, NB @ 2.02 GHz

OS name/kernel version: Fedora 14, custom kernel, Kraken
Client: 6.34
Running in VM: No
 
Project: 6904
Average time/frame: 01:17:17 (based on the first 5%)
CPU: 6174 @ 2.2 GHz
# of CPU sockets: 1
# of Physical cores: 12

# of FAH CPU processes: 1
# of FAH GPU Clients: 0

RAM GB installed: 8
RAM Type: DDR3
RAM Speed: 1333 CAS 8

OS name/kernel version: PXE boot of Linux 2.6.39.2
Client: 6.34
Running in VM: No
 
Being the author of referred workaround I find your post somewhat funny :)

Though I regret to see credit was not given where credit was due.

No disrespect to you was intended; I had no idea that you came up with the workaround. From this day forward, I will refer to it as the "core tear" ;)
 
Project: 6904 (R2,C12,G12)
Average time/frame: 1:11:40
CPU: I7 970_ @ 4.07_GHz
# of CPU sockets: 1
# of Physical cores: 6

# of FAH CPU processes: 12
# of FAH GPU Clients: 0

RAM GB installed: 6
RAM Type: DDR3
RAM Speed: 1600Mhz

OS name/kernel version: Ubuntu 2.6.38
Client: 6.34
Running in VM: No
 
Last edited:
It looks like the 970 @ 4.07 GHz and the single 6174 @ 2.2 are pretty close in tpf.
 
half the cores twice the clock... what were you expecting? :p

Well AMD used to suffer on a mhz by mhz basis (and back with the old P4 this was reversed). It seems that it is no longer the case.
 
Well AMD used to suffer on a mhz by mhz basis (and back with the old P4 this was reversed). It seems that it is no longer the case.

It still does... core i7 is faster clock to clock...4ghz is not double 2.2 ... its closer than it used to be though... that is why desktop hex don't stand a chance against i7 hex.
 
6903 and 6904 frame times below...

If this is ultimately for Stanford, perhaps Stanford should just mine the logs for this? When the work unit results are uploaded, log files are included in that, which has the TPF and various performance statistics. Stanford should be able to see this data across the entire folding population...



-smp 48, 2.7ghz 6-7-5-20-1440. NB 1944 (default @ 1800, but refclock=216).

with dlb engaged + kraken.

6903: 11:43TPF
6904: 16:04TPF




I need to get some info on TPF on these large WU. In an effort to make the deadlines come inline with the expectations of a speedy return of these WU we need TPF.

I will be adding my own data to this thread soon (tomorrow)

Special request: a single 12 core AMD chip.
 
Back
Top