Folding Forum

Since the topic has been locked, I'm moving my complaint here in hopes that SOMEBODY at the PG still listens to suggestions. 7im and I disagreed about what to do with WU size limitations and Kasson didn't want us to discuss it any more.
See viewtopic.php?f=58&t=15215&start=30#p151302

I propose that the V7 client include separate provisions for bandwidth and for memory. Some of use still use dial-up and even if we have a quad/hex/... core CPU which could easily process SMP within the deadlines, the idea of trying to upload or download huge files is anathema to those with limited bandwidth. The term "High performance" does not adequately distinguish between high-performance cpus with plenty of ram and high-performance internet connections. (I think we're talking about what the serverstat calls packet size, not the performance of the processor.)

Anyway, please provide separate options in the v7 client.

@gwildperson: If you read my post, you would have come across this:

7) Introduce transfer cap. The client monitors how much it has downloaded and uploaded (including the failed attempts) and when it reaches the user defined limit, will exit by stating a simple message. It may sound like a trivial thing but for people with fixed quota for the internet usage, it will be a blessing in disguise.

I believe this is a more useful option for limited bandwidth as you can process whatever WU you want and the Client will self-terminate once it reaches a predefined quota. That way, it is easy and the user can choose to do a few large WUs on their powerful hardware or plenty of small ones. Whatever it does, it will remain within the Quota.

@gwildperson, I think we agree more than not. And kasson closed the topic because the WUs have been pulled, they apologized, and they said they would fix it. Not much more to discuss, except your v7 suggestion, which I support.

But I'm not sure the distinction between memory usage and bandwidth usage is significant. HP clients, like SMP, use large chunks of bandwidth, and large chunks of memory. CPU clients use large chunks of neither. Because both memory and bandwidth tend to go hand in hand to the same clients, how does splitting them apart help us? Are there any small WUs with large memory demands?

Maybe this is a request for a new class of work unit as well?

Somebody (maybe bruce) pointed out that the project owner has options about how much data they gather for the upload (sort of a hidden verbosity setting). If we assume that the extra large upload wasn't a mistake, then it's easy to split that project into smaller WUs that (for the sake of an example) run 5% as long and generate 5% as much data. If we assume it was a mistake, then a new project could run just as long and generate 5% as much data.

Either way, it's up to the science people to configure their projects. It's us to do the work, but we need the tools to tell them a ratio between processing time and upload size. The current Small/Normal/Big doesn't allow for independent control of the two but combines them into a single setting.

This was "fixed" by Tear's linux deveopment and presumably will be helped somewhat by the suggestion to download and start processing concurrently with uploading (assuming it's accepted). Even on "normal" SMP WUs, we're still talking about hours of uploads on moderate speed connections (I think that was PantherX's comment) and impossible uploads on dial-up.

gwildperson wrote:...Even on "normal" SMP WUs, we're still talking about hours of uploads on moderate speed connections (I think that was PantherX's comment) and impossible uploads on dial-up.

I haven't a clue about the general internet speed F@H Donors have but on my 512kbps: (~50KB/s download + ~10KB/s upload)
~3 MB = <15 Minutes
~20 MB = ~30 Minutes
~60 MB = 1.5 Hours
~100 MB = 2.5 Hours
I haven't any problems with it but what worries me the most is if my connection drops, I loose a lot of points as I have to restart my upload. For bigadv WUs, I loose ~500 Credits per Hour which I can't complain as overall, it is way better than Project 6701 WUs I would only wish that they change the time taken to calculate the bonus from "Time Server Received WU" to "Time WU was Finished" that way, you internet connection won't have a negative impact as long as you successfully upload the WU Result before the Preferred Deadline.

PantherX wrote:I would only wish that they change the time taken to calculate the bonus from "Time Server Received WU" to "Time WU was Finished" that way, you internet connection won't have a negative impact as long as you successfully upload the WU Result before the Preferred Deadline.

I wish that, too, but the next Gen cannot be distributed until the upload of the current Gen is completed so science demands the end-to-end measurement of time on by server. Not that anybody would do it, but would it be okay to let a finished WU sit for a couple of days before uploading it as long as it meets the final deadline?

codysluder wrote:

PantherX wrote:I would only wish that they change the time taken to calculate the bonus from "Time Server Received WU" to "Time WU was Finished" that way, you internet connection won't have a negative impact as long as you successfully upload the WU Result before the Preferred Deadline.

I wish that, too, but the next Gen cannot be distributed until the upload of the current Gen is completed so science demands the end-to-end measurement of time on by server. Not that anybody would do it, but would it be okay to let a finished WU sit for a couple of days before uploading it as long as it meets the final deadline?

Well, in that case, keep a "Window of opportunity" where if the difference between the WU's Time complete and Time to upload is <3 hours, the bonus points are calculated from Time complete. That way it would provide users with >512kps a really good benefit as we won't be loosing credits and nobody would want to delay it. If a user has >18 hours then they get base points. Thus it would give the autosend feature a few attempts to upload the WU Result and if the user further delays it, then it would be hurting Science which would be reflected by the donor getting base points. Although this isn't perfect, maybe someone can improve on it.

Time WU was finished is a time on the local computer. There is a much greater potential for local time to be manipulated to cheat on points. All time based measurements have to be FAH server times.

And let's remember, the bonus is based on the time it takes to return a completed WU. Finishing a WU today, but uploading tomorrow is not as helpful as uploading that WU today.

Stanford can't issue the next WU until the existing WU is returned. Also, Stanford can't use that data until it is returned. So the bonus has to apply to when Stanford gets the data in their hands, not when the WU is completed locally.

There is no difference in regards to the research data if you have a faster computer, and a slower upload speed versus a slower computer and a really fast upload speed. Total time to return the WU includes both the processing time, and the upload time. Sorry, but that's why SMP WUs initially had such a high points base benchmark. It took in to consideration the extra system resources required to run SMP, including a broadband connection and not dialup. The QRB system follows that same line of reasoning. Intent to upload is not the same as a completed upload. Nice idea, but not generally feasible.

I would only wish that they change the time taken to calculate the bonus from "Time Server Received WU" to "Time WU was Finished" that way, you internet connection won't have a negative impact as long as you successfully upload the WU Result before the Preferred Deadline.

Nice idea for donors like me who have very slow connections, bad idea for the project that wants fast returns..
I think those, like me, who have variable or poor connections just need to factor this in and suck it up. I intend to deal with my problem by adding another connection and by OCing my machines capable of it to balance out the slowness of the up/download.
It is one of the other reasons I stick with mainly gpu output and haven't set all 3 quads to SMP, I only run my i7 on smps at present, I could theoretically generate more work by running 3 smps, but I would then bottleneck my connection. This is actually why I liked running bigadv as although it took hours to send that only happened every few days, running 3 smps through 1 modem would just be continuously sending.

kiore wrote:Nice idea for donors like me who have very slow connections, bad idea for the project that wants fast returns..

True, but maybe my improvised idea with "Window of Opportunity" may help everyone

kiore wrote:...I think those, like me, who have variable or poor connections just need to factor this in and suck it up. I intend to deal with my problem by adding another connection and by OCing my machines capable of it to balance out the slowness of the up/download...

That is exactly what I have done. However, my RAM has been a bottleneck in bigadv so I am not that lucky. Nonetheless, I am happy to contribute within the Preferred Deadline. I really love the GPU Clients as they have hardly any uploading issues however, finding the them here at a reasonable price is another story

I don't really know what features the current thing has now, but I have heard that it uses some kind of gui to manage the clients. If that's the case, then the feature I'd really like is a way to set a client to shutdown after it finishes up the current WU. So basically, a way to set a client to -oneunit while it's still running. I'd love a way to gracefully shut down clients if I need to reboot for some reason. I can usually interrupt a client and add -oneunit, but it would be more elegant to have a way to set it while it's running. Hmm.... now I'm wondering if there's a way to edit the client.cfg file while the job is running and add it there. Does anyone know if -oneunit is in there and the client.cfg gets checked in between WUs? Guess that would be a low tech way to do it. Anyway, if we're going to get a nice gui, it would be a great feature to have.

If you run the v6 console client, you must restart it -- there's nothing that can be edited. If you run the v6 systray client, there's an option in the context menu called "Pause when done" which can be set while the client is running.

It's reasonable to assume that v7 will be similar to v6 but nobody really knows until it actually is ready for distribution.

FAH News: Update on the v7 client

I don't see anything about a GUI to manage clients in that news post, but there are lot's of wild rumors on the internet. For example, I read a post in a top 10 team's folding forum that said the CEO of nvidia donated $ millions to Pande Group, and the poster claimed that's why the ATI client is so far behind NV. He even claimed that's why the ATI GPU work servers ran out of work units last week.

I don't know anything about the ATI client or work servers, but it was well documented that the CEO of NV gave the money to the Engineering department, where he got his degree. And since Pande Group is in the Science department, NOT the Engineering department, that substancial monetary donation had no influence at all on FAH.

Double check your sources. Not everything you hear is true.

What? OK, quoting from the blog entry you linked to...

The first versions will not have everything that donors have asked for, but there will be some significant changes, such as the integration of classic, SMP, and GPU clients, the ability for a single client to handle all of these (eg multi-core + GPU) simultaneously (via multiple cores), a cleaner and more reliable GUI, much better and sophisticated tools for 3rd party developers, and in time the ability to use the FAH client to manage multiple machines easily.

So forgive me reading this wrong then, I thought that when it said 'a cleaner and more reliable GUI' right after talking about the integration of different clients and the ability of a single client to handle them all, I jumped to the conclusion that he was talking about something with a GUI that could manage multiple clients. Forgive the reckless assumptions I drew from reading that. I suppose he could also easily be talking about a single console client that handles multiple classic clients, and a GUI for some other thing.

One option I would like in the future is the ability to activate the oneunit flag without having to stop/restart the client.

e.g. Have a system variable that the client checks before downloading it's next WU.

FAH1unit=0 - carry on as if the -oneunit flag was not used
FAH1unit=1 - stop the client after current upload and before downloading the next WU as if the -oneunit flag had been given

This would avoid the need for a manual restart to add the -oneunit flag to the command line and possibly avoid some lost WUs or lost progress.