My host 12247194 under Windows 7 Pro (Dual Boot, host 12241921 under Linux) finished 4 x FGRPSSE 1.03 in ~ 5:20:00, one hour faster. No times for 1.01.
By turning off hyper-threading, I am now completing the 1.03 Gamma (FGRPSSE) in 5 hours 55 minutes on this i7-4771 machine (Win7 64-bit). That is some improvement, but not as fast as your Xeon E3-1225 v3 @ 3.20GHz.
But then I noticed in your BOINC account 12241921: Measured floating point speed: 4241.46 million ops/sec Measured integer speed: 15093.64 million ops/sec
Whereas in my BOINC account 11368189: Measured floating point speed: 1000 million ops/sec Measured integer speed: 1000 million ops/sec That can't be correct. I think this installation of Windows 7 64-bit is borked, and needs to be reinstalled.
I have a large number of hosts running Linux. They are individually monitored every two hours by a control script running on a server machine. Apart from a number of error checking functions, the script provides warnings for a number of parameters including task fetch and return rates (both CPU and GPU tasks), RAC variations, high and low temperatures beyond set limits for both CPUs and GPUs, etc. Since last Friday, the script has been flagging an increasing number of hosts running CPU tasks as having unusually low fetch and return rates for just CPU tasks.
My fleet has been essentially running on auto with little direct supervision from me. My wife has health issues and I just don't have the time at the moment so I haven't really investigated. I agree with earlier posters that the latest FGRP app for Linux is taking a lot longer to complete tasks so it would appear that this is exactly what the control script is responding to. I have looked at just a couple of machines and see the longer crunch times similar to those noted earlier. I don't know what is happening under Windows or OS X - I don't really have time to investigate. I don't know if the longer run times are expected (more detailed analysis??) or if the times for the latest app weren't meant to change much. We should wait for one of the staff to advise.
EDIT: I now see Christian has responded whilst I was composing. Thanks Christian.
The reason for issuing the new application version was a fix to the "follow-up" code. On Windows (and OSX for that matter) we see a pretty constant 2% increase in total run-time per task, which is to be expected. Only with the 64Bit Linux app, however, the difference in run time is about 21%. Pretty puzzling.
We're working on fixing this. If you're really keen on RAC, in the meantime you may try the 32Bit Linux App (tell the client to use the "i686-pc-linux-gnu" platform and no alternative platform, and install the 32Bit compatibility libraries), this might currently be faster.
DF1DX wrote:My host 12247194
)
By turning off hyper-threading, I am now completing the 1.03 Gamma (FGRPSSE) in 5 hours 55 minutes on this i7-4771 machine (Win7 64-bit). That is some improvement, but not as fast as your Xeon E3-1225 v3 @ 3.20GHz.
But then I noticed in your BOINC account 12241921:
Measured floating point speed: 4241.46 million ops/sec
Measured integer speed: 15093.64 million ops/sec
Whereas in my BOINC account 11368189:
Measured floating point speed: 1000 million ops/sec
Measured integer speed: 1000 million ops/sec
That can't be correct. I think this installation of Windows 7 64-bit is borked, and needs to be reinstalled.
We are investigating the
)
We are investigating the issue with the Linux applications.
I have a large number of
)
I have a large number of hosts running Linux. They are individually monitored every two hours by a control script running on a server machine. Apart from a number of error checking functions, the script provides warnings for a number of parameters including task fetch and return rates (both CPU and GPU tasks), RAC variations, high and low temperatures beyond set limits for both CPUs and GPUs, etc. Since last Friday, the script has been flagging an increasing number of hosts running CPU tasks as having unusually low fetch and return rates for just CPU tasks.
My fleet has been essentially running on auto with little direct supervision from me. My wife has health issues and I just don't have the time at the moment so I haven't really investigated. I agree with earlier posters that the latest FGRP app for Linux is taking a lot longer to complete tasks so it would appear that this is exactly what the control script is responding to. I have looked at just a couple of machines and see the longer crunch times similar to those noted earlier. I don't know what is happening under Windows or OS X - I don't really have time to investigate. I don't know if the longer run times are expected (more detailed analysis??) or if the times for the latest app weren't meant to change much. We should wait for one of the staff to advise.
EDIT: I now see Christian has responded whilst I was composing. Thanks Christian.
Cheers,
Gary.
The reason for issuing the
)
The reason for issuing the new application version was a fix to the "follow-up" code. On Windows (and OSX for that matter) we see a pretty constant 2% increase in total run-time per task, which is to be expected. Only with the 64Bit Linux app, however, the difference in run time is about 21%. Pretty puzzling.
We're working on fixing this. If you're really keen on RAC, in the meantime you may try the 32Bit Linux App (tell the client to use the "i686-pc-linux-gnu" platform and no alternative platform, and install the 32Bit compatibility libraries), this might currently be faster.
BM
Version 1.04 (just issued)
)
Version 1.04 (just issued) should fix this.
BM
I notice the v1.03 and v1.04
)
I notice the v1.03 and v1.04 tasks are quorum size = 1.
The run times are back to
)
The run times are back to normal, with the expected small increase over v1.01.
On this Xeon E5-2660 host
)
On this Xeon E5-2660 host 12242223
Application N Average Median Mininum Maximum StdDeviation
FGRPB1v1.00 6427 37969.5 38040.67 16175.79 41602.40 558.528
FGRPOLD 68 37920.9 38093 36846.11 38321.14 394.326
FGRPSSE 14 42919.7 42947.6 42673.05 43098.47 127.486
FGRPSSEv1.04 17 38877 38869.78 38747.60 39001.84 66.1537
Shows ~2.4% increase. All good.
Bernd Machenschalk
)
Version 1.04 fixed the issue for me.