DA was able to fix it in the forums....
Is the inbox display that much different?

I looked at the CSS, but it's not obvious to me how DA could have fixed it [using standard CSS styles]. You'll have to ask him....

DA was able to fix it in the forums....
Is the inbox display that much different?

I looked at the CSS, but it's not obvious to me how DA could have fixed it [using standard CSS styles]. You'll have to ask him....

He fixed it on the 14th, I think...
Are there any clues for you in the changeset log?
Here...

I am clueless about HTML, so I don't know what some of those changes do.

---

"Time is simply the mechanism that keeps everything from happening all at once."

The cricket graph shows the pipe is maxed out at 90 Mbps. If the online convertor I just used is correct then that is equivalent to 40.5 Gb/hr. With most work units being 366Kb each that works out at a bandwidth equivalent to 109,000 wu/hr. Or 30 units per second - which is about right.
I don't think results out in the field is counting units allocated but unsent.

Allowing for ~2.74% packet overhead and AP tasks, I get around 17 MB and 0.5 AP tasks per second to occupy that 90 Mbps. As the download servers do not interface to the BOINC database at all, out in the field cannot be other than what the Scheduler has instructed hosts to download.

About 80% of hosts have RAC under 260 when things have stabilized, and many of those need less than 10 MB or 1 AP to fill their cache. Such hosts have probably already achieved more or less normal operation, many of the other 20% with larger appetites not yet.

                                                               Joe

Looks like they are working on something, all assimilators and splitters are diabled/not running.

---

Looks like they are working on something, all assimilators and splitters are diabled/not running.

or something broke AGAIN

---

More than likely working on Gowron.

---

Janice

More than likely working on Gowron.

shush we're not supposed to know about that server

---

...yesterday I got a boatload of WUs, and today I got another boatload. My i7 and Linux PCs are BOINCing right along... :)

Ah HA! So, you're the one to blame for clogging everything up! lol

:-))))

Martin

Greetings Martin,

Hey! All I did was doubled my RAM to 8 GB and installed Win7 Pro 64 bit. If that upgrade clogged the pipes, what a POWERHOUSE this thing is now! j/k ;) About the POWERHOUSE that is... :) I did do the upgrade. :)

Keep on BOINCing...! :)

---

CAPT Siran d'Vel'nahr - L L & P _\\//
Winders 11 OS? "What a piece of junk!" - L. Skywalker
"Logic is the cement of our civilization with which we ascend from chaos using reason as our guide." - T'Plana-hath

The cricket graph shows the pipe is maxed out at 90 Mbps. If the online convertor I just used is correct then that is equivalent to 40.5 Gb/hr. With most work units being 366Kb each that works out at a bandwidth equivalent to 109,000 wu/hr. Or 30 units per second - which is about right.
I don't think results out in the field is counting units allocated but unsent.

Allowing for ~2.74% packet overhead and AP tasks, I get around 17 MB and 0.5 AP tasks per second to occupy that 90 Mbps. As the download servers do not interface to the BOINC database at all, out in the field cannot be other than what the Scheduler has instructed hosts to download.

About 80% of hosts have RAC under 260 when things have stabilized, and many of those need less than 10 MB or 1 AP to fill their cache. Such hosts have probably already achieved more or less normal operation, many of the other 20% with larger appetites not yet.

                                                               Joe

I think you are right. The rate of increase in results in the field has dropped to around 13 per second now - about half of what it was. Yet the cricket graph is still saturated. So it is only recording allocated units.

---

Me I'm just getting HTTP error after HTTP error right now when I try to download. Sigh, I'll wait.

I've been able to coax some downloads through, but until the bandwidth relaxes a bit, it's gonna continue to be a fight.

---

"Time is simply the mechanism that keeps everything from happening all at once."

Me I'm just getting HTTP error after HTTP error right now when I try to download. Sigh, I'll wait.

I've been able to coax some downloads through, but until the bandwidth relaxes a bit, it's gonna continue to be a fight.

Yeah, Virtual bumper to bumper, Parking Lot style. :D Or hurry up and wait. ;)

Well, just let Boinc do it's thing overnight, and you'll probably find it's snagged some more work by morning.

---

"Time is simply the mechanism that keeps everything from happening all at once."

I've been slowly able to grab work, and I have a long way to go. The wierd thing is that I have added about 50,000 in pendings since we came back up. I don't mind, but it is a bit unusual for me to add this many so quickly. Out of about 2000 wu so far, every single CPU wu is an AP, which is also fine with me. Usually I get a mix of MB CPU/GPU. Now all MB is strictly GPU except the only CPU work being for the AP units.

Steve

---

Warning, addicted to SETI crunching!
Crunching as a member of GPU Users Group.
GPUUG Website

I've got about 2000 waiting to d/l, Boinc grabs 3 or 4 then starts with the http errors. It's all good.

I am kind of puzzled by the CPU/GPU split so far. Early on, I too got a slew of AP, those are already crunched and returned. Since then, it's running about 25 to 1 GPU to CPU. I really don't want to have to reschedule but looks like I might not have a choice.

---

next outage will be Monday, we will run out of work to split.

---

Most of my work is for my GPU's, I occasionally get CPU MB work and some AP work for the Q8200 but I have a ton of ATI and CUDA MB work between the 2 systems.



Now if I could only get them downloaded.

---

I think you are right. The rate of increase in results in the field has dropped to around 13 per second now - about half of what it was. Yet the cricket graph is still saturated. So it is only recording allocated units.

Under normal conditions when WU's are downloaded without queues forming you would be right, its just that when it was decided to display that statistic they probabaly chose an easy point to generate the data from not realising that under some circumstances the data may be affected by other causes, the data is not mission critical its only for informational purposes.

---

Kevin

I think you are right. The rate of increase in results in the field has dropped to around 13 per second now - about half of what it was. Yet the cricket graph is still saturated. So it is only recording allocated units.

MB rate of downloads might have dropped off, but AP is picking up. Given that 1 AP is worth about 22 MB units bandwidth wise, that'd take up the traffic slack pretty well.

---

Grant
Darwin NT

I'm sure I'm not the only one who has a large number of downloads pending for quite some time. But this could have been expected. Why didn't they limit the downloads initially and ease them up gradually to prevent all this inefficiency? I think they did this before, so why did they change?

Because those who run large caches complained about not being able to fill up before the next outage. Nevermind that with limits in place everyone was treated equally and now it depends a great deal on your ISP and routing through the internet. Best connection gets through.

---

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

Well, the only thing we can do with our big machines - switch it to
other projects and let only the low rider crunch for Seti. ;-)

I have switched my big boy over to milkyway...

Helli

---

A loooong time ago: First Credits after SETI@home Restart