My guess:
Some overzealous firewall or intrusion detection system is diagnosing a DOS / flooding attack on berkeley and is canalizing / limiting the traffic to the data server. It was omitted to curb it again after the reboot.

---

Aloha, Uli

I heard that Berkeley were going to reverse the polarity of the neutron flow, in order to make the upload directory accessible - if so, then I think they need to invest in a new sonic screwdriver as the one they were going to use seems not to be working properly...!

Timbo

---

regards,
Tim
Founder, UK BOINC Team
Join us @ UK BOINC Team: http://www.ukboincteam.org.uk/newforum

My guess:
Some overzealous firewall or intrusion detection system is diagnosing a DOS / flooding attack on berkeley and is canalizing / limiting the traffic to the data server. It was omitted to curb it again after the reboot.

I like that one.
When they first tried to implement the software firewall it clobbered the system completely.

---

Grant
Darwin NT

Here is trace of the traffic on a failed upload.
Connects fine every time. Sends file size frequest. Server Acks that.
Then nothing.....followed by a tcp reset from the server.

I think this combined with the earlier reports that the servers file system was often unable to find its own files might mean that they have a corruption on the server. The actual server request here is to get file size...(see below)....the server never responds to this (although the tcp stack does) and 15 seconds later the server sends a tcp RST.....a timer intervening I guess......end of game!

Trace.

192.168.0.2 1047 66.28.250.125 http TCP 1047 > http [SYN] Seq=1833621860 Ack=0 Win=65535 Len=0 MSS=1460 WS=2
66.28.250.125 http 192.168.0.2 1047 TCP http > 1047 [SYN, ACK] Seq=3666183519 Ack=1833621861 Win=64240 Len=0 MSS=1460 WS=0
192.168.0.2 1047 66.28.250.125 http TCP 1047 > http [ACK] Seq=1833621861 Ack=3666183520 Win=64240 Len=0
192.168.0.2 1047 66.28.250.125 http HTTP POST /sah_cgi/file_upload_handler HTTP/1.0
66.28.250.125 http 192.168.0.2 1047 TCP http > 1047 [ACK] Seq=3666183520 Ack=1833622121 Win=63980 Len=0
192.168.0.2 1047 66.28.250.125 http HTTP Continuation
66.28.250.125 http 192.168.0.2 1047 TCP http > 1047 [ACK] Seq=3666183520 Ack=1833622360 Win=64001 Len=0
66.28.250.125 http 192.168.0.2 1047 TCP http > 1047 [RST, ACK] Seq=3666183520 Ack=1833622360 Win=64001 Len=0


Request to server.

0000 3c 64 61 74 61 5f 73 65 72 76 65 72 5f 72 65 71 *data_server_req
0010 75 65 73 74 3e 0a 20 20 20 20 3c 63 6f 72 65 5f uest*. *core_
0020 63 6c 69 65 6e 74 5f 6d 61 6a 6f 72 5f 76 65 72 client_major_ver
0030 73 69 6f 6e 3e 34 3c 2f 63 6f 72 65 5f 63 6c 69 sion*4*/core_cli
0040 65 6e 74 5f 6d 61 6a 6f 72 5f 76 65 72 73 69 6f ent_major_versio
0050 6e 3e 0a 20 20 20 20 3c 63 6f 72 65 5f 63 6c 69 n*. *core_cli
0060 65 6e 74 5f 6d 69 6e 6f 72 5f 76 65 72 73 69 6f ent_minor_versio
0070 6e 3e 32 37 3c 2f 63 6f 72 65 5f 63 6c 69 65 6e n*27*/core_clien
0080 74 5f 6d 69 6e 6f 72 5f 76 65 72 73 69 6f 6e 3e t_minor_version*
0090 0a 20 20 20 20 3c 67 65 74 5f 66 69 6c 65 5f 73 . *get_file_s
00a0 69 7a 65 3e 31 35 6a 61 30 35 61 63 2e 31 30 37 ize*15ja05ac.107
00b0 33 38 2e 31 32 36 34 30 2e 36 39 30 39 30 34 2e 38.12640.690904.
00c0 31 33 30 5f 34 5f 30 3c 2f 67 65 74 5f 66 69 6c 130_4_0*/get_fil
00d0 65 5f 73 69 7a 65 3e 0a 3c 2f 64 61 74 61 5f 73 e_size*.*/data_s
00e0 65 72 76 65 72 5f 72 65 71 75 65 73 74 3e 0a erver_request*.

---

Has anybody bothered to check to see if an Alian race has hi-jacked the system?

1) Prehapes we have discovered something that we should not have discovered!
2) They have embedered a countdown sequence and are actually using our own computers to co-ordinate a world-wide stick against us.

Have seti paid their ISP Fees? Maybe they had to switch to dial-up because broadband got disconnected?

---

A simple country boy waiting for...
A sign of any kind.

A P4 HT machine:

grep "inished upload\|failed upload" boincseti.log |tail -4000 |cut -d" " -f1,5 |sort |uniq -c

times date finished upload/failed upload

15 2005-07-08 upload
26 2005-07-09 upload
27 2005-07-10 upload
23 2005-07-11 upload
413 2005-07-12 failed
6 2005-07-12 upload
386 2005-07-13 failed
42 2005-07-13 upload
314 2005-07-14 failed
25 2005-07-14 upload
268 2005-07-15 failed
20 2005-07-15 upload
976 2005-07-16 failed
23 2005-07-16 upload
891 2005-07-17 failed
31 2005-07-17 upload
503 2005-07-18 failed
11 2005-07-18 upload

It might be getting worse: 30 to 40 attempts to send one finished WU.
Quite some bandwith here, I can imagine how it looks like in Berkeley...

BR/GL

Iztok

Btw. i did not read all of your posts but i also cannot upload ?!
Can anybody tell how long it took to fix this problem..?!

---

Maybe Berkeley should eject the anti-matter core now, before it explodes? :)

I guess I should not say this... but we have more outages coming. When they find the cause of this packet droppings, they may very likely have to power down some hardware to fix it. Then, there's also the major "misery" outage... in August (maybe). So brace for impact! All power to front deflector shields!

Maybe Berkeley should eject the anti-matter core now, before it explodes? :)

I guess I should not say this... but we have more outages coming. When they find the cause of this packet droppings, they may very likely have to power down some hardware to fix it. Then, there's also the major "misery" outage... in August (maybe). So brace for impact! All power to front deflector shields!

Prognatus , u crunch our dreams :) :) :) :)

---

Dell XPS L702x
smokin' weed and searching for aliens .... ;]
TRUSTNO1

There must be some priority to downloading new work units. I seem to get downloads but have as many as 11 uploads sitting around waiting. Seems so strange since they take about 3 seconds to do -= the eleven of them would take less time to upload than one WU downloaded.....hmmmmm......

This was done a few outages ago so people would at least have units to crunch without people cranking up their cache levels. Downloads are a higher priority than uploads during outages.

Thanks, Mikey = that's good to know. At least I was right about one thing......

The uploads just continue to pile up.....

---

Well whatever it is I hope they get it fixed. I have 9 finished units waiting for upload and the oldest is past its deadline and am also waiting for new units to download. My CPU is IDLE folks.

!? Why?

Well whatever it is I hope they get it fixed. I have 9 finished units waiting for upload and the oldest is past its deadline and am also waiting for new units to download. My CPU is IDLE folks.

!? Why?

Because his CPU gerbil is running on amphetamines and finishes WUs faster...

Of course his CPU gerbil is also psychotic (mainly because of the pharmaceutical load), but that's ANOTHER story.

---

Stewie: So, is there any tread left on the tires? Or at this point would it be like throwing a hot dog down a hallway?

Fox Sunday (US) at 9PM ET/PT

Well now there is a senario.
In another post I made last night, the "experts" said that this problem would/should not result in anyone losing credit due to the workunit being past it's deadline time & date.
As I suspected last night, this senario is now upon us and "we" are losing credit at "our" expense.
Expense being that it is us who choose to run this upon our computers and pay for the power that they consume so why oh why is Berkeley not considering extending the report deadlines instead of sitting upon their hands and making a "minor" mention of this "major" problem on the front page of the website?

First off, I am not out to start a flame war here and it's highly likely that I am just not understanding the situation. Please explain what the setup is that's allowing WUs to hit deadline so soon. However,

1. If you are talking about a setup of running only SETI then that's a self induced scenerio of one flavor that deserves no sympathy and no bandwidth.
   
2. If people are hitting deadline limits due to a long connect time in order to stockpile WUs see #1.
   

Even my XP 1600 isn't close to running past the deadline on SETI WUs. If one sets a reasonably short connect time and allows the scheduler to work, it pretty well prevents this. What am I not seeing? And where is that fire suit...?

---

- da shu @ HeliOS,
"A child's exposure to technology should never be predicated on an ability to afford it."

Hi

I´m running only seti and seti beta ATM and have set my cache at 10 days.
Still have 67 WUs in cache and no problems with deadline.
Dedached from einstein because of the deadline issue.

I have to say that somebody has to respect that a (few) crunchers only want to run seti.
Sorry for that.

Just my 2$.

greetz Mike

---

With each crime and every kindness we birth our future.

Here is trace of the traffic on a failed upload.
Connects fine every time. Sends file size frequest. Server Acks that.
Then nothing.....followed by a tcp reset from the server.

00b0 33 38 2e 31 32 36 34 30 2e 36 39 30 39 30 34 2e 38.12640.690904.
00c0 31 33 30 5f 34 5f 30 3c 2f 67 65 74 5f 66 69 6c 130_4_0*/get_fil
00d0 65 5f 73 69 7a 65 3e 0a 3c 2f 64 61 74 61 5f 73 e_size*.*/data_s
00e0 65 72 76 65 72 5f 72 65 71 75 65 73 74 3e 0a erver_request*.

I'm impressed and sounds like the best guess to date. -- Skip

Let's see,,,,,the game is to "Guess what's wrong with Uploading?" is that correct? So who ever is closer to being right wins? OK,,then, My guess is that:
'
They are taking to long.

There,.....do I win?

---

Hmmm reply text slipped away...
Anyway....
The answer is.... No.
Maybe they are taking two long.
];-)

-------

They are taking to long.

There,.....do I win?[/quote]
[/quote]

---

To me, it looks like the folks that have modified their seti client software, to retry uploads every minute, are the problem.

I've got the standard windows release, and it radomly retries, typically 2-3 hours!

The every minute folks are bringing the server down.

---

They would have had to modify BOINC client, not SETI client.

Also, what evidence do you have that leads you to this conclusion?

I'm not arguing for or against you, I'm just curious as to what clues you have.

Jim

To me, it looks like the folks that have modified their seti client software, to retry uploads every minute, are the problem.

I've got the standard windows release, and it radomly retries, typically 2-3 hours!

The every minute folks are bringing the server down.

---

To me, it looks like the folks that have modified their seti client software, to retry uploads every minute, are the problem.

I've got the standard windows release, and it radomly retries, typically 2-3 hours!

The every minute folks are bringing the server down.

I run optimised clients (seti and boinc) and I have not seen this before. My retries are all between a few minutes and 3 hours 15 minutes. Anyone else heard of this.....its a futile activity for sure if its true....'cos it will never get better that way.

---