Posts by Alexander Klietz

1) Message boards : BOINC Manager : BOINC, DepSpid & DynDNS (Message 7607)
Posted 19 Jan 2007 by Profile Alexander Klietz
Post:
Thanks a lot for your replies, Kathryn and Aurora B.

I read the thread over at the DepSpid forum and did the suggested tests with TCPview and nslookup. I tested it with 5.4.11 on one system and 5.8.1 on another (which is what I had installed up to now). It's quite obvious that BOINC is using an 'old' IP instead of the current one (today 82.83.207.33) until it is restarted.

Now I have upgraded the 5.8.1 installation to 5.8.3 (which does indeed use a new libcurl: 7.16.0 instead of 7.15.5). Let's see what happens tomorrow.

Furthermore, I played a little bit with the client_state files, namely the tag

<scheduler_url>http://depspid.dyndns.org/cgi/index.cgi</scheduler_url>


there. I suspended cpu and network activity in BOINC (without closing it) so that it doesn't update the client_state files anymore. Then I changed "depspid.dyndns.org" to the current IP adress and cancelled suspension again. BOINC updated the client_state files and wrote the original domain name into it, overwriting the changes.

So, I guess, BOINC is fetching the scheduler url from the master_url on each connection attempt, right?

If yes, another idea, if you don't mind:

The homepage of DepSpid currently has the following scheduler tag:

<!--
      <scheduler>http://depspid.dyndns.org/cgi/index.cgi</scheduler>
-->


What would happen, if a second tag would be added which uses the current IP adress instead of the domain name? Something like this:

<!--
      <scheduler>http://depspid.dyndns.org/cgi/index.cgi</scheduler>
      <scheduler>http://82.83.xxx.xxx/cgi/index.cgi</scheduler>
-->


If I understand this page from the BOINC website correctly (see the paragraph titled "The master URL"), then it is possible to have more than one scheduler url and BOINC would parse them all. Would BOINC even accept an IP address instead of a domain name? Most TCP/IP programs do, but you never know... ;-)

I am aware, that the IP address would have to be changed every day, but if this can be done by a script, it might not be a big deal.

Am I completely off or is it worth a suggestion?

Regards

Alex
2) Message boards : BOINC Manager : BOINC, DepSpid & DynDNS (Message 7573)
Posted 18 Jan 2007 by Profile Alexander Klietz
Post:
Hello,

DepSpid is using DynDNS and so it gets everyday a new IP adress, afaik. Apparently BOINC can not handle this and you have to stop and restart it before it reports finished results and downloads new work (after the IP of the project changed).

My question: Is there any way to update DNS / IPs for BOINC without restarting it? Are those IPs stored at a place which is accessible?

I've tried a 'flushdns' which didn't help and I searched through some of the xmls in the BOINC directory but did not find anything obvious.

If you run BOINC only on one computer and all other projects are checkpointing then it is not a big issue to restart BOINC once a day. But if you have a number of PCs (as I do, and some of those have no monitor, keyboard or other needless stuff) then it can be quite annoying.

Any solution (including not-so-kosher hacks)? Thanks in advance.

Regards

Alex

Excerpt from the messages:

18.01.2007 20:00:00|DepSpid|Sending scheduler request: To fetch work
18.01.2007 20:00:00|DepSpid|Requesting 1 seconds of new work
18.01.2007 20:00:22||Project communication failed: attempting access to reference site
18.01.2007 20:00:24||Access to reference site succeeded - project servers may be temporarily down.
18.01.2007 20:00:26|DepSpid|Scheduler request failed: couldn't connect to server
18.01.2007 20:00:26|DepSpid|Deferring communication 2 hours, 30 minutes and 57 seconds, because scheduler request failed
18.01.2007 20:34:25|DepSpid|[file_xfer] Started upload of file spider_24215_0.xml
18.01.2007 20:34:48||Project communication failed: attempting access to reference site
18.01.2007 20:34:48|DepSpid|[file_xfer] Temporarily failed upload of spider_24215_0.xml: system connect
18.01.2007 20:34:48|DepSpid|Backing off 47 minutes and 24 seconds on upload of file spider_24215_0.xml
18.01.2007 20:34:50||Access to reference site succeeded - project servers may be temporarily down.
3) Message boards : BOINC Manager : How to force report when 1 project down? (Message 7299)
Posted 7 Jan 2007 by Profile Alexander Klietz
Post:
Hello teemac,

what you describe is indeed a very odd problem. Normally one project does not interfere with the network communications of another, just as Aurora Borealis has described it.

I'm attached to more than a dozen of projects including Einstein, Malaria and Rosetta and I also have a Ubuntu 6.10 box running BOINC 5.4.11 (edit: sorry, I confused it with the Windows version. I'm still running 5.4.9 on Ubuntu), but I have never experienced the bug you describe.

Please try the following:

- Make sure you can reach both Rosetta and Malariacontrol with your Browser for example, both projects should be up in the moment.

- Make sure your BOINC manager is set to 'always connect to the network' (to rule out any problems with settings in the preferences).

- Then I would recommend to stop Einstein in the 'projects' tab and try another manual 'update' of Rosetta and Malariacontrol. Please check in the 'messages' tab if the scheduler is contacted.

Hope this helps. If not, there would be one last straw: Detaching Einstein, but this would mean that you definitely loose all your Einstein workunits, which is why I would try to avoid it.

Good luck.

Alex
4) Message boards : BOINC client : Cache sizes in Computer summaries not correct, any negative effect? (Message 6590)
Posted 23 Nov 2006 by Profile Alexander Klietz
Post:
Thanks for the reply.

The one with the 'correct' cache size detected is running on Linux (Ubuntu 6.10), the other three on Windows (XP or 2k). Well, that's the most obvious difference at least.

Ok, this might be reason: I just checked this workunit from Docking@home. All three results reported are coming from Linux clients (it's my first D@h result which was credited, that's why I remember :-) ) and all seem to have correct cache sizes (at least all are reasonable for the cpu names given).

Maybe this is the reason for the lower credits on Linux systems compared to Win boxes :-) ... just kidding.

Alex
5) Message boards : BOINC client : Cache sizes in Computer summaries not correct, any negative effect? (Message 6583)
Posted 23 Nov 2006 by Profile Alexander Klietz
Post:
Hello.

I just stumbled across some differences between the cache sizes as noted in the computer summaries and the 'real' cache sizes of the used cpus. I haven't found anything in the forum search here, but I guess it has been asked before. ;-) Hope you don't mind asking.


  • Is there any negative effect, if the cache sizes found by BOINC are not correct?
  • Is the cache size only shown for information or is it somehow 'used' by BOINC to optimize performance?
  • Can it / Should it be changed to the correct value?



Examples from my computers:


  • Athlon64 3200+
    Cache according to BOINC: 976.56 KB
    Real L2 cache: 1,024 KB
    -> not quite right
  • Athlon XP 2400+
    Cache according to BOINC: 256 KB
    Real L2 cache: 256 KB
    -> correct
  • AMD K6-III
    Cache according to BOINC: 976.56 KB
    Real L2 cache: 256 KB
    (plus L3 cache with 2048 KB)
    -> way off
  • AMD K6-2+
    Cache according to BOINC: 976.56 KB
    Real L2 cache: 128 KB
    (plus L3 cache with 512 KB)
    -> way off



As all wrong values read 976.56 KB, is this some kind of default value?

Thanks in advance for any improved insight. :-)

Regards

Alex

6) Message boards : BOINC client : Excessive size of stderr.txt after graphics displayed on Linux w/ ATI Radeon (Message 6471)
Posted 15 Nov 2006 by Profile Alexander Klietz
Post:
I first mentioned this problem to the QMC Forum (thread is here, but is in German language). Martin Korth from the QMC team kindly pointed me to this bug report on freedesktop.org, which might be related to the problem experienced here.

Hope this helps other users to prevent similar problems. The most simple workaround appears to be not to display any graphical output.

Best regards

Alexander Klietz
7) Message boards : BOINC client : Excessive size of stderr.txt after graphics displayed on Linux w/ ATI Radeon (Message 6470)
Posted 15 Nov 2006 by Profile Alexander Klietz
Post:
And this shows the contents of one of the slots. Please note the size of the stderr.txt file here:

8) Message boards : BOINC client : Excessive size of stderr.txt after graphics displayed on Linux w/ ATI Radeon (Message 6469)
Posted 15 Nov 2006 by Profile Alexander Klietz
Post:
The following screenshot shows the disk space taken by two slots running QMC@home after the graphical output has been started:



9) Message boards : BOINC client : Excessive size of stderr.txt after graphics displayed on Linux w/ ATI Radeon (Message 6468)
Posted 15 Nov 2006 by Profile Alexander Klietz
Post:
Here are some technical details about the system:

OS: Ubuntu 6.10 (Linux 2.6.17-10-generic) for Intel x86
BOINC version: boinc_5.4.9_i686-pc-linux-gnu
SETI@home Beta application: setiathome_enhanced 5.17
QMC@home application: Amolqc-beta 5.07

Graphics card: ATI Radeon 9800 Pro (R350) using default driver from Ubuntu 6.10
Other hardware: please see computer summary.

And here is the beginning of the contents of both stderr.txt files:

1. stderr.txt from QMC@home


------
libGL warning: 3D driver claims to not support visual 0x4b
app_graphics_init() called.
scene_init() called.
Scene initialized.
Try R300_SPAN_DISABLE_LOCKING env var if this hangs.
*********************************WARN_ONCE*********************************
File r300_render.c function r300Fallback line 412
Software fallback:ctx->Line.SmoothFlag
***************************************************************************
freeglut ERROR: Function <glutDestroyWindow> called without first calling 'glutInit'.
freeglut ERROR: Function <glutMainLoop> called without first calling 'glutInit'.
freeglut ERROR: Function <glutMainLoop> called without first calling 'glutInit'.
freeglut ERROR: Function <glutMainLoop> called without first calling 'glutInit'.
freeglut ERROR: Function <glutMainLoop> called without first calling 'glutInit'.
freeglut ERROR: Function <glutMainLoop> called without first calling 'glutInit'.
freeglut ERROR: Function <glutMainLoop> called without first calling 'glutInit'.
freeglut ERROR: Function <glutMainLoop> called without first calling 'glutInit'.
freeglut ERROR: Function <glutMainLoop> called without first calling 'glutInit'.
freeglut ERROR: Function <glutMainLoop> called without first calling 'glutInit'.


2. stderr.txt from SETI@home Beta


Work Unit Info:
...............
WU true angle range is : 0.426138
Optimal function choices:
-----------------------------------------------------
name timing error
-----------------------------------------------------
v_BaseLineSmooth 0.43251 0.00000
v_GetPowerSpectrum 0.00283 0.00000
v_ChirpData 0.10632 0.00000
v_Transpose4 0.05310 0.00000
libGL warning: 3D driver claims to not support visual 0x4b
*********************************WARN_ONCE*********************************
File r300_render.c function r300Fallback line 412
Software fallback:ctx->Line.SmoothFlag
***************************************************************************
Try R300_SPAN_DISABLE_LOCKING env var if this hangs.
setiathome-5.17.i686-pc-linux-gnu: freeglut_structure.c:439: fgEnumWindows: Assertion `fgState.Initialised' failed.
SIGABRT: abort called
Stack trace (18 frames):
setiathome-5.17.i686-pc-linux-gnu(boinc_catch_signal+0x91)[0x81400b1]
[0xffffe420]
[0xffffe410]
/lib/tls/i686/cmov/libc.so.6(gsignal+0x50)[0xb7e14770]
/lib/tls/i686/cmov/libc.so.6(abort+0x103)[0xb7e15ef3]
/lib/tls/i686/cmov/libc.so.6(__assert_fail+0xfb)[0xb7e0ddbb]
../../projects/setiweb.ssl.berkeley.edu_beta/setiathome-5.17.i686-pc-linux-gnu.so(fgEnumWindows+0x73)[0xb7dbf853]
../../projects/setiweb.ssl.berkeley.edu_beta/setiathome-5.17.i686-pc-linux-gnu.so(fgWindowByID+0x26)[0xb7dbfa06]
../../projects/setiweb.ssl.berkeley.edu_beta/setiathome-5.17.i686-pc-linux-gnu.so(glutDestroyWindow+0x14)[0xb7dc0394]
../../projects/setiweb.ssl.berkeley.edu_beta/setiathome-5.17.i686-pc-linux-gnu.so(_Z10KillWindowv+0x33)[0xb7db09d7]
../../projects/setiweb.ssl.berkeley.edu_beta/setiathome-5.17.i686-pc-linux-gnu.so[0xb7db0b8d]
../../projects/setiweb.ssl.berkeley.edu_beta/setiathome-5.17.i686-pc-linux-gnu.so(_Z24xwin_graphics_event_loopv+0x122)[0xb7db1256]
../../projects/setiweb.ssl.berkeley.edu_beta/setiathome-5.17.i686-pc-linux-gnu.so(boinc_init_options_graphics_impl+0x47)[0xb7dab9ff]
setiathome-5.17.i686-pc-linux-gnu(_Z31boinc_init_options_graphics_libR13BOINC_OPTIONSPFvvEPc+0x122)[0x8148726]
setiathome-5.17.i686-pc-linux-gnu(boinc_init_graphics_lib+0x53)[0x814885f]
setiathome-5.17.i686-pc-linux-gnu(main+0x245)[0x808f075]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xdc)[0xb7e008cc]
setiathome-5.17.i686-pc-linux-gnu[0x808ecf1]

Exiting...
setiathome-5.17.i686-pc-linux-gnu: freeglut_main.c:1069: glutMainLoop: Assertion `fgState.Initialised' failed.
SIGABRT: abort called
Stack trace (14 frames):
setiathome-5.17.i686-pc-linux-gnu(boinc_catch_signal+0x91)[0x81400b1]
[0xffffe420]
[0xffffe410]
/lib/tls/i686/cmov/libc.so.6(gsignal+0x50)[0xb7e14770]
/lib/tls/i686/cmov/libc.so.6(abort+0x103)[0xb7e15ef3]
/lib/tls/i686/cmov/libc.so.6(__assert_fail+0xfb)[0xb7e0ddbb]
../../projects/setiweb.ssl.berkeley.edu_beta/setiathome-5.17.i686-pc-linux-gnu.so(glutMainLoop+0xa1)[0xb7dbd721]
../../projects/setiweb.ssl.berkeley.edu_beta/setiathome-5.17.i686-pc-linux-gnu.so(_Z24xwin_graphics_event_loopv+0xe2)[0xb7db1216]
../../projects/setiweb.ssl.berkeley.edu_beta/setiathome-5.17.i686-pc-linux-gnu.so(boinc_init_options_graphics_impl+0x47)[0xb7dab9ff]
setiathome-5.17.i686-pc-linux-gnu(_Z31boinc_init_options_graphics_libR13BOINC_OPTIONSPFvvEPc+0x122)[0x8148726]
setiathome-5.17.i686-pc-linux-gnu(boinc_init_graphics_lib+0x53)[0x814885f]
setiathome-5.17.i686-pc-linux-gnu(main+0x245)[0x808f075]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xdc)[0xb7e008cc]
setiathome-5.17.i686-pc-linux-gnu[0x808ecf1]



Screenshot to follow...
10) Message boards : BOINC client : Excessive size of stderr.txt after graphics displayed on Linux w/ ATI Radeon (Message 6467)
Posted 15 Nov 2006 by Profile Alexander Klietz
Post:
Hello,

I would like to point to a potential problem when running BOINC with a graphical output on a Linux system with a ATI Radeon R3xx card (such as Radeon 9800 Pro):

The stderr.txt file starts to grow to an excessive size, in my case up to a maximum of 15 GB during approx. 10 minutes, it only stopped at this size because the hard disk (or file system) was full! Apparently the max. disk use value set in preferences does not have any effect in limiting the file size here!

This was observed both with the QMC@home client and the SETI@home Beta client with graphical output. It did not appear (on my system) with the Einstein@home client, however. Others I haven't tested so far.

Stopping the project in the BOINC manager does not stop the increasing of the file size, closing the BOINC manager apparently does stop the increase.

I would recommend, that anyone who has a similar system should be aware of this potential problem.

I include some technical details and screenshots in separate posts to this thread.

Best regards

Alex



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.