Unless someone has kicked the server, I have not had any problems with uploads / downloads at all.

Had 2 work units earlier today that required a manual "retry now" but went through straight away once I did that.

I have a large enough cache to keep me going and that is fine until either Monday or if something major needs sorting until the outage Tuesday.

Patience I think is the key to getting uploads through, they are slow at times but they do work eventually. Downloaded 4 work units on a test and they came straight away.

---

Well, FWIW my 6 Windoz machines are now OK in all respects as is Uploading and Reporting on all 10 machines. However 3 of my 4 Linux boxes still cannot recieve a single byte of download. The machines complete work, upload results, report, and ask for more work per normal. More work is "promised" but it just goes into the building queue of DL's and nothing at all comes down the wire. They're getting your basic "Temporarily failed download of . . . : http error." I've done all of the usual things like restart the client, warm boot, cold boot, I even power cycled the router. I flushed DNS, at least I think, I'm NOT a linux person really, but still nothing.

I've finally set NNT and will wait 24 hours in case it is a DNS thing and something needs to propogate or time out.

It's hard to believe that 3 boxes broke at the same time on my end when nothing was changed on any of them, but it's also hard to believe that, if it's on Berkeley's end, the masses are not screaming bloody murder in Number Crunching. At this point I don't know what to think. Also, why is one Linux box OK (after the backlog cleared up) but the others are not? They are all running the same distro.

The only thing that comes to mind is I seem to remember something similar way back when there was some trouble with the even/odd work distribution scheme and one of the two stopped feeding. But why only the Linux boxes? Wierd.

Same for me, windows ok/linux not ok.

I can third it, Windows, Mac: Fine, Linux: nothing.

---

I have had no work for at least 2 days. Is it the server or is it a Debt sort of thing? How do I find out if it is a LTD(?)?

---

Vista 64bit
Radeon HD5700
4GB RAM
AMD Athlon II x4 640 Processor 3.23GHz

I have had no work for at least 2 days. Is it the server or is it a Debt sort of thing? How do I find out if it is a LTD(?)?

Best to post this question in the Number Crunching forum for help......

Post there, and copy some of the Boinc messages that it sends you when it does a work request....

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

208.68.240.13 seems to be not responding
and the boinc client does not attempt to connect to the secondary IP 208.68.240.18

the *temporary* solution is to modify /etc/hosts adding one line:
208.68.240.18 boinc2.ssl.berkeley.edu.

208.68.240.13 seems to be not responding
and the boinc client does not attempt to connect to the secondary IP 208.68.240.18

the *temporary* solution is to modify /etc/hosts adding one line:
208.68.240.18 boinc2.ssl.berkeley.edu.

That'll be Vader again.

Note that according to the Server Status Page, there's very little work available at the moment (disks full, probably), so even the temporary fix - which seems like a good one - won't necessarily get you any.

That'll be Vader again.

indeed, like mentioned before...

Note that according to the Server Status Page, there's very little work available at the moment (disks full, probably), so even the temporary fix - which seems like a good one - won't necessarily get you any.

...at least it helps to get those through that are stuck.

The main question is why the round robin dns does not work for some clients.
Here's what I experience:
For me all my win-clients do download, which means that they got bane in their (windows internal) dns cache.
The linux clients in office do download after some trys - those are connected directly to dns-server and get one time vader, next time bane.
My linux-box at home doesn't connect - this one gets dns-infomation from a router which seems to have a cache and vader is in there.
So what's the difference between those two caches? (windows / router)

I read about a internal dns cache in the boinc-client... what about that one?

Wouldn't it be easier to store those two IPs in client_state.xml (instead of the single dns-name) and let the boinc-client do the round robin stuff?

---

mic.

Somehow, even though I'm set to "English" as my language of choice, when I came to the "technical news" page, all my headers turned to Spanish!

---

.

Hello, from Albany, CA!...

Somehow, even though I'm set to "English" as my language of choice, when I came to the "technical news" page, all my headers turned to Spanish!

I wonder if that in any way is related to the page load stalls?

---

208.68.240.13 seems to be not responding
and the boinc client does not attempt to connect to the secondary IP 208.68.240.18

the *temporary* solution is to modify /etc/hosts adding one line:
208.68.240.18 boinc2.ssl.berkeley.edu.

That'll be Vader again.

Note that according to the Server Status Page, there's very little work available at the moment (disks full, probably), so even the temporary fix - which seems like a good one - won't necessarily get you any.

Well, there is no problem with scheduler - it assigned to my quadcore ~40 new units, which are currently waiting (with less or more luck) to be downloaded. And since my previous post it downloaded another 30 (or so) units. Therefore it is a problem with downloading, not with little work. Maybe something stuck with harddrives again.

Somehow, even though I'm set to "English" as my language of choice, when I came to the "technical news" page, all my headers turned to Spanish!

I wonder if that in any way is related to the page load stalls?

Dunno, but it doesn't look like Matt turned off the Google Analytics thingy yet....

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

The main question is why the round robin dns does not work for some clients.

Here is the answer:

The relevant RFCs say that the record order in DNS should be randomized to help balance load.

Trouble is, the RFC does not clearly state who is supposed to randomize:

• Is it the server?
  
• Is it the resolver?
  
• Is it the client?
  

It appears that many DNS server developers have assumed that the resolver or client will randomize. Resolver developers have assumed that what they get is already randomized, or that the client will, and many clients assume that what they get is already suitably randomized.

This is particularly true in most versions of Windows.

---

This does not look like a DNS problem to me. I tried with various DNSes (my ISP's and open DNSes) and also used /etc/hosts to hard bind boinc2.ssl.berkeley.edu with 208.68.240.13 then with 208.68.240.18, and the result is always the same: HTTP error while BOINC is trying to download the already granted work.

I can also ping both 208.68.240.13 and 208.68.240.18 without problem.

I even reduced the MTU (down to 1024 bytes), just in case it would be the result of an added VPN or encapsulation on the route, but here again to no avail... It has been almost 48 hours that the downloads suddenly stopped working for Seti (the other projects are fine in this respect).

Dunno, but it doesn't look like Matt turned off the Google Analytics thingy yet....

I didn't turn it off because I didn't turn it on. Reminder: Eric and Jeff and Bob do stuff here too - just because I'm the only one reporting around here doesn't mean I'm in charge or even know what they are doing all the time.

Anyway... looks like the root drive on vader filled up again, so half the downloads have been choked. Mounts are all messed up, I'm rebooting now, etc.

- Matt

---

-- BOINC/SETI@home network/web/science/development person
-- "Any idiot can have a good idea. What is hard is to do it." - Jeanne-Claude

Looks like Luke got Vader

---

It appears that many DNS server developers have assumed that the resolver or client will randomize. Resolver developers have assumed that what they get is already randomized, or that the client will, and many clients assume that what they get is already suitably randomized.

As far as the servers are conserned bind does ramdomize. In combination with linux client that works out fine.
Problems arise when caches on resolver/client side come into play.

Anyway, vader seems to find it hard to come back to live...

---

mic.

Dunno, but it doesn't look like Matt turned off the Google Analytics thingy yet....

I didn't turn it off because I didn't turn it on. Reminder: Eric and Jeff and Bob do stuff here too - just because I'm the only one reporting around here doesn't mean I'm in charge or even know what they are doing all the time.

Anyway... looks like the root drive on vader filled up again, so half the downloads have been choked. Mounts are all messed up, I'm rebooting now, etc.

- Matt

Thanks for the weekend support, Matt.

. . . Thanks for takin' the time to explain Matt

---

BOINC Wiki . . .

Science Status Page . . .