Both are running the 3621 driver which seems to suit the Einstein application and validator better, with (on a spot check) validation rates between 93% and 94% (41 invalid out of 635 checked, and 31 invalid from 508, respectively).
I presume the preponderance of Haswell CPUs in your study is mainly because of newer machines being built/supplied with the new drivers by default - which is indeed a worrying trend, and one which is not automatically going to go away of its own accord. But I doubt it can be cured without developer input.
You are right, using the newer drivers on Ivy Bridge GPUs also increases the error rate. I don't know if there's any further difference between Ivy and Haswell, but at least the fact that all my invalids were generated against Haswells raises an attention flag.
You just quickly checked my other rig: there are currently 31 invalids, again with all of them being my Ivy against two Haswells. I have no specific number of how many Ivys and Haswells are crunching here overall, but the chance for this being a coincidence seems small.
Although the description refers to what seems to be an embedded Celeron development kit, the ReadMe file has the standard compatibility list for third and fourth generation Core processors, and the zip file seems very similar to the one I have saved from my original 10.18.10.3621 download for the Haswell. I'll do a fuller comparison in the morning.
I see the same problem when I look at my invlids. They are not many, but it really seems like that there is a problem with the hosts that validate against each other. They have high invalid-rates and all of them are HD4600s.
As I do not have so many invalids, I am not really concerned about my credits. But I am afraid that there could be a problem with the data output.
@Richard: that would be an easy link to the old driver, or do you have something more in mind? As a reason for posting this, not asking generally ;)
MrS
A small number - a very small number - of users will take sufficient interest in the work their computers are doing after attaching to this project to realise that there is a problem, find their way to this thread, and discover that there is some interim action they can take to reduce the error rate.
No substitute for a properly engineered solution at source, I know, but since there doesn't seem to be any other course of action accessible to end users, I thought it might help a little.
Although the description refers to what seems to be an embedded Celeron development kit, the ReadMe file has the standard compatibility list for third and fourth generation Core processors, and the zip file seems very similar to the one I have saved from my original 10.18.10.3621 download for the Haswell. I'll do a fuller comparison in the morning.
Comparison done for the 64-bit version (I don't have an iGPU running under 32-bit Windows, so I didn't download a reference copy of the original release).
That 'NUC' download is guaranteed 100% identical to the original version 10.18.10.3621 release, which I downloaded as 'win64_153322.zip' back in June - all 352 files have the same CRC and MD5.
@Richard: that would be an easy link to the old driver, or do you have something more in mind? As a reason for posting this, not asking generally ;)
MrS
A small number - a very small number - of users will take sufficient interest in the work their computers are doing after attaching to this project to realise that there is a problem, find their way to this thread, and discover that there is some interim action they can take to reduce the error rate.
No substitute for a properly engineered solution at source, I know, but since there doesn't seem to be any other course of action accessible to end users, I thought it might help a little.
Sorry for the inconveniences.
I have to admit that I have been way too busy with other things to watch this thread for quite a while.
Could you please outline a "properly engineered solution at source"? Does "source" here means Intel or E@H?
As a possible temporary workaround we could exclude certain devices and driver versions from getting work at all - could you (or anyone else) please summarize which devices and which driver versions are affected?
Firstly, I speak for Windows only (and in my case, it's 64-bit Windows 7).
I'd guess that the problem affects the entire range of Intel CPUs with integrated GPUs - we know them as HD 2500/4000/4400/4600/5000/5100/5200/5300 graphics chipsets, but there are some indications that newer Pentium and even Celeron CPUs with HD graphics can also run OpenCL on the device.
I find the Intel driver download center hard to navigate, but driver searches tend to end up on a page like
Both the drivers on that page - 10.18.10.3907 dated August 2014 and 10.18.10.3960 dated October 2014 - seem to produce a low validation rate with the current Einstein Intel GPU application (and also the equivalent SETI application).
All we can say for certain is that there was a change in behaviour after the 10.18.10.3621 driver, which produces a high validation rate. Quite what goes wrong - what changes in the result file - I'm afraid I can't say: that might be easier for you or Bikeman to extract from the returned results.
Up to you to judge whether the current error return rate from the Intel GPU app is acceptable to the project (especially considering whether validations arising from two 'new driver' hosts matching are scientifically useful).
As an immediate stopgap, setting a maximum driver version of 10.18.10.3621 should restore consistency of results - but will cut off a large number of hosts, whose users will have difficulty locating the older drivers for download. From that point forward, whether there's anything that Einstein can do to work with the newer drivers, or whether this is properly categorised as a driver bug requiring remedial action by Intel, is beyond my knowledge.
(I do have a HD 4600 'Haswell' which I'm happy to run any tests on if needed)
Up to you to judge whether the current error return rate from the Intel GPU app is acceptable to the project (especially considering whether validations arising from two 'new driver' hosts matching are scientifically useful).
My fleet of Android and Linux Arm hosts have five invalid tasks, and a number of inconclusives between them where they have been matched with a pair of intel_gpu hosts:
I think would be a little
)
I think would be a little misleading to categorise this as a Haswell problem.
I have two machines:
i7 'Ivy Bridge' HD 4000
i5 'Haswell' HD 4600
Both are running the 3621 driver which seems to suit the Einstein application and validator better, with (on a spot check) validation rates between 93% and 94% (41 invalid out of 635 checked, and 31 invalid from 508, respectively).
I presume the preponderance of Haswell CPUs in your study is mainly because of newer machines being built/supplied with the new drivers by default - which is indeed a worrying trend, and one which is not automatically going to go away of its own accord. But I doubt it can be cured without developer input.
You are right, using the
)
You are right, using the newer drivers on Ivy Bridge GPUs also increases the error rate. I don't know if there's any further difference between Ivy and Haswell, but at least the fact that all my invalids were generated against Haswells raises an attention flag.
You just quickly checked my other rig: there are currently 31 invalids, again with all of them being my Ivy against two Haswells. I have no specific number of how many Ivys and Haswells are crunching here overall, but the chance for this being a coincidence seems small.
MrS
Scanning for our furry friends since Jan 2002
A user at SETI (which has
)
A user at SETI (which has similar problems to Einstein with the newer drivers) has found this link on the official Intel download site:
https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=23886
'Installs the video graphics driver version 10.18.10.3621 for Intel® NUC products.'
Although the description refers to what seems to be an embedded Celeron development kit, the ReadMe file has the standard compatibility list for third and fourth generation Core processors, and the zip file seems very similar to the one I have saved from my original 10.18.10.3621 download for the Haswell. I'll do a fuller comparison in the morning.
I see the same problem when I
)
I see the same problem when I look at my invlids. They are not many, but it really seems like that there is a problem with the hosts that validate against each other. They have high invalid-rates and all of them are HD4600s.
As I do not have so many invalids, I am not really concerned about my credits. But I am afraid that there could be a problem with the data output.
@Richard: that would be an
)
@Richard: that would be an easy link to the old driver, or do you have something more in mind? As a reason for posting this, not asking generally ;)
MrS
Scanning for our furry friends since Jan 2002
RE: @Richard: that would be
)
A small number - a very small number - of users will take sufficient interest in the work their computers are doing after attaching to this project to realise that there is a problem, find their way to this thread, and discover that there is some interim action they can take to reduce the error rate.
No substitute for a properly engineered solution at source, I know, but since there doesn't seem to be any other course of action accessible to end users, I thought it might help a little.
RE: A user at SETI (which
)
Comparison done for the 64-bit version (I don't have an iGPU running under 32-bit Windows, so I didn't download a reference copy of the original release).
That 'NUC' download is guaranteed 100% identical to the original version 10.18.10.3621 release, which I downloaded as 'win64_153322.zip' back in June - all 352 files have the same CRC and MD5.
Hi
)
Hi Richard!
Sorry for the inconveniences.
I have to admit that I have been way too busy with other things to watch this thread for quite a while.
Could you please outline a "properly engineered solution at source"? Does "source" here means Intel or E@H?
As a possible temporary workaround we could exclude certain devices and driver versions from getting work at all - could you (or anyone else) please summarize which devices and which driver versions are affected?
Thanks,
BM
BM
RE: Hi Richard! Good
)
Good morning Bernd.
Firstly, I speak for Windows only (and in my case, it's 64-bit Windows 7).
I'd guess that the problem affects the entire range of Intel CPUs with integrated GPUs - we know them as HD 2500/4000/4400/4600/5000/5100/5200/5300 graphics chipsets, but there are some indications that newer Pentium and even Celeron CPUs with HD graphics can also run OpenCL on the device.
I find the Intel driver download center hard to navigate, but driver searches tend to end up on a page like
https://downloadcenter.intel.com/SearchResult.aspx?lang=eng&ProdId=3720
(for reference only - please do not use these drivers)
Both the drivers on that page - 10.18.10.3907 dated August 2014 and 10.18.10.3960 dated October 2014 - seem to produce a low validation rate with the current Einstein Intel GPU application (and also the equivalent SETI application).
All we can say for certain is that there was a change in behaviour after the 10.18.10.3621 driver, which produces a high validation rate. Quite what goes wrong - what changes in the result file - I'm afraid I can't say: that might be easier for you or Bikeman to extract from the returned results.
Up to you to judge whether the current error return rate from the Intel GPU app is acceptable to the project (especially considering whether validations arising from two 'new driver' hosts matching are scientifically useful).
As an immediate stopgap, setting a maximum driver version of 10.18.10.3621 should restore consistency of results - but will cut off a large number of hosts, whose users will have difficulty locating the older drivers for download. From that point forward, whether there's anything that Einstein can do to work with the newer drivers, or whether this is properly categorised as a driver bug requiring remedial action by Intel, is beyond my knowledge.
(I do have a HD 4600 'Haswell' which I'm happy to run any tests on if needed)
RE: Up to you to judge
)
My fleet of Android and Linux Arm hosts have five invalid tasks, and a number of inconclusives between them where they have been matched with a pair of intel_gpu hosts:
http://einsteinathome.org/account/127061/computers
they also run at Albert, they have no invalids, nor inconclusives there:
http://albertathome.org/account/65462/computers
Claggy