Running 16 at a time they seem to be in the range of 33,000 to 37,000 seconds. Runningonly 8 at a time at the moment to sse how much difference it makes.
What memory config are you running - 2x16GB or 4x8GB?
There is a difference between an unrecognised tag and a true syntax error. I suspect that something checks and complains about the syntax but perhaps remains silent about the name of a tag because that is not its job. Something else probably reads and responds to tags it understands and simply ignores the ones that it doesn't. That's just my guess.
Yes Gary, that's exactly what's going on. It simply doesn't recognize it.
What memory config are you running - 2x16GB or 4x8GB?
2 x 16Gb @ 2400Mhz seeing as the Ryzen has a dual channel memory controller at 2400Mhz (even though most motherboards allow for faster memory speeds than the CPU officially supports).
First batch of running 8 at a time are in. They're almost all 20,000 seconds so it makes quite a difference compared to running 16 at a time.
Will these LoFreq tasks become available for all computers at some point while this Tuning run is advancing? There's occasional difficulties of getting HiFreq tasks. Looks like the balance on "tasks to send" has shifted quite a bit towards LoFreq tasks.
edit: I overreacted. Looks like server is generating and delivering HiFreq tasks if I manage to wait just a couple of minutes.
The availability trouble I'm having in the last couple of hours is for Hi work. The Einstein server status page has been listing 0 or 1 Hi tasks to send with the work generator status shown as disabled, and my host has been getting:
"Einstein@Home 5/30/2017 7:57:15 AM No work is available for Continuous Gravitational Wave search Galactic Center Tuning lowFreq"
in the event log, and the scheduler log has consistently has shown something like:
"2017-05-30 13:57:17.0076 [PID=12554] [debug] [HOST#10706295] MSG(high) No work sent
2017-05-30 13:57:17.0076 [PID=12554] [debug] [HOST#10706295] MSG(high) No work is available for Continuous Gravitational Wave search Galactic Center Tuning lowFreq"
I see some inconsistency in Hi/Lo distribution. For example my laptop with i7 Q 840 1,87GHz (8M-L3, 2Ch-DDR3) is getting Hi task while my blades with 2x Xeon L5520 2,27GHz (8M-L3, 3Ch-DDR3) aren't.
I see some inconsistency in Hi/Lo distribution. For example my laptop with i7 Q 840 1,87GHz (8M-L3, 2Ch-DDR3) is getting Hi task while my blades with 2x Xeon L5520 2,27GHz (8M-L3, 3Ch-DDR3) aren't.
That is not inconsistent as we distinguish based on CPU model not on reported cache size. The CPU models are chosen by previous runtime analysis and according to the runtimes I see from your Xeon L5520 (8.3h) the low frequency app is justified. A high frequency task would take twice the time on this CPU.
That is not inconsistent as we distinguish based on CPU model not on reported cache size. The CPU models are chosen by previous runtime analysis and according to the runtimes I see from your Xeon L5520 (8.3h) the low frequency app is justified. A high frequency task would take twice the time on this CPU.
From my point it is, cause weaker i7 Q 840 (the same architecture but with lower frequency 1,87 vs 2,27 and less memory channels 2 vs 3) is getting high frequency tasks.
You are assuming that higher CPU frequency equals shorter runtimes which must not be the case for the continuous wave application. You'll see this once the i7 has finished a task.
The different applications O1Spot1Lo and O1Spot1Hi refer to the search frequencies of the scientific search which is conducted from 20 to 500Hz in O1Spot1Lo and from 500 to 1500 Hz O1Spot1Hi. It has nothing to do with the CPU frequency of your computer.
I'm constantly monitoring the average runtimes of all CPU models and I will adjust the server config if needed. So far the runtimes for each model are within the expected ranges for each application.
You are assuming that higher CPU frequency equals shorter runtimes which must not be the case for the continuous wave application. You'll see this once the i7 has finished a task.
No. I'm assuming that in this case when we have i7 Q840 code name Clarksfield which is mobile version of Nehalem microarchitecture and have 1,87GHz clock speed and a 2 channel memory controller is slower than L5520 code name Gainestown which is Nehalem-EP and have 2,27GHz and 3 channel memory controller. I also see that Q840 have a little higher frontend and backend stalled cycle rate than L5520 and a little lower avg IPC ~1,4 for Q840 vs ~1,5 for L5520. So Q840 is able to retire about 2,6 Gops/s per core when for L5520 it is about 3,4 Gops/s per core. Given they have the same microarchitecture, difference in achieved IPC probably comes from 2 vs 3 memory channels.
Christian Beer wrote:
The different applications O1Spot1Lo and O1Spot1Hi refer to the search frequencies of the scientific search which is conducted from 20 to 500Hz in O1Spot1Lo and from 500 to 1500 Hz O1Spot1Hi. It has nothing to do with the CPU frequency of your computer.
I think this is obvious for everyone here.
So it is no clear to me why slower host is getting more computationally demanding Hi frequency tasks while faster one is getting only less demanding Lo frequency ones.
MarkJRunning 16 at a time
)
What memory config are you running - 2x16GB or 4x8GB?
There is a difference between
)
There is a difference between an unrecognised tag and a true syntax error. I suspect that something checks and complains about the syntax but perhaps remains silent about the name of a tag because that is not its job. Something else probably reads and responds to tags it understands and simply ignores the ones that it doesn't. That's just my guess.
Yes Gary, that's exactly what's going on. It simply doesn't recognize it.
AgentB wrote:What memory
)
2 x 16Gb @ 2400Mhz seeing as the Ryzen has a dual channel memory controller at 2400Mhz (even though most motherboards allow for faster memory speeds than the CPU officially supports).
First batch of running 8 at a time are in. They're almost all 20,000 seconds so it makes quite a difference compared to running 16 at a time.
BOINC blog
Will these LoFreq tasks
)
Will these LoFreq tasks become available for all computers at some point while this Tuning run is advancing? There's occasional difficulties of getting HiFreq tasks. Looks like the balance on "tasks to send" has shifted quite a bit towards LoFreq tasks.
edit: I overreacted. Looks like server is generating and delivering HiFreq tasks if I manage to wait just a couple of minutes.
The availability trouble I'm
)
The availability trouble I'm having in the last couple of hours is for Hi work. The Einstein server status page has been listing 0 or 1 Hi tasks to send with the work generator status shown as disabled, and my host has been getting:
"Einstein@Home 5/30/2017 7:57:15 AM No work is available for Continuous Gravitational Wave search Galactic Center Tuning lowFreq"
in the event log, and the scheduler log has consistently has shown something like:
"2017-05-30 13:57:17.0076 [PID=12554] [debug] [HOST#10706295] MSG(high) No work sent
I see some inconsistency in
)
I see some inconsistency in Hi/Lo distribution. For example my laptop with i7 Q 840 1,87GHz (8M-L3, 2Ch-DDR3) is getting Hi task while my blades with 2x Xeon L5520 2,27GHz (8M-L3, 3Ch-DDR3) aren't.
Sebastian M. Bobrecki wrote:I
)
That is not inconsistent as we distinguish based on CPU model not on reported cache size. The CPU models are chosen by previous runtime analysis and according to the runtimes I see from your Xeon L5520 (8.3h) the low frequency app is justified. A high frequency task would take twice the time on this CPU.
Christian Beer wrote:That is
)
From my point it is, cause weaker i7 Q 840 (the same architecture but with lower frequency 1,87 vs 2,27 and less memory channels 2 vs 3) is getting high frequency tasks.
You are assuming that higher
)
You are assuming that higher CPU frequency equals shorter runtimes which must not be the case for the continuous wave application. You'll see this once the i7 has finished a task.
The different applications O1Spot1Lo and O1Spot1Hi refer to the search frequencies of the scientific search which is conducted from 20 to 500Hz in O1Spot1Lo and from 500 to 1500 Hz O1Spot1Hi. It has nothing to do with the CPU frequency of your computer.
I'm constantly monitoring the average runtimes of all CPU models and I will adjust the server config if needed. So far the runtimes for each model are within the expected ranges for each application.
Christian Beer wrote:You are
)
No. I'm assuming that in this case when we have i7 Q840 code name Clarksfield which is mobile version of Nehalem microarchitecture and have 1,87GHz clock speed and a 2 channel memory controller is slower than L5520 code name Gainestown which is Nehalem-EP and have 2,27GHz and 3 channel memory controller. I also see that Q840 have a little higher frontend and backend stalled cycle rate than L5520 and a little lower avg IPC ~1,4 for Q840 vs ~1,5 for L5520. So Q840 is able to retire about 2,6 Gops/s per core when for L5520 it is about 3,4 Gops/s per core. Given they have the same microarchitecture, difference in achieved IPC probably comes from 2 vs 3 memory channels.
I think this is obvious for everyone here.
So it is no clear to me why slower host is getting more computationally demanding Hi frequency tasks while faster one is getting only less demanding Lo frequency ones.