Ive got a feeling my results wont validate. Ill run the batch of 12 short units i have and then switch back to xp. I seem to be getting over a 2x improvement which is undoubtedly too good to be true.
edit: its also obviously wrong because truxoft is calibrating beyond the processing power of the cpu.
After switching back to xp and rerunning benchmarks, i get the same speeds with truxoft still claibrating beyond my cpu's ability. The only possible thing that ive done to affect it is update the BIOS yesterday.
However, its probably a batch of extra short units that cruch in 5 mins, which is quick for my cpu. It also wouldnt explain why truxoft is calibrating so high or would it?
Ive got a feeling my results wont validate. Ill run the batch of 12 short units i have and then switch back to xp. I seem to be getting over a 2x improvement which is undoubtedly too good to be true.
Why do you think your work wont validate? I had a quick look through your results list and didn't see any marked as invalid. I saw plenty marked as valid. When did you change to Vista? Are you sure you are not misinterpreting the calibrating action of the Trux client?
Quote:
edit: its also obviously wrong because truxoft is calibrating beyond the processing power of the cpu.
I've never used the Trux client but I do know it will continue to make adjustments for maybe about 30 results or more before the "calibrating action" has been completed. I think you are worrying about nothing :). If "calibrating" is going to work, your machine has to appear to have much better benchmarks than the standard BOINC client would measure. Is this what you mean by your statement?
I've just looked at a very recent short result of yours where you took 538 seconds and claimed 5.73 and a second machine using the stock standard app and client took 3550 seconds and claimed 6.16. The quorum has not yet formed so the result is "pending" but everything looks to be as it should be. Without the calibrating client you would probably be claiming about 1. The idea of "calibration" is to make up some "correction" factors so that your machine claims what the standard configuration would claim. This seems to be what is happening. Stop worrying :).
After switching back to xp and rerunning benchmarks, i get the same speeds with truxoft still claibrating beyond my cpu's ability. The only possible thing that ive done to affect it is update the BIOS yesterday.
I didn't see this message until after I had posted mine. I imagine that your choice of either Vista or XP will have little observable effect on the behaviour of any part of the BOINC system. Nor should you expect it to have. Drill down into one of your listed results on the website and notice that stderr.out is showing, as part of the information reported when a result completes, values for parameters called real_cpu_time, corrected_cpu_time and corrected_Mfpops. Check a number of results and you will see the "calibrating" action progressively increasing both the corrected_cpu_time in relation to the real_cpu_time and the corrected_Mfpops. I have no experience to base it on but I would say that this is exactly how things are supposed to be. Please go and re-read any commentary or instructions about this on the Trux website.
Quote:
However, its probably a batch of extra short units that cruch in 5 mins, which is quick for my cpu. It also wouldnt explain why truxoft is calibrating so high or would it?
There do indeed seem to be approximately three general types of tasks - let's call them "longs", "shorts" and "short shorts". For your spec machine and the Akos app you are using, I would expect that the true crunch times would be about 60 mins, 15 mins and 6 mins respectively, based on what some of my machines are doing. These should be taken as very general broad "guesstimates" only. Since the Akos app is so fast, and since your credit claim is based on benchmarks x time, you should realise that a normal benchmark combined with a fast time is going to give you a very low claim - about one sixth of what the standard client would claim. The job of the Trux client is to "calibrate" both benchmark and time so as to end up with a "standard" claim for a particular result. There seems to be fairly general consensus that this is a reasonable thing to do. Please note that your choice of OS within the Windows family (if not more widely) should have no real bearing on the calibrating mechanism so you are largely wasting your time by changing back and forth between Vista and XP and expecting to see a significant difference :).
Please go read all you can find on the Trux website and think about what he says in relation to what you are seeing and all should become much clearer. Please also read the "sticky" thread here about the use of calibrating clients.
Edit: Please realise that there can be some controversy, particularly on different projects, about how best to setup what we might call a "fair and equitable" credit claim when highly optimised apps are involved. My personal opinion, and that's all it is, is that a given task should result in the same claim irrespective of the platform used, the level of optimisation of the app or the true amount of cpu seconds actually used. For that reason, I am very much in favour of systems that try to achieve this, particularly if it can be demonstrated to also be fair and equitable across projects. I am hopeful that the Devs here will be able to achieve this with the soon-to-commence S5 data set where they have already stated that there will be a new credit calculating system that gives fixed credit for any given result. We don't know the full details yet.
Running Vista doesn't make running any BOINC application faster.
Perhaps the other way around - as it is still beta, needs more memory to run and possibly more frequent running.
Even XP 64-bit or 64-bit version of Vista doesn't help when app is in 32-bit and it must be run under Wow (Windows 32 on Windows 64).
Anyway, Vista needs to be tested with BOINC and it may be usefull for alpha/beta testers and developers/optimiziers to do some testing. I would not encourage messing with it until familiar both with BOINC and OS being tested...
As far as we, thats me and youngest son, can see, using 32 bit version of Vista compared to win2000 on Dual P3 and winXP home on P4 2.53, non HT, has made no difference to crunch times.
Before these extra short units, Boinc used to accurately estimate that long units would take ~50 mins and short units ~15 mins due to truxoft. Now that ive got these extra short units they were at first estimated to take ~13 mins when they actually took ~6 mins.
At first i though it was Vista but running these units under xp showed no difference so i quickly ruled out Vista as the reaosn.
So i am assuming it was this difference in actual/real cpu times that caused truxofts claibrating client to go crazy and i am claiming unfair credits as Truxoft takes a while to re-calibrate as normal work units come back.
Today is pretty bad with the machine getting over 27 of these very short units. It was a good thing my count restarted at 6am otherwise wouldve hit 32 already.
Before these extra short units, Boinc used to accurately estimate that long units would take ~50 mins and short units ~15 mins due to truxoft. Now that ive got these extra short units they were at first estimated to take ~13 mins when they actually took ~6 mins.
The variation in result times is not a problem. You will have a duration correction factor (DCF) that is jumping around but so what?? The important thing is that the calibration is working. The real test is "Are you being granted approximately what you are claiming?" Look through your results list!! You are being granted very similar to what you are claiming. This means that the other members of each quorum must be pretty much in agreement with you so all is fine. Stop worrying!! :).
Quote:
So i am assuming it was this difference in actual/real cpu times that caused truxofts claibrating client to go crazy and i am claiming unfair credits as Truxoft takes a while to re-calibrate as normal work units come back.
The calibrating client seems to be doing a great job!! You are not claiming unfairly!!
Quote:
Today is pretty bad with the machine getting over 27 of these very short units. It was a good thing my count restarted at 6am otherwise wouldve hit 32 already.
edit: just as i write this i hit the limit :(
Yes, this is the only thing you have to worry about and this is nothing to do with the calibrating client - it's just the luck of the draw. Now that you are getting these short shorts, they will probably persist for up to several days and you will hit the daily limit each day until they are finished. If you are really unlucky, you may even get a repeat dose when you get a new large data file. You have several options if you don't want to see your cpu grow cold :).
1. Make sure you have at least one "backup" project. This is the easiest option and Seti Enhanced is a good choice because that uses FLOP counting and wont be affected by your calibrating client.
2. Use a BoincStudio client instead of the Trux client. This client can calibrate your credit claims but it is a different mechanism from that used by Trux. It is in early (but quite rapid) development and what limited documentation there is exists in French, although an English version is supposed to be available RSN. Its biggest advantage is that it can fake your number of CPUs so that the server thinks you have up to 4 instead of 1 and so your daily limit becomes up to 128 instead of 32. I know it works well as I'm using it on a couple of machines that were hitting the daily limit in less than 2 hours after the start of a new day. If you want to explore the use of this client you will need to do a bit of research and the best place to start is with the BoincStudio thread in this forum. Please realise that BoincStudio is (like BoincView) a system for managing a whole farm of computers and looks very promising in this regard. If you read the thread you will see that you only need a small part of the complete package - a replacement BOINC client that will fake your # of cpus and do credit calibrating. If you read the thread you will know as much as me and then it is pretty straight forward to get the cpu faking working.
3. Messier solutions include (I think - because I haven't personally done it) things like detaching and reattaching your computer once it has run dry. Essentially you are pretending to be a new computer and the server will give you a new quota each time you do it - someone will correct me if I've got this a bit wrong. To me this is far too messy to be viable.
We can blame all this turmoil on Akos. If he'd just let sleeping dogs lie we'd all be still dozing along taking hours instead of minutes and never getting anywhere near the daily quota (for most of us anyway) :) ;). That guy has got a helluva lot to answer for :). He's making the S4 run finish way too early and putting all that extra stress on servers and aircon units, etc, not to mention the grief of the users who are wondering where they are going to get their next fix from :). Really great stuff!! :).
Windows Vista Beta 2
)
Ive got a feeling my results wont validate. Ill run the batch of 12 short units i have and then switch back to xp. I seem to be getting over a 2x improvement which is undoubtedly too good to be true.
edit: its also obviously wrong because truxoft is calibrating beyond the processing power of the cpu.
After switching back to xp
)
After switching back to xp and rerunning benchmarks, i get the same speeds with truxoft still claibrating beyond my cpu's ability. The only possible thing that ive done to affect it is update the BIOS yesterday.
However, its probably a batch of extra short units that cruch in 5 mins, which is quick for my cpu. It also wouldnt explain why truxoft is calibrating so high or would it?
RE: Ive got a feeling my
)
Why do you think your work wont validate? I had a quick look through your results list and didn't see any marked as invalid. I saw plenty marked as valid. When did you change to Vista? Are you sure you are not misinterpreting the calibrating action of the Trux client?
I've never used the Trux client but I do know it will continue to make adjustments for maybe about 30 results or more before the "calibrating action" has been completed. I think you are worrying about nothing :). If "calibrating" is going to work, your machine has to appear to have much better benchmarks than the standard BOINC client would measure. Is this what you mean by your statement?
I've just looked at a very recent short result of yours where you took 538 seconds and claimed 5.73 and a second machine using the stock standard app and client took 3550 seconds and claimed 6.16. The quorum has not yet formed so the result is "pending" but everything looks to be as it should be. Without the calibrating client you would probably be claiming about 1. The idea of "calibration" is to make up some "correction" factors so that your machine claims what the standard configuration would claim. This seems to be what is happening. Stop worrying :).
Cheers,
Cheers,
Gary.
RE: After switching back to
)
I didn't see this message until after I had posted mine. I imagine that your choice of either Vista or XP will have little observable effect on the behaviour of any part of the BOINC system. Nor should you expect it to have. Drill down into one of your listed results on the website and notice that stderr.out is showing, as part of the information reported when a result completes, values for parameters called real_cpu_time, corrected_cpu_time and corrected_Mfpops. Check a number of results and you will see the "calibrating" action progressively increasing both the corrected_cpu_time in relation to the real_cpu_time and the corrected_Mfpops. I have no experience to base it on but I would say that this is exactly how things are supposed to be. Please go and re-read any commentary or instructions about this on the Trux website.
There do indeed seem to be approximately three general types of tasks - let's call them "longs", "shorts" and "short shorts". For your spec machine and the Akos app you are using, I would expect that the true crunch times would be about 60 mins, 15 mins and 6 mins respectively, based on what some of my machines are doing. These should be taken as very general broad "guesstimates" only. Since the Akos app is so fast, and since your credit claim is based on benchmarks x time, you should realise that a normal benchmark combined with a fast time is going to give you a very low claim - about one sixth of what the standard client would claim. The job of the Trux client is to "calibrate" both benchmark and time so as to end up with a "standard" claim for a particular result. There seems to be fairly general consensus that this is a reasonable thing to do. Please note that your choice of OS within the Windows family (if not more widely) should have no real bearing on the calibrating mechanism so you are largely wasting your time by changing back and forth between Vista and XP and expecting to see a significant difference :).
Please go read all you can find on the Trux website and think about what he says in relation to what you are seeing and all should become much clearer. Please also read the "sticky" thread here about the use of calibrating clients.
Edit: Please realise that there can be some controversy, particularly on different projects, about how best to setup what we might call a "fair and equitable" credit claim when highly optimised apps are involved. My personal opinion, and that's all it is, is that a given task should result in the same claim irrespective of the platform used, the level of optimisation of the app or the true amount of cpu seconds actually used. For that reason, I am very much in favour of systems that try to achieve this, particularly if it can be demonstrated to also be fair and equitable across projects. I am hopeful that the Devs here will be able to achieve this with the soon-to-commence S5 data set where they have already stated that there will be a new credit calculating system that gives fixed credit for any given result. We don't know the full details yet.
Cheers,
Cheers,
Gary.
Running Vista doesn't make
)
Running Vista doesn't make running any BOINC application faster.
Perhaps the other way around - as it is still beta, needs more memory to run and possibly more frequent running.
Even XP 64-bit or 64-bit version of Vista doesn't help when app is in 32-bit and it must be run under Wow (Windows 32 on Windows 64).
Anyway, Vista needs to be tested with BOINC and it may be usefull for alpha/beta testers and developers/optimiziers to do some testing. I would not encourage messing with it until familiar both with BOINC and OS being tested...
As far as we, thats me and
)
As far as we, thats me and youngest son, can see, using 32 bit version of Vista compared to win2000 on Dual P3 and winXP home on P4 2.53, non HT, has made no difference to crunch times.
Andy
Before these extra short
)
Before these extra short units, Boinc used to accurately estimate that long units would take ~50 mins and short units ~15 mins due to truxoft. Now that ive got these extra short units they were at first estimated to take ~13 mins when they actually took ~6 mins.
At first i though it was Vista but running these units under xp showed no difference so i quickly ruled out Vista as the reaosn.
So i am assuming it was this difference in actual/real cpu times that caused truxofts claibrating client to go crazy and i am claiming unfair credits as Truxoft takes a while to re-calibrate as normal work units come back.
Today is pretty bad with the machine getting over 27 of these very short units. It was a good thing my count restarted at 6am otherwise wouldve hit 32 already.
edit: just as i write this i hit the limit :(
RE: Before these extra
)
The variation in result times is not a problem. You will have a duration correction factor (DCF) that is jumping around but so what?? The important thing is that the calibration is working. The real test is "Are you being granted approximately what you are claiming?" Look through your results list!! You are being granted very similar to what you are claiming. This means that the other members of each quorum must be pretty much in agreement with you so all is fine. Stop worrying!! :).
The calibrating client seems to be doing a great job!! You are not claiming unfairly!!
Yes, this is the only thing you have to worry about and this is nothing to do with the calibrating client - it's just the luck of the draw. Now that you are getting these short shorts, they will probably persist for up to several days and you will hit the daily limit each day until they are finished. If you are really unlucky, you may even get a repeat dose when you get a new large data file. You have several options if you don't want to see your cpu grow cold :).
1. Make sure you have at least one "backup" project. This is the easiest option and Seti Enhanced is a good choice because that uses FLOP counting and wont be affected by your calibrating client.
2. Use a BoincStudio client instead of the Trux client. This client can calibrate your credit claims but it is a different mechanism from that used by Trux. It is in early (but quite rapid) development and what limited documentation there is exists in French, although an English version is supposed to be available RSN. Its biggest advantage is that it can fake your number of CPUs so that the server thinks you have up to 4 instead of 1 and so your daily limit becomes up to 128 instead of 32. I know it works well as I'm using it on a couple of machines that were hitting the daily limit in less than 2 hours after the start of a new day. If you want to explore the use of this client you will need to do a bit of research and the best place to start is with the BoincStudio thread in this forum. Please realise that BoincStudio is (like BoincView) a system for managing a whole farm of computers and looks very promising in this regard. If you read the thread you will see that you only need a small part of the complete package - a replacement BOINC client that will fake your # of cpus and do credit calibrating. If you read the thread you will know as much as me and then it is pretty straight forward to get the cpu faking working.
3. Messier solutions include (I think - because I haven't personally done it) things like detaching and reattaching your computer once it has run dry. Essentially you are pretending to be a new computer and the server will give you a new quota each time you do it - someone will correct me if I've got this a bit wrong. To me this is far too messy to be viable.
We can blame all this turmoil on Akos. If he'd just let sleeping dogs lie we'd all be still dozing along taking hours instead of minutes and never getting anywhere near the daily quota (for most of us anyway) :) ;). That guy has got a helluva lot to answer for :). He's making the S4 run finish way too early and putting all that extra stress on servers and aircon units, etc, not to mention the grief of the users who are wondering where they are going to get their next fix from :). Really great stuff!! :).
Cheers,
Cheers,
Gary.