Switched, busy...

[Pepo]

I must admit that the "Switched, busy..." text in the status bar is killing my patience. I was looking around for any description of this state and the single place whitch mentions it was pretty unrelated

... the status box (third from right at on the bottom row), which usually says "updating very briefly, then a count-down from 5 seconds to next update, instead said "switched, busy" for a while, perhaps 20 seconds. Then it changed to "updating..."

without any explanation.

Thus the big question from me, Fred: WHAT is happening under the BT's hoods, when it has to keep this message displayed for a long while, exactly each time I enter any tab's page, and if I want to switch from the tab to another one or click anything else prior to finishing this page's update, the clicks are just buffered and buffered and buffered...

Is it necessary to postpone any other GUI activity (like entering any tab or menu or dialog) until this particular one page is refreshed? (Is it because the same thread (as GUI) is waiting for network data?)

[fred]

What happens when you hit a tab:

1) The "Switch busy" text will be shown.
2) The screen contents will be updated. In other words a request is send to all computers.

But the computer on the other side may be busy handling other previous requests. Or BOINC is busy with something and responds slowly to the RPC requests from BT.
As soon a the new request for a screen update starts the new text will appear.

[Pepo]

Could the communication with all possible connected computers and GUI updates be done asynchronously? At least, when I click through 7 different tabs, their pages could be rendered with the last known contents... And when new data comes in, the currently displayed page can be refreshed. The data is anyway coming in continuously, approx. on the predefined intervals.

[fred]

Could the communication with all possible connected computers and GUI updates be done asynchronously? At least, when I click through 7 different tabs, their pages could be rendered with the last known contents... And when new data comes in, the currently displayed page can be refreshed. The data is anyway coming in continuously, approx. on the predefined intervals.

I could make an option not to refresh immediately and let the regular interval take over. It will take some time before you get the most recent data but it will not stress the system as it does now.

[Pepo]

Could the communication with all possible connected computers and GUI updates be done asynchronously? At least, when I click through 7 different tabs, their pages could be rendered with the last known contents... And when new data comes in, the currently displayed page can be refreshed. The data is anyway coming in continuously, approx. on the predefined intervals.

I could make an option not to refresh immediately and let the regular interval take over. It will take some time before you get the most recent data but it will not stress the system as it does now.

I'm looking forward!

BTW, how old data is displayed on the pages? I was in belief that the complete data is continuously coming in and is parsed and displayed by any page. (At least in case of Messages it must be so, because the client keeps only the last 2k, but BT is capable of correctly displaying the whole hundred thousands when displaying Messages after many days. Just the display list creation takes some time and BT possibly has just to check whether the particular client really still adds messages with correctly incremented ID?)

But as I've checked now, each other tab seems to initially display the same data I've seen maybe yesterday evening, and just after successfully getting an update from connected clients, the page is refreshed. Am I (approximately) right? If so, can the pages be first refreshed with some recent data already abroad?

[fred]

I'm looking forward!

BTW, how old data is displayed on the pages? I was in belief that the complete data is continuously coming in and is parsed and displayed by any page. (At least in case of Messages it must be so, because the client keeps only the last 2k, but BT is capable of correctly displaying the whole hundred thousands when displaying Messages after many days. Just the display list creation takes some time and BT possibly has just to check whether the particular client really still adds messages with correctly incremented ID?)

But as I've checked now, each other tab seems to initially display the same data I've seen maybe yesterday evening, and just after successfully getting an update from connected clients, the page is refreshed. Am I (approximately) right? If so, can the pages be first refreshed with some recent data already abroad?

It may be a couple of hours old. As the window is closed, there is almost no activity, except the history fetching.
But I'm not sure what causes your problem.
Basically only the Tasks and History tab may take some time to process all the data.

Is there anyone else, who recognizes these problems.

[Pepo]

But as I've checked now, each other tab seems to initially display the same data I've seen maybe yesterday evening, and just after successfully getting an update from connected clients, the page is refreshed. Am I (approximately) right? If so, can the pages be first refreshed with some recent data already abroad?

It may be a couple of hours old. As the window is closed, there is almost no activity, except the history fetching.

The data which is necessary to keep the history up-to-date - that's at least the list of active and finished tasks. Is this not enough to refresh the Tasks tab?

But I'm not sure what causes your problem.

Maybe I do not have anything here you'd consider being a problem
Kidding... Could you+someone else check the following switch times?

Basically only the Tasks and History tab may take some time to process all the data.

When I try to check all tabs, I can sequentially click on them. Then it takes approx. 20 seconds for each one (Computers, Projects, Tasks, Transfers, Messages, History) to refresh and switch to another busy one. I have currently 2 hosts defined (localhost + one offline external) and 5 seconds manual refresh rate. There are 38 (12 active) tasks aboard.

[fred]

The data which is necessary to keep the history up-to-date - that's at least the list of active and finished tasks. Is this not enough to refresh the Tasks tab?
No not nearly.

The refresh on my computers take < 1 second with 4 computers and 6000+ tasks. But that's on a local net.

So probably the remote computer has a slow connection. And what is slow can't become fast, whatever you do.

[Pepo]

The refresh on my computers take < 1 second with 4 computers and 6000+ tasks. But that's on a local net.

So probably the remote computer has a slow connection. And what is slow can't become fast, whatever you do.

No, my remote computer is off (Status: "Connected, Not connected" or "Not connected", it depends...) and not even on the same network now... and if, then it's 100 Mbit over 5 meter.
That must be something else then than the remote one.


I've tried to restart BT. Now it takes your 1 second
Messages? Stack?

[jjwhalen]

I've been watching this thread with interest.  I've got 2 remotes plus localhost attached to BT, all on a local 100Mb subnet, with a typical total of 1100~1300 tasks across the population.  Even after BT has run continuously for >1week, mostly minimized, I've never seen the Tasks tab take >2sec to refresh (i.e., Switched, busy).  So

[jjwhalen]

I've been watching this thread with interest.  I've got 2 remotes plus localhost attached to BT, all on a local 100Mb subnet, with a typical total of 1100~1300 tasks across the population.  Even after BT has run continuously for >1week, mostly minimized, I've never seen the Tasks tab take >2sec to refresh (i.e., Switched, busy).  So

I seem to recall Pepo saying recently that he's running BOINC 6.11.6/6.11.7 on his hosts.  On a hunch I changed my hosts over from 6.10.58 to the β 6.11.7 and now I'm seeing BT behavior very similar to what Pepo describes.  It's possible there are incompatibilities in the RPC calls from BT, the XML from the 6.11.x client, or both.  What about those Notices the new client sends to BM, that display on the Notices tab and popup in the notification area?  Could they be causing BT's XML parser to choke?

I'll be rolling BOINC back to 6.10.58 pending further dialog on this subject.  If you need further testing, Fred, let me know

[fred]

I seem to recall Pepo saying recently that he's running BOINC 6.11.6/6.11.7 on his hosts.  On a hunch I changed my hosts over from 6.10.58 to the β 6.11.7 and now I'm seeing BT behavior very similar to what he describes.  It's possible there are incompatibilities in the RPC calls from BT, the XML from the 6.11.x client, or both.  What about those Notices the new client sends to BM, that display on the Notices tab and popup in the notification area?  Could they be causing BT's XML parser to choke?

I'll be rolling BOINC back to 6.10.58 pending further dialog on this subject.  If you need further testing, Fred, let me know

\Hmm it may be a but in the BOINC software as this is a real beta version.
It's almost impossible to keep up with all the beta's and test them all.

But it may be that things are not quite compatible.
I may install a beta on my development machine to start implementing the Notices.

[Pepo]

I seem to recall Pepo saying recently that he's running BOINC 6.11.6/6.11.7 on his hosts.  On a hunch I changed my hosts over from 6.10.58 to the β 6.11.7 and now I'm seeing BT behavior very similar to what Pepo describes.  It's possible there are incompatibilities in the RPC calls from BT.....

Could off course be. It is not so long ago some change in the RPC handshake broke its communication with BoincView...

BT runs on the machine with 6.11.6. As I've restarted BT, It had no contact to the machine with 6.11.7, the last one was some week ago (Sunday), but I do not remember whether the tabs' slugishness has been ever since, or appeared at some later point.

I'll try to update the machine to 6.11.7 and will see.

[jjwhalen]

Whatever is causing the slowdown in refresh at the BT end survived the rollback to BOINC 6.10.58  (i.e., uninstall of the 6.11.7, install of 6.10.58).  It also survived a shutdown/restart of BT, as well as a reboot of all 3 computers.  I was forced to uninstall/reinstall BT 0.74 to restore an (apparently) normal refresh cycle.  Weird, huh

--EDIT--Forgot to mention: I did not see this behavior a few weeks ago when I tried out BOINC 6.11.6 on my hosts for a brief period (this was before 6.11.7 was released for testing purposes).  Hmm...

[Pepo]

Weird, huh

Absolutely! You are outperforming my observations