Both of my crunchers have no problems at all holding a 10-day cache. Of course they're both slow by everyone's standards, but when either of them need just a few seconds of work, 1-5 requests and they get a new task, or multiple tasks.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

I am hoping that the AP work in the splitter queue will dry up for a bit.
Then maybe the MB work will flow a bit better and fill some caches. I've only been monitoring my top rig, and it's cache is kinda floating up and down as downloads can complete and work is issued.

It has only been in recent history that I can recall the AP work being split faster than the MB work. It used to be that all of the MB work was split and sent, leaving only AP splitting being done. Quite the opposite at the moment.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

AP work isn´t split any faster Mark.
It gets downloaded slower for some reason.
I could manage to catch 1200 MB in less than 2 hours last night.

Its very weird downloaded 1 AP today with 650 KB/s.
The next one with 6 kb again.

Maybe a ghost WU.

---

With each crime and every kindness we birth our future.

Both of my crunchers have no problems at all holding a 10-day cache. Of course they're both slow by everyone's standards, but when either of them need just a few seconds of work, 1-5 requests and they get a new task, or multiple tasks.

Hehehe, even slower here and no problems :).

The faster machines having smaller caches would reduce the server load considerably

No, they will ask for the same amount of work, no matter how big the cache is.

No they won't.
Depending on the speed of a machine a 2 day cache may require 2,000 Work Units, so a 5 day cache will require 5,0000 Work Units. 10,000 Work Units for a 10 day cache, etc.
Once a cache is full, then the only requests will be to top up the cache & will be made at the rate the machine processes work. But it has to build up the cache in the first place before point is reached. So while building up the cache the demand for work is above & beyond what would be required once the cache has filled up.

My machines are a good example of that.
When the caches aren't full, they will try to get work every 5 minutes. When the caches are full, it's 1 or 2 reqeusts every 30 min to 2 hours (assuming each request for work is successfull). That's a big difference in demand.

---

Grant
Darwin NT

Its very weird downloaded 1 AP today with 650 KB/s.
The next one with 6 kb again.

Maybe a ghost WU.

I think there are still problems with one of the download servers.
For several weeks now downloads have been very variable- some will timeout as soon as they start, or they start- but then it just sit there & nothing is downloaded & it might take 5 minutes or more for it to time out.
Disabling & re-enabling network access & a few retries & then you'll get a bunch all downloading- maybe at 5kB/s within a day of the outage but often at 15kB/s or more a couple of days or more after the outage.
And the then next attempt to download will time out straight away again or not start to download anything at all...

---

Grant
Darwin NT

Someone else might like to comment, but your cruncher with the two GPU has had more than 10 errors in the last 24 hours, compared to others with similar setups that are giving less than one error per day.

Anyway, the blockage appears to have been cleared as there are quite a number of WU (mostly AP for your GPUs).

yep that is why because the nvidia drivers stop working because of high OC of the CPU it was for 1 min before i fix it.Just make 3.7Ghz on Q6600 B3 1.325 VID :D keep pushing to 4Ghz :D
just now i'm writing have download 100 astropulse units

---

I am hoping that the AP work in the splitter queue will dry up for a bit.
Then maybe the MB work will flow a bit better and fill some caches. I've only been monitoring my top rig, and it's cache is kinda floating up and down as downloads can complete and work is issued.

It has only been in recent history that I can recall the AP work being split faster than the MB work. It used to be that all of the MB work was split and sent, leaving only AP splitting being done. Quite the opposite at the moment.

It looks like your wish has been granted ;-)

In fact, I think it's been the case for a while that the AP splitters, working flat out, can turn a 'tape' into WUs a lot faster than the MB splitters can. But they don't always work flat out. There are safeguards in place to avoid them over-filling the WU data storage when, for example, the ready-to-send queue gets big enough.

Now that AP crunching on ATI has reached the mainstream, and more people are beta-testing the NVidia AP app, WUs are collected from that queue more quickly, and there is less need to inhibit the splitters.

Personally, I'd prefer to see fewer AP splitters in play. That would spread out the deployment of AP tasks from new tapes, rather than the current 'boom and bust', with 17 full tapes of AP work already clogging the download pipe but MB struggling to play catch-up.

Thanks Richard....
You understood what I was getting at.
About 1000 AP left in ready to send.
We'll see what shakes if another dataset does not load and start AP splitting back up again.
If the MB work does not have to fight the AP work for bandwidth, maybe downloads will start doing a bit better on the MB work.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

We AP crunchers had to wait up to 4 weeks to get a few.

Had no problems myself to fill my MB cache up to 14 days.

---

With each crime and every kindness we birth our future.

I still have 72 of them on my other machine, most of them came down in one bunch.

---

I got another 160 ap video card wu's but they are low on my cache since I am not doing them right now it took about 2 days to get them I also got several hundred other gpu and cpu wu's also all in the 2 days over 1000 in all wu's.

---

Well you guys and girls have had 12 days of me only feeding 2 of my 3 PC's but...

my X4 630 has now been handed down to my youngest son and has been replaced by an i5 2500K.

Plus its in a feeding frenzy so, if you can't get any work then blame me. :D

Cheers.

---

Looks like we're about to run out of MB work again- the Ready to Send buffer has been shrinking steadily for several hours now & it would appear the splitter problem has resurfaced- they're just not cranking up the production to meet demand.

---

Grant
Darwin NT

Untill the splitters get their act together, that's it for any more MB work apart from the odd WU here & there.

---

Grant
Darwin NT

Untill the splitters get their act together, that's it for any more MB work apart from the odd WU here & there.

A creation rate of 18/sec can't all be resends, can it? So, some splitter action, and some requests will get something - just not all of them, and not enough to satisfy demand. We may just limp through until the lab opens ;-)

Untill the splitters get their act together, that's it for any more MB work apart from the odd WU here & there.

A creation rate of 18/sec can't all be resends,

Nope, they're still splitting, but for whatever reason they're just not cranking it up as required.

---

Grant
Darwin NT

Ready to send went down from 226000 10 hours ago to zero.
Results out in the field increased from 5,4 to 5,8 million.
So it seems some are catching up nicely.

---

With each crime and every kindness we birth our future.

Hopefully a good sign...
MB splitting rate now shows almost 40/second and the Cricket has sprung back to life.

Meow meow meow.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

WARNING WARNING!! The system works great now, let's take it down quick and destroy it :-)

I think you got what you asked for - nothing getting reported at present! Presumably they also found ET and don't want any more results?
Actually I see cricket's "bits out" have dropped again, so presumably that is what has happened.

---