For my GTX770 for 3 WUs:
1. Memory control load has jumped from 45% to 75%
2. Gpu load is the same - 97%
3. Bus interface load - less then 5%.
Looks very promising.
Does it mean that we don't really need high speed PCI Ex 16 bus for each card anymore?
Can anybody with two video cards in one box on PCI Ex 8 bus confirm it?
My client can't download 1.47 opencl-ati application for Linux. I keep getting:
2/27/2015 7:17:59 PM | Einstein@Home | Started download of einsteinbinary_BRP6_1.40_x86_64-pc-linux-gnu__BRP6-Beta-opencl-ati
2/27/2015 7:18:01 PM | Einstein@Home | Giving up on download of einsteinbinary_BRP6_1.40_x86_64-pc-linux-gnu__BRP6-Beta-opencl-ati: permanent HTTP error
(it's a 404 - not found error)
and all 1.47 tasks fail with download error.
My client can't download 1.47 opencl-ati application for Linux. I keep getting:
2/27/2015 7:17:59 PM | Einstein@Home | Started download of einsteinbinary_BRP6_1.40_x86_64-pc-linux-gnu__BRP6-Beta-opencl-ati
2/27/2015 7:18:01 PM | Einstein@Home | Giving up on download of einsteinbinary_BRP6_1.40_x86_64-pc-linux-gnu__BRP6-Beta-opencl-ati: permanent HTTP error
(it's a 404 - not found error)
and all 1.47 tasks fail with download error.
Sorry. Should work now.
BM
This is just an FYI for Bernd. Over the last couple of hours, I've added some more AMD GPU hosts (Linux x86_64) to the pool requesting 1.47 beta work. In each case, I pre-deployed both the 1.47 and 1.40 versions of the app, seeing as I had copies of both and didn't want to risk 404 download errors on the 1.40 version, like the above example. In each case, both versions of the app were regarded as 'needed' since the event log has the familiar message "file exists - skipping download" for both files.
My host ID 7163667 does definitifely not like the new BRP6-Beta 1.49
All new tasks crashe immediately after starting with "Computing Error"
Two Nvidia GTX670/2GB Driver 347.52
All other tasks (CPU/GPU) are running with success since a long time
I stopped getting new Beta tasks for this host now for a while.
I know I am a part of a story that starts long before I can remember and continues long beyond when anyone will remember me [Danny Hillis, Long Now]
New Clients behave differently when detecting the new API version.
As a quick fix I changed the API version in the DB of the Beta apps to make the clients think it's an older API.
To propagate this change to the clients, I don't think there's any other way than to reset the project on the clients where people experience a "No suitable CUDA device" error (see stderr_out).
New Clients behave differently when detecting the new API version.
As a quick fix I changed the API version in the DB of the Beta apps to make the clients think it's an older API.
To propagate this change to the clients, I don't think there's any other way than to reset the project on the clients where people experience a "No suitable CUDA device" error (see stderr_out).
BM
Aaaaargh! But fully justifying your pessimism about updating the API.....
1) It should be possible to make the matching change in client_state.xml (I presume down to 7.2.2 to match v1.39 would be worth a try) - I'll do that when my current tasks finish.
2) Actually, the client makes extraordinarily little use of the tag. I searched the sources a while back because of a different problem, and only found two tests (with two instances of each):
if (app_version->api_version_at_least(6, 0)) - don't use shared memory for communicating between application and client. That's been there for years (since about 2007), so unlikely to be the cause of this problem.
if (!app_version->api_version_at_least(7, 5)) - from befb90f0d4d1f14ae4a42d1a49bd612e9bcc4f96, 30 July 2014. I suspect that one may need some debug attention from a proper programmer.....
New Clients behave differently when detecting the new API version.
As a quick fix I changed the API version in the DB of the Beta apps to make the clients think it's an older API.
To propagate this change to the clients, I don't think there's any other way than to reset the project on the clients where people experience a "No suitable CUDA device" error (see stderr_out).
BM
Aaaaargh! But fully justifying your pessimism about updating the API.....
1) It should be possible to make the matching change in client_state.xml (I presume down to 7.2.2 to match v1.39 would be worth a try) - I'll do that when my current tasks finish.
2) Actually, the client makes extraordinarily little use of the tag. I searched the sources a while back because of a different problem, and only found two tests (with two instances of each):
if (app_version->api_version_at_least(6, 0)) - don't use shared memory for communicating between application and client. That's been there for years (since about 2007), so unlikely to be the cause of this problem.
if (!app_version->api_version_at_least(7, 5)) - from befb90f0d4d1f14ae4a42d1a49bd612e9bcc4f96, 30 July 2014. I suspect that one may need some debug attention from a proper programmer.....
That last changeset says:
Quote:
client: don't pass --device to GPU apps w/ API version >= 7.5
This addresses a problem w/ Bitcoin Utopia,
whose coprocessor app (run via the wrapper) doesn't expect a --device arg,
and fails if it gets one.
The --device mechanism has been superceded by APP_INIT_DATA.gpu_device_num.
GPU apps built with the current API and later should not expect a --device arg
.
We already have an unresolved api problem at Albert that is similar:
Activated exception handling...
[23:07:50][5536][INFO ] Starting data processing... GPU type not found in init_data.xml
[23:07:50][5536][ERROR] Failed to get OpenCL platform/device info from BOINC (error: -161)!
[23:07:50][5536][ERROR] Demodulation failed (error: -161)!
23:07:50 (5536): called boinc_finish
Trulio was asked to supply his Boinc startup, and the init_data.xml from his slot directory, he hasn't supplied either,
For my GTX770 for 3 WUs: 1.
)
For my GTX770 for 3 WUs:
1. Memory control load has jumped from 45% to 75%
2. Gpu load is the same - 97%
3. Bus interface load - less then 5%.
Looks very promising.
Does it mean that we don't really need high speed PCI Ex 16 bus for each card anymore?
Can anybody with two video cards in one box on PCI Ex 8 bus confirm it?
RE: My client can't
)
Sorry. Should work now.
BM
BM
I'm getting: RE: piÄ…,
)
I'm getting:
Me too. Fri 27 Feb 2015
)
Me too.
It works for me now.
)
It works for me now.
RE: RE: My client can't
)
This is just an FYI for Bernd. Over the last couple of hours, I've added some more AMD GPU hosts (Linux x86_64) to the pool requesting 1.47 beta work. In each case, I pre-deployed both the 1.47 and 1.40 versions of the app, seeing as I had copies of both and didn't want to risk 404 download errors on the 1.40 version, like the above example. In each case, both versions of the app were regarded as 'needed' since the event log has the familiar message "file exists - skipping download" for both files.
Cheers,
Gary.
My host ID 7163667 does
)
My host ID 7163667 does definitifely not like the new BRP6-Beta 1.49
All new tasks crashe immediately after starting with "Computing Error"
Two Nvidia GTX670/2GB Driver 347.52
All other tasks (CPU/GPU) are running with success since a long time
I stopped getting new Beta tasks for this host now for a while.
I know I am a part of a story that starts long before I can remember and continues long beyond when anyone will remember me [Danny Hillis, Long Now]
New Clients behave
)
New Clients behave differently when detecting the new API version.
As a quick fix I changed the API version in the DB of the Beta apps to make the clients think it's an older API.
To propagate this change to the clients, I don't think there's any other way than to reset the project on the clients where people experience a "No suitable CUDA device" error (see stderr_out).
BM
BM
RE: New Clients behave
)
Aaaaargh! But fully justifying your pessimism about updating the API.....
1) It should be possible to make the matching change in client_state.xml (I presume down to 7.2.2 to match v1.39 would be worth a try) - I'll do that when my current tasks finish.
2) Actually, the client makes extraordinarily little use of the tag. I searched the sources a while back because of a different problem, and only found two tests (with two instances of each):
if (app_version->api_version_at_least(6, 0)) - don't use shared memory for communicating between application and client. That's been there for years (since about 2007), so unlikely to be the cause of this problem.
if (!app_version->api_version_at_least(7, 5)) - from befb90f0d4d1f14ae4a42d1a49bd612e9bcc4f96, 30 July 2014. I suspect that one may need some debug attention from a proper programmer.....
RE: RE: New Clients
)
That last changeset says:
.
We already have an unresolved api problem at Albert that is similar:
I am getting computation error
Trulio was asked to supply his Boinc startup, and the init_data.xml from his slot directory, he hasn't supplied either,
Claggy