Page 1 of 2 12 LastLast
Results 1 to 40 of 59

Thread: Windows v2.3.0 CRITICAL UPGRADE

  1. #1

    Exclamation Windows v2.3.0 CRITICAL UPGRADE

    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

  2. #2
    Target Butt IronBits's Avatar
    Join Date
    Dec 2001
    Location
    Morrisville, NC
    Posts
    8,619
    Fixed download link

    Running FINE so far

    BTW, SSE2 Only version runs like a champ on an AMD FX55

  3. #3
    Senior Member
    Join Date
    Dec 2002
    Location
    australia
    Posts
    118

    Unanswered question

    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?

  4. #4

    Re: Unanswered question

    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.

  5. #5
    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

  6. #6
    Senior Member
    Join Date
    Dec 2002
    Location
    australia
    Posts
    118

    Client check

    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.

  7. #7
    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.

  8. #8
    Moderator Joe O's Avatar
    Join Date
    Jul 2002
    Location
    West Milford, NJ
    Posts
    643

    Re: Windows v2.3.0 CRITICAL UPGRADE

    Originally posted by Alien88
    This means that Linux/FreeBSD/BeOS are not affected by the bug.
    --
    Mike Garrison
    But KenG6 did reproduce the error on a Linux machine:
    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

  9. #9

    Re: Re: Windows v2.3.0 CRITICAL UPGRADE

    Originally posted by Joe O
    But KenG6 did reproduce the error on a Linux machine:
    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

  10. #10

    Re: Windows v2.3.0 CRITICAL UPGRADE

    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.
    Will all v2.2.0 tests be reassigned or only those with a false residue?
    Is there a way to check residues?

  11. #11

    Re: Re: Re: Windows v2.3.0 CRITICAL UPGRADE

    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
    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.

    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.

  12. #12
    Former QueueMaster Ken_g6[TA]'s Avatar
    Join Date
    Nov 2002
    Location
    Colorado
    Posts
    184
    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!

  13. #13
    This new client has given me an extra 100k cEM/s on my Athlon XP3000+ Barton, now doing 1.1M cEM/s



  14. #14

    Re: Re: Windows v2.3.0 CRITICAL UPGRADE

    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.

  15. #15
    why the delay in stopping accepting work fom the defective clients? Shouldn't this be done immediatly?

  16. #16
    Originally posted by Keroberts1
    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..

    plus it's the holidays and the majority of us are on vacation and we'd like to relax

  17. #17
    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.

  18. #18
    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?
    I do think it, that it doesn 't matter if you pause or exit the client.

  19. #19
    Moderator vjs's Avatar
    Join Date
    Apr 2004
    Location
    ARS DC forum
    Posts
    1,331
    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.

  20. #20
    Senior Member dmbrubac's Avatar
    Join Date
    Dec 2002
    Location
    Ontario Canada
    Posts
    112
    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!

  21. #21

    FreeBSD / Linux

    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

  22. #22
    www.amdusers.com Beerknurd's Avatar
    Join Date
    Jun 2004
    Location
    Ft Worth, TX
    Posts
    54
    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
    It's where your friends are...

  23. #23
    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?

  24. #24
    Forgotten Member
    Join Date
    Dec 2003
    Location
    US
    Posts
    64
    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.

  25. #25
    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
    Yeah, you'll have to expire the test and get a new block.

  26. #26
    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?
    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.

  27. #27
    Moderator vjs's Avatar
    Join Date
    Apr 2004
    Location
    ARS DC forum
    Posts
    1,331
    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.

  28. #28
    Please update the news on the main page as this does also affect the FreeBSD/Linux client now.



  29. #29
    I just upgraded and now when I try and start the client I get the error "ELF interpreter /libexec/ld-elf.so.1 not found" this didn't happen before.



  30. #30
    Former QueueMaster Ken_g6[TA]'s Avatar
    Join Date
    Nov 2002
    Location
    Colorado
    Posts
    184
    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.
    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.
    Proud member of the friendliest team around, Team Anandtech!
    The Queue is dead! (Or not needed.) Long Live George Woltman!

  31. #31
    Member
    Join Date
    Jul 2004
    Location
    Arlington, TX, USA
    Posts
    41

    Exclamation

    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.
    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.

  32. #32
    Originally posted by Matt
    Please update the news on the main page as this does also affect the FreeBSD/Linux client now.
    No, the bug that affects the windows client is different from the one that affects the bsd/linux/beos client.

    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."

  33. #33
    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.
    Correct.. this is what we are going to pretty much do.

  34. #34
    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.
    What version number does it send?

  35. #35
    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.



  36. #36
    Unholy Undead Death's Avatar
    Join Date
    Sep 2003
    Location
    Kyiv, Ukraine
    Posts
    907
    Blog Entries
    1
    wbr, Me. Dead J. Dona \


  37. #37
    Moderator vjs's Avatar
    Join Date
    Apr 2004
    Location
    ARS DC forum
    Posts
    1,331
    Correct.. this is what we are going to pretty much do.
    Great!! It's good to see that the system was planned out enough in advance and currently robust enough to handle problems like this.

    And thanks for answering my post.

  38. #38
    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.
    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.

    There's a new binary up on the download page. Give it a try on both machines you are having problems with.

  39. #39
    Thanks, this new client works on all my FreeBSD machines, including the one that was core dumping (at least it's working at the moment).



  40. #40
    Moderator vjs's Avatar
    Join Date
    Apr 2004
    Location
    ARS DC forum
    Posts
    1,331
    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!!!

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •