Windows Beta Client [v2.5.08]

This is just a stand alone exe. It's not an installer.

Caveats (for v2.5.08): Fixed a bug prohibiting entering a long username. Fixed a bug in the GUI that was cutting off 'test' in the config screen.

Caveats (for v2.5.07): The ones below still apply. This version has support for changing how many intermediate blocks between server reports, similar to the other clients. Under the config button, you will now see a place where you can set the amount of blocks next to 'Trans Int. Blocks' where it says "Freq:"

Caveats (for v2.5.06): YMMV. This is even more beta. This uses updated math libraries which should result in a speed improvement. I have not done calculations to figure out how much faster it is, but if other people would like to that'd be great. Because of the updated libraries, I need to do more testing on this client to make sure things are reported properly. Please test with it, but don't deploy widely.

http://www-personal.umich.edu/~mcgar...2.5.08-win.zip

I am unable to enter a username long enough to put QQQsecondpass on it... seems like maybe this client is missing that update to the UI ;)

Also, is there any possibility of a config-file based windows client in the future? I really hate the registry-based configuration.

Quote:

---

Originally Posted by umccullough

I am unable to enter a username long enough to put QQQsecondpass on it... seems like maybe this client is missing that update to the UI ;)

Also, is there any possibility of a config-file based windows client in the future? I really hate the registry-based configuration.

---

Yeah, good catch. I've fixed that bug. Also fixed the fact that 'test' was cut off in one part of the UI. As for a config based version, I seriously doubt it.

http://www-personal.umich.edu/~mcgar...2.5.08-win.zip

A config file would be really helpful. A lot of people run DC projects in high school and university labs which prevent registry edits from being saved, or revert the hard drive to the standard image after every boot.

When I was in college, I used to use the lab at night and log into every computer in my row (usually five), and run five copies of the Distributed.net client from five folders on my network drive. They would start up from wherever I left off without a hitch (as long as it was running on the same CPU as last time, which it was always was because every computer in the lab was identical). For whatever good it did, we cracked a 64-bit RC5-encrypted message.

Now I'm a consultant and volunteer at my old high school, and they let me run SoB on a bunch of the non-student computers, such as the computers in the library that run the card catalog or check out books. There are a bunch of computers that the librarian (a friend of mine) has to login at the beginning of every day, so I put SoB on his network drive and added it to the startup sequence for those computers. Then the board switched to Windows XP and prevented editing of the registry. After that, the computers would start SoB and find no registry settings, so they would request a new test! Every day they would start and abandon a new test, so I just gave up. If SoB could store its settings in a config file, everything would be fine.

So, for me, the issue is schools. I would run SoB on school computers if I could, but schools prevent registry editing for security reasons. I'm sure that many SoB contributers are students who would run SoB (and probably run other DC projects that use a config file) in the lab if they could. I won't bother to guess how much work this is costing us, but I can tell you that it's more than none.

Alien88,

When do you think you'll be able to say that the new build is safe to deploy to the whole fleet? On the two box I put the new build it seems to be okay but I did not really see any big jump on the speed. Maybe its just the wu I got or the box.

Also I know the number of blocks is up to the user to configure but what would be the general consensus should it be? Also it really is nice thet the client just kept on crunching once it completes one block. BTW that is another way of saying thank you :).

I would recommend that the default be something conservative like 10. Even a very slow computer would be reporting in every day. I'm planning to set mine to about 100, which means that each core will report results every two hours while we do error check. I'll probably leave it that way even after we switch back to first pass, rather than increase it to 200, since the performance boost from saving an extra 4 seconds per hour would be negligible. Reporting 1% as often really will be a big boost for me.

The long term benefits of setting the default to something other than 1 become even greater in the future. The faster computers get, the greater the percentage of time will be wasted reporting results. I came up with my 8% figure based on blocks completing every 50 seconds, but pausing for 3 or 4 seconds to establish a connection and send in the result. The next time computers double in power, that will be 4 seconds every 25 seconds, and so on. With n's reaching 15 million and beyond, further increasing cEMs/second, clients could eventually be spending as much time shaking hands with the server as doing actual work. SoB should future-proof itself by setting the default to no less than 10, otherwise the system-wide loss of performance could become enormous over the next few years.

Quote:

---

Originally Posted by DOSGuy

A config file would be really helpful. A lot of people run DC projects in high school and university labs which prevent registry edits from being saved, or revert the hard drive to the standard image after every boot.

---

While I understand the win to having a flat file config, I just don't have that kind of time to rewrite the windows client. Regarding running in labs, etc, the only place you should be running SB is where you have explicit permission to do so. In most cases, this would mean that you admin the lab and have full control over the machines. This would allow you to easily setup the needed registry entries.

I'd much prefer not to build a client which is going to make it easier for 'rogue' installs by users.

Quote:

---

Originally Posted by DOSGuy

I would recommend that the default be something conservative like 10. Even a very slow computer would be reporting in every day. I'm planning to set mine to about 100, which means that each core will report results every two hours while we do error check. I'll probably leave it that way even after we switch back to first pass, rather than increase it to 200, since the performance boost from saving an extra 4 seconds per hour would be negligible. Reporting 1% as often really will be a big boost for me.

---

Yeah, a number around 10 is what I have been thinking about.

Quote:

---

Originally Posted by engracio

Alien88,

When do you think you'll be able to say that the new build is safe to deploy to the whole fleet? On the two box I put the new build it seems to be okay but I did not really see any big jump on the speed. Maybe its just the wu I got or the box.

---

You probably won't see a huge jump in speed on modern machines. It seems that the older machines benefit more from the updated math libraries.

As for when to deploy? Once I'm satisfied with everything, I will do a final build for all the clients. At that point, for sure, you can deploy more widely.

If you don't mind the possibility of there being some weird bug that hasn't been caught yet in this client, it shouldn't be too big of a deal to deploy it more widely at this point. I've verified it reports residues properly, which was my major concern.

Quote:

---

Originally Posted by Alien88

You probably won't see a huge jump in speed on modern machines. It seems that the older machines benefit more from the updated math libraries.

As for when to deploy? Once I'm satisfied with everything, I will do a final build for all the clients. At that point, for sure, you can deploy more widely.

If you don't mind the possibility of there being some weird bug that hasn't been caught yet in this client, it shouldn't be too big of a deal to deploy it more widely at this point. I've verified it reports residues properly, which was my major concern.

---

Coolest:) Sounds like a plan to me. yes the two boxes are a Q6600 and an E4300. I put 10 also before I posted the question, That seems to be the minimum if you don't want the client to transmit all the time. Thanks for everything :)

Quote:

---

Originally Posted by Alien88

While I understand the win to having a flat file config, I just don't have that kind of time to rewrite the windows client. Regarding running in labs, etc, the only place you should be running SB is where you have explicit permission to do so. In most cases, this would mean that you admin the lab and have full control over the machines. This would allow you to easily setup the needed registry entries.

I'd much prefer not to build a client which is going to make it easier for 'rogue' installs by users.

---

I don't think you understood me. I wasn't talking about installing SB on lab computers, which is impossible because the hard drive images are frozen. I was talking about running SB from my network drive. My computer course required me to spend several hours in the lab each day, and while I was there I would run distributed computing in the background. Nothing was left behind when I logged out; these were not rogue installs.

The local hard drive reverts to the default image after every reboot, but your network drive is yours, and you have explicit permission to store data and use school computers within the rules (no pornography, no file sharing, etc). If you store the config file in a folder in your network space, where you keep a copy of SB, then you can resume the test the next time you're in the lab.

Anyway, I understand what you're saying about it requiring substantial effort, but I just wanted to point out that using a config file would not make it possible to create rogue installations in computer labs.

I'd like to second the use of a flat file for the configuration file.
Sure would make it easier to deploy and manage, like dnet :)

Thanks for all the hard coding and your time to get this done. :cheers:

Yes, dnet was great that way.

I'm testing the beta client on my Q6600, and I've set the frequency to 10 for now. Cores that were doing 3.2M before are at 3.5M now, and one that was at 3.6 is now 3.8. So possibly a 9% performance boost, most of which is probably from transmitting every 10 minutes instead of every minute. The effect of the frequency option will be greatest on fast computers, but you indicated that the other changes have the greatest effect on older computers. If we could even close to that level of increase system wide, that would be a huge boost.

Great job!

Quote:

---

Originally Posted by IronBits

I'd like to second the use of a flat file for the configuration file.
Sure would make it easier to deploy and manage, like dnet :)

---

Yep. I'd even be fine if it was limited to a commandline client like all the OSes for this type of config. Not sure why that wasn't an option from the get-go :/

Anyhow, no big deal - just thought it would be a good idea to ask.

A non-gui client that can be run from the command line?
Now why didn't I think of that? :bang:

Good idea! :rock:

If you run from a network drive, you can create a script (batch file) that imports the registry keys before starting the client and exports them again after closing it.

Somthing like this should do the trick:

@echo off
regedit /s "sob.reg"
start /wait sb.exe
regedit /e "sob.reg" "HKEY_LOCAL_MACHINE\SOFTWARE\LhDn"

save like start.bat and place in same directory where the client is, you need te make a directory for each client.

Quote:

---

Originally Posted by DukeBox

If you run from a network drive, you can create a script (batch file) that imports the registry keys before starting the client and exports them again after closing it.

---

If you have permissions that allow editing the registry. I tried creating a .reg file, but the system wouldn't run it.

Changing frequency from 1 confuses the hell out of Time Left. When I set frequency to 10, it indicates that there are about 10 minutes left, then slowly ticks down to 0 each block. It seems to be initially aware that it has to do 10 blocks, but then updates the time remaining based on the percentage of the current block complete.

If you have full rights, you can also try remotesob. http://sob.qik.nl/remotesob

Quote:

---

Originally Posted by IronBits

A non-gui client that can be run from the command line?
Now why didn't I think of that? :bang:

Good idea! :rock:

---

Would it be quite simple to build a windows version of the linux/mac/beos commandline client?

Quote:

---

Originally Posted by Matt

Would it be quite simple to build a windows version of the linux/mac/beos commandline client?

---

http://www.mingw.org/ is very good for porting Linux code to Windows. The only thing I would ask is that the config files use the .txt extension. Files without extensions are more difficult to view and edit, and files with .ini extension are often blocked (especially with Vista).

Quote:

---

Originally Posted by DOSGuy

Changing frequency from 1 confuses the hell out of Time Left. When I set frequency to 10, it indicates that there are about 10 minutes left, then slowly ticks down to 0 each block. It seems to be initially aware that it has to do 10 blocks, but then updates the time remaining based on the percentage of the current block complete.

---

The time remaining should be based on the current block - so that part's correct. However, you are right, there was a bug with how it calculated the time remaining when changing the frequency. I've fixed that in the code for the next build. Thanks!

Quote:

---

Originally Posted by Joe O

http://www.mingw.org/ is very good for porting Linux code to Windows. The only thing I would ask is that the config files use the .txt extension. Files without extensions are more difficult to view and edit, and files with .ini extension are often blocked (especially with Vista).

---

When you launch the commandline client - you can tell it exactly what filename to use for the config... so that shouldn't matter.

did you fix the bug, that you absolutely have to restart windows after a fresh install? if you don't, you will lose your test after the next restart. happens only once per install, but you can lose days of work through that. :thumbs:
Hope it is easy to fix.

Quote:

---

Originally Posted by Thommy3

did you fix the bug, that you absolutely have to restart windows after a fresh install? if you don't, you will lose your test after the next restart. happens only once per install, but you can lose days of work through that. :thumbs:
Hope it is easy to fix.

---

I *think* that may be a bug with the installer. I'll poke around and see if I can figure it out.

It would be nice if SB was more responsive to shutdown requests. Without SB, my system shuts down in seconds. With SB, after I tell the system to shutdown, the clients keep merrily crunching away until Windows reports that Explorer.exe isn't responding and asks if I want to End Now. Ignore that for about a minute and it will start to save my settings, but it still takes another minute or so to do it. All told, it takes my computer 2-3 minutes to shutdown if I don't turn off SB manually first.

Quote:

---

Originally Posted by DOSGuy

It would be nice if SB was more responsive to shutdown requests. Without SB, my system shuts down in seconds. With SB, after I tell the system to shutdown, the clients keep merrily crunching away until Windows reports that Explorer.exe isn't responding and asks if I want to End Now. Ignore that for about a minute and it will start to save my settings, but it still takes another minute or so to do it. All told, it takes my computer 2-3 minutes to shutdown if I don't turn off SB manually first.

---

That is very true. Hope there is a fix for this.:cheers:

If you shutdown the clients first, that wouldn't happen. ;)

You could always use an old hack of your registry - warning, you could crash your system if you don't know what you are doing.

This is used to speed up the Windows shutdown wait period.

Click Start button > Run > and type "regedit.exe" and hit the <enter> key, then browse to the following key:

HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control

Click on the Control key and in the right hand window you will see this key "WaitToKillServiceTimeout". Double click that key and set it to 200.
Close regedit.exe and then restart your computer.

:D

If that's just reducing how long Windows waits for a service to turn itself off before forcing it to close, could that prevent SB from "shutting down gracefully"?

I am useing v2.5.08 with XP on a P4(Northwood) with 2.66GHz, speed increase is about 5%.

Error?
When I try to change the run level from idle to low or normal I get an error message
"You've entered an invalid frequecy. Please check to make sure that it is between 1 and 10000."

That error is related to the frequency option of "transmit intermediate blocks". Even if you don't use "transmit intermediate blocks", you get the error message above if the value of "freq" is zero (which is the default value I believe).

It's a minor bug and a can be fixed by checking the "freq" value only if "transmit intermediate blocks" is ticked.

it worked, thank you

Guys just wondering if there will be a proper Vista client anytime soon or is this it.

May be is it worthwhile to make a 64 bits client for 64 bits OS. May be it will gain some performance on those machines instead of using the 32 bits emulator with the 32 bits client.

I am very happy with the new Beta Clients and have installed them at all locations. They have been stable and appear to give better performance, both due to new (better) algorithms and by using less resources for intermediate block communications. All my performance issues with the client have been address at this point. I have one maintenance/tracking issue that I have had concerns with from the start. That is keeping track of all of my clients. Although we can track by IP address, in most cases it is not that useful. Home based machines tend to be on a dynamic IP that change often. Work based machines sit behind a firewall/NAT so they all appear to all have the same IP address. I would love a machine name or nickname that I could give to each client instance, it would allow me to easily determine client problems, either stuck/stopped clients or orphaned tests. It would also give me an easier way to track performance per machine or instance. I understand that this change would not improve performance ...other then being able to detect stopped clients and restart them quicker. I would argue that if you are going to change the client with a formal release, and one encompassing so many different and new architectures an addition of an optional machine (instance) name would make client identification an maintenance much easier for the end user.

Nevermind, link just didn't work at school.

Feature requests for the Windows client:

1: The released version did not work for me under Vista - it did not save cache files. Have others seen that problem? Is that fixed in beta? If not, could you please fix it?
Until you support Vista, please upgrade the Web site and the readme ASAP so that new users know about the issue.
It might work under Vista if you change the installer to let the program install outside the Program Files folder - apparently that worked for the BOINC client.

2: Add a CPU throttle option within the program, or via a command line setting, or via a config file setting.

3: Pressing the Exit button should warn very clearly that you will discard the test and days worth of test calculations!

4: Minor items:
Rename Stop to Pause and Start to Restart.
Cap the size of the log file at NNN KB.
I do like the colorful graphic and the option to expire a test online!

Thanks!

can't download the beta client. server is down for some days now

Ps: I have posted in the secondpass-topic. Any comments on the quetions.

Are there any mirror sites where we can download the beta client from? The University of Michigan site errors with a "Cannot Access File, our apologies" blah blah message.

Alternatively, can someone who has it host it for us?

what about proxy support?

its a shame proxy not to be supported...

a lot of computers are behind proxies at their workplaces...

thats why i am running mersenne.org instead of seventeenorbust

hehe, great communication :rock:

I'd be happy to run it on Windows OS with an sob.cfg file.
Easy enough to make notepad the default editor for .cfg files. :)