I cannot remember the last time the daily cricket graph looked the way it does at present - a perfect, solid mass of green. Long may it continue.

http://fragment1.berkeley.edu/newcricket/grapher.cgi?target=%2Frouter-interfaces%2Finr-250%2Fgigabitethernet2_3;ranges=d%3Aw%3Am%3Ay;view=Octets

But if nothing is actually uploading?

Uploads are working fine here, and for the majority of users - otherwise we couldn't be seeing "Results received in last hour 48,463" on the server status page.

You may have been caught by the HE router fault - you could try the proxy solutions suggested in the two sticky 'HE connection problems' threads at the top of this board.

You may have been caught by the HE router fault - you could try the proxy solutions suggested in the two sticky 'HE connection problems' threads at the top of this board.

Never any problems before. Downloads have been fine. The upload problem only started a couple of hours ago.

---

Uploads are working fine here, and for the majority of users - otherwise we couldn't be seeing "Results received in last hour 48,463" on the server status page.

It may be totally irrelevant but I see that results received is down to 45,088 so perhaps I am not the only one with sudden upload problems?

[Edit]
Now I see that Bruno is actually in disabled state, so no wonder uploads are not going through!

---

Uploads are working fine here, and for the majority of users - otherwise we couldn't be seeing "Results received in last hour 48,463" on the server status page.

It may be totally irrelevant but I see that results received is down to 45,088 so perhaps I am not the only one with sudden upload problems?

[Edit]
Now I see that Bruno is actually in disabled state, so no wonder uploads are not going through!

Honestly, uploads are going through normally here - I have none waiting (across five busy machines), and three have gone through since I started typing this reply.

There are regular 'false negatives' on the server status page. My rule of thumb is not to believe it unless the same server shows as disabled on two consecutive updates (i.e. updates with different timestamps - Bruno is running on the 14:40 UTC copy of the page).

Uploads are working fine here, and for the majority of users - otherwise we couldn't be seeing "Results received in last hour 48,463" on the server status page.

It may be totally irrelevant but I see that results received is down to 45,088 so perhaps I am not the only one with sudden upload problems?

[Edit]
Now I see that Bruno is actually in disabled state, so no wonder uploads are not going through!

Bruno looks fine on the latest script run (Update)...

Downloads have slowed to Molasses speed for me and the numbers are starting to pile up. Uploading and reporting has not been a problem at all for a couple days.

Lt

I see Richard beat me to it...re Bruno. He must be faster at two finger typing than I am...:)

i just want to say that i'm getting AP GPU tasks for the first time in ~2 weeks now. they've been flowing for the past ~36 hours or so, albeit sparsely - my AP queue has yet to climb above ~10 tasks. i should also note that this isn't enough to keep my GPU crunching constantly, but i understand we're still debugging some problems. the last time i posted about the server problems was in the "Panic Mode On (55) Server problems" thread over 2 weeks ago.

---

DownLoads are also slow(as a snail), but UPLoads aren't happening, at all.

Not SETI "only" though, CPDN also doesn't get DownLoads through, as well.
(Average throughput between 200 and 1000bytes/sec.). 1.6 to 8Kbit/s followed by
a waiting period and several retries.

---

See Soft^Spirit's new "Highlight: Update from Jeff 10/8/11" thread.

After the PAIX router's memory is increased many of these quirky, intermittent connection issues might disappear. (We can all hope!)

Lt

Uploads and reporting running fine here.

Downloads very slow.

---

Kevin

Downloads are slow, but I'm getting lots of work now including a good handfull of AP's. In fact my 1 rig is becoming a bit of a piggy wiggy with them, seems to be getting the lions share in numbers and as a % of total work.

Brett

---

Uploads, downloads and reporting all working really well here. Hope thats not tempting fate.

Ok, whoever it is that have "the yellow one" in custody, prepare to bring it out in about 30 minutes.

/me ducks.

LOL

You mean ?

Yes, exactly that one. So it was you who had it in custody. Well, it's time to release the little bugger..

Its now four and a half hours since the 30 minute duck warning and no sign of him. I wonder if the fact that I have just roasted his legs and they are now in my belly along with half a bottle of chianti could have anything to do with it.

My kitties said to tell you he was delicious! :-)

---

PROUD MEMBER OF Team Starfire World BOINC

All seems well (aside from the much nicer limits for you power crunchers). The avian friend is happy, and my cache is full..with the correct ETAs I might add.

---

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

As you know, I reverted my host 3751792 to stock when you reported the 'no work to stock GPUs' bug earlier this week.

I'm seeing correct runtime estimates with a DCF currently around 1.2 (it'll drop back again when I reach the next batch of shorties). Since I'm running GPU only, and the card is well fast enough to show APR/estimate anomalies, I'm assuming that the 'non-anonymous-platform' bits of [trac]changeset:24217[/trac] were never applied here, even though we know the change in the ratio limit from 2 to 10 is active. I think the verdict on the APR outlier code is the old Scottish standby of 'not proven', but we ought to test it sometime, for both the stock and anonymous platform cases.
...

For any host with more than 20 validations for an app_version, it's nearly inconceivable that APR/estimates anomalies will make much difference.

For non-anonymous hosts the APR is sent to the host as the <flops> for that app version, so the ratio limit of 10 would have to be exceeded between two requests to the Scheduler for any capping to take place. 1.01^231 = 9.96 so even 231 near zero validated runtimes wouldn't get into the capping. OTOH assuming the APR was about right before that, that shift of ~10 would put the host on the border of the range where -177 elapsed time exceeded errors could happen.

For anonymous hosts where the users are allowing totally inadequate <flops> based on the Whetstone benchmark to be sent by the core client, it is effectively guaranteed that estimates for most GPU processing will be a mess. Those who are getting by because DCF down near 0.02 is enough to compensate for the bad <flops> are merely in danger of DCF going even lower and restricting work fetch, whatever happens to APR matters not since the user has chosen to operate in the zone where the server estimate is always capped.

For all host app versions, the first 10 validations are critical. If the APR isn't somewhat reasonable at that point it will take a lot of good runtimes to shift it to a better approximation. That's where the runtime_outlier logic will be helpful, and I too hope the Astropulse validator code will be updated soon. The project gets about 600 new hosts a day (either really new or new hostID), it's not nice to leave them exposed to a known weakness in the system.

                                                                 Joe

For all host app versions, the first 10 validations are critical. If the APR isn't somewhat reasonable at that point it will take a lot of good runtimes to shift it to a better approximation. That's where the runtime_outlier logic will be helpful, and I too hope the Astropulse validator code will be updated soon. The project gets about 600 new hosts a day (either really new or new hostID), it's not nice to leave them exposed to a known weakness in the system.

                                                                 Joe

And when v7 goes live on SETI, the project will get about a quarter of a million new hosts in the first month - at least, as far as the application_details are concerned. We really ought to prevail on David to consider that number before the event.....

Anonymous_platform hosts return their GPU hardware characteristics in sched_request. I really don't see why that can't be used to seed APR with a first approximation, instead of using a totally irrelevant CPU metric.

Are there any plans of making version 6.12 usable by high end hosts before trying to roll to V7?

---

Janice

Are there any plans of making version 6.12 usable by high end hosts before trying to roll to V7?

Versions of what?

The discussion with Joe was about the SETI science application - currently at v6.03 for CPUs, v6.08/09/10 for CUDA GPUs.

Version 6.12 sounds like a BOINC version number - I'm not having any problems with BOINC v6.12.34, though I don't run what you would call a 'high end host'.

What issues make it unusable? I haven't seen any reported on the boinc_alpha mailing list: that would be a better venue for discussing boinc issues than here, though I can pass on messages if needed.

Still nothing uploading from here. I do not believe Bruno is allowing them. I see his vote monitor function is disabled.

---

Why would it start now? Never happened before.

---