The cEM/s is dropping in my clients. They are running on AMD XP.
I can also see this in the overall project stats window, around the the end March. Does anybody know the reason for this?
Printable View
The cEM/s is dropping in my clients. They are running on AMD XP.
I can also see this in the overall project stats window, around the the end March. Does anybody know the reason for this?
It might be due to an increase in FFT size. Just guessing.
Please find more discussion on cEMs here.
i have noticed the slowdown also, as have many of my Anandtech teammates.
Last time that it was an fft issue, it was a step change down and then started to come back up with the next larger prp test. This has been a gradual slowdown over the last 4-6 days.
Slatz
Because more and more users are getting a test with the larger FFT. On slower computers or computers which aren't on 24/7 it takes several days to complete a single test.
i don't think we are talking about the overall project slowdown. i am talking about my personal pc going from 120Kcems/s about a week ago down to the mid 90's yesterday.
When i woke up this morning, it had step changed back up to 105. Computer has had normal usage during this entire time and I have completed 2 prp tests.
Just wondering if there was a problem somewhere?
Slatz
The overall project slowdown results in the slowdown of the individual systems.
This is because the tests got so large that the fast fourrier transformation takes longer to compute. There are certain steps this behavior kicks in.
So when you are just above such a step, you will notice a considerable decrease in the cEM/s measurement.
With increasing n after having reached a step, cEM/s will go up again, as the correction /the "c" in cEM) is not completely balanced...
also keep in mind that we are testing 12 different k values each with many n values. When the n values grow enough to switch to a different FFT size, the servers are still sending many test with smaller n values. So for a while we'll be receiving test over and under the 'threshold'.
As far as your PC there could be many explanations if another task used CPU time for a while the rate your client reports will be affected. It would normally rise again at night when you don't run anything on this system.
Cheers,
Marc
Hi,
I've experienced the same problem on the Windows32 1.0.0 client . I can actually see the cEM/s "counting down". I stop the client, exit, and restart it and it will quickly go up over the 'old' value and even start "counting up". Try that?
Also that when I type "netstat -a" in a command prompt, there seems to be an issue in the networking part. There are a lot of lines (I assume 1 for every connection attempt) that look like:
TCP mybox:1574 p4-2261:0 LISTENING
TCP mybox:1587 p4-2261:0 LISTENING
TCP mybox:1597 p4-2261:0 LISTENING
TCP mybox:1628 p4-2261:0 LISTENING
and also:
TCP mybox:1574 sb.pns.net:1717 CLOSE_WAIT
TCP mybox:1587 sb.pns.net:1717 CLOSE_WAIT
TCP mybox:1597 sb.pns.net:1717 CLOSE_WAIT
TCP mybox:1628 sb.pns.net:1717 CLOSE_WAIT
Closing, exiting, and restarting the client also takes care of this 'problem'.
I'm running WinXP Pro SP1, no firewalls, but NetBIOS disabled.
Can anyone else confirm this behaviour?
- Marco
The open connections are an issue of the current client. Just use the search function to look for "open connection". But normally it's not a critical incident. Running the client for a longer time could render it uncommunicative, though.
Thanks for the information regarding FFT step increase and the "c" in cEM. This is only the second FFT increase as long as I have been with this project. I didn't know how regular they were.
There is also a general decrease in production with this project at the moment. I have observed the number of active members and pending tests decrease, but there is something else that is wrong also.
I have 4 fairly high speed clients and 3 of these have just got assigned tests that are just above 10 days "old", i.e. that are in the low 3.3M range. Are these abandoned tests from people leaving or are they the result of this error that many have reported: "server had no record of proth test, test abandoned".
Ther "Serivce installer" has helped a lot of people getting around the connection problems, but I think it is a better solution to instead (or in addition) not make so many connections to the server. I clicked off the "transmit intermediate blocks" about a month ago, and have not had a single connection problem since.
Could be coincidence. Maybe the computers reported their blocks in short succesion and the server did a daily discard session...Quote:
I have 4 fairly high speed clients and 3 of these have just got assigned tests that are just above 10 days "old", i.e. that are in the low 3.3M range. Are these abandoned tests from people leaving or are they the result of this error that many have reported: "server had no record of proth test, test abandoned".
A lot of ppl see the service installer as a workaround. Louie is working on a completely new version of the client for some time now. Let's hope it doesn't take much longer to complete it.Quote:
Ther "Serivce installer" has helped a lot of people getting around the connection problems, but I think it is a better solution to instead (or in addition) not make so many connections to the server.
This surely works as the clients connects only after the whole test is done. But keep in mind that you then have to complete the whole test within the expiration time (currently 10 days).Quote:
I clicked off the "transmit intermediate blocks" about a month ago, and have not had a single connection problem since.