I am beginning to believe that the problem lies to the way BOINC Manager sends network requests to boinc client, but I am not sure;

BOINC Manager is only a graphical interface for the daemon, boinc.exe
It allows you to tell BOINC what to do by clicking on buttons, instead of needing to type it all through a command line. It doesn't do anything in terms of communications to a network or the internet. That's all done by the daemon (the client).

---

Some good news: I managed to set BOINC as a service using the latest .sh script (I read in the trac that there were some Leopard issues with the service script) and now boinc runs on its own. However, if I manually try network connections through BOINC manager, it's just the same as before. I will have to wait for a task to finish and report on its own to see if I'm gonna get a boinc CLIENT freeze as well.

I have another question. I usually set boinc processor % to 40% in order to keep my Mac in the 50s. I have noticed that, during the BOINC Manager freeze, the processor throttling doesn't work, i.e. it's working until BOINC Managers becomes responsive again at 0% or 100%, whichever happens to be the case at the time of the freeze. As I understand it, the throttling is applied by the client, not by BM. That said, I guess that it's the client that doesn't behave during the time BM seems frozen. On the bottom line stdoutdae is client's log, right? That's where I got this when I asked for project update through the Manager (notice the one minute freeze):

18-Jan-2008 09:19:53 [SETI@home] Sending scheduler request: Requested by user.  Requesting 0 seconds of work, reporting 0 completed tasks
18-Jan-2008 09:20:54 [SETI@home] Task 24fe07ad.2188.15205.4.6.236_1 exited with zero status but no 'finished' file
18-Jan-2008 09:20:54 [SETI@home] If this happens repeatedly you may need to reset the project.
18-Jan-2008 09:20:54 [SETI@home] Restarting task 24fe07ad.2188.15205.4.6.236_1 using setiathome_enhanced version 528
18-Jan-2008 09:20:55 [SETI@home] Task 25ja07ab.29718.270449.8.6.234_0 exited with zero status but no 'finished' file
18-Jan-2008 09:20:55 [SETI@home] If this happens repeatedly you may need to reset the project.
18-Jan-2008 09:20:59 [SETI@home] Scheduler request succeeded: got 0 new tasks

BOINC Manager is only a graphical interface for the daemon, boinc.exe
...

Maybe this thread should move to BOINC core client then...

OK, first task finished. Looks like it's the core's fault after all. Without BM running, as soon as the client tried to start uploading the result, it froze and after a minute the upload started (and completed successfully). At the same time, both SETI workers exited with "zero" status, losing some of their work. The workers started again after the freeze, under different PIDs, which means the other two crashed. However, this happens with Rosetta workers as well. Actually, I take it this is normal, since the workers crash whenever they cannot communicate with the boinc core for some reason, for example when repairing the disk using Disk Utility, that some times hogs the whole system for a few minutes.

Part of stdoutdae.txt follows:

18-Jan-2008 11:42:40 [SETI@home] Computation for task 25ja07ab.29718.270449.8.6.234_0 finished
18-Jan-2008 11:42:41 [SETI@home] Starting 24fe07ad.2188.15205.4.6.242_1
18-Jan-2008 11:42:41 [SETI@home] Starting task 24fe07ad.2188.15205.4.6.242_1 using setiathome_enhanced version 528
18-Jan-2008 11:42:42 [SETI@home] Started upload of 25ja07ab.29718.270449.8.6.234_0_0
18-Jan-2008 11:43:44 [SETI@home] Task 24fe07ad.2188.15205.4.6.242_1 exited with zero status but no 'finished' file
18-Jan-2008 11:43:44 [SETI@home] If this happens repeatedly you may need to reset the project.
18-Jan-2008 11:43:44 [SETI@home] Restarting task 24fe07ad.2188.15205.4.6.242_1 using setiathome_enhanced version 528
18-Jan-2008 11:43:45 [SETI@home] Task 24fe07ad.2188.15205.4.6.236_1 exited with zero status but no 'finished' file
18-Jan-2008 11:43:45 [SETI@home] If this happens repeatedly you may need to reset the project.
18-Jan-2008 11:43:50 [SETI@home] Finished upload of 25ja07ab.29718.270449.8.6.234_0_0

This looks a lot like the freezing flaw that would need rewrite of many things to get fixed.

---

Indeed, looks like the same to me... What puzzles me, though, is that I tried BM 5.4.x, which reportedly uses async DNS, and I noticed the exact same behavior. Additionally, I can find no apparent reason as to why this DNS-related freeze would kick-in just in Leopard on my NEW Macbook (Santa Rosa mb), since I have several Macs and XPs around and none has this issue. I also have a MacBook Pro with Leopard, no prob. at all!

The only thing I can think of is that there is a different system software component that handles such requests on a Santa Rosa - based intel Mac, that gives back to the core client different output that the previous ones used to. However, I still haven't been able to install BOINC on another Santa-Rosa Mac to see what will happen...

I guess I'll be waiting for a BOINC update or even a System Software update for what I know...

Asynch DNS is only part of the puzzle - another issue is that if the core client spends significant time on any task, then the manager will freeze.

The solution would be to make all communication between the manager and client asynchronous, and I seem to recall something in the Boinc V6 development which does exactly this.

---

Asynchronous communication between manager, core client and project clients is always a good idea, although somehow complex, I guess.

However, I still believe it would be easier (and faster) to find and fix the bug that creates the issue. I mean, it's very rarely seen (for now at least), on specific systems and has to do with Leopard and Santa Rosa motherboard (at least from where I see it).

Incorporating full multi-threading / asynchronous I/Os would just make the whole project look like it works fine, but it won't be.

OK, I think I have some more information, extremely useful this time... Looks like it's a DNS-related issue, after all. Here's the new information:

All the above behavior happens as long as I have not set any custom DNS settings in my network preference. OS X uses my router as a DNS server, which should work OK and actually does on any network stuff except from BOINC CC. Here's the host -v output in this case (DNS Server: 192.168.0.1):

Thanars-MacBook:~ thanar$ host -v boinc.berkeley.edu
Trying "boinc.berkeley.edu"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49780
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;boinc.berkeley.edu.		IN	A

;; ANSWER SECTION:
boinc.berkeley.edu.	3600	IN	CNAME	boinc.SSL.berkeley.edu.
boinc.SSL.berkeley.edu.	73281	IN	A	128.32.18.189

Received 76 bytes from 192.168.0.1#53 in 425 ms
Trying "boinc.SSL.berkeley.edu"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12023
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;boinc.SSL.berkeley.edu.		IN	AAAA

Received 40 bytes from 192.168.0.1#53 in 242 ms

If I add my service provider's DNS information in the network preferences, however, BM and BCC begin to behave correctly and -after a few network connection tries that give a 10-second lag- connections start working like a charm. I also noticed that the host-v output is different this time:

Thanars-MacBook:~ thanar$ host -v boinc.berkeley.edu
Trying "boinc.berkeley.edu"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16488
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;boinc.berkeley.edu.		IN	A

;; ANSWER SECTION:
boinc.berkeley.edu.	3508	IN	CNAME	boinc.SSL.berkeley.edu.
boinc.SSL.berkeley.edu.	73189	IN	A	128.32.18.189

Received 76 bytes from 213.5.17.21#53 in 630 ms
Trying "boinc.SSL.berkeley.edu"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40248
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;boinc.SSL.berkeley.edu.		IN	AAAA

Received 40 bytes from 213.5.17.21#53 in 692 ms
Trying "boinc.SSL.berkeley.edu"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55626
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;boinc.SSL.berkeley.edu.		IN	MX

;; ANSWER SECTION:
boinc.SSL.berkeley.edu.	86400	IN	MX	5 setimail.SSL.berkeley.edu.

Received 65 bytes from 213.5.17.21#53 in 787 ms

Any ideas?

OK, I think I have some more information, extremely useful this time... Looks like it's a DNS-related issue, after all.

I've posted BOINC development version 5.10.40 for the Mac to the Alpha Download Page. This version does asynchronous DNS lookups. Please post here to let me know if it fixes your problem.

Cheers,
--Charlie

---

Charlie Fenton
BOINC / SETI@home Macintosh & Windows Programmer

Sorry Charlie, I've been away for a while... Just saw your post, so I will try 5.10.40 under such DNS settings, that push current versions to the limit. Will let you know as soon as I have more information.

--just noticed that 5.10.41 is out as well. I guess it comes with async DNS lookups, right?

Sorry Charlie, I've been away for a while... Just saw your post, so I will try 5.10.40 under such DNS settings, that push current versions to the limit. Will let you know as soon as I have more information.

--just noticed that 5.10.41 is out as well. I guess it comes with async DNS lookups, right?

Yep.

---

Charlie Fenton
BOINC / SETI@home Macintosh & Windows Programmer

After some extensive testing, I can almost definitely say that BM no longer freezes and the clients no longer exit unexpectedly while under network activity, since I installed 5.10.41 last night. I tried the same DNS configurations that used to create a couple of such problems in pre-.40 versions of BOINC.

One down, plenty to do then I guess... Keep up the great work everyone!

I've had similar problems on my Emac os10.3.9/with dialup.....Comp errors, hanging, and temporary stalling everytime I upgrade beyond 5.2.13 . I keep thinking it'll be better, but so far it never has been. I'm just hoping that I'll be able to continue using 5.2.13 I'm getting ready to uninstall 5.10.34, which is as big a disaster for me as the other versions beyond 5.2. I'm just a normal person who wants to support these programs (have been w seti for many years) but who doesn't have time or expertise to keep troubleshooting this stuff.....I just ask for something simple and functional. BTW I have added my wife's WindowsXP machine to my recently account with no problems...hmmm. Denny

5.10.42 continues to work just fine on my configuration... No network-related issues whatsoever. I guess the culprit has been found to be sync DNS lookups; at least for now... Looks like an FC to me...

Regarding Dennis' problem... 5.10.40 up have been OK for me, should be for you as well, unless your problem is a completely different story. Even on pre-5.10.40 installations, when I had manually entered my ISP's DNS servers, things were a lot better. Maybe you should try it out as well, although I don't remember how dial-up connections used to work...

As far as your comment goes I would like to add that this project, being dynamic and open, is excused regarding flaws on new versions; In the bottom line, there is always an older build for you to try if you are having problems with the new one. I've had issues on my widows machines a few months ago as well, that forced me to switch back to 5.9.x versions, but the eventually ceased to exist.

5.10.42 continues to work just fine on my configuration... No network-related issues whatsoever. I guess the culprit has been found to be sync DNS lookups; at least for now... Looks like an FC to me...

Regarding Dennis' problem... 5.10.40 up have been OK for me, should be for you as well, unless your problem is a completely different story. Even on pre-5.10.40 installations, when I had manually entered my ISP's DNS servers, things were a lot better. Maybe you should try it out as well, although I don't remember how dial-up connections used to work...

As far as your comment goes I would like to add that this project, being dynamic and open, is excused regarding flaws on new versions; In the bottom line, there is always an older build for you to try if you are having problems with the new one. I've had issues on my widows machines a few months ago as well, that forced me to switch back to 5.9.x versions, but the eventually ceased to exist.

No criticism of the projects or the people involved intended. I understand that the only way to not fail occasionally is to not try. I'm just frustrated because I don't have the tech expertise to readily analyze the problems I am having that are affecting my installation/operation of newer Boinc versions. On the bright side, I have become much more proficient in uninstalling/reinstalling var versions of Boinc. I'll probably give 5.10.40 (or higher) a try in a week or so.