found this file on one of my systems anybody no what it is its not on my other three boinc.gorlaeus.net

Well... it is the Leiden Classical url (see HERE)... so maybe only that system is or has been attached to that project?

thank you 4 help worried it was something in my system i did not want there

Yay got my first workunit in ages \\o/

---

Heya guys and gals,
well this is the first time posting to this forum and all i want to say is that i have been fretting for several weeks now thinking there was something wrong with my config on my end. ie router/firewall/xp etc....
LIGHTBULB

---

Heya guys and gals!,
I have been fretting for weeks now thinking there was a problem on my side with router/firewall/xp etc........
Then LIGHTBULB !
Lets check seti website.....
DOOOOOOH
Cause and effect found:)
Keep up the great work!
I'll keep crunching 'till I help find that ET life source!
bartman

---

Thanks again for your patience during the past couple of weeks. While I appreciate the kind words and sentiments I should point out that this past weekend for me wasn't exactly restful time off. I was working at
my other job.

- Matt

I hope that your other job as a musician was less stressful than the past days with SETI and that you had a good weekend after all.
As for SETI; it isn't life threatening to all of us to spend our days waiting for WU's, so we will survive :-{)

-=[ Jurre ]=-

---

-=[ Not all who wander are lost ]=-

If you do a ping setiathome.berkeley.edu

I do find the server intermittently switching between

208.68.240.11
128.32.18.152

This should be resolved to let us connect/download/upload.

Greetings from Belgium,

HP ;-))

---

This may be why I managed to download 2 pieces of work 2 days ago but have not been able to upload the result or download anything else since! Ah well, will just be patient and wait for everything to get back to norm soon. Thanks for the info. LindaM

---

Linda

Hi !

I am also having problems with connection to seti@home, but I am not sure where is the problem. I instaled BOINC 64bit manager and this problem could be connected to that.

5/15/2007 12:19:09 PM|SETI@home|Requesting 30240 seconds of new work
5/15/2007 12:19:19 PM|SETI@home|Scheduler RPC succeeded [server version 509]
5/15/2007 12:19:19 PM|SETI@home|Message from server: platform 'windows_x86_64' not found
5/15/2007 12:19:19 PM|SETI@home|Deferring communication for 1 days 0 hr 0 min 0 sec
5/15/2007 12:19:19 PM|SETI@home|Reason: requested by project

If someone can comment that I would be very thankful... I have Windows XP 64-bit, and since boinc didn't work because of seti problems I thought that maybe problem was on my side so I downloaded new version (64 bit this time)...

Andy

I'm not sure, Andy, but it seems that there isn't any software to process SETI's works units with that platform. There is for win x86 32 bit platforms, and sure that they're makin' one for 64 bit.

Is there a version of XP on 64 bits? I didn't know that!

See the platforms available here: http://boinc.berkeley.edu/download_all.php

Version 5.9.10: Development version (MAY BE UNSTABLE - USE ONLY FOR TESTING)

---

If you do a ping setiathome.berkeley.edu

I do find the server intermittently switching between

208.68.240.11
128.32.18.152

This should be resolved to let us connect/download/upload.

Greetings from Belgium,

HP ;-))

128.32.18.152 being
OrgName: University of California
OrgID: UNIVER-22
Address: IST - Communication and Network Services
Address: ATTN Network Services Group
Address: 2484 Shattuck Ave 1640
Address: NOTE See Comment for DMCA INFO
City: Berkeley
StateProv: CA
PostalCode: 94720-1640

and
208.68.240.11 being
OrgName: SETIATHOME
OrgID: SETIA
Address: 7 Gauss Way
Address: Room 325A
City: Berkeley
StateProv: CA
PostalCode: 94720

In effect this means that every other attempt is not even reaching the lab and the SETI servers?!

Johan

---

Yes, it's not only your clients which can't upload.

No, I am not able to upload either, neither Seti main nor Seti Beta.

Hopefully the rebooting of Bruno will do the trick eventually...

---

"I'm trying to maintain a shred of dignity in this world." - Me

If you do a ping setiathome.berkeley.edu

I do find the server intermittently switching between

208.68.240.11
128.32.18.152

This should be resolved to let us connect/download/upload.

Greetings from Belgium,

HP ;-))

128.32.18.152 being
OrgName: University of California
OrgID: UNIVER-22
Address: IST - Communication and Network Services
Address: ATTN Network Services Group
Address: 2484 Shattuck Ave 1640
Address: NOTE See Comment for DMCA INFO
City: Berkeley
StateProv: CA
PostalCode: 94720-1640

and
208.68.240.11 being
OrgName: SETIATHOME
OrgID: SETIA
Address: 7 Gauss Way
Address: Room 325A
City: Berkeley
StateProv: CA
PostalCode: 94720

In effect this means that every other attempt is not even reaching the lab and the SETI servers?!

Johan

By checkin' only IP numbers, yes, but remember that the SETI@Home depends on Berkeley university (and uses part of their infrastructure), so, it's possible that due the overload on net transit, part of the info can be reditected to secondary servers.

If you readed the posts from all the last week, you'll see that the lab is a bit revolutioned right now.

---

I have created a Thread in Number Crunching about the Intermittent random switching of Server IP Addresses; also, I have notified Matt by PM about this and asked for him to check out that Thread which is:

Intermittent random Server IP switching...

I have been monitoring this since Friday.


Sincerely,

---

TimeLord04
Have TARDIS, will travel...
Come along K-9!
Join Calm Chaos

What a weekend. As noted by the others they successfully got the replacement science database server from Sun and brought it to the lab Friday afternoon. As we hoped it was basically plug n' play after putting the old thumper's drives in it. After some file system syncing and data checking Eric started the splitters on Saturday. All was well until bruno's httpd processes choked (more on that below). So we were not sending work for a whole day until Jeff kicked bruno this morning. The bright side is this allowed the splitters to create a whole pile of work in the meantime which we are sending out right now as fast as we can. The main bottleneck is NFS on the workunit file server which is (and always has been) choking at around 60 Mbps. It'll take a while for things to catch up.

We officially retired both koloth and kryten as of today - both are powered down, and in the case of koloth completely removed from the closet to make way for thumper, sidious, and then some. With the closet as empty as it has been in a long time I finally removed dozens of unused SCSI/ethernet/terminal/power cables that came with the rack, all tucked in various corners and secured with cable ties. The process of cutting the tightly wound ties in sharp metal cages left me with four bleeding wounds on my hands - nothing bad, only two required band aids - but I've wanted to get that particular clutter out of that rack for years.

With koloth and kryten gone bruno has been taking up most of the slack. I noticed last week it gets into these periods of malaise where httpd just stops working. I think this may be buggy restart logic when we rotate web logs, but it's a little weirder than that. Adding insult to injury one of its internal drives just up and died today. Luckily it was a RAID spare so nothing was harmed, and we had replacement drives already donated to us a while back. Eric replaced the drive, but we may need to reboot to fully pick it up. Probably during the usual outage tomorrow. Bruno is dropping lots of packets right now, resulting in all kinds of upload/download snags and showing up as "disabled" on the server status page. This should clear up over time.

The server situation will be in major flux, and generally in a positive direction, over the next week or so. I'll be trying to keep updating the server status page, but I make no guarantees about its accuracy.

Thanks again for your patience during the past couple of weeks. While I appreciate the kind words and sentiments I should point out that this past weekend for me wasn't exactly restful time off. I was working at
my other job.

- Matt

Congrats Matt. You get a cookie.(grin)

---

I've detached altogether for the short term.

Intermittent random Server IP switching...

I have been monitoring this since Friday.

There's no problem.

Matt has mentioned that DNS gives one or the other IP address so that Berkeley can load balance between two servers.

And sure enough:

; <<>> DiG 9.3.1 <<>> setiathome.berkeley.edu
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42173
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 13, ADDITIONAL: 12

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

;; ANSWER SECTION:
setiathome.berkeley.edu. 507    IN      CNAME   setiathome.SSL.berkeley.edu.
setiathome.SSL.berkeley.edu. 217 IN     A       128.32.18.152
setiathome.SSL.berkeley.edu. 217 IN     A       208.68.240.11

All's working well for that bit.

Happy crunchin',
Martin

---

See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)

So far It been almost 12 hours and I think I've restarted the PC once for M$ and I've uploaded a WU and reported a grand total of 1 time each, Something is Broken.

I'm beginning to agree.

1) The network bits/second should not be declining while my ability to download is still effectively nothing.

2) The network bits/second should not be declining while my ability to upload is nothing.

Depends on exactly what the problem is.

If Bruno (for example) is running out of connection handles, dropping packets and generally overloaded, it could very well be spending all its time trying to start tasks and deal with connections, and little time transferring bits.

If that's the case, then an overload looks exactly like you describe.

---

Yes Houston euh Berkeley we have a problem...
We (Belgium - Europ) cannot upload / download / update and often the webpages take long to load...

Yes we know BOINC and SETI... Been here since 1999

Yes we have read all the mail...
Inclusive all the to the point facts and the inevitable interference...

Yes have patience...

Thats why I do find this kind of organisation of TECHNICAL NEWS not good.

I mean tech news should be SEC and only mention the things that present themselves without any anwers or expanding threads of our part.

In this way we (I) wouldn't have to wade through numerous non facts...

I just want to know what is happening, and why I cannot connect.
This is not obvious, even not after reading all of the messages.

Greetings from Belgium
HP ;-))

;; ANSWER SECTION:
setiathome.berkeley.edu. 507 IN CNAME setiathome.SSL.berkeley.edu.
setiathome.SSL.berkeley.edu. 217 IN A 128.32.18.152
setiathome.SSL.berkeley.edu. 217 IN A 208.68.240.11
[/pre]
All's working well for that bit.

Happy crunchin',
Martin

Two servers and two networks. If the round-robin DNS is working, each query will return the two "A" records in the opposite order.

... and each resolver should serve the responses in random order as well.

It's only an issue when the DNS server doesn't randomize (because the RFC isn't clear where "round-robin" is supposed to happen) and the resolver doesn't randomize (because the programmer read the RFC and assumed the server will do it).

Microsoft is particularly bad on this issue, both in their server and in the resolver.

---

Thank you. I am glad we are back up. I am sure that this was a nightmare for all of you involved in the recovery. Still it was strange out here. After running this for so long, it was like the disappearance of an old friend. I check in a couple times per week for updates. It was kind of interesting to note how I missed the routine.

---

As I mentioned yesterday, I REALLY hope the admins don't take the servers and satabase offline today for backup. The four hour outage for that normal process tends to cause an additional 6 hours of 'catch up' disruption and there is quite enough upload/download disruption going on right now.

On the other hand, if they are able to identify and fix any *new* issues that might be contributing to the *OBVIOUS* upload/download snags we are seeing in what otherwise might simply be an extended post outage disruption associated with the extended outage (we are 24 hour post outage and the upload/download disruption is still very much in play), then that would be a good thing.

---