The curve starts at the same time the WFV went to zero, so it may be because the UCB folks started other processes as soon as WFV was zero, slowing down the splitters. Still, whatever caused it, I hope they make a note of it - if we need the splitters running full-out some time, they'll know ONE possible performance bottleneck!

IIRC, the assimilators and deleters started the instant WFV hit zero. Could that explain the slowing?

---

"Are you suggesting coconuts migrate?"

has the system restarted or still down?

has the system restarted or still down?

You can check that on the Server status page.

---

"Are you suggesting coconuts migrate?"

has the system restarted or still down?

You can check that on the Server status page.

cheers

has the system restarted or still down?

You can check that on the Server status page.

cheers

Not yet ...

---

"In a world without walls and fences, who needs windows and gates ?"
for the team

hooray its started again

ROM: I sent a message the other day about "scheduler".... Now I have begun to receive WU's in batches with little to no wait. The upload is another thing I have a file that's been in start mode for two weeks. The process starts and achives a tcp thread for the first 10.63 KB block. Then apparently it drops off and the client times out the process. The file(result) looks to be only 10.63 KB long ??? and I assume the client never gets the ACK for the block sent.
This process never changes maybe this points to you current failure and buildup of the retry que.... Boinc is 4.19, os is win/ME, 1.30 ghz processor, Dialup at 56K.....

---

I have no more problems to receive WUs, it's running slowly which is not surprising, but I'm still unableto UL.

In the UL process, I've got 1/3 WU lost, 2/3 still trying. In the DL process, 4 WUs officialy lost, 5 in fact. No big deal, but one more proof of the inefficiency of the protocol, not in term of speed but in term of security. One WU at least has downloaded 85% before stopping for awhile, the at the end disapearing. Anybody knows if the UL/DL process handle partial transfers ?

Every PCs under Boinc 4.72

---

"In a world without walls and fences, who needs windows and gates ?"
for the team

ROM: I sent a message the other day about "scheduler".... Now I have begun to receive WU's in batches with little to no wait. The upload is another thing I have a file that's been in start mode for two weeks. The process starts and achives a tcp thread for the first 10.63 KB block. Then apparently it drops off and the client times out the process. The file(result) looks to be only 10.63 KB long ??? and I assume the client never gets the ACK for the block sent.
This process never changes maybe this points to you current failure and buildup of the retry que.... Boinc is 4.19, os is win/ME, 1.30 ghz processor, Dialup at 56K.....

I've been watching two computers today and they have the same experience. 100% of the file is uploaded, no ACK (I'm guessing here) is received, and the file goes back into the retry UL state.

---

May this Farce be with You