Results 1 to 12 of 12

Thread: Cems/sec slowdown???

  1. #1

    Question Cems/sec slowdown???

    several of my Anandtech teammates and myself are reporting that with the k/n values that we have gotten in the last few days have slowed down the rates significantly...>10% in most cases.

    My rates fell from the low 90's a week ago to the low 80's the last few days, even with a higher n.

    Any suggestions, explanations or is this happening to everyone

    Slatz

  2. #2
    This happened to me also, but since my rankings didn't drop substantially, I suspect that it is fairly uniform. Don't know the reason, though...

  3. #3
    Member
    Join Date
    Nov 2002
    Location
    Haverhill, MA
    Posts
    76
    i notice almost a 20% slow down on one machine but i haven't been able to figure out the slow down on my linux boxen

  4. #4
    Senior Member Frodo42's Avatar
    Join Date
    Nov 2002
    Location
    Jutland, Denmark
    Posts
    299
    Well my computer has not yet slowed down, on the other hand it is a couble of days since I last recieved a new test.

    Perhaps it is because the sieving is falling behind (or at least the file thats included in the version of SB we have)?
    I don't fully understand how the sieving works (anyways not the math part of it), just a wild guess ...

  5. #5
    Member
    Join Date
    Sep 2002
    Location
    London
    Posts
    94
    May be client has changed to longer fft lenght because
    numbers are longer (?). I think that math code is hand written asm and there is several versions of the code and client choose
    right one based on number lenght. System is not optimal, but it is a lot faster than using same code for every lenght.

    This is wild guess also.

    Nuutti

    P.S. SB clien is based on Mersenne95 :
    http://www.mersenne.org/source.htm

  6. #6
    Sieve it, baby!
    Join Date
    Nov 2002
    Location
    Potsdam, Germany
    Posts
    959
    @Frodo42:

    Sieving only eliminates tests, it has no influence on the tests that haven't been sorted out yet and are sent to the SB client.

  7. #7
    nuutti's "wild guess" is the right one.

    same thing happened when we got to this "n" level with k=27653.

    the FFT length just doubled so the tests will all run ~10% slower.

    -Louie

  8. #8
    Sieve it, baby!
    Join Date
    Nov 2002
    Location
    Potsdam, Germany
    Posts
    959
    This also happened 1-2 times before, right?
    At least I sometimes had the impression the rate dropped although the n value increased.

  9. #9
    Member
    Join Date
    Sep 2002
    Location
    London
    Posts
    94
    Probably. I guess that fft size changes when number lenght doubles but it can be denser. It just requies more work to code
    many different fft sizes.

    Nuutti

    P.S. Here is some infotmation what fft means(It is a method to multiple big numbers very fast) :http://www.tasam.com/~lrwiman/FAQ-mers

  10. #10
    Dang. I came over to say that I realized we were into tests where n was greater than ~2.6 million, but people beat me to it.

    BTW, does anyone know at which cross-over the FFT exceeds the 256k L2 of the Tbird and newer Athlon CPUs? If not I will ask the GIMPS guys if they remember the cross-overs that fit into the various levels of L2.

  11. #11
    Member
    Join Date
    Sep 2002
    Location
    London
    Posts
    94
    I made speed test to prime 95 and got following things :
    fft lengths are 1792K, 1536K, 1280K, 1024K, 892K, 768K, 640K, 512K, 448K, 384K, 320K, 256K
    So this might give some picture about fft length changing frequency.

    Yours,

    Nuutti

  12. #12
    we've really got to get this cem/s thing fixed. I can handle even stand to look at my stats, it's just painful.
    www.team-tnt.net

Posting Permissions

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