Doubt about linux benchmark and some docking users

Message boards : Number crunching : Doubt about linux benchmark and some docking users

Author	Message
daniele Volunteer tester Joined: Oct 23 06 Posts: 86 ID: 190 Credit: 6,702 RAC: 0	Message 1248 - Posted 3 Nov 2006 14:42:10 UTC Last modified: 3 Nov 2006 14:51:10 UTC
	Hi all :) Since credits are assigned with the "man-in-the-middle" (I don't know the real name) """algorithm""" ("""""""""""), problems related to fairness are increased. Why this? I understand that benchmarks are not suitable to test a linux system, and there's no problem, but many linux hosts claims for an amount of credits which is far far far lower than the unfair amount deriving from the benchmark. How could it happen that an Athlon XP 2600 claims for nearly half the credits I claim for with my XP 2400+? The same is for many hosts I "met" on my way crunching. So I have a doubt. How many zillions of processes are you running on your systems? Are you sure you're not running the entire services collection in your distro? But the real question is (I ask because today I've seen this happening! I would never have thought about this): are you sure you are not running the client itself with nice 19? This sometimes happens with Fedora and similar, and it's a totally wrong thing to do. If the client runs with nice 19 the benchmark will give very low results if only a service moves in your system while the benchmark is running. If there's an interrupt by whatever, the benchmark nearly stops, because it's veeery nice to others processes. I understand low results, ok, I've already said this. But not an Opteron "running" slower than an Athlon, this is not possible, and not an XP2600+ claiming for half the credits than my XP2400+ for the same WU in the same cpu time. I think you agree with this statement: in an ideal condition, any host running the same WU in any cpu time, should claim for the same credit. If it doesn't happen, it's sure that there are hosts not running in the proper way. Also if the benchmark is a bad one, the total claimed credit should be the same. CPU time will change if you're running other processes, but if the WU takes double time and your cpu power is at half, you'll ask for the same credit. So, ask. I will (don't know when) proceed with a list of linux users who are claiming for too little credit.
	ID: 1248 \| Rating: 0 \| rate: /

Andre Kerstens Forum moderator Project tester Volunteer tester Joined: Sep 11 06 Posts: 749 ID: 1 Credit: 15,199 RAC: 0	Message 1251 - Posted 3 Nov 2006 21:50:06 UTC - in response to Message ID 1248 .
	Daniele, It is by now well known that the standard boinc benchmarks give much lower numbers than the same benchmarks on windows (on the same hardware). There is a discussion on the boinc_dev (or boinc_projects, can't remember anymore) ongoing how this can be changed. As a matter of fact, because of this inequality between platforms we are planning to stop using the boinc benchmarks all together and use other metrics for credit assignment like Rosetta and CPDN do. Cheers Andre Hi all :) Since credits are assigned with the "man-in-the-middle" (I don't know the real name) """algorithm""" ("""""""""""), problems related to fairness are increased. Why this? I understand that benchmarks are not suitable to test a linux system, and there's no problem, but many linux hosts claims for an amount of credits which is far far far lower than the unfair amount deriving from the benchmark. How could it happen that an Athlon XP 2600 claims for nearly half the credits I claim for with my XP 2400+? The same is for many hosts I "met" on my way crunching. So I have a doubt. How many zillions of processes are you running on your systems? Are you sure you're not running the entire services collection in your distro? But the real question is (I ask because today I've seen this happening! I would never have thought about this): are you sure you are not running the client itself with nice 19? This sometimes happens with Fedora and similar, and it's a totally wrong thing to do. If the client runs with nice 19 the benchmark will give very low results if only a service moves in your system while the benchmark is running. If there's an interrupt by whatever, the benchmark nearly stops, because it's veeery nice to others processes. I understand low results, ok, I've already said this. But not an Opteron "running" slower than an Athlon, this is not possible, and not an XP2600+ claiming for half the credits than my XP2400+ for the same WU in the same cpu time. I think you agree with this statement: in an ideal condition, any host running the same WU in any cpu time, should claim for the same credit. If it doesn't happen, it's sure that there are hosts not running in the proper way. Also if the benchmark is a bad one, the total claimed credit should be the same. CPU time will change if you're running other processes, but if the WU takes double time and your cpu power is at half, you'll ask for the same credit. So, ask. I will (don't know when) proceed with a list of linux users who are claiming for too little credit. ____________ D@H the greatest project in the world... a while from now!
	ID: 1251 \| Rating: 0 \| rate: /

daniele Volunteer tester Joined: Oct 23 06 Posts: 86 ID: 190 Credit: 6,702 RAC: 0	Message 1252 - Posted 4 Nov 2006 1:47:50 UTC - in response to Message ID 1251 .
	It is by now well known that the standard boinc benchmarks give much lower numbers than the same benchmarks on windows (on the same hardware). Yes, as I told that's not real a problem for me, I understand that it's fair if I leave credits to winsicure users, as I have a good and secure OS. I can't have all the best things for me, so I'm generous and leave my credit for them. :P What I meant is it's not normal (of course it is normal, but it shouldn't be) that an Athlon XP 2600+ with linux (nearly the same kernel as mine) claims for 2/3 of the credit for the same WU in the same CPU time. When I crunch a WU with it as a companion, I receive 6 credit per hour claiming for 8,5. And There's another Athlon XP (2700+) in the same situation, an Opteron(!!) crunching for 6 hours and claiming for 20 total credits O_O There are many cases like these, let's say one in 3 crunched WUs, and This is not only the benchmark, this could be a problem in those systems. I only wanted to let this guys know that their linux boxes aren't running properly. Maybe it's boinc's fault, maybe not. Could be many causes together. As a matter of fact, because of this inequality between platforms we are planning to stop using the boinc benchmarks all together and use other metrics for credit assignment like Rosetta and CPDN do. I've read about this, I think it's the best solution for users regarding fairness. Probably it's not the best one for being used as a term of comparison between projects with different directions and admins, unless there's a guidance by someone. ANyway I'm crunching more and more for d@h, credits are not important by themselves, and I'm rather waiting for new results from the project. Bye :)
	ID: 1252 \| Rating: 0 \| rate: /

[B^S] Doug Worrall Volunteer tester Joined: Sep 13 06 Posts: 127 ID: 74 Credit: 11,046 RAC: 0	Message 1253 - Posted 4 Nov 2006 3:02:55 UTC Last modified: 4 Nov 2006 3:09:08 UTC
	Good News Andre, When, is Docking going to stop using the Linux Benchmark Process, and give claimed credit, by a timed w/u? Success Done 5,363.78 6.91 19.03 This is an example, Boinc wants to give me 6.91, yet, seeing as they donnot use the Benchmark process, you get what is "desrved" nearly 20 credits for 1 and a half hours. Sincerely Doug
	ID: 1253 \| Rating: 0 \| rate: /

Conan Volunteer tester Joined: Sep 13 06 Posts: 219 ID: 100 Credit: 4,256,493 RAC: 0	Message 1259 - Posted 6 Nov 2006 2:48:31 UTC
	> I may as well get in early the, please don't copy Rosetta for their crediting system. I believe it to be flawed and still open to a form of unfair claiming (some call cheating), where the first result returned gets full cobblestone claim, while the later ones get a lower average. This encourages people to do ultra short run times so they can be the first to return results. It may still be a good system but needs to be modified for fairness overall. I am not sure exactly how CPDN or Einstein do it but there does not appear to be anyone complaining about granted cobblestones from these projects and a check with my own computers shows Windows and Linux get about the same credits. Rosetta now also gives significantly lower cobblestones/hour than most of my other projects (still double what Docking gives my linux machines). Rosetta also differs in that amount awarded changes with every Protein sequence that is processed as each will give different results. One other thing I don't understand with Rosetta is how I can be matched up with someone who does 1 hour runs and I am doing 6 hour runs, surely I am doing far more Science for the project and should be rewarded for this? Is Docking going to introduce a parameter where the user can change how long they process a Workunit like Rosetta does? ____________
	ID: 1259 \| Rating: 0 \| rate: /

Dagorath Joined: Sep 18 06 Posts: 38 ID: 116 Credit: 4,866 RAC: 0	Message 1261 - Posted 6 Nov 2006 4:40:32 UTC - in response to Message ID 1248 . Last modified: 6 Nov 2006 4:41:29 UTC
	But the real question is (I ask because today I've seen this happening! I would never have thought about this): are you sure you are not running the client itself with nice 19? This sometimes happens with Fedora and similar, and it's a totally wrong thing to do. I run BOINC on Fedora Core 5. I start BOINC at boot with the following lines added to the end of /etc/profile: ulimit -s unlimited cd /home/me/bin/BOINC ./run_manager & The /home/me/bin/BOINC/run_manager file is: cd /home/me/bin/BOINC exec ./boincmgr $@ As far as I can see I am not running BOINC with nice 19 but the benchmarks and credit claims are very low compared to what I get when that computer crunches under Windoze. I am another Linux newbie and I wonder... maybe some line in some other script is causing BOINC to run with nice 19?
	ID: 1261 \| Rating: 0 \| rate: /

daniele Volunteer tester Joined: Oct 23 06 Posts: 86 ID: 190 Credit: 6,702 RAC: 0	Message 1272 - Posted 6 Nov 2006 12:06:08 UTC - in response to Message ID 1261 . Last modified: 6 Nov 2006 12:06:34 UTC
	But the real question is (I ask because today I've seen this happening! I would never have thought about this): are you sure you are not running the client itself with nice 19? This sometimes happens with Fedora and similar, and it's a totally wrong thing to do. I run BOINC on Fedora Core 5. I start BOINC at boot with the following lines added to the end of /etc/profile: ulimit -s unlimited cd /home/me/bin/BOINC ./run_manager & The /home/me/bin/BOINC/run_manager file is: cd /home/me/bin/BOINC exec ./boincmgr $@ As far as I can see I am not running BOINC with nice 19 but the benchmarks and credit claims are very low compared to what I get when that computer crunches under Windoze. I am another Linux newbie and I wonder... maybe some line in some other script is causing BOINC to run with nice 19? I don't know FC very well, but you can try this ps -eo ni,args\|grep boinc The first coulumn is the NICE value, it should be 0 for the client. If it's 0, your problem should be another one. How many credits per hour do you claim for, in default conditions?
	ID: 1272 \| Rating: 0 \| rate: /

daniele Volunteer tester Joined: Oct 23 06 Posts: 86 ID: 190 Credit: 6,702 RAC: 0	Message 1273 - Posted 6 Nov 2006 12:10:17 UTC - in response to Message ID 1259 . Last modified: 6 Nov 2006 12:11:47 UTC
	... the first result returned gets full cobblestone claim, while the later ones get a lower average. This encourages people to do ultra short run times so they can be the first to return results. I agree with you, it happened to me few days ago to receive 90+ credits for a WU lasting 3 hours. At the moment I didn't realize that I could be the first to return that WU, but probably I was.
	ID: 1273 \| Rating: 0 \| rate: /

Dagorath Joined: Sep 18 06 Posts: 38 ID: 116 Credit: 4,866 RAC: 0	Message 1276 - Posted 6 Nov 2006 12:46:52 UTC - in response to Message ID 1272 .
	I don't know FC very well, but you can try this ps -eo ni,args\|grep boinc The first coulumn is the NICE value, it should be 0 for the client. If it's 0, your problem should be another one. The output is... 0 ./boincmgr 0 ./boinc -redirectio -insecure 0 grep boinc OK, so boinc is running at nice 0. How many credits per hour do you claim for, in default conditions? Here at D@H I was completing WUs in about 1hr 20 min and claiming 9 credits. That's about 7 credits per hour, most of the time that machine does very little other work.
	ID: 1276 \| Rating: 0 \| rate: /

Andre Kerstens Forum moderator Project tester Volunteer tester Joined: Sep 11 06 Posts: 749 ID: 1 Credit: 15,199 RAC: 0	Message 1287 - Posted 6 Nov 2006 16:27:07 UTC - in response to Message ID 1259 .
	I don't know Rosetta that well, so are there more details on this parameter? Andre Is Docking going to introduce a parameter where the user can change how long they process a Workunit like Rosetta does? ____________ D@H the greatest project in the world... a while from now!
	ID: 1287 \| Rating: 0 \| rate: /

David Ball Forum moderator Volunteer tester Joined: Sep 18 06 Posts: 274 ID: 115 Credit: 1,634,401 RAC: 0	Message 1290 - Posted 6 Nov 2006 22:48:22 UTC - in response to Message ID 1287 .
	I don't know Rosetta that well, so are there more details on this parameter? Andre Is Docking going to introduce a parameter where the user can change how long they process a Workunit like Rosetta does? They talk about it HERE It's slightly outdated in that the run time can now be selected from 1 hour to 24 hours and defaults to 3 hours. -- David
	ID: 1290 \| Rating: 0 \| rate: /

daniele Volunteer tester Joined: Oct 23 06 Posts: 86 ID: 190 Credit: 6,702 RAC: 0	Message 1305 - Posted 7 Nov 2006 11:28:50 UTC - in response to Message ID 1276 . Last modified: 7 Nov 2006 11:32:11 UTC
	Here at D@H I was completing WUs in about 1hr 20 min and claiming 9 credits. That's about 7 credits per hour, most of the time that machine does very little other work. This is the problem which we have to concentrate on. If your Athlon 64 runs for 1,5 hours and claims for 9 credits, and one core of my CoreDuo@2GHz runs for 3 hours and claims for 30 credits (for a similar WU), then our hosts are claiming for nearly the same number of credits per hour, but they shouldn't. If the work done is the same, the claimed credits should be the same. Before saying this, however, we have to know if the WU "contains" exactly the same work when running on different systems. Also your celeron, crunching for 3 hours, claims for half the credits I claim for. This could be right only if the work done is half the work I do on my hosts. If the work is the same, than your systems are claiming respectively for one third and half the credits than mine. Without going any further for now, the problem could be "distro-related". In few days, when I finish my current work, I want to set up a poll in order to know how the claimed credits are distributed "per distro". Anyway I hope that we'll soon use another way for granting credits :)
	ID: 1305 \| Rating: 0 \| rate: /

daniele Volunteer tester Joined: Oct 23 06 Posts: 86 ID: 190 Credit: 6,702 RAC: 0	Message 1306 - Posted 7 Nov 2006 11:34:53 UTC - in response to Message ID 1287 . Last modified: 7 Nov 2006 11:46:03 UTC
	I don't know Rosetta that well, so are there more details on this parameter? Andre Is Docking going to introduce a parameter where the user can change how long they process a Workunit like Rosetta does? That's an interesting additional parameter for "fine tuning", but it's not so important at this moment. First we (you) should grant credits based on the work done (not on the benchmark results), then you can dinamically change the work per WU. edit: I read about the changes that will occur in the client (and its benchmark) for linux in few weeks, so this could be another way of solving the problem. Let's see what happens. I also read your post in another thread saying that it would be better to solve the problem at root, and make all projects use only one credits system. This would be nice too, but I don't think this will happen in short time for the biggest projects. Would be nice for small starting projects, anyway.
	ID: 1306 \| Rating: 0 \| rate: /

Andre Kerstens Forum moderator Project tester Volunteer tester Joined: Sep 11 06 Posts: 749 ID: 1 Credit: 15,199 RAC: 0	Message 1312 - Posted 8 Nov 2006 0:49:42 UTC - in response to Message ID 1305 .
	For this alpha, the generated workunits have exactly the same number of FLOPS. Andre If the work done is the same, the claimed credits should be the same. ____________ D@H the greatest project in the world... a while from now!
	ID: 1312 \| Rating: 0 \| rate: /

Webmaster Yoda Volunteer tester Joined: Nov 14 06 Posts: 43 ID: 271 Credit: 6,498 RAC: 0	Message 1621 - Posted 26 Nov 2006 6:28:21 UTC - in response to Message ID 1312 . Last modified: 26 Nov 2006 7:23:29 UTC
	For this alpha, the generated workunits have exactly the same number of FLOPS. I don't yet have conclusive evidence, but am running some tests on my Athlon XP 3000+ which previously crunched with Windows 2000 Professional. I'm now running it with Puppy Linux. http://docking.utep.edu/show_host_detail.php?hostid=760 (Windows) http://docking.utep.edu/show_host_detail.php?hostid=1032 (Linux) With Windows, it took approx. 6.5 hours per work unit. I won't know for a few hours yet, but I have set it up with Puppy Linux and it looks like the first work unit will take under 4 hours (38.124% complete after 01:26:02). The interesting thing to me is that Linux boxes could thus get more credit (per CPU hour) than identical boxes running Windows if we go to Flops counting. But perhaps I'm missing something here. EDIT: Unfortunately the first WU errored out after 2:20 hours Docking@Home 26/11/2006 15:09:34 Unrecoverable error for result 1tng_mod0001_12704_112971_2 (process got signal 11) I'm letting it upload the huge error log in the hope it helps the project.
	ID: 1621 \| Rating: 0 \| rate: /

Andre Kerstens Forum moderator Project tester Volunteer tester Joined: Sep 11 06 Posts: 749 ID: 1 Credit: 15,199 RAC: 0	Message 1623 - Posted 26 Nov 2006 20:03:58 UTC - in response to Message ID 1621 . Last modified: 26 Nov 2006 20:11:41 UTC
	Hi Yoda, Thanks for letting that logfile upload. It was not that huge was it: only 8 MB ;-) Anyway, the reason the result errored out is memory problems during the energy minimization phase. This is what the logfile showed: *** LEVEL -4 WARNING FROM <VEHEAP> * * COULD NOT SATISFY STORAGE REQUEST. ************************************** BOMLEV ( -1) IS REACHED - TERMINATING. WRNLEV IS 0 * LEVEL -4 WARNING FROM <LINKHP> * * OVERLAP AT BEGINNING OF FREE LIST. **************************************** BOMLEV ( -1) IS REACHED - TERMINATING. WRNLEV IS 0 Basically it means that Charmm does a request to the OS to get some memory on the heap, but doesn't get it (the could not satisfy storage message above). After that Charmm exits. The question is now why this is happening? I see that your machine has 512 MB of memory. Is it swapping to disk at the moment Charmm exits? How much memory do you allow boinc (and thus the app) to use (I believe that's a preference setting)? Were any other applications that need a lot of memory running at the time? Regarding the difference between linux and windows: yes there will be a difference. Charmm has originally been developed for UNIX (and later Linux) and was never meant to run on Windows (who would ever run a scientific application on Windows? ;-), but of course then BOINC came around and since most volunteers run Windows (unfortunately...) the Scripps team has ported Charmm to windows. But it won't run as fast windows as on a unix-based platform (for the moment). Also, there is currently a big difference in the results of the benchmarks that the BOINC client runs before you get work. This is due to the fact that the Linux BOINC client hasn't been compiled with all the optimizations like they have done for the Windows client. Of course this makes a big difference for the credit system. I understand that this will be corrected in the next release. Hope that explanation helps. Thanks Andre For this alpha, the generated workunits have exactly the same number of FLOPS. I don't yet have conclusive evidence, but am running some tests on my Athlon XP 3000+ which previously crunched with Windows 2000 Professional. I'm now running it with Puppy Linux. http://docking.utep.edu/show_host_detail.php?hostid=760 (Windows) http://docking.utep.edu/show_host_detail.php?hostid=1032 (Linux) With Windows, it took approx. 6.5 hours per work unit. I won't know for a few hours yet, but I have set it up with Puppy Linux and it looks like the first work unit will take under 4 hours (38.124% complete after 01:26:02). The interesting thing to me is that Linux boxes could thus get more credit (per CPU hour) than identical boxes running Windows if we go to Flops counting. But perhaps I'm missing something here. EDIT: Unfortunately the first WU errored out after 2:20 hours Docking@Home 26/11/2006 15:09:34 Unrecoverable error for result 1tng_mod0001_12704_112971_2 (process got signal 11) I'm letting it upload the huge error log in the hope it helps the project. ____________ D@H the greatest project in the world... a while from now!
	ID: 1623 \| Rating: 0 \| rate: /

KSMarksPsych Volunteer tester Joined: Sep 13 06 Posts: 26 ID: 87 Credit: 8,222 RAC: 0	Message 1625 - Posted 26 Nov 2006 23:58:40 UTC
	The memory prefernces are only available in the alpha version of the BOINC software right now. David and/or Rom have asked the alpha testers to give that a good testing.
	ID: 1625 \| Rating: 0 \| rate: /

Webmaster Yoda Volunteer tester Joined: Nov 14 06 Posts: 43 ID: 271 Credit: 6,498 RAC: 0	Message 1627 - Posted 27 Nov 2006 2:10:26 UTC - in response to Message ID 1623 .
	Hi Yoda, Thanks for letting that logfile upload. It was not that huge was it: only 8 MB ;-) Anyway, the reason the result errored out is memory problems during the energy minimization phase. This is what the logfile showed: *** LEVEL -4 WARNING FROM <VEHEAP> * * COULD NOT SATISFY STORAGE REQUEST. ************************************** BOMLEV ( -1) IS REACHED - TERMINATING. WRNLEV IS 0 * LEVEL -4 WARNING FROM <LINKHP> * * OVERLAP AT BEGINNING OF FREE LIST. ************************************** BOMLEV ( -1) IS REACHED - TERMINATING. WRNLEV IS 0 Basically it means that Charmm does a request to the OS to get some memory on the heap, but doesn't get it (the could not satisfy storage message above). After that Charmm exits. The question is now why this is happening? I see that your machine has 512 MB of memory. Is it swapping to disk at the moment Charmm exits? How much memory do you allow boinc (and thus the app) to use (I believe that's a preference setting)? Were any other applications that need a lot of memory running at the time? I allow BOINC to use up to 75% of total virtual memory and (apart from the tiny O/S) it was running nothing but BOINC. The WU had not finished, BOINC is set to keep applications in memory, but as Docking is the only project it's attached to, there should have been no swapping. The second WU finished without incident (in 3:45 hours). I'm aware of the credit/benchmarks issue. I just ran Docking under Linux for testing, not for the credit. But if we go to FLOPS counting or fixed credit, Linux should get its revenge :D ____________ Join the #1 Aussie Alliance on Docking@Home**
	ID: 1627 \| Rating: 0 \| rate: /

suguruhirahara Forum moderator Volunteer tester Joined: Sep 13 06 Posts: 282 ID: 15 Credit: 56,614 RAC: 0	Message 1628 - Posted 27 Nov 2006 11:09:06 UTC - in response to Message ID 1623 .
	Hi Andre, A bit off-topic, The question is now why this is happening? I see that your machine has 512 MB of memory. Is it swapping to disk at the moment Charmm exits? How much memory do you allow boinc (and thus the app) to use (I believe that's a preference setting)? Were any other applications that need a lot of memory running at the time? If there aren't plenty of available RAM and charmm need to use swap, does the application run so unstably, enough to cause 0x1 incorrect function? It's like science applications of climateprediction.net;-) Also I've never seen the error on linux, except the case where I forgot to set ulimit to unlimited. Regarding the difference between linux and windows: yes there will be a difference. Charmm has originally been developed for UNIX (and later Linux) and was never meant to run on Windows (who would ever run a scientific application on Windows? ;-), but of course then BOINC came around and since most volunteers run Windows (unfortunately...) the Scripps team has ported Charmm to windows. But it won't run as fast windows as on a unix-based platform (for the moment). Unfortunately to utilize the resources of PC one must optimise source code for windows or mac... please keep up nice works:) ____________ I'm a volunteer participant; my views are not necessarily those of Docking@Home or its participating institutions.
	ID: 1628 \| Rating: 0 \| rate: /

Andre Kerstens Forum moderator Project tester Volunteer tester Joined: Sep 11 06 Posts: 749 ID: 1 Credit: 15,199 RAC: 0	Message 1648 - Posted 29 Nov 2006 4:33:43 UTC - in response to Message ID 1628 .
	If there aren't plenty of available RAM and charmm need to use swap, does the application run so unstably, enough to cause 0x1 incorrect function? It's like science applications of climateprediction.net;-) Also I've never seen the error on linux, except the case where I forgot to set ulimit to unlimited. We honestly don't know yet. In fortran speak, this error is very general and can be caused by anything. Since we have a hard time reproducing it in our lab (we have about 25 different computer architectures running linux, windows and mac) we're having a hard time finding out what causes this... We'll keep on testing though! Hopefully charmm c33b1 will solve this problem, although we can't be completely sure of that. [quote] Unfortunately to utilize the resources of PC one must optimise source code for windows or mac... please keep up nice works:) We will!! Thanks for your good work on the forums Suguru :-) Andre ____________ D@H the greatest project in the world... a while from now!
	ID: 1648 \| Rating: 0 \| rate: /

Message boards : Number crunching : Doubt about linux benchmark and some docking users

Database Error
: The MySQL server is running with the --read-only option so it cannot execute this statement

array(3) {
  [0]=>
  array(7) {
    ["file"]=>
    string(47) "/boinc/projects/docking/html_v2/inc/db_conn.inc"
    ["line"]=>
    int(97)
    ["function"]=>
    string(8) "do_query"
    ["class"]=>
    string(6) "DbConn"
    ["object"]=>
    object(DbConn)#25 (2) {
      ["db_conn"]=>
      resource(102) of type (mysql link persistent)
      ["db_name"]=>
      string(7) "docking"
    }
    ["type"]=>
    string(2) "->"
    ["args"]=>
    array(1) {
      [0]=>
      &string(50) "update DBNAME.thread set views=views+1 where id=90"
    }
  }
  [1]=>
  array(7) {
    ["file"]=>
    string(48) "/boinc/projects/docking/html_v2/inc/forum_db.inc"
    ["line"]=>
    int(60)
    ["function"]=>
    string(6) "update"
    ["class"]=>
    string(6) "DbConn"
    ["object"]=>
    object(DbConn)#25 (2) {
      ["db_conn"]=>
      resource(102) of type (mysql link persistent)
      ["db_name"]=>
      string(7) "docking"
    }
    ["type"]=>
    string(2) "->"
    ["args"]=>
    array(3) {
      [0]=>
      object(BoincThread)#3 (16) {
        ["id"]=>
        string(2) "90"
        ["forum"]=>
        string(1) "2"
        ["owner"]=>
        string(3) "190"
        ["status"]=>
        string(1) "0"
        ["title"]=>
        string(50) "Doubt about linux benchmark and some docking users"
        ["timestamp"]=>
        string(10) "1164774823"
        ["views"]=>
        string(4) "1410"
        ["replies"]=>
        string(2) "19"
        ["activity"]=>
        string(20) "1.5735231723376e-127"
        ["sufferers"]=>
        string(1) "0"
        ["score"]=>
        string(1) "0"
        ["votes"]=>
        string(1) "0"
        ["create_time"]=>
        string(10) "1162564930"
        ["hidden"]=>
        string(1) "0"
        ["sticky"]=>
        string(1) "0"
        ["locked"]=>
        string(1) "0"
      }
      [1]=>
      &string(6) "thread"
      [2]=>
      &string(13) "views=views+1"
    }
  }
  [2]=>
  array(7) {
    ["file"]=>
    string(63) "/boinc/projects/docking/html_v2/user/community/forum/thread.php"
    ["line"]=>
    int(184)
    ["function"]=>
    string(6) "update"
    ["class"]=>
    string(11) "BoincThread"
    ["object"]=>
    object(BoincThread)#3 (16) {
      ["id"]=>
      string(2) "90"
      ["forum"]=>
      string(1) "2"
      ["owner"]=>
      string(3) "190"
      ["status"]=>
      string(1) "0"
      ["title"]=>
      string(50) "Doubt about linux benchmark and some docking users"
      ["timestamp"]=>
      string(10) "1164774823"
      ["views"]=>
      string(4) "1410"
      ["replies"]=>
      string(2) "19"
      ["activity"]=>
      string(20) "1.5735231723376e-127"
      ["sufferers"]=>
      string(1) "0"
      ["score"]=>
      string(1) "0"
      ["votes"]=>
      string(1) "0"
      ["create_time"]=>
      string(10) "1162564930"
      ["hidden"]=>
      string(1) "0"
      ["sticky"]=>
      string(1) "0"
      ["locked"]=>
      string(1) "0"
    }
    ["type"]=>
    string(2) "->"
    ["args"]=>
    array(1) {
      [0]=>
      &string(13) "views=views+1"
    }
  }
}

query: update docking.thread set views=views+1 where id=90