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 ...
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?
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?
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+.
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...
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.
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?
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?]
Posting Permissions
Reply With Quote
