I guess Richard's technique does work. But, when I did drink beer, I didn't drink before 5 or 6 in the afternoon. It's morning here. :)

You could drink coffee, tea, water, or whatever you like, what is important is to take your mind out of the problem and relax. The problem will eventually be fixed and normally we can't do anything to help. Just maybe send an email to the lab guy's warning them about the problem as some does.

---

My problem is, I'm running Linux and don't have a clue about programming and compiling on Linux. :(

You don't have to understand programming, you just have to follow a recipe.

1) ./_autosetup
2) ./configure
3) ./make

Then your cake is baked.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

My problem is, I'm running Linux and don't have a clue about programming and compiling on Linux. :(

You don't have to understand programming, you just have to follow a recipe.

1) ./_autosetup
2) ./configure
3) ./make

Then your cake is baked.

Hi Keith,

Yeah, that seems to be the easy part. I'm talking about the source code and how many files it comprises and what to go through to alter the code, etc... :\ Oh and where to put the source code and what to transfer to the BOINC directory etc., etc. I really do not think I'm up to attempting to try.

When I made that statement about "spoofing" I was just stating that I can see a point to doing it since it doesn't take long for a GPU to get through a cache of WUs. With expected or unexpected outages, it can come in handy. :)

Have a great day! :)

Siran

---

CAPT Siran d'Vel'nahr - L L & P _\\//
Winders 11 OS? "What a piece of junk!" - L. Skywalker
"Logic is the cement of our civilization with which we ascend from chaos using reason as our guide." - T'Plana-hath

You could achieve the same goal without the need of compiling by using rescheduling. There are a lots of program available to do that. Some on this forums. Just need to dig a little.

I`m glad to here now you understand why we need to spoofing, the simple answer, the builds & GPU are so fast so a 100 WU limit is unreal.

---

Back to the thread topic.

Did anyone really knows why the Apache server stops to work on every Sunday morning?

As posted by Richard before, 3 times in a row it's hard to believe is a coincidence.

---

With 'spoofing' I can get any amount of GPU tasks but if the outage is longer than about 6 hours, I'll run out of CPU tasks too.

Spoofing the CPU count would be useless as Seti@Home only gives you 100 CPU tasks no matter how many CPU cores you have but I do have an idea about how to get more. I just haven't implemented it yet.

My idea is this: when the CPU gets close to starving, make the GPU donate a bunch of tasks to the CPU. This can be done with an external program with no need to modify Boinc client.

---

My idea is this: when the CPU gets close to starving, make the GPU donate a bunch of tasks to the CPU. This can be done with an external program with no need to modify Boinc client.

That's the idea behind "rescheduling"

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

I don't have too, just follow the instructions in: https://boinc.berkeley.edu/trac/wiki/CompileClient
The code is in the standard C++, last time i see something like it was >35 Years ago in my engineering school.
About the outage, that was fast! I only could drink a couple of beers. You see Richard technique works perfect. LOL

. . Thanks for that link but I think I will be up for a lot of reading before I would be ready to try it.

. . And I vote [1] for Richard (and Wiggos) technique.

Stephen

8^{

Hi Juan,
Sorry, but I'm not even going to attempt that. I dabbled in C++ programming and some B.A.S.I.C., but gave it up because my brain was not up to the task. It takes way too long for me to learn things, especially complicated things like computer programming. So, I stay away from it even if I could benefit from it as in this case. :)
I guess Richard's technique does work. But, when I did drink beer, I didn't drink before 5 or 6 in the afternoon. It's morning here. :)
Have a great day! :)
Siran

. . I share your trepidations about tackling a task like this, but maybe I will venture out further down the track, it would be a very positive move.

. . On the second point, maybe it's time to change :) Needs do as needs must :) </joke>

Stephen

:)

I seriously doubted my ability and no experience with programming or compiling until I was forced into that task by necessity to fix the bug I discovered in the client with a max_concurrent statement in multiple projects.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Just had an upload not go through on it's first attempt, and the web site here was MIA for a couple of minutes.

---

Grant
Darwin NT

While I'm personally finding this whole Linux thread interesting, perhaps a mod could move the whole thing to another thread as it clearly has nothing to do with the SETI servers being in Panic Mode?

Yeah, my bad. Sorry. I thought it would just be one or two posts and have the problem resolved, but it turned into more than that.

I posted here because this is probably the most-viewed thread where hopefully someone who knows the answer would see it.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

While I'm personally finding this whole Linux thread interesting, perhaps a mod could move the whole thing to another thread as it clearly has nothing to do with the SETI servers being in Panic Mode?

Yeah, my bad. Sorry. I thought it would just be one or two posts and have the problem resolved, but it turned into more than that.

I posted here because this is probably the most-viewed thread where hopefully someone who knows the answer would see it.

No blame to anyone. It's mostly a community thing the way threads develop.

I have PM'ed arkayn (the thread owner.)

Hopefully arkayn will take a look.

Otherwise a name change might be the best solution.

I prefer to keep the name the same, as this is the name that everyone looks for when seeing if it is a universal problems or not.


So, if you want to talk about compiling code or how to switch to linux, please use an appropriate thread as opposed to this one.

---

I prefer to keep the name the same, as this is the name that everyone looks for when seeing if it is a universal problems or not.
So, if you want to talk about compiling code or how to switch to linux, please use an appropriate thread as opposed to this one.

. . +1

Stephen

< shrug >

While I'm personally finding this whole Linux thread interesting, perhaps a mod could move the whole thing to another thread as it clearly has nothing to do with the SETI servers being in Panic Mode?

Yeah, my bad. Sorry. I thought it would just be one or two posts and have the problem resolved, but it turned into more than that.

I posted here because this is probably the most-viewed thread where hopefully someone who knows the answer would see it.

No blame to anyone. It's mostly a community thing the way threads develop.

I have PM'ed arkayn (the thread owner.)

Hopefully arkayn will take a look.

Otherwise a name change might be the best solution.

I went ahead and just made a thread in the Linux Q&A section, since it seems like this won't be a quick fix.

I'll see how it ends up going over there instead of littering this thread with it.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

Just wanted to mention an update here... I finally got it resolved, thanks to TBar.

He provided me with the boinc and boinccmd binaries for 6.10.37 and I had to do some fiddling-around to make it work, but..

2019-09-24 17:53:41 Starting BOINC client version 6.10.37 for x86_64-pc-linux-gnu
2019-09-24 17:53:41 log flags: file_xfer, sched_ops, task, sched_op_debug
2019-09-24 17:53:41 Libraries: libcurl/7.58.0 OpenSSL/1.0.2n zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0 librtmp/2.3
2019-09-24 17:53:41 Data directory: /var/lib/boinc-client
2019-09-24 17:53:41 Processor: 8 GenuineIntel Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz [Family 6 Model 60 Stepping 3]
2019-09-24 17:53:41 OS: Linux: 4.15.0-62-generic
...
2019-09-24 17:36:59 SETI@home update requested by user
2019-09-24 17:37:00 SETI@home [sched_op_debug] Fetching master file
2019-09-24 17:37:00 SETI@home Fetching scheduler list
2019-09-24 17:37:05 SETI@home [sched_op_debug] Got master file; parsing
2019-09-24 17:37:05 SETI@home [sched_op_debug] Found 1 scheduler URLs in master file
2019-09-24 17:37:05 SETI@home Master file download succeeded
2019-09-24 17:37:10 SETI@home [sched_op_debug] Starting scheduler request
2019-09-24 17:37:10 SETI@home Sending scheduler request: Requested by user.
2019-09-24 17:37:10 SETI@home Reporting 100 completed tasks, requesting new tasks
2019-09-24 17:37:10 SETI@home [sched_op_debug] CPU work request: 1731456.00 seconds; 4.00 idle CPUs
2019-09-24 17:37:15 SETI@home Scheduler request completed: got 0 new tasks
2019-09-24 17:37:15 SETI@home [sched_op_debug] Server version 709
2019-09-24 17:37:15 SETI@home Message from server: No tasks sent
2019-09-24 17:37:15 SETI@home Message from server: SETI@home v8 needs 32.00MB more disk space. You currently have 0.00 MB available and it needs 32.00 MB.
2019-09-24 17:37:15 SETI@home Project requested delay of 303 seconds

And I figured out that disk space issue. Apparently, when you set a max log size in cc_config, that value counts as "currently used", even if the file isn't anywhere near that number yet. Fixed that, and tried again:

2019-09-24 17:57:52 SETI@home [sched_op_debug] Starting scheduler request
2019-09-24 17:57:52 SETI@home Sending scheduler request: To fetch work.
2019-09-24 17:57:52 SETI@home Requesting new tasks
2019-09-24 17:57:52 SETI@home [sched_op_debug] CPU work request: 1731456.00 seconds; 4.00 idle CPUs
2019-09-24 17:57:57 SETI@home Scheduler request completed: got 24 new tasks
2019-09-24 17:57:57 SETI@home [sched_op_debug] Server version 709
2019-09-24 17:57:57 SETI@home Project requested delay of 303 seconds
2019-09-24 17:57:57 SETI@home [sched_op_debug] estimated total CPU job duration: 102436 seconds
2019-09-24 17:57:57 SETI@home [sched_op_debug] Deferring communication for 5 min 3 sec
2019-09-24 17:57:57 SETI@home [sched_op_debug] Reason: requested by project

So I'm back up and running, finally.

Again, Thank you, TBar! Also Keith for trying to help as well.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

Glad you sorted it out. I thought about grabbing that 6.10.37 branch as it had more recent updates to the 6.10.60 branch, but you said you wanted the same as your 6.10.58 so that is what I tried. Should have gone with my gut instinct. Doesn't mean I would have been successful though as I didn't have an old 12.04 lying around.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Glad you sorted it out. I thought about grabbing that 6.10.37 branch as it had more recent updates to the 6.10.60 branch, but you said you wanted the same as your 6.10.58 so that is what I tried. Should have gone with my gut instinct. Doesn't mean I would have been successful though as I didn't have an old 12.04 lying around.

I just didn't want to go BEYOND the 6.10 branch. A slight rollback is fine. Just needed to get the openssl library to be newer than 0.9.8g is all, so that comms could happen properly.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

The servers are certainly struggling at the moment- 160k+/hr coming in, and while the splitters are occasionally able to crank out the work, they just can't sustain the output needed to rebuild the ready-to-send buffer.

---

Grant
Darwin NT