Yeah I noticed to and I was really not paying attention because it's probably in my logs as well ( I think most if not all of the servers for classic now report credit as well ).
Guess I was just looking for an explanation as to why I get the feeling it's to low, not the credit but the ppd. But I'll live with it
@Nantes, there is a thread for HFM.net in the 3rd party forum here, if you have any problems just post them there you'll get tons of help.
core_a4 projects with silly ppd
Moderators: Site Moderators, FAHC Science Team
-
- Posts: 1579
- Joined: Fri Jun 27, 2008 2:20 pm
- Hardware configuration: Q6600 - 8gb - p5q deluxe - gtx275 - hd4350 ( not folding ) win7 x64 - smp:4 - gpu slot
E6600 - 4gb - p5wdh deluxe - 9600gt - 9600gso - win7 x64 - smp:2 - 2 gpu slots
E2160 - 2gb - ?? - onboard gpu - win7 x32 - 2 uniprocessor slots
T5450 - 4gb - ?? - 8600M GT 512 ( DDR2 ) - win7 x64 - smp:2 - gpu slot - Location: The Netherlands
- Contact:
Re: core_a4 projects with silly ppd
I don't have specific information about what might have happened to these WUs, but the most common situation is a WU that downloads, fails, (perhaps a different WU is processed, perhaps not), the same WU is reassigned and it is completed. Since the total time from the FIRST download to the FINAL upload is used to calculate the QRB, monitoring software (and donors) are often look at the time the WU was reassigned and reach a false conclusion about the expected QRB.Joe_H wrote:Those points credited are all consistent with getting bonus through the QRB as the base points are 89. As I can complete one of the 8001 WU's in just over 4 hours and get around 300 points on my 2.4 Core 2 Duo, these obviously took a bit longer.
Posting FAH's log:
How to provide enough info to get helpful support.
How to provide enough info to get helpful support.
Re: core_a4 projects with silly ppd
I have project 7611 again (4, 20, 120) and instead of the usual ~55k PPD (smp and gpu combined) I have 22k with this project. What the hell is wrong with project 7611?
P.S: Using the 6th open-beta of client v7.
P.S: Using the 6th open-beta of client v7.
-
- Site Admin
- Posts: 7990
- Joined: Tue Apr 21, 2009 4:41 pm
- Hardware configuration: Mac Studio M1 Max 32 GB smp6
Mac Hack i7-7700K 48 GB smp4 - Location: W. MA
Re: core_a4 projects with silly ppd
Your results with the 7611 seem consistent with what others have reported, it does appear to give PPD about 20% lower than similar projects. It is low even compared to its companion project 7610. There may have been a thread about having its points adjusted, I do not recall the outcome on that. In any case, my 2.8 i7 gets TPF's of about 7.5-8 minutes on 7611's, and under 7 minutes to as low as 5.5 minutes doing 7610's. Both do seem to be very sensitive to thread synchronization, very little CPU time taken by another process leads to large changes in the frame times. Whether anything will be done about it I don't know and am not all that concerned about. Personally I just grumble a bit (mostly to myself) about the dip in points when I get them, and feel better when I get units with better PPD results.
Re: core_a4 projects with silly ppd
All SMP projects are sensitive to thread synchronization issues. This is particularly noticeable when a V7 Windows client is installed on a system with an ATI GPU since the GPU will take one full thread and SMP will take all threads, leaving the total one short. The imbalance is constant and performance suffers. (You can configure the same thing in V6, but when you configure two clients, people tend to think about it more.) With an NV GPU, it's not a problem, since the GPU client takes maybe 2% rather than 100% of one core. Sure, there's an imbalance, but the GPU more than makes up for a small loss in SMP productivity.
As a general statement, we say that SMP runs at the speed of the slowest thread. That's not perfectly true since competing tasks do their best to get the processing they need, no matter which (virtual?) CPU is available, but it's still a good statement for the long term. Ask yourself what percentage of the time will one of SMP's threads be "late" and if it's a big percentage, reduce the number of SMP threads requested so that all threads will be synchronized most/all of the time.
As a general statement, we say that SMP runs at the speed of the slowest thread. That's not perfectly true since competing tasks do their best to get the processing they need, no matter which (virtual?) CPU is available, but it's still a good statement for the long term. Ask yourself what percentage of the time will one of SMP's threads be "late" and if it's a big percentage, reduce the number of SMP threads requested so that all threads will be synchronized most/all of the time.
Posting FAH's log:
How to provide enough info to get helpful support.
How to provide enough info to get helpful support.
-
- Site Admin
- Posts: 7990
- Joined: Tue Apr 21, 2009 4:41 pm
- Hardware configuration: Mac Studio M1 Max 32 GB smp6
Mac Hack i7-7700K 48 GB smp4 - Location: W. MA
Re: core_a4 projects with silly ppd
By "Both do seem to be very sensitive to thread synchronization, very little CPU time taken by another process leads to large changes in the frame times" I mean that they appear to be more sensitive than many other SMP projects I have processed. Using as little as 10-20% of a single CPU thread for a period of time would cause the frame times to increase by quite a bit. Using a similar amount with some other SMP projects would only result in tacking on 5-10 seconds a frame, not as noticeable a change.
Why this effects the WU's from these projects more I can't say, I would assume it is related to the geometry of the simulation. The A4 core also seems to be more easily perturbed than the A3, but I have seen A4 projects that behaved better than 7610 and 7611 to small amounts of other processing being active. In any case, 7611 with the same atom count and parameters for points as 7610 definitely takes longer for each frame than 7610 on all three of my Intel systems. And I am comparing times when only the OS is running besides the folding client.
Why this effects the WU's from these projects more I can't say, I would assume it is related to the geometry of the simulation. The A4 core also seems to be more easily perturbed than the A3, but I have seen A4 projects that behaved better than 7610 and 7611 to small amounts of other processing being active. In any case, 7611 with the same atom count and parameters for points as 7610 definitely takes longer for each frame than 7610 on all three of my Intel systems. And I am comparing times when only the OS is running besides the folding client.
Re: core_a4 projects with silly ppd
I have not observed any real differences in A4 sensitivity compared to A3 projects.
Two things must be controlled, if you're going to compare. First, the number of threads must be the same, and second, whatever the OS does or does not do functionally to competing processes such as minimizing cache contention by adding a pseudo-lock on affinity will be very important.
Ultimately, however, FAH does not decide how the OS is going to dispatch competing threads, the OS does. The sensitivity to competing tasks for identical FAH projects will be different on Linux, on WinXP, on Win7/Vista, and on MacOS. (I'm not even sure the Vista and Win7 will be the same, but they're more likely identical that any of the others in the list.)
Perhaps a third thing that might have to be controlled to get a straightforward comparison is the nature of the interruptions. e.g.- does the 10-20% consist of a lot of very short interruptions or a relatively few interruptions of longer duration.
By the way, what's taking 10%-20% of a single CPU? That seems like a lot compared to my example of a NV GPU task and it's very small compared to my example of an AMD GPU task.
How much overhead do you see in those numbers? Windows Task Manager will show Kernel Times if you select Performance + View.
Two things must be controlled, if you're going to compare. First, the number of threads must be the same, and second, whatever the OS does or does not do functionally to competing processes such as minimizing cache contention by adding a pseudo-lock on affinity will be very important.
Ultimately, however, FAH does not decide how the OS is going to dispatch competing threads, the OS does. The sensitivity to competing tasks for identical FAH projects will be different on Linux, on WinXP, on Win7/Vista, and on MacOS. (I'm not even sure the Vista and Win7 will be the same, but they're more likely identical that any of the others in the list.)
Perhaps a third thing that might have to be controlled to get a straightforward comparison is the nature of the interruptions. e.g.- does the 10-20% consist of a lot of very short interruptions or a relatively few interruptions of longer duration.
By the way, what's taking 10%-20% of a single CPU? That seems like a lot compared to my example of a NV GPU task and it's very small compared to my example of an AMD GPU task.
How much overhead do you see in those numbers? Windows Task Manager will show Kernel Times if you select Performance + View.
Posting FAH's log:
How to provide enough info to get helpful support.
How to provide enough info to get helpful support.
-
- Site Admin
- Posts: 7990
- Joined: Tue Apr 21, 2009 4:41 pm
- Hardware configuration: Mac Studio M1 Max 32 GB smp6
Mac Hack i7-7700K 48 GB smp4 - Location: W. MA
Re: core_a4 projects with silly ppd
(After two prior responses went poof! due to login timeout when I pressed Submit, the short version:)
Been doing OS/software/hardware comparisons on and off for nearly 30 years, so I do know how to compare apples to apples.
Same number of threads - check.
OS settings the same - check.
Most folding has been done under OS X, I may run enough WU's with the Mac's booted into Windows at some point in the future to be abel to add them to my comparisons. Percentages reported are from OS X showing 100% for each thread, or a total of 800% on the 2.8 i7 and Xeon. OS overhead is about 5% for the kernel and system services.
Most of the time they are running with nothing else besides F@H running. When I am using one with just a browser, then I will see an average of 10-20% load from that. It is spiky as I navigate to various sites. I see about the same overall effect on folding from when another application uses a steady amount of CPU to record a digital TV stream from an USB tuner.
Overall, when doing A3 WU's I saw about a 6-10% increase in TPF compared to when nothing else was running. The increase in TPF for A4 was higher, 10-15% greater was typical with the type of loads mentioned.
Been doing OS/software/hardware comparisons on and off for nearly 30 years, so I do know how to compare apples to apples.
Same number of threads - check.
OS settings the same - check.
Most folding has been done under OS X, I may run enough WU's with the Mac's booted into Windows at some point in the future to be abel to add them to my comparisons. Percentages reported are from OS X showing 100% for each thread, or a total of 800% on the 2.8 i7 and Xeon. OS overhead is about 5% for the kernel and system services.
Most of the time they are running with nothing else besides F@H running. When I am using one with just a browser, then I will see an average of 10-20% load from that. It is spiky as I navigate to various sites. I see about the same overall effect on folding from when another application uses a steady amount of CPU to record a digital TV stream from an USB tuner.
Overall, when doing A3 WU's I saw about a 6-10% increase in TPF compared to when nothing else was running. The increase in TPF for A4 was higher, 10-15% greater was typical with the type of loads mentioned.