Grant you are a long playing record that has got stuck, and a very wrong oner at that.

Over the weekend there was NO AP PRODUCTION, and the servers were behaving just as bad as they are now with AP production.

Grant will be right at home on these message boards, we're all long-playing records here.

But actually, I'm with him here. My observations were that the scheduler was considerably freeer, both faster to respond and more likely to allocate MB work (even when both requests and reports were combined in a single update), starting from the time when the last of the then-loaded tapes had its last AP tasks split (or when I got up on Monday morning, which was a few hours later).

Now the timeouts are almost certain again, I'm about to try a little experiment: sitting at a machine with dual monitors (BOINC Manager open on one, the same host's website task list on the other), I'm going to see how long the delay is between the scheduler request being made and the ghosts appearing on the website. From preliminary observations with two separate computers (when variations in local clock settings come into play), my guess is 'seconds at most'. Then, I may have to dig out the old Wireshark to see what packets appear on the line, and when.

Ah well, Murphy strikes again. Just as I settle down in front of the dual monitors on host 2901600, it fetches three times in succession without a timeout - just topping up to the 100 quota level. And I can't get any more until the next one finishes....

Time for a cup of coffee before we start on a run of shorties - I'll have an excuse for a fetch every five minutes, once they start.

Edit - mind you, although I may have had three allocated on the last three contacts, I haven't been able to download any of them yet. But that's another story.

Both the two old tasks reported, and the two new tasks assigned, got a server time stamp of 14 Nov 2012 | 21:00:52 UTC (I'd done a special clock synchronisation before I started, so the times should be pretty good). So, the scheduler's actual work was completed in under five seconds, but it took almost two more minutes for the reply to reach me.

Could you do the same test with the AP-splitters stoped? and/or with the use of a proxie... that could be very interesting...

What i'd like to see is as a test, run the scheduler off the Campus Network, that would help prove whether the Hurricane link and associated routers was the problem (which are almost always heavily loaded),
or whether the problem was a bit more upstream,

Well, my "ghosts-only" machine (Unimatrix02) has gotten down to about 700 ghosts (nothing in the machine itself - he did get some resent WUs rather sporadically since my last msg, but never got near 100 in the machine) and gets Timeouts all the time now on work requests...this sucks!

I infer from above that the staff doesn't want to bother with the (potential) workaround of shutting down AP production for awhile...
do they care about work not getting done?

Ive found that using a proxy I can get the scheduller to answer but then all the downloads fails... if I take out the proxy, then the downloads succeed but the scheduller fails...
So turning on and off the proxy Im slowly getting the ghosts downloaded and also Ive got an asignment of 155 new tasks for an almost dried host...

There is something else going on here and may be the usuall suspects are not guilty this time... May be some router failling like last year?

Ive found that using a proxy I can get the scheduller to answer but then all the downloads fails... if I take out the proxy, then the downloads succeed but the scheduller fails...
So turning on and off the proxy Im slowly getting the ghosts downloaded and also Ive got an asignment of 155 new tasks for an almost dried host...

There is something else going on here and may be the usuall suspects are not guilty this time... May be some router failling like last year?

That's why i'd like to see them try the Campus Network and ISP, using a Proxy might be bypassing some or all of the Hurricane Network/ISP,

Ive found that using a proxy I can get the scheduller to answer but then all the downloads fails... if I take out the proxy, then the downloads succeed but the scheduller fails...
So turning on and off the proxy Im slowly getting the ghosts downloaded and also Ive got an asignment of 155 new tasks for an almost dried host...

There is something else going on here and may be the usuall suspects are not guilty this time... May be some router failling like last year?

That's why i'd like to see them try the Campus Network and ISP, using a Proxy might be bypassing some or all of the Hurricane Network/ISP,

Claggy

Try this proxie: 8.21.6.225 port 80, it works very fast on both directions... > 50Kbps

Ive found that using a proxy I can get the scheduller to answer but then all the downloads fails... if I take out the proxy, then the downloads succeed but the scheduller fails...
So turning on and off the proxy Im slowly getting the ghosts downloaded and also Ive got an asignment of 155 new tasks for an almost dried host...

There is something else going on here and may be the usuall suspects are not guilty this time... May be some router failling like last year?

That's why i'd like to see them try the Campus Network and ISP, using a Proxy might be bypassing some or all of the Hurricane Network/ISP,

Claggy

Try this proxie: 8.21.6.225 port 80, it works very fast on both directions... > 50Kbps

Grant you are a long playing record that has got stuck, and a very wrong oner at that.

Over the weekend there was NO AP PRODUCTION, and the servers were behaving just as bad as they are now with AP production.

rob, there's something wrong at your end. I was waiting for the AP Splitters to stop to try to get to the scheduler with one of my computers that could not make a successful Scheduler contact to report many hours of work.

When the AP Splitters stopped, after hours of having zero luck, I was able to do the following:

Your assertion that things did not get better is simply not-true. It may be 100% true for you which would point to a problem you continued to have, but for "the rest" of us there was a direct correlation to the AP Splitters running and our inability to report. As soon as the AP Splitters stopped running (meaning AP work was still in distribution, just not being split), things got miraculously better.