Page 1 of 2
Downtime between WUs?
Posted: Wed Jun 20, 2012 3:55 pm
by csvanefalk
I mostly get 8004 WUs, and currently it takes about 1-2 minutes for a new WU to start folding after one finishes...is there a way to get around this? I am not sure, but it seems that the client waits to download and start folding until the old WU is sucessfully uploaded to the server. Would it not be possible to relegate the verification and uploading to a separate process, so that the new WU can start folding immediately?
The typical downtime message I am referring to is this:
Code: Select all
23:33:54:WU00:FS00:0xa4:Completed 247500 out of 250000 steps (99%)
23:34:13:WU00:FS00:0xa4:Completed 250000 out of 250000 steps (100%)
23:34:13:WU00:FS00:0xa4:DynamicWrapper: Finished Work Unit: sleep=10000
23:34:23:WU00:FS00:0xa4:
23:34:23:WU00:FS00:0xa4:Finished Work Unit:
23:34:23:WU00:FS00:0xa4:- Reading up to 770532 from "00/wudata_01.trr": Read 770532
23:34:23:WU00:FS00:0xa4:trr file hash check passed.
23:34:23:WU00:FS00:0xa4:- Reading up to 456640 from "00/wudata_01.xtc": Read 456640
23:34:23:WU00:FS00:0xa4:xtc file hash check passed.
23:34:23:WU00:FS00:0xa4:edr file hash check passed.
23:34:23:WU00:FS00:0xa4:logfile size: 22476
23:34:23:WU00:FS00:0xa4:Leaving Run
23:34:24:WU00:FS00:0xa4:- Writing 1255052 bytes of core data to disk...
23:34:24:WU00:FS00:0xa4:Done: 1254540 -> 1194750 (compressed to 95.2 percent)
23:34:24:WU00:FS00:0xa4: ... Done.
23:35:08:WU00:FS00:0xa4:- Shutting down core
23:35:08:WU00:FS00:0xa4:
23:35:08:WU00:FS00:0xa4:Folding@home Core Shutdown: FINISHED_UNIT
23:35:13:WU00:FS00:FahCore returned: FINISHED_UNIT (100 = 0x64)
23:35:13:WU00:FS00:Sending unit results: id:00 state:SEND error:OK project:8004 run:121 clone:10 gen:192 core:0xa4 unit:0x000001256652edcb4ee901ca46b1295e
23:35:13:WU00:FS00:Uploading 1.14MiB to 171.67.108.59
23:35:13:WU00:FS00:Connecting to 171.67.108.59:8080
23:35:13:WU01:FS00:Connecting to assign3.stanford.edu:8080
23:35:14:WU01:FS00:News: Welcome to Folding@Home
23:35:14:WU01:FS00:Assigned to work server 171.67.108.59
23:35:14:WU01:FS00:Requesting new work unit for slot 00: READY smp:12 from 171.67.108.59
23:35:14:WU01:FS00:Connecting to 171.67.108.59:8080
23:35:15:WU01:FS00:Downloading 531.56KiB
23:35:16:WU00:FS00:Upload complete
23:35:16:WU00:FS00:Server responded WORK_ACK (400)
23:35:16:WU00:FS00:Final credit estimate, 922.00 points
23:35:16:WU00:FS00:Cleaning up
23:35:22:WU01:FS00:Download 96.32%
23:35:22:WU01:FS00:Download complete
23:35:22:WU01:FS00:Received Unit: id:01 state:DOWNLOAD error:OK project:8004 run:175 clone:16 gen:86 core:0xa4 unit:0x0000007d6652edcb4ee9037454d514d4
23:35:22:WU01:FS00:Starting
23:35:22:WU01:FS00:Running FahCore: /usr/bin/FAHCoreWrapper /var/lib/fahclient/cores/www.stanford.edu/~pande/Linux/AMD64/Core_a4.fah/FahCore_a4 -dir 01 -suffix 01 -version 701 -lifeline 956 -checkpoint 30 -np 12
23:35:22:WU01:FS00:Started FahCore on PID 1630
23:35:22:Started thread 9 on PID 956
23:35:22:WU01:FS00:Core PID:1634
23:35:22:WU01:FS00:FahCore 0xa4 started
23:35:22:WU01:FS00:0xa4:
23:35:22:WU01:FS00:0xa4:*------------------------------*
23:35:22:WU01:FS00:0xa4:Folding@Home Gromacs GB Core
23:35:22:WU01:FS00:0xa4:Version 2.27 (Dec. 15, 2010)
23:35:22:WU01:FS00:0xa4:
23:35:22:WU01:FS00:0xa4:Preparing to commence simulation
23:35:22:WU01:FS00:0xa4:- Looking at optimizations...
23:35:22:WU01:FS00:0xa4:- Created dyn
23:35:22:WU01:FS00:0xa4:- Files status OK
23:35:22:WU01:FS00:0xa4:- Expanded 543810 -> 1303296 (decompressed 239.6 percent)
23:35:22:WU01:FS00:0xa4:Called DecompressByteArray: compressed_data_size=543810 data_size=1303296, decompressed_data_size=1303296 diff=0
23:35:22:WU01:FS00:0xa4:- Digital signature verified
23:35:22:WU01:FS00:0xa4:
23:35:22:WU01:FS00:0xa4:Project: 8004 (Run 175, Clone 16, Gen 86)
23:35:22:WU01:FS00:0xa4:
23:35:22:WU01:FS00:0xa4:Assembly optimizations on if available.
23:35:22:WU01:FS00:0xa4:Entering M.D.
23:35:28:WU01:FS00:0xa4:Completed 0 out of 250000 steps (0%)
23:35:47:WU01:FS00:0xa4:Completed 2500 out of 250000 steps (1%)
Re: Downtime between WUs?
Posted: Wed Jun 20, 2012 4:05 pm
by 7im
What is the value of this option in your log?
<next-unit-percentage v=' ? '/>
Set it one percentage lower so the next WU downloads just a bit sooner.
Please also note that 1-2 minutes is a vast improvement over the previous v6 client. As you can see in your log, the current WU, and the next WU are uploading/downloading concurrently. The v6 client uploaded first, then downloaded next, causing much longer pauses between work units.
Re: Downtime between WUs?
Posted: Wed Jun 20, 2012 4:15 pm
by csvanefalk
Hehe, I guess I am getting spoiled already
I just itch to optimize stuff...will set the variable you pointed out and see what happens
Re: Downtime between WUs?
Posted: Wed Jun 20, 2012 4:17 pm
by Jesse_V
Usually the next-unit-percentage is set to 99, (the default) so that when a WU gets to 99%, the client downloads the next WU. Then when the WU finishes, the next one is ready to go. Like 7im said, you can adjust this value to download the WU sooner or later. But the clock starts when the WU downloads, so it's your call.
Re: Downtime between WUs?
Posted: Wed Jun 20, 2012 4:28 pm
by csvanefalk
Jesse_V wrote:But the clock starts when the WU downloads
Can you elaborate on this a bit? Could there be problems?
Re: Downtime between WUs?
Posted: Wed Jun 20, 2012 4:58 pm
by Zagen30
csvanefalk wrote:Jesse_V wrote:But the clock starts when the WU downloads
Can you elaborate on this a bit? Could there be problems?
I assume he was referring to how it affects bonus points. The return time is calculated from when the WU is first downloaded, not when the client starts processing it, so by having WUs downloaded at 99% you'll lose some bonus points as the previous WU is being finished. It's not that much, though, so I wouldn't worry about it.
Re: Downtime between WUs?
Posted: Wed Jun 20, 2012 4:58 pm
by iceman1992
csvanefalk wrote:Jesse_V wrote:But the clock starts when the WU downloads
Can you elaborate on this a bit? Could there be problems?
Just that if you set the client to download a new unit at 91% for example, and it finished downloading at say 94%, it will be sitting idle at least until the current one finishes. That drops your QRB
Re: Downtime between WUs?
Posted: Wed Jun 20, 2012 5:03 pm
by csvanefalk
Ah ok, thanks!
Re: Downtime between WUs?
Posted: Wed Jun 20, 2012 5:13 pm
by csvanefalk
EDIT: this has occured for all WUs since I changed the setting, so I am guessing I am doing something wrong :-/
Alright, so I set it to 98%...and now I am having trouble with the client being assigned the same WU it is already working on?? Can I fix this?
Code: Select all
17:08:51:WU00:FS00:0xa4:Completed 242500 out of 250000 steps (97%)
17:09:10:WU00:FS00:0xa4:Completed 245000 out of 250000 steps (98%)
17:09:10:WU01:FS00:Connecting to assign3.stanford.edu:8080
17:09:11:WU01:FS00:News: Welcome to Folding@Home
17:09:11:WU01:FS00:Assigned to work server 171.67.108.59
17:09:11:WU01:FS00:Requesting new work unit for slot 00: RUNNING smp:12 from 171.67.108.59
17:09:11:WU01:FS00:Connecting to 171.67.108.59:8080
17:09:12:ERROR:WU01:FS00:Exception: Have already seen this work unit 0x0000004d6652edcb4ee90039505df21a aborting download
17:09:12:WU01:FS00:Connecting to assign3.stanford.edu:8080
17:09:12:WU01:FS00:News: Welcome to Folding@Home
17:09:12:WU01:FS00:Assigned to work server 171.67.108.59
17:09:12:WU01:FS00:Requesting new work unit for slot 00: RUNNING smp:12 from 171.67.108.59
17:09:12:WU01:FS00:Connecting to 171.67.108.59:8080
17:09:13:ERROR:WU01:FS00:Exception: Have already seen this work unit 0x0000004d6652edcb4ee90039505df21a aborting download
17:09:28:WU00:FS00:0xa4:Completed 247500 out of 250000 steps (99%)
17:09:47:WU00:FS00:0xa4:Completed 250000 out of 250000 steps (100%)
17:09:47:WU00:FS00:0xa4:DynamicWrapper: Finished Work Unit: sleep=10000
17:09:57:WU00:FS00:0xa4:
17:09:57:WU00:FS00:0xa4:Finished Work Unit:
17:09:57:WU00:FS00:0xa4:- Reading up to 769884 from "00/wudata_01.trr": Read 769884
17:09:57:WU00:FS00:0xa4:trr file hash check passed.
17:09:57:WU00:FS00:0xa4:- Reading up to 456868 from "00/wudata_01.xtc": Read 456868
17:09:57:WU00:FS00:0xa4:xtc file hash check passed.
17:09:57:WU00:FS00:0xa4:edr file hash check passed.
17:09:57:WU00:FS00:0xa4:logfile size: 22561
17:09:57:WU00:FS00:0xa4:Leaving Run
17:09:58:WU00:FS00:0xa4:- Writing 1254717 bytes of core data to disk...
17:09:58:WU00:FS00:0xa4:Done: 1254205 -> 1194511 (compressed to 95.2 percent)
17:09:58:WU00:FS00:0xa4: ... Done.
17:10:12:WU01:FS00:Connecting to assign3.stanford.edu:8080
17:10:12:WU01:FS00:News: Welcome to Folding@Home
17:10:12:WU01:FS00:Assigned to work server 171.67.108.59
17:10:12:WU01:FS00:Requesting new work unit for slot 00: RUNNING smp:12 from 171.67.108.59
17:10:12:WU01:FS00:Connecting to 171.67.108.59:8080
17:10:13:ERROR:WU01:FS00:Exception: Have already seen this work unit 0x0000004d6652edcb4ee90039505df21a aborting download
17:10:42:WU00:FS00:0xa4:- Shutting down core
17:10:42:WU00:FS00:0xa4:
17:10:42:WU00:FS00:0xa4:Folding@home Core Shutdown: FINISHED_UNIT
17:10:48:WU00:FS00:FahCore returned: FINISHED_UNIT (100 = 0x64)
17:10:48:WU00:FS00:Sending unit results: id:00 state:SEND error:OK project:8004 run:69 clone:16 gen:54 core:0xa4 unit:0x0000004d6652edcb4ee90039505df21a
17:10:48:WU00:FS00:Uploading 1.14MiB to 171.67.108.59
17:10:48:WU00:FS00:Connecting to 171.67.108.59:8080
17:10:51:WU00:FS00:Upload complete
17:10:51:WU00:FS00:Server responded WORK_ACK (400)
17:10:51:WU00:FS00:Final credit estimate, 909.00 points
17:10:51:WU00:FS00:Cleaning up
17:11:49:WU01:FS00:Connecting to assign3.stanford.edu:8080
17:11:50:WU01:FS00:News: Welcome to Folding@Home
17:11:50:WU01:FS00:Assigned to work server 171.67.108.59
17:11:50:WU01:FS00:Requesting new work unit for slot 00: READY smp:12 from 171.67.108.59
17:11:50:WU01:FS00:Connecting to 171.67.108.59:8080
17:11:50:WU01:FS00:Downloading 532.48KiB
17:11:57:WU01:FS00:Download 48.08%
17:12:00:WU01:FS00:Download complete
17:12:00:WU01:FS00:Received Unit: id:01 state:DOWNLOAD error:OK project:8004 run:66 clone:51 gen:18 core:0xa4 unit:0x000000146652edcb4eee56383fcdfed7
17:12:00:WU01:FS00:Starting
17:12:00:WU01:FS00:Running FahCore: /usr/bin/FAHCoreWrapper /var/lib/fahclient/cores/www.stanford.edu/~pande/Linux/AMD64/Core_a4.fah/FahCore_a4 -dir 01 -suffix 01 -version 701 -lifeline 956 -checkpoint 30 -np 12
17:12:00:WU01:FS00:Started FahCore on PID 2140
17:12:00:Started thread 36 on PID 956
17:12:00:WU01:FS00:Core PID:2144
17:12:00:WU01:FS00:FahCore 0xa4 started
17:12:00:WU01:FS00:0xa4:
17:12:00:WU01:FS00:0xa4:*------------------------------*
17:12:00:WU01:FS00:0xa4:Folding@Home Gromacs GB Core
17:12:00:WU01:FS00:0xa4:Version 2.27 (Dec. 15, 2010)
17:12:00:WU01:FS00:0xa4:
17:12:00:WU01:FS00:0xa4:Preparing to commence simulation
17:12:00:WU01:FS00:0xa4:- Looking at optimizations...
17:12:00:WU01:FS00:0xa4:- Created dyn
17:12:00:WU01:FS00:0xa4:- Files status OK
17:12:00:WU01:FS00:0xa4:- Expanded 544749 -> 1305312 (decompressed 239.6 percent)
17:12:00:WU01:FS00:0xa4:Called DecompressByteArray: compressed_data_size=544749 data_size=1305312, decompressed_data_size=1305312 diff=0
17:12:00:WU01:FS00:0xa4:- Digital signature verified
17:12:00:WU01:FS00:0xa4:
17:12:00:WU01:FS00:0xa4:Project: 8004 (Run 66, Clone 51, Gen 18)
17:12:00:WU01:FS00:0xa4:
17:12:00:WU01:FS00:0xa4:Assembly optimizations on if available.
17:12:00:WU01:FS00:0xa4:Entering M.D.
17:12:06:WU01:FS00:0xa4:Completed 0 out of 250000 steps (0%)
17:12:25:WU01:FS00:0xa4:Completed 2500 out of 250000 steps (1%)
17:12:45:WU01:FS00:0xa4:Completed 5000 out of 250000 steps (2%)
Re: Downtime between WUs?
Posted: Wed Jun 20, 2012 8:24 pm
by Jesse_V
Apologizes, yes I meant bonus points...
Re: Downtime between WUs?
Posted: Wed Jun 20, 2012 10:55 pm
by GreyWhiskers
Here's a post from a while ago.
It helped me to understand what happens between the "next-percentage" time and when a WU is ready to fold, having completed the previous WU. It's important to know what kind of WUs you are folding (e.g., are you doing bigadv's with 25 MB or 50 MB downloads, or are you doing smaller WUs?), and what the nature of your internet connection is. FWIW, I am doing a mix of regular SMP WUs and Core 15 Fermi GPU WUs, none of which have very big downloads. BTW, it doesn't matter how big the uploads are - that happens in parallel with processing the next WU. I have a Comcast cable internet connection in Silicon Valley, which gives me maybe a couple of Mbps upload and 15 Mbps download, so the downloads occur very, very quickly.
Finally, with the latest SMP WUs being very small - on my i7 2600k, less than an hour per WU,and with short deadlines of 1.6 days - downloading too soon will be noticeable in the QRB points.
GreyWhiskers wrote:13:38:43:WU01:FS02:0xa4:Completed 250000 out of 250000 steps (100%)
13:38:43:WU01:FS02:0xa4:DynamicWrapper: Finished Work Unit: sleep=10000
13:38:44:WU03:FS02:Connecting to assign3.stanford.edu:8080
13:38:44:WU03:FS02:News: Welcome to Folding@Home
13:38:44:WU03:FS02:Assigned to work server 171.67.108.58
13:38:44:WU03:FS02:Requesting new work unit for slot 02: RUNNING smp:6 from 171.67.108.58
13:38:44:WU03:FS02:Connecting to 171.67.108.58:8080
13:38:45:WU03:FS02:Downloading 531.87KiB
13:38:46:WU03:FS02:Download complete
13:38:46:WU03:FS02:Received Unit: id:03 state:DOWNLOAD error:OK project:8001 run:21 clone:53 gen:10 core:0xa4 unit:0x000000126652edca4eded91fac1d64a7
13:38:53:WU01:FS02:0xa4:
13:38:53:WU01:FS02:0xa4:Finished Work Unit:
Especially for SMP, which factors Quick return Bonus into the points calculation, I have chosen to set the "next unit percentage" to 100%. Here are some of the reasons:
- The QRB clock starts with your download and ends with the upload complete of your finished product.
- There is at least 10 seconds, usually much longer, between the 100% and the "Finished Work Unit". See the "Sleep" line. After the "sleep", this time is used to package up the various log files and completed data files created during execution of your WU into one compressed file to upload to the server, and clean up the WU.
- Your new WU will start only after the "Finished Work Unit" time.
- if you have a decently fast internet connection, you can use this time between 100% and Finished Work unit to download your next WU.
- I don't remember an instance when the actual download time exceeded this. I folded bigadv SMP WUs for quite some time with 25 MByte downloads - but I was running them on v6 where I couldn't take advantage of this overlap.
- Even if your download did take a few seconds longer than the 100%-to-"Finished Work Unit" time, these few seconds are undoubtedly MUCH shorter than the TPF frame time. If your TPF for a big WU is, say, 8 minutes, and you download at 99%, and if the download takes say 25 seconds, your QRB clock started at least 8 minutes earlier than it needed to - you can't start folding this new WU anyway until you reach the "Finished Work Unit" time anyway.
In the first example you included, the SMP download was only 48.90 KiB, which was downloaded in about a second. Your log example didn't show what your TPF for that WU was, but if it was several minutes, you were holding onto the downloaded WU for all that time, PLUS the 100% to "Finished Work Unit" time, while the QRB clock was ticking.
In your second example, which DID start at the download at 100%, you downloaded a much larger WU, 531.87 KiB. The download took about 2 seconds: from 13:38:44 (connecting to assign) to 13:38:46 (Download complete). Even though you had only 10 seconds between 100% and "Finished Work Unit" (the previous WU must have been very small), you still had 7 extra seconds before folding could start. Your TPF for the finished work unit was 64 seconds. If you HAD downloaded at 99%, you would have been sitting on the next WU for 64 + 10 - 2 = 72 seconds while the QRB clock ticked, [EDIT] vs the 7 seconds you did wait[/EDIT]. I've seen some short WUs where that 65 seconds could have made a difference in your points.
Anyway, that's my long-winded 2 cents.
Re: Downtime between WUs?
Posted: Thu Jun 21, 2012 12:39 am
by bruce
csvanefalk wrote:EDIT: this has occurred for all WUs since I changed the setting, so I am guessing I am doing something wrong :-/
Alright, so I set it to 98%...and now I am having trouble with the client being assigned the same WU it is already working on?? Can I fix this?
I takes you 19 seconds to complete a frame for this project. You can change next-unit-percentage from 98% to 100% and it will improve your QRB by 38 seconds -- probably not something you'll even notice. Downloading actually took 11 seconds (from 17:11:49 to 17:12:00) so it normally won't have any trouble downloading between when the WU reaches 100% and when the FahCore is finished organizing the data for upload (61 seconds from 17:09:47 to 17:10:48).
The data uploaded in 3 seconds (from 17:10:48 to 17:10:51)
I don't see a lot of room for improvement. I suppose if you replaced your HD with an SSD you could save a reasonable percentage of the 61 seconds.
Some servers are programmed to reissue the same WU if the same Client ID requests a new WU before it finishes with a WU for the same slot. It's much better for the client to reject it with the "already seen" message than to accept it and process it a second time for zero credit.
Re: Downtime between WUs?
Posted: Sun Jun 24, 2012 8:49 am
by csvanefalk
Thanks for all the replies so far! You guys have really helped me understand the inter-WU processing period a lot better.
I noticed one issue I am wondering about though. Below you can find my logfile as I finish folding a 7905 WU...notice the whopping 6 minute gap between
... Done and
Shutting down core... I was actively monitoring CPU and memory usage (with top) during this period, and the system was more or less completely idle. There were occasional (5-6) spikes of acitvity that involved the Client, but these were extremely brief and used no more than a few percentage points of the total CPU capacity (9%).
Can someone help me understand what the Client is doing during this interval? What is it waiting for?
Code: Select all
08:30:30:WU00:FS00:0xa4:Completed 495000 out of 500000 steps (99%)
08:30:31:WU01:FS00:Connecting to assign3.stanford.edu:8080
08:30:32:WU01:FS00:News: Welcome to Folding@Home
08:30:32:WU01:FS00:Assigned to work server 128.113.12.163
08:30:32:WU01:FS00:Requesting new work unit for slot 00: RUNNING smp:12 from 128.113.12.163
08:30:32:WU01:FS00:Connecting to 128.113.12.163:8080
08:30:33:WU01:FS00:Downloading 1.85MiB
08:30:39:WU01:FS00:Download 37.24%
08:30:45:WU01:FS00:Download 67.70%
08:30:48:WU01:FS00:Download complete
08:30:48:WU01:FS00:Received Unit: id:01 state:DOWNLOAD error:OK project:7905 run:89 clone:3 gen:7 core:0xa4 unit:0x0000000b00ac9c234e4d8516efac4ed5
[christopher@chrisdesktop ~]$ 08:32:09:WU00:FS00:0xa4:Completed 500000 out of 500000 steps (100%)
08:32:09:WU00:FS00:0xa4:DynamicWrapper: Finished Work Unit: sleep=10000
08:32:19:WU00:FS00:0xa4:
08:32:19:WU00:FS00:0xa4:Finished Work Unit:
08:32:20:WU00:FS00:0xa4:- Reading up to 24721224 from "00/wudata_01.trr": Read 24721224
08:32:20:WU00:FS00:0xa4:trr file hash check passed.
08:32:20:WU00:FS00:0xa4:edr file hash check passed.
08:32:20:WU00:FS00:0xa4:logfile size: 25640
08:32:20:WU00:FS00:0xa4:Leaving Run
08:32:21:WU00:FS00:0xa4:- Writing 24754220 bytes of core data to disk...
08:32:24:WU00:FS00:0xa4:Done: 24753708 -> 19664894 (compressed to 79.4 percent)
08:32:24:WU00:FS00:0xa4: ... Done.
08:39:06:WU00:FS00:0xa4:- Shutting down core
08:39:06:WU00:FS00:0xa4:
08:39:06:WU00:FS00:0xa4:Folding@home Core Shutdown: FINISHED_UNIT
08:39:29:WU00:FS00:FahCore returned: FINISHED_UNIT (100 = 0x64)
08:39:29:WU00:FS00:Sending unit results: id:00 state:SEND error:OK project:7905 run:110 clone:0 gen:12 core:0xa4 unit:0x0000000d00ac9c234e4d8589ed06c89f
08:39:29:WU00:FS00:Uploading 18.75MiB to 128.113.12.163
08:39:29:WU00:FS00:Connecting to 128.113.12.163:8080
08:39:29:WU01:FS00:Starting
08:39:29:WU01:FS00:Running FahCore: /usr/bin/FAHCoreWrapper /var/lib/fahclient/cores/www.stanford.edu/~pande/Linux/AMD64/Core_a4.fah/FahCore_a4 -dir 01 -suffix 01 -version 701 -lifeline 1129 -checkpoint 30 -np 12
08:39:29:WU01:FS00:Started FahCore on PID 11400
08:39:29:Started thread 16 on PID 1129
08:39:29:WU01:FS00:Core PID:11404
08:39:29:WU01:FS00:FahCore 0xa4 started
08:39:30:WU01:FS00:0xa4:
08:39:30:WU01:FS00:0xa4:*------------------------------*
08:39:30:WU01:FS00:0xa4:Folding@Home Gromacs GB Core
08:39:30:WU01:FS00:0xa4:Version 2.27 (Dec. 15, 2010)
08:39:30:WU01:FS00:0xa4:
08:39:30:WU01:FS00:0xa4:Preparing to commence simulation
08:39:30:WU01:FS00:0xa4:- Looking at optimizations...
08:39:30:WU01:FS00:0xa4:- Created dyn
08:39:30:WU01:FS00:0xa4:- Files status OK
08:39:30:WU01:FS00:0xa4:- Expanded 1935474 -> 2552108 (decompressed 131.8 percent)
08:39:30:WU01:FS00:0xa4:Called DecompressByteArray: compressed_data_size=1935474 data_size=2552108, decompressed_data_size=2552108 diff=0
08:39:30:WU01:FS00:0xa4:- Digital signature verified
08:39:30:WU01:FS00:0xa4:
08:39:30:WU01:FS00:0xa4:Project: 7905 (Run 89, Clone 3, Gen 7)
08:39:30:WU01:FS00:0xa4:
08:39:30:WU01:FS00:0xa4:Assembly optimizations on if available.
08:39:30:WU01:FS00:0xa4:Entering M.D.
08:39:35:WU00:FS00:Upload 29.66%
08:39:36:WU01:FS00:0xa4:Completed 0 out of 500000 steps (0%)
08:39:41:WU00:FS00:Upload 50.99%
08:39:47:WU00:FS00:Upload 67.32%
08:39:53:WU00:FS00:Upload 95.31%
08:39:57:WU00:FS00:Upload complete
08:39:57:WU00:FS00:Server responded WORK_ACK (400)
08:39:57:WU00:FS00:Final credit estimate, 4633.00 points
08:39:58:WU00:FS00:Cleaning up
Re: Downtime between WUs?
Posted: Sun Jun 24, 2012 9:10 am
by Nathan_P
There is a known problem if you are using the ext4 file system on a linux machine. For reasons that i don't know the ext 4 filing system takes a very long time to write out the WU files to a standard HDD at the end of processing. This does not happen on an SSD with ext 4 or on ext3 filing systems
Re: Downtime between WUs?
Posted: Sun Jun 24, 2012 9:38 am
by csvanefalk
Nathan_P wrote:There is a known problem if you are using the ext4 file system on a linux machine. For reasons that i don't know the ext 4 filing system takes a very long time to write out the WU files to a standard HDD at the end of processing. This does not happen on an SSD with ext 4 or on ext3 filing systems
That would fit my situation exactly - I am running ext4 on a standard HDD. I am going to google this a bit and see if I can find a solution.
EDIT: it seems running the client on a RAM disk should resolve this...I am going to try that setup and see what happens.