I don't know if anyone else, (including the SETI@Home crew), has been monitoring this; so, I thought I'd post it here:


In light of all of the recent hardware deaths and change-outs; IP Routing at Berkeley's end keeps randomly switching between:

Old IP Address:

128.32.18.152


New IP Address:

208.68.240.11


I noticed this during the reincarnation of Thumper. Since the rebuild was complete and activated late on Friday; there has been intermittent periods of freezing and locking up switching Threads within the Forums of both SETI@Home AND Beta/Astropulse.

When this freezing/locking up has occurred the only way I found to "fix" it was the "ipconfig /flushdns" in a command prompt. Then I would "ping setiathome.berkeley.edu" and "ping setiweb.ssl.berkeley.edu"; since the change to Hurricane, Pappa states we should always get 208.68.240.11, here is what I get:


Ping setiathome.berkeley.edu

Pinging setiathome.SSL.berkeley.edu [128.32.18.152] with 32 bytes of data

Reply from 128.32.18.152: bytes=32 time=58ms TTL=238
Reply from 128.32.18.152: bytes=32 time=49ms TTL=238
Reply from 128.32.18.152: bytes=32 time=58ms TTL=238
Reply from 128.32.18.152: bytes=32 time=50ms TTL=238

Ping statistics for 128.32.18.152:

Packets: Sent=4, Received=4, Lost=0, (0% loss),

Approximate round trip time in milli-seconds:

Minimum=49ms, Maximum=58ms, Average=53ms


Ping setiweb.ssl.berkeley.edu

Pinging setiathome.ssl.berkeley.edu [208.68.240.11] with 32 bytes of data

Reply from 208.68.240.11: bytes=32 time=37ms TTL=239
Reply from 208.68.240.11: bytes=32 time=42ms TTL=239
Reply from 208.68.240.11: bytes=32 time=30ms TTL=239
Reply from 208.68.240.11: bytes=32 time=35ms TTL=239

Ping statistics for 208.68.240.11:

Packets: Sent=4, Received=4, Lost=0, (0% loss),

Approximate round trip time in milli-seconds:

Minimum=30ms, Maximum=42ms, Average=36ms


Sometimes I get both of them at the "proper" address of 208.68.240.11, sometimes I get both on the "wrong" address of 128.32.18.152... Usually, (since the reimplementation of Thumper), the two pings switch out which one is the "128." Address and which one is the "208." Address... So; is this related to the Thumper crash and rebuild or, did something else fail at or around the same time as Thumper that is now doing this??? Also, is this the reason for the "hanging"/"stuck" Download(s) of WUs?


Sincerely,

---

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

I don't know if anyone else, (including the SETI@Home crew), has been monitoring this; so, I thought I'd post it here:


In light of all of the recent hardware deaths and change-outs; IP Routing at Berkeley's end keeps randomly switching between:

Old IP Address:

128.32.18.152


New IP Address:

208.68.240.11


I noticed this during the reincarnation of Thumper. Since the rebuild was complete and activated late on Friday; there has been intermittent periods of freezing and locking up switching Threads within the Forums of both SETI@Home AND Beta/Astropulse.

When this freezing/locking up has occurred the only way I found to "fix" it was the "ipconfig /flushdns" in a command prompt. Then I would "ping setiathome.berkeley.edu" and "ping setiweb.ssl.berkeley.edu"; since the change to Hurricane, Pappa states we should always get 208.68.240.11, here is what I get:


Ping setiathome.berkeley.edu

Pinging setiathome.SSL.berkeley.edu [128.32.18.152] with 32 bytes of data

Reply from 128.32.18.152: bytes=32 time=58ms TTL=238
Reply from 128.32.18.152: bytes=32 time=49ms TTL=238
Reply from 128.32.18.152: bytes=32 time=58ms TTL=238
Reply from 128.32.18.152: bytes=32 time=50ms TTL=238

Ping statistics for 128.32.18.152:

Packets: Sent=4, Received=4, Lost=0, (0% loss),

Approximate round trip time in milli-seconds:

Minimum=49ms, Maximum=58ms, Average=53ms


Ping setiweb.ssl.berkeley.edu

Pinging setiathome.ssl.berkeley.edu [208.68.240.11] with 32 bytes of data

Reply from 208.68.240.11: bytes=32 time=37ms TTL=239
Reply from 208.68.240.11: bytes=32 time=42ms TTL=239
Reply from 208.68.240.11: bytes=32 time=30ms TTL=239
Reply from 208.68.240.11: bytes=32 time=35ms TTL=239

Ping statistics for 208.68.240.11:

Packets: Sent=4, Received=4, Lost=0, (0% loss),

Approximate round trip time in milli-seconds:

Minimum=30ms, Maximum=42ms, Average=36ms


Sometimes I get both of them at the "proper" address of 208.68.240.11, sometimes I get both on the "wrong" address of 128.32.18.152... Usually, (since the reimplementation of Thumper), the two pings switch out which one is the "128." Address and which one is the "208." Address... So; is this related to the Thumper crash and rebuild or, did something else fail at or around the same time as Thumper that is now doing this??? Also, is this the reason for the "hanging"/"stuck" Download(s) of WUs?


Sincerely,

This looks to me like the IP based load balancing (dynamic switching between Kryten and Bruno(?) )is still enabled on berkeleys dns servers.

This should have been turned off while kryten was retired.

---

Join BOINC United now!

I don't know if anyone else, (including the SETI@Home crew), has been monitoring this; so, I thought I'd post it here:


In light of all of the recent hardware deaths and change-outs; IP Routing at Berkeley's end keeps randomly switching between:

Old IP Address:

128.32.18.152


New IP Address:

208.68.240.11


I noticed this during the reincarnation of Thumper. Since the rebuild was complete and activated late on Friday; there has been intermittent periods of freezing and locking up switching Threads within the Forums of both SETI@Home AND Beta/Astropulse.

When this freezing/locking up has occurred the only way I found to "fix" it was the "ipconfig /flushdns" in a command prompt. Then I would "ping setiathome.berkeley.edu" and "ping setiweb.ssl.berkeley.edu"; since the change to Hurricane, Pappa states we should always get 208.68.240.11, here is what I get:


Ping setiathome.berkeley.edu

Pinging setiathome.SSL.berkeley.edu [128.32.18.152] with 32 bytes of data

Reply from 128.32.18.152: bytes=32 time=58ms TTL=238
Reply from 128.32.18.152: bytes=32 time=49ms TTL=238
Reply from 128.32.18.152: bytes=32 time=58ms TTL=238
Reply from 128.32.18.152: bytes=32 time=50ms TTL=238

Ping statistics for 128.32.18.152:

Packets: Sent=4, Received=4, Lost=0, (0% loss),

Approximate round trip time in milli-seconds:

Minimum=49ms, Maximum=58ms, Average=53ms


Ping setiweb.ssl.berkeley.edu

Pinging setiathome.ssl.berkeley.edu [208.68.240.11] with 32 bytes of data

Reply from 208.68.240.11: bytes=32 time=37ms TTL=239
Reply from 208.68.240.11: bytes=32 time=42ms TTL=239
Reply from 208.68.240.11: bytes=32 time=30ms TTL=239
Reply from 208.68.240.11: bytes=32 time=35ms TTL=239

Ping statistics for 208.68.240.11:

Packets: Sent=4, Received=4, Lost=0, (0% loss),

Approximate round trip time in milli-seconds:

Minimum=30ms, Maximum=42ms, Average=36ms


Sometimes I get both of them at the "proper" address of 208.68.240.11, sometimes I get both on the "wrong" address of 128.32.18.152... Usually, (since the reimplementation of Thumper), the two pings switch out which one is the "128." Address and which one is the "208." Address... So; is this related to the Thumper crash and rebuild or, did something else fail at or around the same time as Thumper that is now doing this??? Also, is this the reason for the "hanging"/"stuck" Download(s) of WUs?


Sincerely,

This looks to me like the IP based load balancing (dynamic switching between Kryten and Bruno(?) )is still enabled on berkeleys dns servers.

This should have been turned off while kryten was retired.

OK - then should this be directed to Matt's or Eric's, (or someone else on the crew's), attention? That is; should I copy this information and paste it into the Technical News area for them to see? Or, will someone let them know that I have started this Thread here in Number Crunching? I believe that this is something pertinent for them to address, don't you? [EDIT:] Especially since they have officially retired Kryten and another Server as of yesterday, and yet this continues even now...[/EDIT.]

[EDIT 2:] Right now; for me, (7:33AM PDT), both locations are reflecting the old "128." Address...[/EDIT 2]

[EDIT 3:] ...and now, (7:39AM PDT), without the "ipconfig /flushdns"; both just switched to the proper "208." Address...[/EDIT 3:]


Sincerely,

---

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

OK - then should this be directed to Matt's or Eric's, (or someone else on the crew's), attention? That is; should I copy this information and paste it into the Technical News area for them to see? Or, will someone let them know that I have started this Thread here in Number Crunching? I believe that this is something pertinent for them to address, don't you? [EDIT:] Especially since they have officially retired Kryten and another Server as of yesterday, and yet this continues even now...[/EDIT.]

Sincerely,

You could try sending a Private Message using the new system.

Alternately most of the Staff's email addresses can be found here.

---

Sir Arthur C Clarke 1917-2008

OK - then should this be directed to Matt's or Eric's, (or someone else on the crew's), attention? That is; should I copy this information and paste it into the Technical News area for them to see? Or, will someone let them know that I have started this Thread here in Number Crunching? I believe that this is something pertinent for them to address, don't you? [EDIT:] Especially since they have officially retired Kryten and another Server as of yesterday, and yet this continues even now...[/EDIT.]

Sincerely,

You could try sending a Private Message using the new system.

Alternately most of the Staff's email addresses can be found here.

Thanks, Keith T.


I just sent this in a PM to Matt:


"5-15-2007 at 7:51AM - PDT


Matt,


I just wanted to bring to your attention something I've been monitoring since the reincarnation and reimplementation of the new Thumper machine late on Friday. There seems to be random and intermittent IP Address switching at the Servers at Berkeley even though Kryten has been taken down and retired.

I created a Thread in Number Crunching that addresses this concern. That Thread is here:

Intermittent random Server IP switching...

After reviewing the information I have provided there; is this possibly why "Upload(s)" and "Download(s)" are still affected and hanging, along with the intermittent hanging/freezing of Threads in both the SETI@Home Forums and Beta/Astropulse Forums???


Thanks,"

==================================================================

So, now we wait and see...

---

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

http://setiathome.berkeley.edu and http://setiweb.ssl.berkeley.edu are both aliases to our public web servers (that serve the home page and other web pages), namely klaatu and kosh. Only kosh is on Hurricane (208.68...) - klaatu is on the Berkeley LAN (128.32...). These aliases are served via roundrobin DNS, which means when you go to setiathome.berkeley.edu the space lab DNS server randomly assigns you either klaatu or kosh, as a means for load balancing.

This has been the case for a couple months now, and is not a sign of something wrong.

- 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

Good Afternoon TImeLord04

Now to really confuse things (or stir it?)

ping -a 208.68.240.11

Pinging setiathome.ssl.berkeley.edu [208.68.240.11] with 32 bytes of data:

Reply from 208.68.240.11: bytes=32 time=171ms TTL=244
Reply from 208.68.240.11: bytes=32 time=171ms TTL=244
Reply from 208.68.240.11: bytes=32 time=170ms TTL=244
Reply from 208.68.240.11: bytes=32 time=170ms TTL=244

Ping statistics for 208.68.240.11:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 170ms, Maximum = 171ms, Average = 170ms

ping -a 128.32.18.152

Pinging klaatu.SSL.Berkeley.EDU [128.32.18.152] with 32 bytes of data:

Reply from 128.32.18.152: bytes=32 time=158ms TTL=238
Reply from 128.32.18.152: bytes=32 time=157ms TTL=238
Reply from 128.32.18.152: bytes=32 time=157ms TTL=238
Reply from 128.32.18.152: bytes=32 time=157ms TTL=238

Ping statistics for 128.32.18.152:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 157ms, Maximum = 158ms, Average = 157ms

So far so good. Now tracert

tracert 128.32.18.152

Tracing route to klaatu.SSL.Berkeley.EDU [128.32.18.152]
over a maximum of 30 hops:

1 <10 ms <10 ms <10 ms 192.168.1.254
2 12 ms 12 ms 13 ms sgrs-lns-04-lo0.onetel.net.uk [212.67.121.52]
3 12 ms 13 ms 12 ms 212.67.125.252
4 14 ms 11 ms 13 ms 212.67.120.82
5 12 ms 12 ms 13 ms g1-2.corebr04.thn6.uk.as8586.net [213.246.145.157]
6 84 ms 15 ms 13 ms 195.66.224.185
7 13 ms 12 ms 12 ms g14-0-0.core02.lon01.atlas.cogentco.com [130.117.2.21]
8 84 ms 82 ms 84 ms p9-0.core02.jfk02.atlas.cogentco.com [66.28.4.253]
9 122 ms 120 ms 121 ms p12-0.core01.mci01.atlas.cogentco.com [154.54.3.202]
10 133 ms 135 ms 135 ms p15-0.core01.den01.atlas.cogentco.com [154.54.3.13]
11 156 ms 154 ms 154 ms p10-0.core02.sfo01.atlas.cogentco.com [66.28.4.209]
12 156 ms 156 ms 155 ms g0-1.na21.b003070-1.sfo01.atlas.cogentco.com [66.250.9.6]
13 156 ms 156 ms 172 ms CENIC.demarc.cogentco.com [38.112.6.226]
14 157 ms 158 ms 158 ms inet-ucb--oak-isp.cenic.net [137.164.24.142]
15 157 ms 158 ms 156 ms g4-1.inr-202-reccev.Berkeley.EDU [128.32.0.50]
16 158 ms 158 ms 160 ms g6-2.inr-230-spr.Berkeley.EDU [128.32.255.114]
17 158 ms 159 ms 157 ms ssl-f1.SSL.Berkeley.EDU [169.229.0.218]
18 161 ms 159 ms 158 ms klaatu.SSL.Berkeley.EDU [128.32.18.152]

Trace complete.

And

tracert 208.68.240.11

Tracing route to setiathome.ssl.berkeley.edu [208.68.240.11]
over a maximum of 30 hops:

1 <10 ms <10 ms <10 ms 192.168.1.254
2 13 ms 12 ms 13 ms sgrs-lns-04-lo0.onetel.net.uk [212.67.121.52]
3 12 ms 12 ms 12 ms 212.67.125.252
4 13 ms 192.168.1.254 reports: Destination protocol unreachable.

Trace complete.

Do I sniff a contradiction amongst this?

PS: Should I sign myself as Castellan Spandrill (speling?)

---

IF this is the cause of the problems in uploading / downloading and reporting work then this problem must have existed for many, many months.

If it is possible to look at the daily cricket graphs from months ago the erratic nature of the graph has existed for some time. Usually appearing after the weekly Tuesday outage and then some time later the erratic nature goes away and a smooth line appears in the graph.

I have learned over time that when the cricket graph is erratic in nature, I personally cannot upload or download. When, in time, the graph smooths out then I can upload and download data.

---

Boinc....Boinc....Boinc....Boinc....

Never mind, retracted... Reread response...


Thanks.

============================================
[EDIT:]

http://setiathome.berkeley.edu and http://setiweb.ssl.berkeley.edu are both aliases to our public web servers (that serve the home page and other web pages), namely klaatu and kosh. Only kosh is on Hurricane (208.68...) - klaatu is on the Berkeley LAN (128.32...). These aliases are served via roundrobin DNS, which means when you go to setiathome.berkeley.edu the space lab DNS server randomly assigns you either klaatu or kosh, as a means for load balancing.

This has been the case for a couple months now, and is not a sign of something wrong.

- Matt

OK - however; what about the intermittent Web page hanging issues... When these addresses keep switching around, I'm experiencing freezes and hangs on the Web Browser that only seem to clear if I "ipconfig /flushdns" then when I reissue the Ping Command, I find that indeed the Server IP has changed, yet again... If true load balancing is occuring, (both at SETI@Home and Beta/Astropulse), shouldn't there be no hanging or freezing; that is, shouldn't it run smooth and seamless?

Since it isn't seamless, and there is hanging and freezing, could this issue cascade to other areas of the Server Network, (Uploading/Downloading), or is this just limited to the Web Pages and that the Uploading/Downloading issues are still elsewhere?


[/EDIT.]


Sincerely,

---

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

http://setiathome.berkeley.edu and http://setiweb.ssl.berkeley.edu are both aliases to our public web servers (that serve the home page and other web pages), namely klaatu and kosh. Only kosh is on Hurricane (208.68...) - klaatu is on the Berkeley LAN (128.32...). These aliases are served via roundrobin DNS, which means when you go to setiathome.berkeley.edu the space lab DNS server randomly assigns you either klaatu or kosh, as a means for load balancing.

This has been the case for a couple months now, and is not a sign of something wrong.

- Matt

Ooops! Thanks Matt

---

Good Afternoon TImeLord04

Now to really confuse things (or stir it?)

ping -a 208.68.240.11

Pinging setiathome.ssl.berkeley.edu [208.68.240.11] with 32 bytes of data:

Reply from 208.68.240.11: bytes=32 time=171ms TTL=244
Reply from 208.68.240.11: bytes=32 time=171ms TTL=244
Reply from 208.68.240.11: bytes=32 time=170ms TTL=244
Reply from 208.68.240.11: bytes=32 time=170ms TTL=244

Ping statistics for 208.68.240.11:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 170ms, Maximum = 171ms, Average = 170ms

ping -a 128.32.18.152

Pinging klaatu.SSL.Berkeley.EDU [128.32.18.152] with 32 bytes of data:

Reply from 128.32.18.152: bytes=32 time=158ms TTL=238
Reply from 128.32.18.152: bytes=32 time=157ms TTL=238
Reply from 128.32.18.152: bytes=32 time=157ms TTL=238
Reply from 128.32.18.152: bytes=32 time=157ms TTL=238

Ping statistics for 128.32.18.152:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 157ms, Maximum = 158ms, Average = 157ms

So far so good. Now tracert

tracert 128.32.18.152

Tracing route to klaatu.SSL.Berkeley.EDU [128.32.18.152]
over a maximum of 30 hops:

1 <10 ms <10 ms <10 ms 192.168.1.254
2 12 ms 12 ms 13 ms sgrs-lns-04-lo0.onetel.net.uk [212.67.121.52]
3 12 ms 13 ms 12 ms 212.67.125.252
4 14 ms 11 ms 13 ms 212.67.120.82
5 12 ms 12 ms 13 ms g1-2.corebr04.thn6.uk.as8586.net [213.246.145.157]
6 84 ms 15 ms 13 ms 195.66.224.185
7 13 ms 12 ms 12 ms g14-0-0.core02.lon01.atlas.cogentco.com [130.117.2.21]
8 84 ms 82 ms 84 ms p9-0.core02.jfk02.atlas.cogentco.com [66.28.4.253]
9 122 ms 120 ms 121 ms p12-0.core01.mci01.atlas.cogentco.com [154.54.3.202]
10 133 ms 135 ms 135 ms p15-0.core01.den01.atlas.cogentco.com [154.54.3.13]
11 156 ms 154 ms 154 ms p10-0.core02.sfo01.atlas.cogentco.com [66.28.4.209]
12 156 ms 156 ms 155 ms g0-1.na21.b003070-1.sfo01.atlas.cogentco.com [66.250.9.6]
13 156 ms 156 ms 172 ms CENIC.demarc.cogentco.com [38.112.6.226]
14 157 ms 158 ms 158 ms inet-ucb--oak-isp.cenic.net [137.164.24.142]
15 157 ms 158 ms 156 ms g4-1.inr-202-reccev.Berkeley.EDU [128.32.0.50]
16 158 ms 158 ms 160 ms g6-2.inr-230-spr.Berkeley.EDU [128.32.255.114]
17 158 ms 159 ms 157 ms ssl-f1.SSL.Berkeley.EDU [169.229.0.218]
18 161 ms 159 ms 158 ms klaatu.SSL.Berkeley.EDU [128.32.18.152]

Trace complete.

And

tracert 208.68.240.11

Tracing route to setiathome.ssl.berkeley.edu [208.68.240.11]
over a maximum of 30 hops:

1 <10 ms <10 ms <10 ms 192.168.1.254
2 13 ms 12 ms 13 ms sgrs-lns-04-lo0.onetel.net.uk [212.67.121.52]
3 12 ms 12 ms 12 ms 212.67.125.252
4 13 ms 192.168.1.254 reports: Destination protocol unreachable.

Trace complete.

Do I sniff a contradiction amongst this?

PS: Should I sign myself as Castellan Spandrill (speling?)

OK - So, with the "Destination protocol unreachable"; doesn't this indicate a REAL PROBLEM here??? Hence the "load balancing" is kicking in and allowing people to connect; however, wouldn't this create a "HUGE BOTTLENECK" in connectivity??? Or, since I'm no DNS expert, (HA - not even in the slightest), again; should we be looking elsewhere?


Sincerely,

---

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

One more note; as I've been trying to learn and understand more and more about the big picture in the hardware soup that is SETI@Home and Beta/Astropulse...


OK - "IF" the load balancing is doing it's proper job, (and I have no expertise to say it isn't; I can only report what I'm seeing), then from what I'm reading here by Matt, (and elsewhere by others), is that even though there is a "perceived" bottleneck in connectivity that this is not the case, and all is well...

Why then are we, (myself and others), experiencing Browser Page Freezes and Hangs on an ongoing intermittent basis which coincide with the random Server IP Address switching happening and ongoing at Berkeley?

Next; with the above shoved aside for the moment, since Bruno, (from what I'm reading elsewhere), is the Upload/Download Server and currently is down now too due to unknown issues - why are some people able to circumvent the Upload/Download block with this "fanout" thing or manually editing some file, (which I don't truly understand as my thing is hardware, not software), to a "proxy" address of 128.32.18.173??? (Also updated that allegedly this has now been blocked because using that proxy allegedly costs SSL money...)

So, bottom line - where are we??? Are things improving; or, are we seeing a huge cascade of issues that the SETI Team are scrambling to overcome, (both hardware and software and some DNS issues thrown in too), since the Kryten failure months ago??? If this, (as I see it), is a cascade of issues; shouldn't we all, (all users around the world), back off from hammering the Servers with Upload and Download requests while things get ironed out? Or, am I being too simplistic?

I would love to physically be there in Berkeley to assist; however, with my limited knowledge, (based on what I'm seeing and what I'm learning by reading), I'd only get in the way... So, what can I do to help from my end; other than just "be patient"... Those two words have been thrown out to everyone here so many times that many have gotten frustrated to the point of leaving the Project(s). I'm not one to pack my bags. I've invested some money and endeavored to donate valued and needed hardware to the SETI Team; as well as my own personal electricity, (as others do too), so what can I/we do at this moment for the SETI Team/Crew to get all of this cleared up?

If it truly isn't a DNS/load balancing/IP issue, and since Kryten is no longer in the picture, is this latest incident with Bruno now the key to the issue - or is there still more to come before this is ironed out?


Sincerely,

---

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

In reply to TimeLord04.. Our server setup isn't really all that complicated, but it's also in varying levels of flux, and I don't have the time to write up every level of detail. It's amazing to me how many people can deduce a lot about our setup from the little information I do have time to provide. But sometimes people insert incompetence, random failure or evil conspiracy to spackle the holes in their big picture. Fair enough. I try to correct that when I can.

[edit: I'm not saying this is what you're doing - just a general observation...]

- 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

In reply to TimeLord04.. Our server setup isn't really all that complicated, but it's also in varying levels of flux, and I don't have the time to write up every level of detail. It's amazing to me how many people can deduce a lot about our setup from the little information I do have time to provide. But sometimes people insert incompetence, random failure or evil conspiracy to spackle the holes in their big picture. Fair enough. I try to correct that when I can.

[edit: I'm not saying this is what you're doing - just a general observation...]

- Matt

Sorry that people have been bugging you lately Matt out of being ignorant.
I think TL is just curious though. We who are on your side are though very curious and have a tendency to sometimes lap up all your info as best we can. Keap up the good work and hope you had a good gig this weekend!

Carl

---

It is SEXY to DONATE!
Skype = demiurg2

Sorry that people have been bugging you lately Matt out of being ignorant.

Sorry I didn't mean to make it sound like anybody is ignorant. I'm really floored by the interest, and wish I had time to fill in all the blanks.

- 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

I didn't mean it that way. I just mean't the very few people who has been ignorant and bugged you.
Don't worry:-)

The rest of us are just a big case of curiosity killed the cat!
We really appreciate when you have time to tell us things and we do understand that you often don't have time.

Take care!
Carl

---

It is SEXY to DONATE!
Skype = demiurg2

Sorry that people have been bugging you lately Matt out of being ignorant.

Sorry I didn't mean to make it sound like anybody is ignorant. I'm really floored by the interest, and wish I had time to fill in all the blanks.

- Matt

LOL Matt, it is very interesting, and your posts are always very informative. I know we will all be waiting for the tech news update you post regarding todays short outage. :-) Thanks for all the hard work, you guys are doing a great job.

Jeremy

---

Sorry that people have been bugging you lately Matt out of being ignorant.

Sorry I didn't mean to make it sound like anybody is ignorant. I'm really floored by the interest, and wish I had time to fill in all the blanks.

- Matt

LOL Matt, it is very interesting, and your posts are always very informative. I know we will all be waiting for the tech news update you post regarding todays short outage. :-) Thanks for all the hard work, you guys are doing a great job.

Jeremy

Why does everyone say it better than me today? *scratches my third ear*

---

It is SEXY to DONATE!
Skype = demiurg2

Sorry that people have been bugging you lately Matt out of being ignorant.

Sorry I didn't mean to make it sound like anybody is ignorant. I'm really floored by the interest, and wish I had time to fill in all the blanks.

- Matt

LOL Matt, it is very interesting, and your posts are always very informative. I know we will all be waiting for the tech news update you post regarding todays short outage. :-) Thanks for all the hard work, you guys are doing a great job.

Jeremy

Why does everyone say it better than me today? *scratches my third ear*

Must be one of THOSE days. ROFL J/K. h ehhe

---

Hi Matt
I do not think anyone took you post that way. Your updates are great, I am sure that all of us are glad to get any level of detail you have time to post. I amazed at the level of talent that are here with the SETI crunchers, the idea that the group in general want to help resolve any issues. Most realize that your time is limited and are thankful that you spent so much of your personal time helping us.
Having my electronics training in the “dark ages” when vacuum tubes were “in”, these posting are good for us old “geeks” in the migration across the analog to digital bridge.

I have notice you do not do any shows scheduled in central Florida area, but if you do let us know.

I just want to put my 2 cents worth in.
M & J

Sorry that people have been bugging you lately Matt out of being ignorant.

Sorry I didn't mean to make it sound like anybody is ignorant. I'm really floored by the interest, and wish I had time to fill in all the blanks.

- Matt

---

[color= blue][u]SETI@home classic workunits = 5,906 with CPU time of 60,377 hours[/u][/color]