Results 1 to 15 of 15

Thread: Linux client bombs out

  1. #1

    Linux client bombs out

    This whole project seems kinda thin on documentation: I tried starting the linux client and it crashed. I rebooted to windows to try it there and it runs just fine (so it ain't the hardware).

    Is there any kind of information somewhere what kind of speed to expect? Is 7 minutes for 10000 iterations good or bad or what? So I could at least figure if I'm in the right ballpark and my machine is actually doing the right thing? Somehow I wold've expected some kind of README file or something ...

  2. #2
    the linux client is a little manic. try v1 instead of v1.02. i have the old versions still online here

    http://www-personal.engin.umich.edu/~lhelm/

    let me know if that doesn't fix your prob. and sorry for the lack of the README. i should make one of those someday.

    -Louie

  3. #3
    On a related note, does anyone know which Linux client version is best for avoiding the segfault problem?

    Have a teammate who was getting it with, what I assume is the newest client version. Doing the trick with changing the server address didn't help any but going to v 0.97 DID stop the segfaulting.

    Anyone who is running Linux have any practical knowledge/advice on avoiding the linux segfault?

  4. #4
    I tried 1.0 and it worked fine for about one test. It finished, downloaded the next one and segfaulted at 0.6% done. Better than doing it right away, but it was sheer chance that I was there to see it happen and I would've lost production if it had happened overnight...

    And I'm assuming there aren't any wrappers or such that would monitor a client and restart it when necessary?

  5. #5
    I've been running 1.02 on a number of machines for a while. They only appear to hang when the network goes down or sometimes when the server goes down. I haven't seen any seg faults since getting v1.02.

    I've attached my sclient.conf if you want to have a check, but I don't think there's anything unusual about it.

    At the moment I am getting 7 and a half minutes for 10000 iterations on an XP 1800+.
    Attached Files Attached Files

  6. #6
    v1.0 and v 1.01 had problems with seg faults for me but never have had any problems with v1.02

  7. #7
    Interesting. I'd be curious about people's setup -- I'm running RH8.0 on a P4, maybe that has some influence.

    1.02 gets all the way to the "got k and n from cache" then segfaults right away. 1.0 is fine for an entire test, then segfaults just after it's delivered the results and is 0.6% into the next number. Twice now, so I don't think this was just coincidence. Is there a "debugging mode" or such that would generate a good useful trace or something? I'd be happy to take it into that mode on my next exponent just before it uploads...

  8. #8
    If you grab v0.97, I bet it will not seg fault at all. However, it will run a little slower since you are using a P4.

    The problem is related to the dns calls and has to do with poor glibc implementations by linux programmers. Sadly, even static binaries are dependant on glibc for dns calls because of the way linux people have hacked things up recently. If I remember correctly, people with newer installs of linux are experiencing the most problems. The older linux builds, and the newest alpha builds don't have issues.

    -Louie

  9. #9
    Junior Member
    Join Date
    Jan 2003
    Location
    Amsterdam
    Posts
    4
    1.02 works fine (apart from the CLOSE_WAIT connections) on my debian woody system which has libc6-2.2.5 installed.
    debian unstable includes libc6-2.3.1 Is that the offending glibc?

  10. #10
    No, debian unstable works fine for me. I guess it must be older versions causing the problems.

    Just out of interest, why does SoB make DNS calls if you give it an IP rather than sb.pns.net?

    By the way, I think that v1.02 hangs if one of these calls fails (ie. when the local network is down).

  11. #11
    Originally posted by jjjjL

    The problem is related to the dns calls and has to do with poor glibc implementations by linux programmers.
    I'd be willing to buy that for the occasional hang, but the segfaults must be something else, as they're always encountered AFTER I've uploaded a finished n/k pair. It downloads a fresh k/n, starts crunching, gives me exactly two updates (10000 and 20000 iterations) then bombs out. All it shows on the screen is "segmentation violation", nothing else.

    (It didn't hang or crash at all, by the way, when the server went down on the weekend. However that wasn't long enough for my box to finish a complete test...)

    [Edit: I second the question: why would it make DNS cals if it has a numeric IP address at hand already?]

  12. #12
    Bumpage, as there are more threads on this topic and I never noticed any sort of resolution or definitive answer.

  13. #13
    Originally posted by Hawk
    At the moment I am getting 7 and a half minutes for 10000 iterations on an XP 1800+.
    10000 for only 7 1/2 minutes !!!!

    :shocked:

    How to configure to get that fast ? BTW, I'm very new to DF with Linux RH8 and I'm using Xeon2.8........pls advise

    Do we have a handle for this version of df (this 7 minutes version) ?
    Last edited by Hua Luo Han; 03-17-2003 at 09:00 AM.

  14. #14
    Sieve it, baby!
    Join Date
    Nov 2002
    Location
    Potsdam, Germany
    Posts
    959
    Uhm... this is Seventeen or Bust, not Distributed Folding. So an iteration is not the same as the one you know...

  15. #15
    Originally posted by Mystwalker
    Uhm... this is Seventeen or Bust, not Distributed Folding. So an iteration is not the same as the one you know...
    oops ........

Posting Permissions

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