Fixed download link
Running FINE so far
BTW, SSE2 Only version runs like a champ on an AMD FX55
A very critical bug was found by KenG6 of Team Anandtech and has now been fixed. The bug only effects Windows machines with non SSE2 processors. This means that Linux/FreeBSD/BeOS are not affected by the bug.
We ask that you spread the word about this new client, because it is very important that v2.2.0 windows clients are upgraded to v2.3.0. Due to the nature of this bug and the possibility of missing a prime, in a few weeks we will stop accepting work from the Windows v2.2.0 client. At that point, the v2.2.0 windows tests will be reassigned and restested to make sure we did not miss a prime. The server will not accept work from the Windows v2.2.0 at that time.
Please head over to http://seventeenorbust.com/download/ and get the new client. We thank KenG6 for finding this bug.
--
Mike Garrison
After I download new version and start it running,
1) will it fix problem with current test? Ie should I expire current test?
2) I started a previous test with 1.2.? and finished with 2.2 when it became available. I have the z<n> file for previous test saved at semi-regular points (and just before I changed clients), should I re-run last days of previous test with new client?
Originally posted by tqft
After I download new version and start it running,
1) will it fix problem with current test? Ie should I expire current test?
2) I started a previous test with 1.2.? and finished with 2.2 when it became available. I have the z<n> file for previous test saved at semi-regular points (and just before I changed clients), should I re-run last days of previous test with new client?
1) no, it won't.. expire the current test
2) yeah, you could do that.. if we got a matching residue then everything is good.
so just because there will occur an error with the 2.20 client on non SSE2 cpu, you will stop accepting tests coming from all v2.20 windows clients?
I'm not happy with this. now i can upgrade my clients again while i'm only using P4 cpu's with sse2.
is it not possible to stop accepting tests of non sse2 systems only?
Last edited by fenrir; 12-25-2004 at 07:22 AM.
member of Dutch Power Cows
Am running previous test now - from backup z<> file 10 Dec 2004.
Test is k=19249, n=7213406 - be about 6 days to completion, user tqft (I use this handle in a lot of forums) if you want to do a residue check.
Originally posted by fenrir
so just because there will occur an error with the 2.20 client on non SSE2 cpu, you will stop accepting tests coming from all v2.20 windows clients?
I'm not happy with this. now i can upgrade my clients again while i'm only using P4 cpu's with sse2.
is it not possible to stop accepting tests of non sse2 systems only?
Unfortentely, we don't have a choice. We have no way to tell if the host is a SSE2 machine or a non-SSE2 machine.
But KenG6 did reproduce the error on a Linux machine:Originally posted by Alien88
This means that Linux/FreeBSD/BeOS are not affected by the bug.
--
Mike Garrison
Here's something striking. I tried running the same smaller prime on a Linux machine (PII-400). It followed the same pattern, even though the test restarted from 0.0%!
Joe O
Well, that's not cool. According to Louie it shouldn't happen on the Linux machines..Originally posted by Joe O
But KenG6 did reproduce the error on a Linux machine:
I'll have to talk to him about that
Will all v2.2.0 tests be reassigned or only those with a false residue?Originally posted by Alien88
At that point, the v2.2.0 windows tests will be reassigned and restested to make sure we did not miss a prime.
Is there a way to check residues?
I'm not saying it's impossible, but I find it hard to believe that this same issue is causing problems on non-SSE2 *LINUX* machines on restart.Originally posted by Alien88
Well, that's not cool. According to Louie it shouldn't happen on the Linux machines..
I'll have to talk to him about that
Does it even produce a zXXXXXXX file on such a short test or does it restart with just the "cache" file? If so, I don't know how it's any different then starting from scratch.
Please help me understand more precisely how to recreate this in Linux. Thanks.
Cheers,
Louie
PS - I replied to Mike's post but this is meant for KenG6.
Check my log in the other thread. It does indeed produce a z file, even on such a small run; this surprised me too. When I continued the test, it started virtually from zero, but apparently it used the file and the result came out wrong.
I'll mail you a copy of the PRP emulation program I've put together to send values like this into the SB client by TCP (I.E. not by editing the cache file, which is hard in Linux).
I hope this didn't ruin your Christmas.
When this is over, I'd still like to get permission to release my PRP emulation program, by the way.
Proud member of the friendliest team around, Team Anandtech!
The Queue is dead! (Or not needed.) Long Live George Woltman!
Originally posted by Joh14vers6
Will all v2.2.0 tests be reassigned or only those with a false residue?
Is there a way to check residues?
The only way to tell if it's a false residue is to retest it :\ So.. right now, it'll be all Windows v2.2.0 tests.. but that could change.
why the delay in stopping accepting work fom the defective clients? Shouldn't this be done immediatly?
Well, it could be done immediatly, but I would bet that people would complain about not having enough time to upgrade their clients..Originally posted by Keroberts1
why the delay in stopping accepting work fom the defective clients? Shouldn't this be done immediatly?
plus it's the holidays and the majority of us are on vacation and we'd like to relax
the error would not be present in tests just paused right. Only if the user presed the exit button without pausing first? I had a single test i finished and i paused the test for a short while but i thiki pressed stop and then started the processing up again later. I can send in my log if that would help at all. Perhaps if viewing a person's log can prove whether or not they have been producing valid results could help us single out which tests that have been returned were faulty and which were in fact correct. Also be sure to check for factors before refilling the ques. Some factors have been found for tests in that range and it would be a shame to double or even triple check a tests with a factor.
I do think it, that it doesn 't matter if you pause or exit the client.Originally posted by Keroberts1
the error would not be present in tests just paused right. Only if the user presed the exit button without pausing first?
Man,
Just switch everything to smaller n testing until this is sorted out, at least then we would be able to check against previous residues.
I've been doing P-1 on a range which was passed by without me noticing it. I submitted 3 or 4 factors for tests which have already been assigned. When we redo those tests, will the server know not to hand them out because I found factors (albeit 'too late')? Getting scoring credit would be nice but not critical - just so long as the test don't go to PRP!
The bug that was found with the FreeBSD/Linux/BeOS client has been fixed (Well, FBSD and Linux have been so far) and you can download the client on the download page.
It's not near as serious as the Windows bug, but if you were to control-c/kill sb within the first 10 minutes of the test it would lead to an invalid residue.
--
Mike
What happens with a test that was started under the 2.2 client and then the client is upgraded to 2.3? How will you know to flush that test? Does the server track the client version for each block?
How about the case that intermediate blocks are not being submitted and the client is upgraded in the middle of the test?
One current grip I have with 2.3.0 is that if I delete the K and N DWORD keyes from the registry, the client will not create them, and crash when executed. I believe that when these keys are missing the client should recreate them and request a new test from the server.
Yeah, you'll have to expire the test and get a new block.Originally posted by Beerknurd
Ok I changed to v2.3. But I installed it in the same directory. Therefor it resumed the task that my v2.2 client was running..... Is this bad. I'd sure hate to restart the test. I swear it takes like 2 weeks to finish a task. It only runs at .23M
We know at assignment of the test what version the client is, therefor since it was started on 2.2 it will get retested when we put all those blocks back into the queue, so you might as well expire it and get a new one.Originally posted by SearchingTNT
What happens with a test that was started under the 2.2 client and then the client is upgraded to 2.3? How will you know to flush that test? Does the server track the client version for each block?
How about the case that intermediate blocks are not being submitted and the client is upgraded in the middle of the test?
I would hope that all of those tests with non-sse v2.2 be redone.
Here is my 0.02 for a plan to consider if you will.
1. Don't remove those tests from the system, let them finish and those of a few people who continue working with version 2.2 con tinue to accept those as well.
I'm sure some people will not be able to upgrade the client etc. (hold on for a rational) And if we simply stop accepting results we loose those computers from the system.
2. Release 2.3, it makes sence that 99% of the people who upgraded to 2.2 will also upgrade to 2.3 in time since 2.2 isn't that old, people should still be working same buildings etc. ( This has already started)
Now here is the fix,
3. Always reassign all tests from suspect clients by simply be readded them to the dropped-tests que, just as easy as deleting those tests from the server.
4. In a couple weeks all the problems from 2.2 will be sorted out and submissions from 2.2 will become almost zero through upgrading, like 1.2 etc.
5. Some of those tests from the dropped que retested with 2.3 will have matching resides with 2.2.
(not all 2.2 is submitting false results correct)
Those tests wouldn't require retesting double-checking ever and those with mismatching resides would simply be added again to error-fix automatically to be tested again later.
Doesn't really sound like a large problem here... we just need a practical solution.
I'd like to thank the sysadmins for being on top of this over the holidays.
I was afraid of that. At the assignment of a test, my queue sends a fake version number, since it has no idea what client will connect to get the work. The results it sends back do have the correct information, in its entirety, but you can't trust the fetch information.Originally posted by Alien88
We know at assignment of the test what version the client is, therefor since it was started on 2.2 it will get retested when we put all those blocks back into the queue, so you might as well expire it and get a new one.
Proud member of the friendliest team around, Team Anandtech!
The Queue is dead! (Or not needed.) Long Live George Woltman!
Non-SSE2 PC's are also, most likely the slowest PC's. That means the WU could have started two or three releases ago. Also it may be months for the current WU to process. My previous PC would have taken a year to process one WU.Originally posted by Ken_g6[TA]
I was afraid of that. At the assignment of a test, my queue sends a fake version number, since it has no idea what client will connect to get the work. The results it sends back do have the correct information, in its entirety, but you can't trust the fetch information.
No, the bug that affects the windows client is different from the one that affects the bsd/linux/beos client.Originally posted by Matt
Please update the news on the main page as this does also affect the FreeBSD/Linux client now.
The news page was updated when I posted the new client concerning the smaller bug: "We have also fixed a minor bug with the Linux and FreeBSD clients and we ask that you upgrade those clients too. Altho the bug is not near as serious as the Windows bug, if you were to abort a test in the first 10 minutes it would lead to an invalid residue."
Correct.. this is what we are going to pretty much do.Originally posted by vjs
I would hope that all of those tests with non-sse v2.2 be redone.
Here is my 0.02 for a plan to consider if you will.
1. Don't remove those tests from the system, let them finish and those of a few people who continue working with version 2.2 con tinue to accept those as well.
I'm sure some people will not be able to upgrade the client etc. (hold on for a rational) And if we simply stop accepting results we loose those computers from the system.
2. Release 2.3, it makes sence that 99% of the people who upgraded to 2.2 will also upgrade to 2.3 in time since 2.2 isn't that old, people should still be working same buildings etc. ( This has already started)
Now here is the fix,
3. Always reassign all tests from suspect clients by simply be readded them to the dropped-tests que, just as easy as deleting those tests from the server.
4. In a couple weeks all the problems from 2.2 will be sorted out and submissions from 2.2 will become almost zero through upgrading, like 1.2 etc.
5. Some of those tests from the dropped que retested with 2.3 will have matching resides with 2.2.
(not all 2.2 is submitting false results correct)
Those tests wouldn't require retesting double-checking ever and those with mismatching resides would simply be added again to error-fix automatically to be tested again later.
Doesn't really sound like a large problem here... we just need a practical solution.
I'd like to thank the sysadmins for being on top of this over the holidays.
What version number does it send?Originally posted by Ken_g6[TA]
I was afraid of that. At the assignment of a test, my queue sends a fake version number, since it has no idea what client will connect to get the work. The results it sends back do have the correct information, in its entirety, but you can't trust the fetch information.
Great!! It's good to see that the system was planned out enough in advance and currently robust enough to handle problems like this.Correct.. this is what we are going to pretty much do.
And thanks for answering my post.
I compiled the client on a different box this time. Apparently, with FreeBSD, you can't run new binaries on old machines.. but you can run new binaries built on old machines on newer machines.Originally posted by Matt
On a different FreeBSD machine, version 5.2.1 I get the error "/libexec/ld-elf.so.1: Shared object "libm.so.3" not found" with the new client, this doesn't occur with 1.2.5 and 2.2.0 just core dumps.
There's a new binary up on the download page. Give it a try on both machines you are having problems with.
There are also reports on my home team that the new release cleared up other issues as well, one member is no longer having issues with their 200-MMX.
Version 1 worked
Version 2.2 Didn't work, faults, errors, etc.
Version 2.3 Works perfect!!!