Unrecognised tag in cc_config.xml

Message boards : BOINC client : Unrecognised tag in cc_config.xml
Message board moderation

To post messages, you must log in.

AuthorMessage
dividedbymyself

Send message
Joined: 5 Jul 08
Posts: 33
Message 18662 - Posted: 20 Jul 2008, 13:20:34 UTC

Hi,

I'm running Boinc (v. 5.10.45) on two computers and both give the same error immediately after starting Boinc:

Unrecognized tag in cc_config.xml: <work_request_factor>
Unrecognized tag in cc_config.xml: <measurementbenchmark_debug>

On one of my computers I do have problems with it downloading too much work that won't finish before the deadline, could this be caused by these errors? And if so, what can I do to correct this?

Thanks for any advise,

Bart
ID: 18662 · Report as offensive
dividedbymyself

Send message
Joined: 5 Jul 08
Posts: 33
Message 18666 - Posted: 20 Jul 2008, 15:42:02 UTC - in response to Message 18665.  

They rang a bell but are not legal in that form. The FAQ's/Wiki's shows what's allowed and with what client version:

http://boincfaq.mundayweb.com/index.php?language=1&view=91&sessionID=eff2c289401f3b411e2fd047057571b9
#http://boinc.berkeley.edu/trac/wiki/ClientMessages



I can't find them on those pages at all, so should I just delete them from the cc_config.xml file to get rid of the error messages?
ID: 18666 · Report as offensive
dividedbymyself

Send message
Joined: 5 Jul 08
Posts: 33
Message 18668 - Posted: 20 Jul 2008, 16:12:48 UTC - in response to Message 18667.  
Last modified: 20 Jul 2008, 16:14:00 UTC

Yes remove.

The first of the 2 I loosely remember as being disabled. For completeness maybe the documentation should include them if so and from what version outed. The second is I think just malformed and unclear as to why you have these 2.

And, obviously, they don't account for you getting too much work.



I've been thinking about it how I got them since you said they are not legal. I think I've been fooling around with the Boincview core client configuration once already quite some time ago and that's how they got into the file, though I can't be sure it happened that way, I can't think of any other way either.

Anyway, I removed those lines from the file and now the error messages are no more.

Thanks for your help.

Bart
ID: 18668 · Report as offensive
Profile Gundolf Jahn

Send message
Joined: 20 Dec 07
Posts: 1069
Germany
Message 18669 - Posted: 20 Jul 2008, 16:49:35 UTC - in response to Message 18662.  

...
On one of my computers I do have problems with it downloading too much work that won't finish before the deadline, could this be caused by these errors? And if so, what can I do to correct this?

As Sekerob pointed out, the unrecognised tags don't cause your problems. If you get too much work units, you have to adjust XX in
Computer is connected to the Internet about every XX days
(Leave blank or 0 if always connected. BOINC will try to maintain at least this much work.)
and
Maintain enough work for an additional XX days
in the preferences of your account at the affected project or
Connect about every XX days and Additional work buffer
in your local preferences.

Gruß,
Gundolf
Computer sind nicht alles im Leben. (Kleiner Scherz)
ID: 18669 · Report as offensive
dividedbymyself

Send message
Joined: 5 Jul 08
Posts: 33
Message 18683 - Posted: 20 Jul 2008, 22:22:34 UTC - in response to Message 18669.  

Hi Gundolf,

I've set "Computer is connected to the Internet about every XX days" to 0 (I'm always connected) and I've set "Maintain enough work for an additional XX days" to 3 days.
This problem started when I attached to Malariacontrol, as they've a very short deadline. Then I changed Malaria to my other computer, and ABC from that one to the one that first had malaria (I exchanged them). Now ABC doesn't have such a short deadline at all, but still it downloaded a lot of work and went into priority mode right away. I solved that again by attaching more projects on that computer, so there's always plenty of work available on that computer, without only a few projects with short WU's having to fill 3 days by downloading a lot of work.
So I can say the problem is solved, but the solution is not very elegant.

I only just think of another possible solution, but I don't know if it would work as I haven't tried it yet and I'm not eager to try as it involves the cc_config.xml file again that I can change with the Boincview core client configuration that I assume, made the erroneous tags I just removed. They're the "maximum number of file transfers" settings, both total and per-project. Maybe when downloading several WU's at the same time, calculations get messed up or something, and I could set them both to 1. But I think this is not the cause of the problem to be honest. Still I don't know what it is...

Bart
ID: 18683 · Report as offensive
Profile Jord
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 29 Aug 05
Posts: 15486
Netherlands
Message 18685 - Posted: 20 Jul 2008, 22:39:23 UTC - in response to Message 18683.  

They're the "maximum number of file transfers" settings, both total and per-project.

Open cc_config.xml with Notepad.
Add to it:

<cc_config>
<log_flags>
<benchmark_debug>1</benchmark_debug>
<options>
<max_file_xfers>your number</max_file_xfers>
<max_file_xfers_per_project>your number</max_file_xfers_per_project>
</options>
<cc_config>


Save file with the File->Save option.

Only add those parts you don't have yet, check their spelling in case they are already there. Some have changed 'name'. I added your benchmark debug output as well.
ID: 18685 · Report as offensive
Profile Gundolf Jahn

Send message
Joined: 20 Dec 07
Posts: 1069
Germany
Message 18692 - Posted: 20 Jul 2008, 23:40:28 UTC - in response to Message 18683.  
Last modified: 20 Jul 2008, 23:41:05 UTC

Hi Gundolf,

I've set "Computer is connected to the Internet about every XX days" to 0 (I'm always connected) and I've set "Maintain enough work for an additional XX days" to 3 days.

Sounds reasonable :-)
This problem started when I attached to Malariacontrol, as they've a very short deadline. Then I changed Malaria to my other computer, and ABC from that one to the one that first had malaria (I exchanged them). Now ABC doesn't have such a short deadline at all, but still it downloaded a lot of work and went into priority mode right away...

Did you read Ageless's response in Questions and problems: Projects Running Past Deadline? It's about Milkyway, but perhaps BOINC has still to adjust the <duration_correction_factor> for Malariacontrol after your swapping of computers.

Gruß,
Gundolf
ID: 18692 · Report as offensive
dividedbymyself

Send message
Joined: 5 Jul 08
Posts: 33
Message 18718 - Posted: 21 Jul 2008, 20:01:43 UTC
Last modified: 21 Jul 2008, 20:05:16 UTC

I'll post my responses to Ageless, Gundolf and Dagorath (good to see you here as well:) )in this one message.

Ageless first. Tanks for the advise, I'll edit the file later to see what's going to happen. I don't need to try the benchmark debug again, or any kind of debug, as all of that is abracadabra to me anyway. I only switched them on to see what it was some time ago, but when I saw what happened, I switched them off again ASAP.

Now to both the other rescue workers.
The additional work buffer shouldn't be the problem for ABC. Their deadline is normally about a week, so 3 days of buffer can't be too much for that one, and as I've attached that to this machine not too long ago the problem could still be the duration factor that has to settle. I'll have to wait and see. For malariacontrol things are different, their deadline is about 3 days. I've been told on the forum over there that I should have a max. workbuffer of 1.45 days or something like that, to overcome some factor that's built in Boinc itself. Normally I'm always connected, but I've had technical problems already a few times, interrupting my connection for a few days, that's why I choose to set it to 3 days. As on my other computer I never had this problem with ABC, or any other project, I choose to switch them so I didn't need to adjust this setting. But to be complete, I've had the "over-download" thing happening to Yoyo as well a couple of times, on the same machine that gave problems with malaria. When I exchanged ABC and malaria, I switched yoyo as well to where malaria was before, so this could also still be the duration factor.
Now both ABC and Yoyo have been crunching the hell out of themselves to overcome their emergencies (and I deleted some of them as well), and now their long term debt is pretty low, so I'll have to wait what's going to happen when they start downloading new work again.

I'll change the settings Jord gave me and I'll report back overhere, or open a new thread if I run into problems again.

Thanks for the advice guys.

Bart
ID: 18718 · Report as offensive
dividedbymyself

Send message
Joined: 5 Jul 08
Posts: 33
Message 19527 - Posted: 17 Aug 2008, 10:35:58 UTC - in response to Message 18685.  

They're the "maximum number of file transfers" settings, both total and per-project.

Open cc_config.xml with Notepad.
Add to it:

<cc_config>
<log_flags>
<benchmark_debug>1</benchmark_debug>
<options>
<max_file_xfers>your number</max_file_xfers>
<max_file_xfers_per_project>your number</max_file_xfers_per_project>
</options>
<cc_config>


Save file with the File->Save option.

Only add those parts you don't have yet, check their spelling in case they are already there. Some have changed 'name'. I added your benchmark debug output as well.


Hi Jord,

I've been running into deadline problems again because of short deadlines, now with Poem@home, so I tried to add both max_file_xfers parameters (my number set to 1 on both), but they are not recognised again.

I noticed I already had the <file_xfer>1</file_xfer> tag in the cc_config file, probably by default, which doesn't give an error. Now I don't know if this means my max-download is already set to 1 this way, I haven't been around to specifically watch it happen so far.

Do you know if this tag already regulates the max-download?

I hope you can explain.

Thanks,
Bart

ID: 19527 · Report as offensive
Profile Jord
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 29 Aug 05
Posts: 15486
Netherlands
Message 19533 - Posted: 17 Aug 2008, 13:17:15 UTC - in response to Message 19527.  

I already had the <file_xfer>1</file_xfer> tag in the cc_config file, probably by default

Apropos of nothing, there is nothing in cc_config.xml by default as this file isn't made by BOINC. It's made by you, all entries in it are entered by you. So someone, most probably you, must have put it in there. ;-)
ID: 19533 · Report as offensive
dividedbymyself

Send message
Joined: 5 Jul 08
Posts: 33
Message 19534 - Posted: 17 Aug 2008, 13:49:59 UTC - in response to Message 19533.  

To Ageless:
I think the file was made when I was fooling around with the Boincview core manager, I didn't do it manually anyway. I've got no knwledge of it, so I wouldn't even know how to set it up, as you might have noticed.

To Sekarob:
I know these tags are for simultanious downloads, that's why I wanted to know if it would make a difference so Boinc wouldn't download too much as it might get "confused" about time-calculations when downloading several WU's at the same time. I already mentioned before I thought it would probably not matter, and so far I still don't know. But I'll see what's gonna happen again in the next weeks.

Thanks for your replies,

Bart
ID: 19534 · Report as offensive
Profile Jord
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 29 Aug 05
Posts: 15486
Netherlands
Message 19535 - Posted: 17 Aug 2008, 14:08:38 UTC - in response to Message 19534.  

To Ageless:
I think the file was made when I was fooling around with the Boincview core manager, I didn't do it manually anyway. I've got no knwledge of it, so I wouldn't even know how to set it up, as you might have noticed.

It's in the BOINC FAQ Service. (plug, plug) ;-)
ID: 19535 · Report as offensive
BobCat13

Send message
Joined: 6 Dec 06
Posts: 118
United States
Message 19544 - Posted: 17 Aug 2008, 21:51:36 UTC - in response to Message 19538.  

Dagorath wrote:
To Ageless:
I think the file was made when I was fooling around with the Boincview core manager


Boincview doesn't touch that file.


Yes, it does. There is an option in BV named "Open BOINC core client configuration" that allows the user to change the cc_config.xml settings. If there is no cc_config.xml, one will be created when clicking the "Save to computer" button.
ID: 19544 · Report as offensive
BobCat13

Send message
Joined: 6 Dec 06
Posts: 118
United States
Message 19550 - Posted: 18 Aug 2008, 3:53:19 UTC - in response to Message 19548.  

Dagorath wrote:
To Ageless:
I think the file was made when I was fooling around with the Boincview core manager


Boincview doesn't touch that file.


Yes, it does. There is an option in BV named "Open BOINC core client configuration" that allows the user to change the cc_config.xml settings. If there is no cc_config.xml, one will be created when clicking the "Save to computer" button.


Thanks for the info. My mistake for not looking at Boincview for a while. Do you suppose Boincview wrote the tags incorrectly?

Those tags were correct for cc ver. 5.8.xx which was probably the current version when BoincView was coded. Core client ver. 5.10.xx either changed or eliminated those tags.

Anyway, putting the tags right isn't going to solve his problem. It might appear to go away for a while and he may credit the correct tags for making the problem go away but it will return.

Only way to fix too many tasks downloading on a project that has short deadlines or variable runtimes is to use a very small cache setting, i.e. 0.1 days.

Superlink behaves the same way with their 48 hour deadline and differing runtime from batch to batch. I tried using a 16 hour cache and when it got a batch of tasks that ran 4 times as long as the previous batch, the machine went into EDF mode for an entire day.
ID: 19550 · Report as offensive

Message boards : BOINC client : Unrecognised tag in cc_config.xml

Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.