The server says there is work, but I am getting the following message. And I was getting work units until the new app version appeared.
2/15/2016 1:55:22 PM | Einstein@Home | No work sent
2/15/2016 1:55:22 PM | Einstein@Home | No work is available for Gravitational Wave search O1 all-sky tuning
2/15/2016 1:55:22 PM | Einstein@Home | see scheduler log messages on
"Why some hosts take 6h and some 24h we don't know yet."
This may be a sign of that the memory size accessed randomly by an computational iteration (loop, subroutine, etc.) exceeds one level of the cache hierarchy on some machines, but not on other ones.
For example (since these units very rare), some or a couple of O1 units may fit in a large (8 MB or greater) L3 cache but CPUs with no L3 keeps under heavy pressure the RAM, showing a definite multiplier for run time for same computation capacity.
One of my machines is an APU (2x2 MB L2, no L3) running constantly BRP6 on iGPU with two threads; its GPU shares memory bandwidth with the CPU computation. At the last GW search turn I used to run 2 CPU threads with it, resulting 38K seconds BRP6 computation time. With current gamma-ray search (seems memory-intensive) the BRP6 run time is 15-20% longer. With running 2 O1 units it was expected to double the BRP6 run time - to 70-80K seconds - with 34 hour run time for O1s (stopped at 4% after 5K seconds).
The server says there is work, but I am getting the following message. And I was getting work units until the new app version appeared.
2/15/2016 1:55:22 PM | Einstein@Home | No work sent
2/15/2016 1:55:22 PM | Einstein@Home | No work is available for Gravitational Wave search O1 all-sky tuning
2/15/2016 1:55:22 PM | Einstein@Home | see scheduler log messages on
I don't think this has anything to do with your settings. The Client reports both platforms, so it's up to the server to decide which work to send. For some past applications the 32Bit version was slightly faster than the 64Bit version, I guess the server configuration was just kept from there. I'll look into that tomorrow.
The i3-550 has picked up some 64bit as well, but time difference between the 32bit and 64bit is not so pronounced (not AVX). I'll go gpu free for a day to get a measure on timing.
I just allowed a Haswell based machine to join the test. It runs Linux x86_64 and I notice there are two apps listed on the app page - 1.03 (X64) and 1.03 (AVX).
Since AVX has been in Intel processors since Sandy Bridge (I believe - could be wrong) shouldn't the machine have been assigned the 1.03 (AVX) app? The downloaded app was labeled x86_64-pc-linux-gnu__X64. I presume there is another version labeled __AVX?
EDIT: Maybe no Linux hosts are getting AVX. These are GW tasks on a machine rather more powerful than mine and the app listed there is X64 and not AVX.
An AVX task crashed on my AMD A10-6700 running Windows 10 while two X64 are running on my Opteron 1210, dated 2007 and running SuSE Linux Leap 42.1.
Tullio
Yup. On two machines I've had runtimes from 39K through 95K for v1.03. Quicker on the Linux box. But going well though, just awaiting quorum. These hosts do nothing except BOINC and wait for me to turn up after work ....
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
The server says there is
)
The server says there is work, but I am getting the following message. And I was getting work units until the new app version appeared.
2/15/2016 1:55:22 PM | Einstein@Home | see scheduler log messages on
https://einsteinathome.org/host_sched_logs/11674/11674479
"Why some hosts take 6h and
)
"Why some hosts take 6h and some 24h we don't know yet."
This may be a sign of that the memory size accessed randomly by an computational iteration (loop, subroutine, etc.) exceeds one level of the cache hierarchy on some machines, but not on other ones.
For example (since these units very rare), some or a couple of O1 units may fit in a large (8 MB or greater) L3 cache but CPUs with no L3 keeps under heavy pressure the RAM, showing a definite multiplier for run time for same computation capacity.
One of my machines is an APU (2x2 MB L2, no L3) running constantly BRP6 on iGPU with two threads; its GPU shares memory bandwidth with the CPU computation. At the last GW search turn I used to run 2 CPU threads with it, resulting 38K seconds BRP6 computation time. With current gamma-ray search (seems memory-intensive) the BRP6 run time is 15-20% longer. With running 2 O1 units it was expected to double the BRP6 run time - to 70-80K seconds - with 34 hour run time for O1s (stopped at 4% after 5K seconds).
RE: The server says there
)
Just got some! :)
OK some observations based on
)
OK some observations based on validated tasks this host
Fastest task ~21K seconds this task is the 64 bit app
Slowest ~31K seconds this task is the 32 bit app
Edit: corrected some timings on slowest task
I don't know why i am getting 32 bit app, i will look again at the E@H settings.
I don't think this has
)
I don't think this has anything to do with your settings. The Client reports both platforms, so it's up to the server to decide which work to send. For some past applications the 32Bit version was slightly faster than the 64Bit version, I guess the server configuration was just kept from there. I'll look into that tomorrow.
BM
BM
This should be fixed now, if
)
This should be fixed now, if you can run the 64Bit version, you should get it.
BM
BM
This is working fine now,
)
This is working fine now, thanks Bernd.
The i3-550 has picked up some 64bit as well, but time difference between the 32bit and 64bit is not so pronounced (not AVX). I'll go gpu free for a day to get a measure on timing.
I just allowed a Haswell
)
I just allowed a Haswell based machine to join the test. It runs Linux x86_64 and I notice there are two apps listed on the app page - 1.03 (X64) and 1.03 (AVX).
Since AVX has been in Intel processors since Sandy Bridge (I believe - could be wrong) shouldn't the machine have been assigned the 1.03 (AVX) app? The downloaded app was labeled x86_64-pc-linux-gnu__X64. I presume there is another version labeled __AVX?
EDIT: Maybe no Linux hosts are getting AVX. These are GW tasks on a machine rather more powerful than mine and the app listed there is X64 and not AVX.
Cheers,
Gary.
An AVX task crashed on my AMD
)
An AVX task crashed on my AMD A10-6700 running Windows 10 while two X64 are running on my Opteron 1210, dated 2007 and running SuSE Linux Leap 42.1.
Tullio
Yup. On two machines I've had
)
Yup. On two machines I've had runtimes from 39K through 95K for v1.03. Quicker on the Linux box. But going well though, just awaiting quorum. These hosts do nothing except BOINC and wait for me to turn up after work ....
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