Thanks to Each of You for the Explainations - Much Appreciated

---

BOINC Wiki . . .

Science Status Page . . .

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.

This is where a 10 Day Cache is a Killer. What I suspect in your cache is that your ISP is very slow in updating DNS. I will have to think about how we got around this before. Matt had set a Very short TTL and there were many IPS's that did not honor it.

When I do Lookups on both download servers I get the Berkeley IP (blocked)) and the External IP that the scheduler would handoff.

So as I have sent a note Matt, it would be patient for a bit.

---

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.

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.

The DNS system is used by many companies internally for many reasons. It isn't exclusive to the internet, even though it was originally designed for it. There are ways of segregating the internal DNS system from the external (or Internet) DNS system. Even though I have all my computers on my LAN registered in my local DNS, doesn't mean they are accessible through the internet.

Some companies even run their own "root" servers if they do not want their employees using the internet, though that's quite rare these days but not unheard of.

---

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.

The DNS system is used by many companies internally for many reasons. It isn't exclusive to the internet, even though it was originally designed for it. There are ways of segregating the internal DNS system from the external (or Internet) DNS system. Even though I have all my computers on my LAN registered in my local DNS, doesn't mean they are accessible through the internet.

Some companies even run their own "root" servers if they do not want their employees using the internet, though that's quite rare these days but not unheard of.

setiboincdata.ssl.berkeley.EDU isn't on a corporate LAN, so the LAN discussion, while interesting, doesn't apply to "why can't I upload/download."

---

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.

The DNS system is used by many companies internally for many reasons. It isn't exclusive to the internet, even though it was originally designed for it.

Some companies even run their own "root" servers if they do not want their employees using the internet, though that's quite rare these days but not unheard of.

Actually I Love this!

For DNS to work properly in Windows AD, the person configuring it has to have an understanding of DNS and then configuration of DNS as it publishes to the world (infrastructure). As far as I know that part is well documented in DNS and Bind. While Windows AD takes care of a "lot" of things you stil have to know how DNS works.

For the AD Domains for World Web Sites that gets a little trickier. The common problem as to why they are not visible is AD DNS is not allowed to talk to the Gateway (two way). Pick your misconfigured router/firewall/dns. If the Primary Name Server is unaccessable then it is DEAD! Yes there are other even more PhooPahsss or tricks... LOL

---

Please consider a Donation to the Seti Project.

Well, I took the suggestion about shutting down my SETI machines, recycling my router, etc. I'm very pleased to report that it worked!!!!

Thanks to all for being so helpful, even if I was a little crabby earlier in the thread. (Well, maybe more than a litlle...).

---

This is where a 10 Day Cache is a Killer. What I suspect in your cache is that your ISP is very slow in updating DNS. I will have to think about how we got around this before. Matt had set a Very short TTL and there were many IPS's that did not honor it.

When I do Lookups on both download servers I get the Berkeley IP (blocked)) and the External IP that the scheduler would handoff.

So as I have sent a note Matt, it would be patient for a bit.

Sorry.. I would if BOINC could..

BOINC V6.6.36 can't manage work cache > ~ 3,500 WUs.
[If you go over this size.. like I posted.. BOINC go crazy.]
http://setiathome.berkeley.edu/forum_thread.php?id=54289


For some months I posted here at the SETI@home forum also in the BOINC/dev forum that > BOINC V6.6.11 can't manage > ~ 2,500 WU cache.
CUDA performance went very bad.. I guess because in higher BOINC versions the CUDA CPU support is very bad. [CPU support gone very much down compared with BOINC V6.6.11 .]


Soo .. I'm down to 2 days.. set 3 days. [current ~ 1,600 WUs at HDD].
But BOINC can't fill up the cache because of download errors.



Yes.. it's really disappointing that BOINC can't manage high WU cache.
Yes.. sorry if it's sounding negative..
But.. I'm really disappointed that BOINC can't support high.. in my case.. ~ 8,000 WUs cache.. ~ 10 days.
Before with my old QX6700.. 10 days.. ~ 700 WUs.. everything well.
But now everyday I hope my PC will not run out of work.

Ohh.. well..


Yes.. my GPU cruncher have too much performance for the SETI@home server.

---

setiboincdata.ssl.berkeley.EDU isn't on a corporate LAN, so the LAN discussion, while interesting, doesn't apply to "why can't I upload/download."

Actually it does to an extent. While I can not remember if there are 6 or 8 nameservers involved in this whole fiacsco... It means the Boinc was able to find the 208.xxx.xxx.xxx address not the 128.xxx.xxx.xxx which is the Berkeley Lan (web side). As I recall setiboincdata.ssl.berkeley.EDU is the "returned" scheduler DNS name. So unlike lookups for bruno or vader which are the two download servers and getting the proper 208.xxx.xxx.xxx addresses it would mean that your computer could not find the machine or the handoff from the scheduler did not give a resovable name or IP of the correct server to contact for that actual download.

---

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.

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.

The DNS system is used by many companies internally for many reasons. It isn't exclusive to the internet, even though it was originally designed for it. There are ways of segregating the internal DNS system from the external (or Internet) DNS system. Even though I have all my computers on my LAN registered in my local DNS, doesn't mean they are accessible through the internet.

Some companies even run their own "root" servers if they do not want their employees using the internet, though that's quite rare these days but not unheard of.

setiboincdata.ssl.berkeley.EDU isn't on a corporate LAN, so the LAN discussion, while interesting, doesn't apply to "why can't I upload/download."

I had already agreed with this basic premise that is true. I was just commenting on your statement that /REGISTERDNS is only for Windows AD and that it isn't used in the real world. This comment, of course, took the conversation off topic, but I felt it was worth pointing out that there are real world uses for /REGISTERDNS and the DNS system other than its applications with the Internet.

---

Those having had the same problems, has solved the issue by a simple reboot of their machines. So, have you rebooted your troubled PC's?

I'ts a DNS issue coming from the fact that the project shut down and then had to turn on again one of the download servers.

REBOOT MAN, REBOOT, AND STOP COMPLAINING :-)

Message 910956

..yes man.. made the reboot.. ;-)


But maybe need to 'reboot' [ON/OFF] also the DSL-router?

But.. this will not help if my ISP is too slowly.. to 'see' the new IP address of Berkeley.. or what ever..

---

First BOINC is a work in progress! Yes there can and will be problems...

Next when there are problems maintaining such a large cache common sense states start scaling back until you can find a working medium. For Myself, I have a .5 day cache. If I run out of work then I do other projects which relieves the stress on the Seti Servers. When You have a machine that is trying to grab 3500 WU's and Send as many; as we are recovering from an extended outage it will be nothing less than Chaos! In your case you have probably several problems, You ISP does not have the IP's of where things are trying to go or come from and you have a TON of them all trying at the same time. It will take a while and you have to be patient!
Seti tries to take care of its own. There are times that the WORLD Interferes with Seti taking care of its own.
Then you add individual computer problems ontop of all that.

You can only say one thing FRUSTRATION! The hard part is learning what you can control and what will take time for others to sort out.

I know that I can not control Comcast's Name/Proxy Servers and on my part for 3 machines (that had the same problems) I had to be patient. BOINC and my Cache I have control over. Matt works to make sure that the Servers that you computer needs to contact are properly registered and working.

So we sit back and wait. You may need to do several manual updates (anything to get you ISP to get the correct information) to get you ISP to get the corect DNS entries. But then when you force Seti to run at the Bleeding Edge you can only expect problems. Then it falls back to you to understanding what you can control and what you can not control. That is where you start moving ahead.

Regards

This is where a 10 Day Cache is a Killer. What I suspect in your cache is that your ISP is very slow in updating DNS. I will have to think about how we got around this before. Matt had set a Very short TTL and there were many IPS's that did not honor it.

When I do Lookups on both download servers I get the Berkeley IP (blocked)) and the External IP that the scheduler would handoff.

So as I have sent a note Matt, it would be patient for a bit.

Sorry.. I would if BOINC could..

BOINC V6.6.36 can't manage work cache > ~ 3,500 WUs.
[If you go over this size.. like I posted.. BOINC go crazy.]
http://setiathome.berkeley.edu/forum_thread.php?id=54289


For some months I posted here at the SETI@home forum also in the BOINC/dev forum that > BOINC V6.6.11 can't manage > ~ 2,500 WU cache.
CUDA performance went very bad.. I guess because in higher BOINC versions the CUDA CPU support is very bad. [CPU support gone very much down compared with BOINC V6.6.11 .]


Soo .. I'm down to 2 days.. set 3 days. [current ~ 1,600 WUs at HDD].
But BOINC can't fill up the cache because of download errors.



Yes.. it's really disappointing that BOINC can't manage high WU cache.
Yes.. sorry if it's sounding negative..
But.. I'm really disappointed that BOINC can't support high.. in my case.. ~ 8,000 WUs cache.. ~ 10 days.
Before with my old QX6700.. 10 days.. ~ 700 WUs.. everything well.
But now everyday I hope my PC will not run out of work.

Ohh.. well..


Yes.. my GPU cruncher have too much performance for the SETI@home server.

---

Please consider a Donation to the Seti Project.

Actually I Love this!

For DNS to work properly in Windows AD, the person configuring it has to have an understanding of DNS and then configuration of DNS as it publishes to the world (infrastructure). As far as I know that part is well documented in DNS and Bind. While Windows AD takes care of a "lot" of things you stil have to know how DNS works.

For the AD Domains for World Web Sites that gets a little trickier. The common problem as to why they are not visible is AD DNS is not allowed to talk to the Gateway (two way). Pick your misconfigured router/firewall/dns. If the Primary Name Server is unaccessable then it is DEAD! Yes there are other even more PhooPahsss or tricks... LOL

Actually, the whole reason for having secondary name servers is so that when the primary is down, everything else can potentially still work, and in practice, that's true.

Let's say you have a registered domain "pappa.org" -- the simple solution is that www.pappa.org is handled in the traditional way as documented in DNS and BIND (and others), and your Active Directory domain would be pappa.local.

That way, you don't have any confusion between the ".local" namespace and the globally resolvable ".org" namespace.

... and the .org name servers are public.

I should not be able to reach in from the globally routable IP space and query anything in "pappa.local" because that would let me build a complete list of resources on the domain.

---

Actually I Love this!

For DNS to work properly in Windows AD, the person configuring it has to have an understanding of DNS and then configuration of DNS as it publishes to the world (infrastructure). As far as I know that part is well documented in DNS and Bind. While Windows AD takes care of a "lot" of things you stil have to know how DNS works.

For the AD Domains for World Web Sites that gets a little trickier. The common problem as to why they are not visible is AD DNS is not allowed to talk to the Gateway (two way). Pick your misconfigured router/firewall/dns. If the Primary Name Server is unaccessable then it is DEAD! Yes there are other even more PhooPahsss or tricks... LOL

Actually, the whole reason for having secondary name servers is so that when the primary is down, everything else can potentially still work, and in practice, that's true.

Let's say you have a registered domain "pappa.org" -- the simple solution is that www.pappa.org is handled in the traditional way as documented in DNS and BIND (and others), and your Active Directory domain would be pappa.local.

That way, you don't have any confusion between the ".local" namespace and the globally resolvable ".org" namespace.

... and the .org name servers are public.

I should not be able to reach in from the globally routable IP space and query anything in "pappa.local" because that would let me build a complete list of resources on the domain.

In some cases a "limited DNS server or the appliance is placed on the edge for Global Names." It does not replicate anything *.local.
It also presumes that beside the A Record for pappa.org (and the route) I have a CNAME Record for www.pappa.org that resolves. Anything inside my boundary will not resolve (except locally). I know this is boring the living daylights out of most users. As they do not know what is being talked about "other" than is currently affecting them. It is all majik (incorrectly mislabeled as the Internet to Seti)!

So for Seti it is a mixed bag. As Long as the 208.xxx.xxx.xxx IP's are findable world wide from BOINC we should be okay (with time). When a change is made it takes time to get the rest of the world in sync.

Sorry to cut and run have to go pick up the wife.

---

Please consider a Donation to the Seti Project.

Actually, the whole reason for having secondary name servers is so that when the primary is down, everything else can potentially still work, and in practice, that's true.

Let's say you have a registered domain "pappa.org" -- the simple solution is that www.pappa.org is handled in the traditional way as documented in DNS and BIND (and others), and your Active Directory domain would be pappa.local.

That way, you don't have any confusion between the ".local" namespace and the globally resolvable ".org" namespace.

... and the .org name servers are public.

I should not be able to reach in from the globally routable IP space and query anything in "pappa.local" because that would let me build a complete list of resources on the domain.

In some cases a "limited DNS server or the appliance is placed on the edge for Global Names." It does not replicate anything *.local.
It also presumes that beside the A Record for pappa.org (and the route) I have a CNAME Record for www.pappa.org that resolves. Anything inside my boundary will not resolve (except locally). I know this is boring the living daylights out of most users. As they do not know what is being talked about "other" than is currently affecting them. It is all majik (incorrectly mislabeled as the Internet to Seti)!

So for Seti it is a mixed bag. As Long as the 208.xxx.xxx.xxx IP's are findable world wide from BOINC we should be okay (with time). When a change is made it takes time to get the rest of the world in sync.

Sorry to cut and run have to go pick up the wife.
[/quote]
For names like setiboincdata.ssl.berkeley.EDU, the TTL is five minutes. The "refresh" interval is 1 hour.

No matter what combination of devices are used, when they make a change to an A record, old data should be completely gone in 65 minutes, tops.

That assumes that a secondary updated just before the change (and can continue to answer for another 60 minutes) and that the "worst case" machine consistently hits the last secondary to update -- plus the five minutes for local caching.

---

Remember to Buckle your seatbelt......it makes it harder for the aliens to suck you out of the car!!!

---

I am still getting expected number and getting zero also connect failed, is it because the servers are getting maxed out and I have to wait until the can send me my downloads? Also got a couple of http errors which I assume is the same as connect failed, can upload but not download on my last few luckily I am doing other BOINC project so hopefully it will sort itself out again.

---

I've got about 70+ Work Units queued up to download. Only 2 of them have done so, all the rest give connect() failed messages.
Re-booted the computer, no joy. Re-booted the modem, no joy. Re-booted the computer again after re-booting the modem, no joy.
*shrug*
Will leave it overnight & see how it goes.

---

Grant
Darwin NT

Yeah, all of my rigs have downloads waiting to happen, and I looked at the cricket graph and we're not maxed out..but I do notice that the replica is offline, though that has nothing to do with WU downloads.

Though I haven't been looking at the packet rate cricket graph.. I think that pegs out around 9k/sec, so the bandwidth can still have headroom left, but if there are too many packets, then more data can't go through.

At least one of my downloads now have 3 hours of elapsed download time.

I'm not complaining, just stating facts/assumptions. I have more than plenty of work already downloaded and ready to crunch for this to even worry me a little bit.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

I had problems on a couple of my sys getting the downloads to start earlier, even after a reboot. So I did a ipconfig/flushdns from the command prompt and that cleared them.

---

I did a ipconfig/flushdns from the command prompt and that cleared them.

Just gave that a go, no joy.
I'll go back to the "See what happens overnight" method.

---

Grant
Darwin NT