The Sieve application IS a 64b one, and yet the X2 6000 (K8) almost goes core for core with the Q6600. Again, not a very big disparity compared with that I witness at Einstein. Will look at Docking next.
I'm not sure how to do docking. So far I only have 16 wus completed on teh Q6600 and so only collected the most recent 16 from the others. The wus runtime varies greatly I see variations as shown on the hosts:
I'll recalculate this tommorrow or so, when I have a larger base. For Example, the times for the 9600 include these 16:
4410, 3814, 4585, 4549, 4284, 4905, 4260, 4404, 3317, 1502, 3544, 4661, 4342, 3166, 4042, and 4199.
does anyone know how much memory an Einstein WU takes?
Good news, the installation of 32b libs has allowed Einstein to run on the 9950's. Currently at 03:10:00 and 33% comp.
Well, my first task on my 3700+ took 40,833.34 seconds (11.34 hours). As was pointed out, I have no idea if that is a runtime maxima, minima, or somewhere in between... I'm under the assumption that Bikeman doesn't overclock. If that is true, then I have a 25% clock advantage over a single core from a 175 (nominal for a 175 and a San Diego 3700+ is 2200MHz, mine runs at 2750MHz).
Plan: Run a few more to try to see where the cyclic variance is currently at in the current frequency template. Later, try changing "AuthenticAMD" in the binary to be "AuthenticABC" (the "Naughty Intel" test).
I'm under the assumption that Bikeman doesn't overclock. If that is true, then I have a 25% clock advantage over a single core from a 175 (nominal for a 175 and a San Diego 3700+ is 2200MHz, mine runs at 2750MHz).
Correct, I never overclock. But sometimes I try out things software-wise, so my hosts might not be perfect comparison targets. But anyway, I don't own a 175, my best AMD box is an X2 4580e @ 2.5 GHz. Currently none of my hosts is crunching under Windows.
Quote:
Plan: Run a few more to try to see where the cyclic variance is currently at in the current frequency template. Later, try changing "AuthenticAMD" in the binary to be "AuthenticABC" (the "Naughty Intel" test).
Ok, anybody who would like to do the same: note that you have to prepare an app_info.xml file first, to prevent BOINC from applying the MD5 checksum check on the executable (a modified version would fail the test, probably causing an automatic re-download of the app files).
Upps...after re-checking....I do indeed have a 175 among my hosts :-), I'm sorry. Actually it is a rented machine at a hoster , and it is really a virtual server where I get about half a core. This one was completely off my radar, so please forgive my ignorance. Because E@H is run in a VM, I would not use that box as a benchmark either, tho.
Well, my first task on my 3700+ took 40,833.34 seconds (11.34 hours). As was pointed out, I have no idea if that is a runtime maxima, minima, or somewhere in between...
In between. The frequency was 847.70, and sequence number 596.
According to the cycle length estimating function I posted a while back, the expected cycle period for 847.70 is 210.4, so sequence number 596 is about 83% of the way through the third cycle.
As your next three results are sequentially lower in the same frequency, I'd expect them to drop in time requirement at a nearly linear rate. (I think you are far enough away from the minimum not to have much of a wiggle problem)
However, your other results in queue on that host are from two other frequencies, and while I have pretty good handle on the cycle length, there is definitely a dependence on frequency for which I don't even have the beginnings of a model.
So, for your goal, I suggest running just one more result before switching to the patched executable, which will mean you have two remaining on which to test it.
There's also the reference unit posted by Bernd a while ago and the Windows batch file using this (see later in the same thread). This eliminates the need to care about cycle periods etc. The ref unit was designed for S5R3, but should be pretty representative for S5R4 as well.
Good luck with that. I tried that about a year ago with very poor results. I was using a VMware workstation (6.0.2, I think) with an Ubuntu 7.04 and 7.10 guest. Performance was in the tank due to overhead from the VM.
I'd be interested though if you have better luck...since this disparity has been around for almost 2 years now...
If you just want to give Linux a try, you'd be better off just booting from a live Linux CD, and installing BOINC to its virtual drive. That way, you won't have the overhead of a VM.
(Sorry Brian, that I didn't think to mention this before.)
So, for your goal, I suggest running just one more result before switching to the patched executable, which will mean you have two remaining on which to test it.
I doubt if I'm going to have the time to tinker in the next 4 days, which is the amount of CPU time needed (approx), so I'll probably do that on another round. As I think I remember reading, the fact that we don't get as many of the same template at the same time makes it more difficult to do this kind of testing, particularly on my (now) slow system. Note: That was not a dig at the app, but just the fact that yes, I realize the technology has passed me by...
OK found a break(made one as
)
OK found a break(made one as I'm a supervisor...hehehehehe), Found the average cpu time for Primegrid PSP Sieve wus.
Intel Q6600, 817 seconds
AMD 9950one, 890
AMD 9600, 1014
AMDX2 6000, 827
The Sieve application IS a 64b one, and yet the X2 6000 (K8) almost goes core for core with the Q6600. Again, not a very big disparity compared with that I witness at Einstein. Will look at Docking next.
I'm not sure how to do docking. So far I only have 16 wus completed on teh Q6600 and so only collected the most recent 16 from the others. The wus runtime varies greatly I see variations as shown on the hosts:
Intel Q6600 1631 - 3378 seconds
AMD 9950one 2877 -4584
AMD 9600 1502 - 4905
AMD 6000 2986 - 4286
perhaps I should wait until I have a much larger sample? Perhaps the different types of wus take different amounts of time to process?
If I left it to the 16 samples the averages would be:
Intel Q6600, 2965 seconds
AMD 9950, 3985
AMD 9600, 3999
AMD 6000, 3621
I'll recalculate this tommorrow or so, when I have a larger base. For Example, the times for the 9600 include these 16:
4410, 3814, 4585, 4549, 4284, 4905, 4260, 4404, 3317, 1502, 3544, 4661, 4342, 3166, 4042, and 4199.
does anyone know how much
)
does anyone know how much memory an Einstein WU takes?
Good news, the installation of 32b libs has allowed Einstein to run on the 9950's. Currently at 03:10:00 and 33% comp.
RE: does anyone know how
)
On my system the Windows SSE app (the "_1" app) is currently fluctuating between 64 and 70MB...
RE: does anyone know how
)
Well, my first task on my 3700+ took 40,833.34 seconds (11.34 hours). As was pointed out, I have no idea if that is a runtime maxima, minima, or somewhere in between... I'm under the assumption that Bikeman doesn't overclock. If that is true, then I have a 25% clock advantage over a single core from a 175 (nominal for a 175 and a San Diego 3700+ is 2200MHz, mine runs at 2750MHz).
Plan: Run a few more to try to see where the cyclic variance is currently at in the current frequency template. Later, try changing "AuthenticAMD" in the binary to be "AuthenticABC" (the "Naughty Intel" test).
RE: I'm under the
)
Correct, I never overclock. But sometimes I try out things software-wise, so my hosts might not be perfect comparison targets. But anyway, I don't own a 175, my best AMD box is an X2 4580e @ 2.5 GHz. Currently none of my hosts is crunching under Windows.
Ok, anybody who would like to do the same: note that you have to prepare an app_info.xml file first, to prevent BOINC from applying the MD5 checksum check on the executable (a modified version would fail the test, probably causing an automatic re-download of the app files).
CU
Bikeman
RE: But anyway, I don't
)
Upps...after re-checking....I do indeed have a 175 among my hosts :-), I'm sorry. Actually it is a rented machine at a hoster , and it is really a virtual server where I get about half a core. This one was completely off my radar, so please forgive my ignorance. Because E@H is run in a VM, I would not use that box as a benchmark either, tho.
CU
Bikeman
RE: Well, my first task on
)
In between. The frequency was 847.70, and sequence number 596.
According to the cycle length estimating function I posted a while back, the expected cycle period for 847.70 is 210.4, so sequence number 596 is about 83% of the way through the third cycle.
As your next three results are sequentially lower in the same frequency, I'd expect them to drop in time requirement at a nearly linear rate. (I think you are far enough away from the minimum not to have much of a wiggle problem)
However, your other results in queue on that host are from two other frequencies, and while I have pretty good handle on the cycle length, there is definitely a dependence on frequency for which I don't even have the beginnings of a model.
So, for your goal, I suggest running just one more result before switching to the patched executable, which will mean you have two remaining on which to test it.
There's also the reference
)
There's also the reference unit posted by Bernd a while ago and the Windows batch file using this (see later in the same thread). This eliminates the need to care about cycle periods etc. The ref unit was designed for S5R3, but should be pretty representative for S5R4 as well.
CU
Bikeman
RE: RE: Maybe I'll try a
)
If you just want to give Linux a try, you'd be better off just booting from a live Linux CD, and installing BOINC to its virtual drive. That way, you won't have the overhead of a VM.
(Sorry Brian, that I didn't think to mention this before.)
RE: So, for your goal, I
)
I doubt if I'm going to have the time to tinker in the next 4 days, which is the amount of CPU time needed (approx), so I'll probably do that on another round. As I think I remember reading, the fact that we don't get as many of the same template at the same time makes it more difficult to do this kind of testing, particularly on my (now) slow system. Note: That was not a dig at the app, but just the fact that yes, I realize the technology has passed me by...