Is it hard to Spoof a host ?
Can someone explain how to do it here so were all on the same playing field.

Thanks

---

Is it hard to Spoof a host ?
Can someone explain how to do it here so were all on the same playing field.

Thanks

You need to join the GPUUG team for the information. It involves downloading the BOINC master code branch and compiling the client with the necessary changes to the code.

---

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

A proud member of the OFA (Old Farts Association)

Is it hard to Spoof a host ?
Can someone explain how to do it here so were all on the same playing field.

Thanks

You need to join the GPUUG team for the information. It involves downloading the BOINC master code branch and compiling the client with the necessary changes to the code.

So the information won't be shared with anyone who doesn't join the team?
Interesting ...

---

Is it hard to Spoof a host ?
Can someone explain how to do it here so were all on the same playing field.

Thanks

You need to join the GPUUG team for the information. It involves downloading the BOINC master code branch and compiling the client with the necessary changes to the code.

So the information won't be shared with anyone who doesn't join the team?
Interesting ...

What do you think the impact to the project would be if all of the current 90,000 active users all of a sudden spoofed every one of their hosts to 64 gpus? Think about it.

"With great power . . . comes great responsibility"

---

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

A proud member of the OFA (Old Farts Association)

Is it hard to Spoof a host ?
Can someone explain how to do it here so were all on the same playing field.

Thanks

You need to join the GPUUG team for the information. It involves downloading the BOINC master code branch and compiling the client with the necessary changes to the code.

So the information won't be shared with anyone who doesn't join the team?
Interesting ...

What do you think the impact to the project would be if all of the current 90,000 active users all of a sudden spoofed every one of their hosts to 64 gpus? Think about it.

Right, because all 90,000 active users are running Linux, and have the skills and means to do this. Pull the other one, Keith, it's got bells on...

"With great power . . . comes great responsibility"

...comes something, that's for sure ... Was it your intent to sound that arrogant?

---

He’s quoting the very commonly referenced movie/comic Spider-Man. Several references to the same sentiment existed before Spider-Man, but I think most people associate the phrase with the comics.

---

Seti@Home classic workunits: 29,492 CPU time: 134,419 hours

Right, because all 90,000 active users are running Linux, and have the skills and means to do this. Pull the other one, Keith, it's got bells on...

"With great power . . . comes great responsibility"

...comes something, that's for sure ... Was it your intent to sound that arrogant?

I guess my attempt at levity fell on deaf ears. Yes that was a popular movie reference. I interpreted your comment as an affront to the GPUUG. We take our responsibilities seriously.

If you look at the Top 100 participants list of those running Linux, you will notice that not everyone is a member of the GPUUG. So without the assistance of the GPUUG, independent users have been able to figure out how to spoof the client. It is not rocket science. Have you even bothered to download the master and look at the code in the client directory? The instructions for compiling the BOINC code is published right on the BOINC pages. All it takes is some effort on the part of the participant to read the code, figure out what needs to be changed and follow the instructions to make your own client that spoofs gpus. Heck you don't even have to be running Linux to run a spoofed client. Make the Windows client and run the SoG app.

All I was trying to get across is that we shouldn't willy-nilly make it as easy as downloading the AIO for the masses and have everyone spoof multiple gpus. I'm sure the database and the servers will crumble under the load. You can always use a rescheduler if you are running out of work on Tuesday's. Heck the need for a spoofed client is less and less now that the outages are reasonable again at 4-5 hours. The only reason the spoofed client came into existence was having to deal with the 12-14 hour or longer outages we were experiencing for a great long while.

---

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

A proud member of the OFA (Old Farts Association)

. Don't want to do it, then don't
Never said that Zalster.
you just have to have the skills to do it,
I bet half the guys on your team that did this don't have the skills, they were helped...…..
I guess it's not what you know, but who you know, and everyone knows this.

---

Let me quit my team of 20 years, get the info from GPUUG and then rejoin my Team,
So STUPID.

---

There are so many misunderstanding about the spoofed client and that generate "bad feelings" about.

Let's me try to explain the history of the builds (please forgive my bad english)

The main reason why spoofed client exists is because most of the big crunchers has very hard time to keep his hosts crunching SETI 24/4.
I know nobody from any project promise we will have work for a 24/7 usage, but that is for another thread.

There are several ways to bypass the 100 WU per GPU/CPU buffer in Boinc, the most know one is with the use of Rescheduling (another gasoline thread too) . We use them for years and even now rises some pro and some against.

With the advent of the heavy optimized Linux Special sauce builds and the arrival of the latest top range GPU's who crunch a WU in less than a minute that problem become even worst. And to make all worst the constant outages for several hours make impossible to keep them working 24/7 even with a lot of babysitting and the use of rescheduling.

This is why some of us, after study the widely available Boinc code find a way to make the creation of the large WU buffer needed to keep the big hosts (with GPU's) automatically.

How that was made is by "spoofing" the number of GPU's the host has, Then the Boinc will send to each one of them 100 additional GPU WU, creating the large buffer needed for the host runs for about 1/2 to 1 day. That is why we call it "spoofed client"

But that large cache has a problem, if not handled with caution, it could cause serious problem by swaming the servers with huge amount of data.

That's is why we (the ones who develop the builds not the project admins) decided to keep this builds in a closed loop, where we could control who use and mainly all who use agree to handle the large buffer with some "special" rules to prevent any harm to the serves.

They could be used in any size of host, even those who not need a larger buffer than 100 WU, and that is our main concern, just imagine a host with a return rate of, lets choose a random number, of 3 WU per day who could works perfect with a 30 WU buffer changing to have 6400 WU? It could easy produce > 6300 aborted WU, a day after the other, and that the server sure will not handle well. Now imagine 1000's of hosts making the same?

This is the main reason why we not make them available to the general public, we can't control it's wrong usage.

---

If you bothered to look at the list of members and their levels of contribution, you'd see that it has nothing to do with "elite" status. Its more about commitment to the SETI project and the primary use of GPUs for crunching (hence GPU users group). we have members RAC ranging from <1000 to >1 million.

But yes, it is invite only, and anyone who wants to join under the pretense of gaining some code exploits that were discovered by the members of our team and planning to leave immediately would not be admitted to the team in the first place.

If you search Juan's posts on the forums, you should find the information needed to point you in the right direction. he even posted the location/name of the module that needs to be edited.

---

Seti@Home classic workunits: 29,492 CPU time: 134,419 hours

You don't need a "spoofed" client to receive more tasks. People have been doing a simple edit of a certain BOINC.xml file for Years without having to recompile the client. The information required has been posted on this board a few times. It's actually easier to do in Windows and MacOS than it is in Linux, in Linux it's a little harder to lock the file after it has been edited. If you want to try it, search this board. All I'm going to offer is the only way to lock the file in Linux. Just follow the instructions here, https://superuser.com/questions/104015/removing-write-permission-does-not-prevent-root-from-writing-to-the-file/104022#104022
To lock the file, make the file Read Only, cd to the folder then, sudo chattr +i filename.ext
To unlock the file, sudo chattr -i filename.ext, then change it to Read&Write.

That's All I'm going to say, Don't PM Me about it.

before the advent of the GPU spoofing, I was probably hit harder than anyone else (having the most productive single host, by a long shot) during both planned Tuesday system outages, as well as unplanned server crashes.

For planned outages I could plan for it, spending several hours on Monday nights manually rescheduling to cache thousands of tasks so that I could continue to crunch WU's in the event of a long outage. For unplanned outages I was pretty much at the mercy of the length of the outage, because even a 2070 on the special app will only last 1-2hrs with a cache of only 100 tasks. More cards and more tasks don't change this as all the cards work in parallel.

So for many of the people with very productive systems, it becomes more a matter of convenience than anything else.

modern GPUs and app developments have over run the old restrictions that were put in place at a time when processing 1 WU took an entire day. now we have GPUs that can do the same task in less than 30 seconds.

---

Seti@Home classic workunits: 29,492 CPU time: 134,419 hours

modern GPUs and app developments have over run the old restrictions that were put in place at a time when processing 1 WU took an entire day. now we have GPUs that can do the same task in less than 30 seconds.

These restrictions were put into place to stop huge amounts of data being returned after an outage as it caused database problems. That is it, no other reason.

Now if you know that these problems no longer exist then fine I expect to see the limit removed.

What has happened with spoofing is that unless the return rate from spoofed machines is controlled after an outage, then you are negating the whole reason for the 100 task limit and making things worse.

The 100 task limit was to specifically stop machines with large caches returning all the work at once. So in effect this could make recovery after an outage worse.

When I raised this point before I was assured that people who spoofed were aware of this fact and controlled their task return so as not to flood the servers. Is this still correct?

When I raised this point before I was assured that people who spoofed were aware of this fact and controlled their task return so as not to flood the servers. Is this still correct?

That is one of the rules we ask all to follow. But that depends on each one. Mine at least return up to 100 WU only at a time.
BTW There Is another common mistake, only very few uses the builds (around 25 hosts only last time i count).

---

I’ve always been under the impression that the restrictions were put in place more as a precautionary measure in preventing a large amount of resends in the event that a host trashes its entire WU cache due to hardware or software issues on the host’s end. Combined with the developers feelings that you’d never need more than 100 anyway based on the processing rate of the time.

Do you have evidence or a source that says the restrictions were put into place specifically for the case of work returned after an outage?

---

Seti@Home classic workunits: 29,492 CPU time: 134,419 hours

This is a side question.

We have a whole thread in this section of the forum for hosts returning crap WU results. I've messaged a few of them, but I don't think the message gets through. They keep getting more WUs even though they error out. Is it possible to for extreme cases (not sure where to draw the line) to block the machine until the person comes on the seti site and clicks an acknowledgement button??

The 100 task limit was to specifically stop machines with large caches returning all the work at once. So in effect this could make recovery after an outage worse.

I remember reading somewhere the main reason for the limit was to stop having so many outstanding unused task assignments in the Database. Previously anyone could download up to 10000 tasks at a time. The problem was, there was a number of people who would download 10000 tasks and then never run BOINC again, causing those 10000 tasks to remain in the database for months before timing out. Imagine how many tasks would be in the database if Everyone was allowed to hold 10000 tasks. In reality, very few people need that many tasks, and it really doesn't matter if those people have 500 In Progress tasks or 3000 in progress tasks. What matters to the database is what's in the All column and that column will be quite high on a Host that Needs 10000 tasks a day. Take for example this Host, do you really think it would matter if the In Progress column said 1400 rather than 3200?
State: All (27891) · In progress (3200) · Validation pending (14703) · Validation inconclusive (430) · Valid (9558) · Invalid (0) · Error (0) Application: All (27891) · AstroPulse v7 (0) · SETI@home v8 (27891)

Again, what matters is the ALL column, and the difference between 27891 and 26091 is pretty much insignificant. However, it's the difference between the Host working and Not working during certain periods of the week. Last I heard SETI needed all the Hosts it could get working. I really don't see a problem with uploads, it doesn't matter how many tasks you have completed I've Never seen more than a couple of hundred upload at any one time and the next couple of hundred isn't any different than any other Host uploading. The only concern would be downloads if the RTS was low, but, in my observation the slower Hosts always get more tasks and refill faster than the fastest Hosts, at least on My machines. Just remember, out of the 100000 or so active Hosts, there are relatively few with the need for higher cache levels, and I really don't think SETI will mind if the owners do what they can to keep them working.

The BOINC scheduler and client has a mechanism to punish hosts who only return garbage or errored tasks. It is supposed to limit a bad host to one task a day. It does not work. Witness the bad hosts thread you mentioned.

We have suggested that bad hosts be prevented from contacting the project to get work with a lock on their account. Once they remedied the host the lock would be removed. But that suggestion has not been taken up because it would involve a lot of rewriting of the client code. It would also take moderation efforts.

---

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

A proud member of the OFA (Old Farts Association)

I’ve always been under the impression that the restrictions were put in place more as a precautionary measure in preventing a large amount of resends in the event that a host trashes its entire WU cache due to hardware or software issues on the host’s end. Combined with the developers feelings that you’d never need more than 100 anyway based on the processing rate of the time.

Do you have evidence or a source that says the restrictions were put into place specifically for the case of work returned after an outage?

I unfortunately don't have a link at the moment. So far I can not even find a mention of the limit let alone the reason

However if you think about it, your reason is a non starter as there are lots of hosts totally trashing almost every WU due to old/faulty or wrong driver GPU's and they just continue, the 100 WU limit has no effect. So re-sends stay high

Also I assume "the developers" refers to Boinc. This isn't a Boinc limit, this is a server side SETI@Home project limit. Other projects have their own or none.

Also think about it, the only time the 100 WU limit has any affect is during an outage. The rest of the time your GPU's can return work as quickly as they like and it makes no difference.

My fastest machine is around 2.5 mins a task, it never "runs out" during normal working so the 100 task limit has no affect and I don't notice it .

However hundreds of machines returning thousands of WU' after an outage can cause database instability, the longer the outage obviously the worse it becomes.

If it is possible to reduce A) The amount of work returned and B)The amount of replacement tasks asked for after an outage it will recover quicker.

I will see if I can find any prof of what I am saying but it may take a while.