Message boards : BOINC client : Unrecognised tag in cc_config.xml
Message board moderation
Author | Message |
---|---|
Send message Joined: 5 Jul 08 Posts: 33 |
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 |
Send message Joined: 5 Jul 08 Posts: 33 |
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: 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? |
Send message Joined: 5 Jul 08 Posts: 33 |
Yes remove. 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 |
![]() Send message Joined: 20 Dec 07 Posts: 1069 ![]() |
... 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) ![]() |
Send message Joined: 5 Jul 08 Posts: 33 |
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 |
![]() Send message Joined: 29 Aug 05 Posts: 15585 ![]() |
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. |
![]() Send message Joined: 20 Dec 07 Posts: 1069 ![]() |
Hi Gundolf, 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 |
Send message Joined: 5 Jul 08 Posts: 33 |
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 |
Send message Joined: 5 Jul 08 Posts: 33 |
They're the "maximum number of file transfers" settings, both total and per-project. 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 |
![]() Send message Joined: 29 Aug 05 Posts: 15585 ![]() |
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. ;-) |
Send message Joined: 5 Jul 08 Posts: 33 |
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 |
![]() Send message Joined: 29 Aug 05 Posts: 15585 ![]() |
To Ageless: It's in the BOINC FAQ Service. (plug, plug) ;-) |
Send message Joined: 6 Dec 06 Posts: 118 ![]() |
Dagorath wrote: To Ageless: 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. |
Send message Joined: 6 Dec 06 Posts: 118 ![]() |
Dagorath wrote: To Ageless: 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. |
Copyright © 2025 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.