Thank's Ned I was refering to the BUTTONS

---

Much more user friendly

How is something that doesn't seem to work a large percentage of the time (recently, anyway) user friendly in any way, shape or form????

Follow the thread to the previous message. He's referring to the buttons to automatically add BBCODE tags.

If you aren't referring to the buttons that add BBCODE tags, then you're responding to the wrong topic.

Edit:

I've said this many times, and this is a good time to repeat it.

If you are referring to the servers being out of work, that isn't meant to be "user friendly" -- those transactions are between the BOINC client and the BOINC servers.

SETI strongly suggests that you crunch for more than one project, so that during lean times here you will not run out.

Alternately, you can shut down for a day. The work assigned (but not yet downloaded) will be here tomorrow -- or sooner.

... but I'd suggest another project, or a bigger cache, or both.

Actually, I was referring to the (apparent) fact that I am not getting tasks d/l that I have been (supposedly) handed by the servers, at least if the BOINC Tasks and Transfers tabs are correct. And I had already shut down this machine for most of a day, earlier.

<snark/> And another project didn't invite me back, SETI did </snark>

---

Much more user friendly

How is something that doesn't seem to work a large percentage of the time (recently, anyway) user friendly in any way, shape or form????

Follow the thread to the previous message. He's referring to the buttons to automatically add BBCODE tags.

If you aren't referring to the buttons that add BBCODE tags, then you're responding to the wrong topic.

Edit:

I've said this many times, and this is a good time to repeat it.

If you are referring to the servers being out of work, that isn't meant to be "user friendly" -- those transactions are between the BOINC client and the BOINC servers.

SETI strongly suggests that you crunch for more than one project, so that during lean times here you will not run out.

Alternately, you can shut down for a day. The work assigned (but not yet downloaded) will be here tomorrow -- or sooner.

... but I'd suggest another project, or a bigger cache, or both.

Actually, I was referring to the (apparent) fact that I am not getting tasks d/l that I have been (supposedly) handed by the servers, at least if the BOINC Tasks and Transfers tabs are correct. And I had already shut down this machine for most of a day, earlier.

<snark/> And another project didn't invite me back, SETI did </snark>

I know what you were referring to -- but if you review the thread you'll see that the post you quoted is about something different (and much more user friendly).

As for work: I don't know what you're talking about, as I've been able to get work within the past hour.

Could it be a setting? Could you have an inappropriate app_info.xml, maybe left over from before? Is it impatience?

I don't know. What I do know is that a very small, dedicated staff is working very hard to keep things running smoothly, and being snarky doesn't make a difference either way.

---

Thank's Ned I was refering to the BUTTONS

Yep. I followed the thread back and it was IOTTMCO.

The buttons are much more user friendly. I could be snarky and complain that they don't work if you block scripting, but that's my choice and not something wrong with the project.

---

Much more user friendly

How is something that doesn't seem to work a large percentage of the time (recently, anyway) user friendly in any way, shape or form????

Follow the thread to the previous message. He's referring to the buttons to automatically add BBCODE tags.

If you aren't referring to the buttons that add BBCODE tags, then you're responding to the wrong topic.

Edit:

I've said this many times, and this is a good time to repeat it.

If you are referring to the servers being out of work, that isn't meant to be "user friendly" -- those transactions are between the BOINC client and the BOINC servers.

SETI strongly suggests that you crunch for more than one project, so that during lean times here you will not run out.

Alternately, you can shut down for a day. The work assigned (but not yet downloaded) will be here tomorrow -- or sooner.

... but I'd suggest another project, or a bigger cache, or both.

Actually, I was referring to the (apparent) fact that I am not getting tasks d/l that I have been (supposedly) handed by the servers, at least if the BOINC Tasks and Transfers tabs are correct. And I had already shut down this machine for most of a day, earlier.

<snark/> And another project didn't invite me back, SETI did </snark>

I know what you were referring to -- but if you review the thread you'll see that the post you quoted is about something different (and much more user friendly).

As for work: I don't know what you're talking about, as I've been able to get work within the past hour.

Could it be a setting? Could you have an inappropriate app_info.xml, maybe left over from before? Is it impatience?

I don't know. What I do know is that a very small, dedicated staff is working very hard to keep things running smoothly, and being snarky doesn't make a difference either way.

You are right about the original quote - my bad.

As far as BOINC 6.6.36 goes, I have changed no settings (except queue length, from 2 days -> 5 days) for several days; it was working fine for a while after the Tuesday PM, then stopped actual d/l and u/l of Tasks. As I said before, I have about 50 tasks trying to d/l...

EDIT: I know the staff is working hard, but it is frustrating for me (as well as others) to be caught in the midst of whatever-this-is.

---

I don't know. What I do know is that a very small, dedicated staff is working very hard to keep things running smoothly, and being snarky doesn't make a difference either way.

You are right about the original quote - my bad.

As far as BOINC 6.6.36 goes, I have changed no settings (except queue length, from 2 days -> 5 days) for several days; it was working fine for a while after the Tuesday PM, then stopped actual d/l and u/l of Tasks. As I said before, I have about 50 tasks trying to d/l...

EDIT: I know the staff is working hard, but it is frustrating for me (as well as others) to be caught in the midst of whatever-this-is.

Why be frustrated when the project is doing exactly what they have promised?

They have always promised that there will be outages, and there will be time when there is no work. They've suggested running BOINC on computers that will be on anyway. BOINC can carry a large cache (to bridge outages) and BOINC handles multiple projects so that projects don't need 99.999% reliability.

If you want to run computers just to crunch, then you are certainly welcome, but you do so at your own risk.

If you're frustrated, it is because your expectation is not what the project promises to deliver.

I know I'm not a big cruncher by any means, but I've always got work, and I turn my computers off and on based solely on my needs, not SETI or BOINC.

Sorry if that isn't what you wanted to hear.

---

Me too.

Gah!

---

Me too.

Gah!

I'm saying very much the opposite.

---

As far as BOINC 6.6.36 goes, I have changed no settings (except queue length, from 2 days -> 5 days) for several days; it was working fine for a while after the Tuesday PM, then stopped actual d/l and u/l of Tasks. As I said before, I have about 50 tasks trying to d/l...

EDIT: I know the staff is working hard, but it is frustrating for me (as well as others) to be caught in the midst of whatever-this-is.

If you are still having issues at this time, Upload download Problems.
Stop and ReStart BOINC. I had two machine that were stuck in that loop... If it is a Service Mode/Protected install make sure you stop the Service.

The other things taht could be affecting dowloads could be as Matt has added the other download server back into the mix. DNS could be/is somewhat whacked out.
* Shutdown BOINC, open a command windows and type ipconfig /flushdns Wit about 30 seconds and restart BOINC. Then force a manual update.

Regards

---

Please consider a Donation to the Seti Project.

As far as BOINC 6.6.36 goes, I have changed no settings (except queue length, from 2 days -> 5 days) for several days; it was working fine for a while after the Tuesday PM, then stopped actual d/l and u/l of Tasks. As I said before, I have about 50 tasks trying to d/l...

EDIT: I know the staff is working hard, but it is frustrating for me (as well as others) to be caught in the midst of whatever-this-is.

If you are still having issues at this time, Upload download Problems.
Stop and ReStart BOINC. I had two machine that were stuck in that loop... If it is a Service Mode/Protected install make sure you stop the Service.

The other things taht could be affecting dowloads could be as Matt has added the other download server back into the mix. DNS could be/is somewhat whacked out.
* Shutdown BOINC, open a command windows and type ipconfig /flushdns Wit about 30 seconds and restart BOINC. Then force a manual update.

Regards

eh Pappa - shouldn't you also type: ipconfig /registerdns AFTER the flushdns and BEFORE restarting . . .

---

BOINC Wiki . . .

Science Status Page . . .

eh Pappa - shouldn't you also type: ipconfig /registerdns AFTER the flushdns and BEFORE restarting . . .

Only if you're running Active Directory. It has nothing to do with DNS in the real world.

---

As far as BOINC 6.6.36 goes, I have changed no settings (except queue length, from 2 days -> 5 days) for several days; it was working fine for a while after the Tuesday PM, then stopped actual d/l and u/l of Tasks. As I said before, I have about 50 tasks trying to d/l...

EDIT: I know the staff is working hard, but it is frustrating for me (as well as others) to be caught in the midst of whatever-this-is.

If you are still having issues at this time, Upload download Problems.
Stop and ReStart BOINC. I had two machine that were stuck in that loop... If it is a Service Mode/Protected install make sure you stop the Service.

The other things taht could be affecting dowloads could be as Matt has added the other download server back into the mix. DNS could be/is somewhat whacked out.
* Shutdown BOINC, open a command windows and type ipconfig /flushdns Wit about 30 seconds and restart BOINC. Then force a manual update.

Regards

eh Pappa - shouldn't you also type: ipconfig /registerdns AFTER the flushdns and BEFORE restarting . . .

IPCONFIG /REGISTERDNS is only needed if you want to update your Host A record to your DNS server, which has nothing to do with flushing your local DNS resolver cache.

So no, you do not have to type IPCONFIG /REGISTERDNS each time you flush it.

---

eh Pappa - shouldn't you also type: ipconfig /registerdns AFTER the flushdns and BEFORE restarting . . .

Only if you're running Active Directory. It has nothing to do with DNS in the real world.

I think I would argue this one with you Ned. Its not for AD only, but for any server that supports DNS Dynamic Updates, which is mostly associated with local networks, and very often ignored by ISPs. The only reason why its ignored by your ISP is because your ISP actually communicates with your "modem"/router. This is why if you change "modems" or routers with your ISP, you usually have to force a reboot/reset to get it to work, because the ISP expects the same PHY address each time and the reset sends a sort of /REGISTERDNS to get things working again.

All /REGISTERDNS does is forces an update of your DNS Server's Host A record pertaining to your computer's address. /REGISTERDNS is mostly only useful if you change your IP address manually and you would like to update the record immediately without a reboot.

It does have uses with DNS in the real world because it ensures that Host A records, which will usually get updated automatically, remains accurate. For instance, changing the IP address of a member web server and wanting to update its Host A record on the primary DNS server on the network so that, even for up to 5 minutes it won't be inaccurate.

---

The only reason why its ignored by your ISP is because your ISP actually communicates with your "modem"/router.

When I pick up my home phone and dial the support number for "my" ISP, my office phone rings (home phone on line 2, office phone on line 1).

If (wearing my ISP hat) it needs to be in DNS (like the A records for the upload/download servers) it needs a static IP.

If it has a dynamic IP, it's a workstation on a LAN and probably shouldn't be visible beyond the LAN.

I see lots of strange problems caused by "LAN" DNS and public DNS for a company trying to work in the same namespace. I have a number of customers who can't see their own web sites because their "LAN Consultant" put their domain name in Active Directory.

BOINC won't care if your machine has an A record or not -- IPCONFIG /REGISTERDNS will not update the ssl.berkeley.EDU zone.

---

Pappa:
Dr. C.E.T.I.:

I tried your suggestions, but they didn't help. My other machine, which had a large work queue is still working on that, but having similar problems - can't d/l. It had a couple of dead u/l in Transfers tab, which Retry pushed up, but also has some d/l in that tab, and they won't work with Retry - just cycle through to "Retry in xx:yy:zz".

---

eh Pappa - shouldn't you also type: ipconfig /registerdns AFTER the flushdns and BEFORE restarting . . .

Only if you're running Active Directory. It has nothing to do with DNS in the real world.

I think I would argue this one with you Ned. Its not for AD only, but for any server that supports DNS Dynamic Updates, which is mostly associated with local networks, and very often ignored by ISPs.

All /REGISTERDNS does is forces an update of your DNS Server's Host A record pertaining to your computer's address. /REGISTERDNS is mostly only useful if you change your IP address manually and you would like to update the record immediately without a reboot.

It does have uses with DNS in the real world because it ensures that Host A records, which will usually get updated automatically, remains accurate. For instance, changing the IP address of a member web server and wanting to update its Host A record on the primary DNS server on the network so that, even for up to 5 minutes it won't be inaccurate.

I am sitting behind a Firewall/Router to Cable. I do not have an internal WINS or DNS servers active as I have not brought the Domain Controller back online.

Generally "ipconfig /flushdns" is to blow out my "resolver cache" on "this machine." This fits with 99.x% of the users.

If the above mentioned machines were active on my network then /registerdns would let WINS and the Others know something has happened and start a round of updates. The DNS Server would have pointers to Seti's DNS Servers (we won't go into that detail)

---

Please consider a Donation to the Seti Project.

If it has a dynamic IP, it's a workstation on a LAN and probably shouldn't be visible beyond the LAN.

I don't know about that. Strictly speaking maybe, but there are a handful of situations I can think of where 'other than static IP address servers' need to be accessed by other employees and therefore need to be visible in DNS. One scenario would be employee printer sharing. Another would be a local intranet web server where the DHCP or DNS Server fails, and is subsequently restored and you have employees calling on the internal help desk line complaining that they can't access resources. The easy and usual answer is to take a coffee break and it'll "magically" be there soon, but for more important employees, such as the guy who signs my paycheck, I tend to use a few extra tools such as /REGISTERDNS to get it up and running quickly for him.

I see lots of strange problems caused by "LAN" DNS and public DNS for a company trying to work in the same namespace. I have a number of customers who can't see their own web sites because their "LAN Consultant" put their domain name in Active Directory.

Sounds like their "LAN Consultant" didn't research everything thoroughly enough.

BOINC won't care if your machine has an A record or not -- IPCONFIG /REGISTERDNS will not update the ssl.berkeley.EDU zone.

Fully agreed. Using /REGISTERDNS does not somehow reload valid entires into the local resolver cache. They will get reloaded automatically through the normal lookup process (and hopefully not through a poisoned source!).

---

If it has a dynamic IP, it's a workstation on a LAN and probably shouldn't be visible beyond the LAN.

I don't know about that. Strictly speaking maybe, but there are a handful of situations I can think of where 'other than static IP address servers' need to be accessed by other employees and therefore need to be visible in DNS. One scenario would be employee printer sharing. Another would be a local intranet web server where the DHCP or DNS Server fails, and is subsequently restored and you have employees calling on the internal help desk line complaining that they can't access resources. The easy and usual answer is to take a coffee break and it'll "magically" be there soon, but for more important employees, such as the guy who signs my paycheck, I tend to use a few extra tools such as /REGISTERDNS to get it up and running quickly for him.

Shared printers should not be publicly available -- I should not be able to print to your printer (I definitely should not be able to try and print solid black on your printer, not that I'd even think of such a thing).

If a workstation needs to access a shared resource, it should be on the same LAN, or it should be using some technology that extends the LAN to his location (i.e. a VPN).

Anything else is too open to abuse.

Your other examples are also LAN examples -- and while I guess I might allow that we're talking about the "real world" in those cases, it's a relatively small "real world" compared to the one that starts at the dot.

---

Pappa:
Dr. C.E.T.I.:

I tried your suggestions, but they didn't help. My other machine, which had a large work queue is still working on that, but having similar problems - can't d/l. It had a couple of dead u/l in Transfers tab, which Retry pushed up, but also has some d/l in that tab, and they won't work with Retry - just cycle through to "Retry in xx:yy:zz".

The quick look shows that both machines are Vista Ultimiate. I sould ask how they are connected to the internet and Brand names of the router BOINC version etc.

So depending on "timing" if boinc was stopped on both machines and you flushed DNS it should have dumped IP's that would have been held on the local machine. All I can say is that potentially your Router to the Internet has cached something that is incorrect.

It this is the case, then stopping BOINC, ipconfig /flushdns then before you start anything... GO over to the Router and unplug power for 20 seconds. Plug power back in and allow it to reconnect to the Internet. Then on your machine open a web browser and type in setiathome.berkeley.edu

This is overkill, but you could then in the same CMD window type ipconfig /displaydns and then scroll until you find the record for Seti which would look something like this.

setiweb.ssl.berkeley.edu
----------------------------------------
Record Name . . . . . : setiweb.ssl.berkeley.edu
Record Type . . . . . : 5
Time To Live . . . . : 277
Data Length . . . . . : 4
Section . . . . . . . : Answer
CNAME Record . . . . : setiathome.ssl.berkeley.edu

Then start BOINC and press the Update button. It knows the IP address for the Seti DNS Servers.

setiboinc.ssl.berkeley.edu
----------------------------------------
Record Name . . . . . : setiboinc.ssl.berkeley.edu
Record Type . . . . . : 1
Time To Live . . . . : 288
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 208.68.240.20

Last but not least, restart your computers and then unplug the Router for 20 seconds.

Then start the transfer retries, if still get something like this...

6/24/2009 4:10:00 PM SETI@home Beta Test [error] File 03ja09ad.8874.7434.8.11.71 has wrong size: expected 375329, got 0

The system is still overloaded and having handoff errors from the scheduler to the download server(s).

---

Please consider a Donation to the Seti Project.

I don't know what you are talking about..

Flush here.. flush there.. ;-)


All my downloads.. now maybe ~ 300 in the BOINC overview.. are all with errors.

Wrong size or http or what ever.. errors.


A reboot of the PC didn't helped.

---