All S5 WU of a Freq. Not The Same

Jayargh
Jayargh
Joined: 9 Feb 05
Posts: 64
Credit: 1205159
RAC: 0
Topic 191514

I have noticed that some workunits in the same frequency run take 10-20% longer than the majority....a signal detected or injected perhaps? Yet the server always has you claim the exact same amount of credit as the standard. There seems to need to be an adjustment made here as Einstein is starting to average significantly lower AGAIN(as in b4 optys) in credit granted compared to other projects and as more people notice ...you will get more migration away from Einstein....Perhaps flops counts instead of fixed credit by server? Seems to be a bit more fair what Seti is doing....that if a wu takes longer or shorter than standard you are compensated accordingly....my lil ol rant...

Idefix
Idefix
Joined: 21 Mar 05
Posts: 11
Credit: 43293
RAC: 0

All S5 WU of a Freq. Not The Same

Hi,

Quote:
There seems to need to be an adjustment made here as Einstein is starting to average significantly lower AGAIN(as in b4 optys) in credit granted compared to other projects

I can only compare SETI and Einstein because I only run these two projects. My credit production rate of Einstein is 2.6 times higher than the rate of SETI. During the times of S4 it was only 1.4 times. So, I get more credits per hour with S5 than with S4.

If you look at the project stats of Einstein you will see that a lot of users are getting more credits with S5. The credit production rate of Einstein has increased significantly since the change from S4 to S5. At the moment I don't see the need for raising the creditd grants of Einstein even further ...

Regards,
Carsten

Jayargh
Jayargh
Joined: 9 Feb 05
Posts: 64
Credit: 1205159
RAC: 0

RE: Hi,RE: There seems to

Message 41805 in response to message 41804

Quote:
Hi,
Quote:
There seems to need to be an adjustment made here as Einstein is starting to average significantly lower AGAIN(as in b4 optys) in credit granted compared to other projects

I can only compare SETI and Einstein because I only run these two projects. My credit production rate of Einstein is 2.6 times higher than the rate of SETI. During the times of S4 it was only 1.4 times. So, I get more credits per hour with S5 than with S4.

If you look at the project stats of Einstein you will see that a lot of users are getting more credits with S5. The credit production rate of Einstein has increased significantly since the change from S4 to S5. At the moment I don't see the need for raising the creditd grants of Einstein even further ...

Regards,
Carsten

Ok Carsten here is my example on the same host HT enabled only used for Boinc and web surfing, nothing else running, and at the time of both wu's only running Einstein...The 1st one here ran about 59k secs and claimed 175.93 credits. The 2nd wu consecutive in numbering and same frequency ran approx 48k secs here and claimed 175.93 credits..... now you think that is fair? No adjustment needs to be made? Would like to hear an explanation from project devs Bruce or Bernd on this one....11k secs difference same credit is pretty significant Is it not? Over a 20% difference in time spent. This is the main thrust of my post.
Thanks JR

[B@H] Ray
[B@H] Ray
Joined: 4 Jun 05
Posts: 621
Credit: 49583
RAC: 0

That is common with HT as the

That is common with HT as the vertual CPU only uses the skipped cup cyles of the real one.

The more an application is tuned to use as many cycles as possable the more the vertual cpu will slow down. Most other BOINC programs miss a lot more of them than Einstein so your vertual CPU should run slower on Einstein.

Differences in WU's also has to be taken into account so we can not tell if the vertual CPU was running slower or if it was the WU.

[EDIT]
just looked at top two your systems, you were running S4 until just a coupple days ago, on the S4 the diference above did not show up as much.


Try the Pizza@Home project, good crunching.

MB Atlanos
MB Atlanos
Joined: 11 Feb 05
Posts: 30
Credit: 1758276
RAC: 0

RE: Ok Carsten here is my

Message 41807 in response to message 41805

Quote:

Ok Carsten here is my example on the same host HT enabled only used for Boinc and web surfing, nothing else running, and at the time of both wu's only running Einstein...The 1st one here ran about 59k secs and claimed 175.93 credits. The 2nd wu consecutive in numbering and same frequency ran approx 48k secs here and claimed 175.93 credits..... now you think that is fair? No adjustment needs to be made? Would like to hear an explanation from project devs Bruce or Bernd on this one....11k secs difference same credit is pretty significant Is it not? Over a 20% difference in time spent. This is the main thrust of my post.
Thanks JR


It's only a HT-CPU not the 2 independent CPUs which it can pretend to be. So the processor must share his inertial processing units - the 'power' of the simulated CPUs may vary. I guess the sheduler was just not always symmetric at the controlling of the workflow.

Single- or real Dualprocessors are pretty constant at crunchtimes for the same type of WUs, very little fluctuation - only 100-200 seconds.

Someone with more experience or knowledge can describe this better or correct me if i have remembered this piece wrong.

Jayargh
Jayargh
Joined: 9 Feb 05
Posts: 64
Credit: 1205159
RAC: 0

RE: That is common with HT

Message 41808 in response to message 41806

Quote:

That is common with HT as the vertual CPU only uses the skipped cup cyles of the real one.

The more an application is tuned to use as many cycles as possable the more the vertual cpu will slow down. Most other BOINC programs miss a lot more of them than Einstein so your vertual CPU should run slower on Einstein.

Differences in WU's also has to be taken into account so we can not tell if the vertual CPU was running slower or if it was the WU.

[EDIT]
just looked at top two your systems, you were running S4 until just a coupple days ago, on the S4 the diference above did not show up as much.

Ray -That difference when you watch the processes is 2-4%( one processor showing say 48% and the other 50%or 52% throughout its runs not 20% such as 1 at 40% and the other at 60%....but you may have a valid point and a good explanation of why there are such variances in my times....maybe it is HT induced....and now I am running Seti also on this host so I can't make real good comparasins from this point forward.... gonna keep an eye on my 1.8 gig single processor and see if I get large differences.

[B@H] Ray
[B@H] Ray
Joined: 4 Jun 05
Posts: 621
Credit: 49583
RAC: 0

RE: Ray -That difference

Message 41809 in response to message 41808

Quote:

Ray -That difference when you watch the processes is 2-4%( one processor showing say 48% and the other 50%or 52% throughout its runs not 20% such as 1 at 40% and the other at 60%....but you may have a valid point and a good explanation of why there are such variances in my times....maybe it is HT induced....and now I am running Seti also on this host so I can't make real good comparasins from this point forward.... gonna keep an eye on my 1.8 gig single processor and see if I get large differences.


Can't say if it is the HT or not, but looks like it. But you still get a lot more done than a P4 without HT, so feel good about that part.
Cheers
Ray

EDIT
How many credits dues an AMD XP64X2 cost?


Try the Pizza@Home project, good crunching.

archae86
archae86
Joined: 6 Dec 05
Posts: 3145
Credit: 7024924931
RAC: 1806140

RE: That is common with HT

Message 41810 in response to message 41806

Quote:

That is common with HT as the vertual CPU only uses the skipped cup cyles of the real one.

The more an application is tuned to use as many cycles as possable the more the vertual cpu will slow down. Most other BOINC programs miss a lot more of them than Einstein so your vertual CPU should run slower on Einstein.


I own a Gallatin (Northwood derived P4 with an additional 2 Megabytes of cache which was sold as the first P4 Extreme Edition). I have run in hypertheaded mode most of the time for a couple of years.

The reported CPU time for BOINC result completion has not varied appreciably between the two virtual CPUs (note, I believe it is not correct to say there is one real one and one virtual one).

As I have been running with CPU affinity, it does happen that sometimes other tasks on the PC which use appreciable time take it preferentially from one of the two virtual CPUs, but unlike my Win98 machines, the reported CPU time accounting has been remarkably stable in the face of such challenges.

I think the second quoted paragraph also differs from my observations. As Akos made progressive efficiency improvements there was not a steady loss of HT gain, as woudl be the case were your description accurate. Instead there was one step along the way at which ther was a huge switch (from appreciable HT gain to substantial HT loss).

At the moment I'm doing some fresh looks at HT advantage/disadvantage for the current Einstein S5 application and SETI Enhanced. Unlike Akos' later S4 aps, the current S5 ap benefits from HT on my Gallatin, and the traditional coziness of a pairing of Einstein with SETI still applies, not necessarily to the same degree as in the halcyon days of yore. I'll post numbers in a separate thread when they are ready.

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5842
Credit: 109411301157
RAC: 34917504

I agree entirely with what

I agree entirely with what archae86 is saying. If you can keep one virtual cpu doing EAH and one virtual cpu doing Seti then you have the best possible situation. If you lose affinity and both CPUs are doing the same project, you will see a significant lengthening of the time take to do a result.

I believe this is what JRenkar is seeing.

Cheers,
Gary.

Jayargh
Jayargh
Joined: 9 Feb 05
Posts: 64
Credit: 1205159
RAC: 0

RE: I agree entirely with

Message 41812 in response to message 41811

Quote:

I agree entirely with what archae86 is saying. If you can keep one virtual cpu doing EAH and one virtual cpu doing Seti then you have the best possible situation. If you lose affinity and both CPUs are doing the same project, you will see a significant lengthening of the time take to do a result.

I believe this is what JRenkar is seeing.

Hi Gary
As I originally and subsequently posted when my examples were run I was NOT running Seti. In fact at that point I had no wu's. I think it is a combination of HT and some variabity in the wu's but would like to see a 20% difference in this type of situation on a single proccesor or a trully dual or quad set-up before I scream bloody murder again about unfair crediting.... however I have seen some weird claimed credit not due to old Boinc clients and the jury is still out on whether a fixed system is the better choice over counting flops to alleviate a situation where a wu takes longer.
Thanks JR

archae86
archae86
Joined: 6 Dec 05
Posts: 3145
Credit: 7024924931
RAC: 1806140

RE: Hi Gary As I

Message 41813 in response to message 41812

Quote:

Hi Gary
As I originally and subsequently posted when my examples were run I was NOT running Seti.


JR,
Consider the difference in reported CPU time (and actual productivity) between a Einstein paired with a SETI and an Einstein paired with and Einstein.

We all know that differences is huge.

Therefore, if there is any task running on your machine which preferentially runs on one of the two virtual CPUs it will can distort the CPU time on _the other_ CPU running Einstein up or down. In my own case, I've had surprising variety of things take up meaningful CPU over hours of time:

1. a bad advertisement on page on of the The Times (the one from London which deigns not to need to designate itself to a place, and which deemed Firefox too insignificant a browser to look into my bug report).
2. bad advertisements on several other places.
3. a bad implementation of a Windows driver or communication protocal to an HP printer across my network--every time I printed to the Postcript printer a process promptly started eating over 10% of available CPU (and 100% of available Wireless network capacity! until hand stopped or rebooted).

...

The point is there are "good sharers" (like SETI) and "bad sharers" (like the later Akos S4 aps) and everything in between. If you don't run any long-term processes which eat substantial CPU, this is a minor noise problem, and your reported times, I predict, may be as stable as mine. But if you have any persistent processes, they'll put a thumb on the scale, and it won't likely bet neutral.

None of this means HT does not work. It does mean than CPU time reporting in complex systems is a bit iffy. Not exactly news to anyone who ran on a multi-programmed IBM system/360 in 1969 (as I did). In any system efficiently sharing multiple resources, pretending there is one resource and reporting it runs aground when the other sharers are non-equivalent.

I think I've just elaborated on Gary's point here--not claiming to have introduced substantial new material.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.