highFreq or lowFreq

Jim1348
Jim1348
Joined: 19 Jan 06
Posts: 463
Credit: 257957147
RAC: 0

archae86 wrote:2. I suggest

archae86 wrote:

2. I suggest you check by review in Windows Explorer what the exact file name and file location is (many folks have accidentally saved a file with the wrong extension--Windows makes that all too easy).

Good point.  Use Notepad to create a file with those entries, but DO NOT save it as a text file.  Rather, use the "save as" function to save it as "app_config.xml".  That is, do not change the extension from ".txt" to ".xml" after you create it, or it will not work.

Then, if you put it in the right folder (C:\ProgramData\BOINC\projects\einstein.phys.uwm.edu), it will work.

 
Nick
Nick
Joined: 12 Oct 13
Posts: 27
Credit: 8949649
RAC: 0

ARCHAE Here is my

ARCHAE

Here is my app_config.xml

 

<app_config>
 <app>
   <name>hsgamma_FGRPB1G</name>
     <fraction_done_exact/>
     <gpu_versions>
         <gpu_usage>0.5</gpu_usage>
         <cpu_usage>0.5</cpu_usage>
     </gpu_versions>
 </app>     
 <app>
  <name>einstein_O1Spot1TLo</name>
   <fraction_done_exact/>
 </app>

 <app>
   <name>hsgamma_FGRPB1</name>
   <fraction_done_exact/>
 </app>
</app_config>

 

Here is the log

 

5/26/2017 7:13:45 AM |  | Starting BOINC client version 7.6.33 for windows_x86_64
5/26/2017 7:13:45 AM |  | log flags: file_xfer, sched_ops, task
5/26/2017 7:13:45 AM |  | Libraries: libcurl/7.47.1 OpenSSL/1.0.2g zlib/1.2.8
5/26/2017 7:13:45 AM |  | Data directory: C:\ProgramData\BOINC
5/26/2017 7:13:45 AM |  | Running under account Nick
5/26/2017 7:13:46 AM |  | CUDA: NVIDIA GPU 0: GeForce GTX 1050 Ti (driver version 381.65, CUDA version 8.0, compute capability 6.1, 4096MB, 3404MB available, 2138 GFLOPS peak)
5/26/2017 7:13:46 AM |  | CUDA: NVIDIA GPU 1: GeForce GTX 650 Ti (driver version 381.65, CUDA version 8.0, compute capability 3.0, 2048MB, 1697MB available, 1425 GFLOPS peak)
5/26/2017 7:13:46 AM |  | OpenCL: NVIDIA GPU 0: GeForce GTX 1050 Ti (driver version 381.65, device version OpenCL 1.2 CUDA, 4096MB, 3404MB available, 2138 GFLOPS peak)
5/26/2017 7:13:46 AM |  | OpenCL: NVIDIA GPU 1: GeForce GTX 650 Ti (driver version 381.65, device version OpenCL 1.2 CUDA, 2048MB, 1697MB available, 1425 GFLOPS peak)
5/26/2017 7:13:46 AM | SETI@home | Found app_info.xml; using anonymous platform
5/26/2017 7:13:46 AM |  | Host name: Server
5/26/2017 7:13:46 AM |  | Processor: 16 GenuineIntel Intel(R) Xeon(R) CPU           X5570  @ 2.93GHz [Family 6 Model 26 Stepping 5]
5/26/2017 7:13:46 AM |  | Processor features: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss htt tm pni ssse3 cx16 sse4_1 sse4_2 popcnt syscall nx lm vmx tm2 dca pbe
5/26/2017 7:13:46 AM |  | OS: Microsoft Windows 10: Professional x64 Edition, (10.00.14393.00)
5/26/2017 7:13:46 AM |  | Memory: 23.98 GB physical, 27.48 GB virtual
5/26/2017 7:13:46 AM |  | Disk: 232.24 GB total, 165.15 GB free
5/26/2017 7:13:46 AM |  | Local time is UTC -7 hours
5/26/2017 7:13:46 AM | Einstein@Home | Found app_config.xml
5/26/2017 7:13:46 AM |  | Config: report completed tasks immediately
5/26/2017 7:13:46 AM |  | Config: use all coprocessors
5/26/2017 7:13:46 AM | Einstein@Home | URL http://einstein.phys.uwm.edu/; Computer ID 12525148; resource share 100
5/26/2017 7:13:46 AM | SETI@home | URL http://setiathome.berkeley.edu/; Computer ID 8204995; resource share 100
5/26/2017 7:13:46 AM | Einstein@Home | General prefs: from Einstein@Home (last modified 15-May-2017 08:58:10)
5/26/2017 7:13:46 AM | Einstein@Home | Computer location: home
5/26/2017 7:13:46 AM | Einstein@Home | General prefs: no separate prefs for home; using your defaults
5/26/2017 7:13:46 AM |  | Reading preferences override file
5/26/2017 7:13:46 AM |  | Preferences:
5/26/2017 7:13:46 AM |  | max memory usage when active: 24559.22MB
5/26/2017 7:13:46 AM |  | max memory usage when idle: 24559.22MB
5/26/2017 7:13:46 AM |  | max disk usage: 100.00GB
5/26/2017 7:13:46 AM |  | max download rate: 999997 bytes/sec
5/26/2017 7:13:46 AM |  | max upload rate: 4999997 bytes/sec
5/26/2017 7:13:46 AM |  | (to change preferences, visit a project web site or select Preferences in the Manager)

Specifically what is not reporting the correct estimated remaining time is the FGRPSSE application. Others seem to be reporting correctly. I do not know how to identify that in the app_config.xml file.

Appreciate your help.

 

 

archae86
archae86
Joined: 6 Dec 05
Posts: 3145
Credit: 7057284931
RAC: 1601723

Nick_43 wrote:Specifically

Nick_43 wrote:
Specifically what is not reporting the correct estimated remaining time is the FGRPSSE application. Others seem to be reporting correctly. I do not know how to identify that in the app_config.xml file.

I made a copy of my current client_state.xml file (from the ProgramData\BOINC directory on my Windows 10 machine) and opened the copy in a text editor to look for names.  I looked for names others had successfully used in app_config, then reviewed their relationship to executables, and by analogy hoped I found the sort of reference wanted in app_config.  If you have not already consulted that source, perhaps it can work for you?

Nick
Nick
Joined: 12 Oct 13
Posts: 27
Credit: 8949649
RAC: 0

ARCHAE86 As you can see in

ARCHAE86

As you can see in my post above, I am using all of the names in your app_config.xml file except for the einstein_O1Spot1THi which is not valid for my machine.

I have determined that BOINC is not correctly reading the parameter from the app_config.xml file because I can change the parameter to read <fiction_done_exact/> (note it says "fiction" not "fraction" or simply "xxx") and no error message is generated. Clear syntax errors such as an added "/" or "[" do generate error messages (see below) so clearly it's reading the app_config.xml file.

unexpected text ']' in app_config.xml

 

Nick

archae86
archae86
Joined: 6 Dec 05
Posts: 3145
Credit: 7057284931
RAC: 1601723

Nick_43 wrote:I am using all

Nick_43 wrote:
I am using all of the names in your app_config.xml file except for the einstein_O1Spot1THi

I'm not running the application which is listed in the application column of the Valid tasks page for your machine as Gamma-ray pulsar binary search #1 v1.05 (FGRPSSE) windows_intelx86.  Thus there is no entry for it in the app_config.xml I provided.  It seems this is the one you want.

Reviewing the three application names in the file you posted, I see only these:

hsgamma_FGRPB1G, einstein_O1Spot1TLo, hsgamma_FGRPB1

It seems that you hope hsgamma_FGRPB1 will match the current version of "Gamma-ray pulsar binary search #1 v1.05 (FGRPSSE) windows_intelx86".  My only suggestion, other than waiting for someone with better ideas than mine to post, is that you explore your client_state.xml to see if you can find a different candidate name there.

Nick
Nick
Joined: 12 Oct 13
Posts: 27
Credit: 8949649
RAC: 0

ARCHAE86 It seems that you

ARCHAE86

It seems that you hope hsgamma_FGRPB1 will match the current version of "Gamma-ray pulsar binary search #1 v1.05 (FGRPSSE) windows_intelx86".  My only suggestion, other than waiting for someone with better ideas than mine to post, is that you explore your client_state.xml to see if you can find a different candidate name there.

I did.  hsgamma_FGRPB1 is the proper name but as I stated above, BOINC does not read the parameter <fraction_done_exact/> in the app_config.xml file as I can put anything in that field and it won't complain of an error. I can replace it with <XXXXX> and BOINC will not complain.

 

<app_config>
 <app>
  <name>hsgamma_FGRPB1</name>
  <XXXXXX/>
 </app>
 <app>
   <name>hsgamma_FGRPB1G</name>
   <fraction_done_exact/>
   <gpu_versions>
         <gpu_usage>0.5</gpu_usage>
         <cpu_usage>0.5</cpu_usage>
   </gpu_versions>
 </app>
 <app>
  <name>einstein_O1Spot1TLo</name>
  <XXXXX/>
 </app>
</app_config>

DanNeely
DanNeely
Joined: 4 Sep 05
Posts: 1364
Credit: 3562358667
RAC: 162

archae86 wrote:MarkHNC

archae86 wrote:
MarkHNC wrote:
Wouldn't a tiny buffer prevent me from getting longer running units? 

No it would not prevent you getting work.

With current deadlines, task types, and the duration estimating characteristics of the boinc client, people who want to mix this particular new CPU work with GPU work on Einstein need either to set a very short queue length, or to be prepared to spend a lot of time manually adjusting back and forth in order effectively to use a different queue length setting for GPU tasks and for CPU tasks.

Somewhat to my unpleasant surprise, the current boinc client seems to trip into high priority mode well over a day before the task deadline with a CPU task load the machine could easily finish on time. This "feature" combined with the already known DCF mismatch problem between work types really drives down the acceptable queue length.

At the moment I am making a once per day CPU task fetch procedure in which I first adjust down the queue length to 0.2 days on one machine and 0.3 days on another machine, and only then enable CPU task fetch. When new work has come on board, I first disable CPU task fetch again, then raise my queue length to my desired two days. The specific numbers are particular to my specific machines, and I agree with Gary that for a first shot 0.1 days is a really good idea, especially if you want a set-and-forget situation.

This will all get somewhat better when the project raises the deadline for these CPU tasks from the current short 5 days, but it is not going to get really good unless a brave new BOINC really handles a mix of different performing work types much better regarding run time estimation.  Don't hold your breath for that one.

 

In the previous science run I've found it much less work to just do a weekly abort run and kill several hundred tasks per GPU equipped PC.

 

I don't appear to be having much of a problem with the tuning run because my GPU boxes are running a large fraction of work from backup projects because I didn't want to waste CPU power slowly running fermi tasks when my GPUs can rocket through them 100x faster.  I think playing with local settings files to free extra GPU cores up by reducing the number Boinc thinks it should be using and then lying about the amount of CPU Fermi GPU tasks need may have helped with limiting the CPU imbalance too in addition to letting me keep the GPU fully loaded while running multiple CPU apps.

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5845
Credit: 109969616431
RAC: 30318550

Nick_43 wrote:Specifically

Nick_43 wrote:
Specifically what is not reporting the correct estimated remaining time is the FGRPSSE application. Others seem to be reporting correctly.

Sorry to be coming in late on this but I've been otherwise occupied and I haven't seen anyone give the following possible explanation.

I have lots of hosts doing FGRPB1 CPU tasks and whilst I haven't paid much attention to their runtime behaviour, my experience has been that these tasks get to somewhere in the range of 40%-70% complete and then suddenly finish.  It does seem to vary quite a bit depending on CPU type.

In other words, the app's internal mechanism for calculating the true percentage done is flawed.  If a task is actually about to finish and it happens to show 8 hours elapsed and 50% complete, wouldn't BOINC's fraction_done_exact mechanism simply be forced to show approximately 8 hours remaining if it is working properly?

 

Cheers,
Gary.

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5845
Credit: 109969616431
RAC: 30318550

Nick_43 wrote:I have

Nick_43 wrote:
I have determined that BOINC is not correctly reading the parameter from the app_config.xml file because I can change the parameter to read <fiction_done_exact/> (note it says "fiction" not "fraction" or simply "xxx") and no error message is generated.

There is a difference between an unrecognised tag and a true syntax error.  I suspect that something checks and complains about the syntax but perhaps remains silent about the name of a tag because that is not its job.  Something else probably reads and responds to tags it understands and simply ignores the ones that it doesn't.  That's just my guess.

 

Cheers,
Gary.

MarkJ
MarkJ
Joined: 28 Feb 08
Posts: 437
Credit: 137621151
RAC: 16773

MarkJ wrote:Ryzen 1700 at

MarkJ wrote:

Ryzen 1700 at stock clocks getting Lo only. Current estimate 5+ hours. Will see how they go. Hopefully they can get some stats out of the tuning run.

its this host

Running 16 at a time they seem to be in the range of 33,000 to 37,000 seconds. Running only 8 at a time at the moment to sse how much difference it makes.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.