As the Work Unit Crunches

Come join the... uh... er... fold.

Moderators: just brew it!, farmpuma

Re: As the Work Unit Crunches

Postposted on Sun Oct 03, 2010 7:34 pm

JustAnEngineer wrote:
Ragnar Dan wrote:What the BIOS calls the MCH is running hot.
That's your motherboard chipset. Does your chipset have one of those dinky little 40mm fans that always fail?
I know it is, I'm just amused it continues using that term when the memory controller has moved onto the CPU now.

It's a Gigabyte X58A-UD3R, BTW, and has a heatsink only on its NB, but I haven't checked how well attached it is. It probably needs a re-gooping, but the real problem is still the CPU & its HSF. There appears to be poor conduction from the heatspreader to the HS, and I also notice Core 0 is upwards of 10-12° C warmer than Core 3. The proc (a 930) is presently running at 3500 MHz, and when running Folding@Home, shows temperature readings near 100° C on the first core. Sounds dangerous, but I'm not convinced it's accurate. But I am considering a new HSF, and perhaps even a new motherboard to get what I think the processor can do out of it.
Last edited by Ragnar Dan on Sun Oct 03, 2010 7:39 pm, edited 1 time in total.
Ragnar Dan
Gerbil Elder
Silver subscriber
 
 
Posts: 5349
Joined: Sun Jan 20, 2002 6:00 pm

Re: As the Work Unit Crunches

Postposted on Sun Oct 03, 2010 7:39 pm

A chipset cooler may be cheaper than a new motherboard:
http://www.svc.com/hr-05-sli-ifx.html
http://www.svc.com/hr-05-ifx.html
i7-4770K, H70, Gryphon Z87, 16 GiB, R9-290, SSD, 2 HD, Blu-ray, SB ZX, TJ08-E, SS-660XP², 3007WFP+2001FP, RK-9000BR, MX518
JustAnEngineer
Gerbil God
Gold subscriber
 
 
Posts: 15153
Joined: Sat Jan 26, 2002 6:00 pm
Location: The Heart of Dixie

Re: As the Work Unit Crunches

Postposted on Sun Oct 03, 2010 7:53 pm

I appreciate the links, though I think at least one of the HS's is too tall for my case's width, but I think when I solve the CPU heat problem the chipset's will likely disappear with it. After all, it has 2 whole oz. of copper. :wink:
Ragnar Dan
Gerbil Elder
Silver subscriber
 
 
Posts: 5349
Joined: Sun Jan 20, 2002 6:00 pm

Re: As the Work Unit Crunches

Postposted on Fri Jan 07, 2011 7:54 pm

I decided to put this post in a more appropriate thread.

I tried installing my new CoGage True Spirit HSF setup yesterday, and apparently I harmed the motherboard's CPU socket when tightening down the new HS, somehow. Which means it's probably not going to work for me without some serious repairs using a diamond cutter's glass (or whatever it's called) and a very small tool to bend the 8 little metal contacts back to their proper places. Though I think it may be my CPU's heatspreader that's the main cause of the heat problem, because it appears to be overly convex by the looks of the thermal interface material (or goop, as I call it) on it after removing the old HSF. But I chose to buy a new mobo in a hurry (an EVGA X58 FTW3 132-GT-E768-KR board presently selling at Newegg for ~$265 - $30 rebate + shipping) rather than trying to fix the old one, but after spending $27 to get it overnighted to me, I learned it won't be shipped until tonight, which means I won't get it until Monday. Which is quite a pisser. I swear every time I break a computer part, it's Thursday or Friday. I definitely have to quit doing computer labors on those days.
Ragnar Dan
Gerbil Elder
Silver subscriber
 
 
Posts: 5349
Joined: Sun Jan 20, 2002 6:00 pm

Re: As the Work Unit Crunches

Postposted on Mon May 09, 2011 1:26 pm

I think I'm forgetting something, but I can't remember what it may be for the present. I reinstalled Windows 7 over the weekend in order to fix a stupid problem MS caused when Windows Update told me to upgrade their MS Security Essentials software a few months ago. The upgrade made it quit working, and a series of annoying interactions with an MS helper from India demonstrated they couldn't fix it. I tried a less severe solution on Saturday, and that failed to fix the main problem, but caused a new one: my GPU (a GTS 450) started running very slowly. I found the following thread on Stanford's Foldingforum Nvidia driver 270.51 & 270.61 break FAH, which has a link to this thread claiming nVidia's 266.58 drivers work best.

After reinstalling Windows to solve the MSSE problem, and installing my most important software, I installed the previously mentioned GPU driver. But still the GPU client runs at about 36% the speed it used to do. A vague notion that its client or core wasn't getting enough CPU cycles caused me to reconfigure the client setting it to "low" instead of "idle" priority, but that made no difference, although the SMP client also running under Windows does produce more quickly while the GPU client isn't performing up to par. I'm netting a loss of about 5000 - 6000 PPD, though. And I'm stumped.
Ragnar Dan
Gerbil Elder
Silver subscriber
 
 
Posts: 5349
Joined: Sun Jan 20, 2002 6:00 pm

Re: As the Work Unit Crunches

Postposted on Tue May 10, 2011 12:53 pm

Well here's an odd occurrence: the GPU client (which is the Fermi client, BTW) began working normally after it finished and uploaded a WU at 20:39 UTC last night. It has worked properly since then, and this morning I checked the logs and changed it back to idle priority, and it has continued working as it should. Heck if I know why. And I just learned something today which will please most -bigadv SMP folders, but I'll make a new thread about it.
Ragnar Dan
Gerbil Elder
Silver subscriber
 
 
Posts: 5349
Joined: Sun Jan 20, 2002 6:00 pm

Re: As the Work Unit Crunches

Postposted on Wed Jul 06, 2011 3:13 pm

Last night I turned in a bigadv WU, and according to the HFM.NET monitoring program, expected about 73500 points for it. What I got instead, however, was around 60000 points. I assumed Stanford had made some sort of calculation error and decided to look into it over the next day or so and then go on folding-forum.org and complain about it.

Today I began looking into it and found out that my point loss was not an error, but done purposely. According to Vijay Pande's blog:
The main jist of the change is that we are decreasing the points associated with bigadv WUs, from 50% over SMP to 20% over SMP.


And as usual with Stanford, they haven't updated their Kfactor listing on the project listing page after making the change, so the monitoring software won't report accurate figures.

That has made me reconsider the huge electricity cost of my contributions. Money I could be saving for retirement, among other things.

But, they also say:
The other change that we have in mind to do is to bring all classic and GPU WUs into the Quick Return Bonus (QRB) system. This would help further bring all FAH projects into balance. There may be some issues with GPUs and QRB, so we are looking to see what we can do to minimize problems with that before making a change in the points for GPU WUs.

So I may wait a while. Then again, I may not.
Ragnar Dan
Gerbil Elder
Silver subscriber
 
 
Posts: 5349
Joined: Sun Jan 20, 2002 6:00 pm

Re: As the Work Unit Crunches

Postposted on Wed Jul 06, 2011 3:56 pm

That actually would be great. My GPU would benefit greatly from the QRB since it's almost always idle, while my CPU isn't. bigadv was overweighted in the first place anyway.
Mothership: Thuban 1055T@3.7GHz, 12GB DDR3, M5A99X EVO, GTX470+Icy Vision Rev.2@840/3800, Vertex 2E 60GB
Supply ship: Sargas@2.8GHz, 12GB DDR3, M4A88TD-V EVO/USB3
Corsair: Macbook Air Ivy Bridge
Crayon Shin Chan
Minister of Gerbil Affairs
 
Posts: 2214
Joined: Fri Sep 06, 2002 10:14 am
Location: Malaysia

Re: As the Work Unit Crunches

Postposted on Wed Jul 06, 2011 3:59 pm

Ragnar Dan wrote:Last night I turned in a bigadv WU, and according to the HFM.NET monitoring program, expected about 73500 points for it. What I got instead, however, was around 60000 points. I assumed Stanford had made some sort of calculation error and decided to look into it over the next day or so and then go on folding-forum.org and complain about it.

Today I began looking into it and found out that my point loss was not an error, but done purposely. According to Vijay Pande's blog:
The main jist of the change is that we are decreasing the points associated with bigadv WUs, from 50% over SMP to 20% over SMP.


And as usual with Stanford, they haven't updated their Kfactor listing on the project listing page after making the change, so the monitoring software won't report accurate figures.

That has made me reconsider the huge electricity cost of my contributions. Money I could be saving for retirement, among other things.

But, they also say:
The other change that we have in mind to do is to bring all classic and GPU WUs into the Quick Return Bonus (QRB) system. This would help further bring all FAH projects into balance. There may be some issues with GPUs and QRB, so we are looking to see what we can do to minimize problems with that before making a change in the points for GPU WUs.

So I may wait a while. Then again, I may not.


I'm almost to the point of shutting down, if I have another $ 300ish electric bill this month it might be time to pack it in , which is shame because I just recently started my long climb up page 1 for 2630 and have been a Top 20 producer for a month or so.
ASUS P5B-E,ConroeE6400,2GB Mushkin DDR2 800,
EVGA 8800GTS,Corsair 520HX,Antec 900,WD320 GB,Samsung 204B
rogue426
Graphmaster Gerbil
 
Posts: 1251
Joined: Thu Jul 21, 2005 8:51 pm

Re: As the Work Unit Crunches

Postposted on Wed Jul 06, 2011 6:10 pm

Crayon Shin Chan wrote:That actually would be great. My GPU would benefit greatly from the QRB since it's almost always idle, while my CPU isn't. bigadv was overweighted in the first place anyway.

I am of the opposite opinion. I prefer SMP over GPU, since for some reason GPU makers can't get their power consumption under control. I don't mind GPU getting more points because of the large megaFLOPs advantage, but not to the point before -bigadv where SMP folding was somewhat pointless. GPU heat also seems to expose a quality problem among video cards where margin is cut to very small and they break a lot easier than CPUs. So if I have to pick either CPU or GPU to consume power and generate heat, I would much rather it be the CPU.
Image
The Model M is not for the faint of heart. You either like them or hate them.

Gerbils unite! Fold for UnitedGerbilNation, team 2630.
Flying Fox
Gerbil God
 
Posts: 24142
Joined: Mon May 24, 2004 1:19 am

Re: As the Work Unit Crunches

Postposted on Wed Jul 06, 2011 6:44 pm

One modification: HFM.NET seems to be accurate now. I don't see that there was a change to the page I mentioned, but I don't recall the original number for certain anymore, and blah blah... I don't care as much about that. All that matters is that it's of great cost to run bigadv WU's, and of significantly less use than it had been. I don't know that I'll be able to quit using the room A/C in the room the bigadv SMP machine is in, but I know it will run the compressor less often if I quit running the bigadv's. And that fact is becoming more persuasive the more I think about it.
Ragnar Dan
Gerbil Elder
Silver subscriber
 
 
Posts: 5349
Joined: Sun Jan 20, 2002 6:00 pm

Re: As the Work Unit Crunches

Postposted on Wed Jul 06, 2011 6:57 pm

Ragnar Dan wrote:One modification: HFM.NET seems to be accurate now. I don't see that there was a change to the page I mentioned, but I don't recall the original number for certain anymore, and blah blah... I don't care as much about that. All that matters is that it's of great cost to run bigadv WU's, and of significantly less use than it had been. I don't know that I'll be able to quit using the room A/C in the room the bigadv SMP machine is in, but I know it will run the compressor less often if I quit running the bigadv's. And that fact is becoming more persuasive the more I think about it.

Summer is in full swing. I see nothing new.
Image
The Model M is not for the faint of heart. You either like them or hate them.

Gerbils unite! Fold for UnitedGerbilNation, team 2630.
Flying Fox
Gerbil God
 
Posts: 24142
Joined: Mon May 24, 2004 1:19 am

Re: As the Work Unit Crunches

Postposted on Wed Jul 06, 2011 7:03 pm

I've quit running dedicated folding nodes; my "crate farm" days are long gone. I still run a number of SMP clients, but they have to be on machines that have another purpose as well (desktop, file server, web server, burn-in test of new hardware, etc.); this has been sufficient to consistently keep me in the top 20 producers on Team TR.

I'll still crank up an extra node or two in the winter when the heat output is a benefit instead of fighting with the A/C; but electricity just costs too damn much these days to do more than that. Furthermore, living in Illinois (where a lot of our electricity comes from coal) means running dedicated folders also contributes a non-trivial amount to CO2 emissions and other pollutants; the extra A/C load just compounds this.

I still believe that the research F@h does is worthwhile, and will continue to participate as long as it is practical for me to do so.

One idea I've toyed with is figuring out a way to set things up so that the extra heat output does not fight with the A/C -- vent the exhaust of a couple of systems to the outside during the summer months. Or stick 'em in the attic -- as long as the CPU HSF is a bit over-speced, it ought to be able to handle the higher ambient temps without becoming unstable.
(this space intentionally left blank)
just brew it!
Administrator
Gold subscriber
 
 
Posts: 36920
Joined: Tue Aug 20, 2002 9:51 pm
Location: Somewhere, having a beer

Re: As the Work Unit Crunches

Postposted on Fri Aug 05, 2011 1:38 pm

Adding to this post...

Well, I found out that -bigadv folding in Linux is more efficient enough that it caused my machine's OC to become unstable. And because of the small amount of disk space I granted the Virtual Machine, when it died it somehow killed the WU. Which meant there was no reason to try to get it (Ubuntu 10.04.3 LTS) working since I could just use notfred's iso instead, and gain even more efficiency. So I did that. I've gone from ~33.5 minutes / frame in Windows to as few as 29.75 minutes / frame using notfred's iso, which is quite a gain (> 11%).

I slowed the machine's base clock down by 1 Mhz in its BIOS, and then later used an EVGA utility to do another Mhz, which with a 20x multiplier amounts to 40 Mhz per core slowdown, and 320 Mhz for all 8 threads. But it's still fast as heck. One thing I forgot a bit about was the OS's system clock. I thought when it started out that its time started at UTC, but now it's listing the time as local time, and looking at the FAHlog indicates the same thing since it started. Furthermore, I can't read the client's files on any other machine except the host. I'm sure I'm not thinking about something, but I'll find out later.
Ragnar Dan
Gerbil Elder
Silver subscriber
 
 
Posts: 5349
Joined: Sun Jan 20, 2002 6:00 pm

Re: As the Work Unit Crunches

Postposted on Sat Aug 06, 2011 1:59 am

So you are saying that LinuxSMP (even running a VM on a Windows host) is now faster than WinSMP again? With or without -bigadv?
Image
The Model M is not for the faint of heart. You either like them or hate them.

Gerbils unite! Fold for UnitedGerbilNation, team 2630.
Flying Fox
Gerbil God
 
Posts: 24142
Joined: Mon May 24, 2004 1:19 am

Re: As the Work Unit Crunches

Postposted on Sat Aug 06, 2011 10:05 am

I've only tested with -bigadv, but it's as much as 3.5 minutes / frame faster on my machine, even with the CPU slowed down slightly to keep it from crashing.
Ragnar Dan
Gerbil Elder
Silver subscriber
 
 
Posts: 5349
Joined: Sun Jan 20, 2002 6:00 pm

Re: As the Work Unit Crunches

Postposted on Sun Aug 07, 2011 9:38 pm

To address a couple of the points raised in your last post to the sticky thread --

- VirtualBox allows 8 CPUs; you may want to give it a try sometime. Caveat: I've been less than impressed with their SMP implementation in the past; but maybe it has gotten better.

- Rather than futzing around with Samba, it might be easier to use whatever folder sharing facilities your virtualization tool provides to make a folder on the host system visible to the guest.
(this space intentionally left blank)
just brew it!
Administrator
Gold subscriber
 
 
Posts: 36920
Joined: Tue Aug 20, 2002 9:51 pm
Location: Somewhere, having a beer

Re: As the Work Unit Crunches

Postposted on Tue Aug 09, 2011 8:28 pm

I read some talk about VirtualBox over at foldingforum.org, and the word was that it wasn't very good, still. Though that was before the revision released in the last couple of months. Still, it's worth testing some day. Once I get a less precarious setup than I presently have (I lost a monitor due to bent pins on its VGA connector -> DVI converter) maybe I'll give it a go.

I tried to mess with that folder sharing stuff without reading anything, but I quickly decided to run notfred's ISO and that thing has it all set up already, though I had to change how it was networked to get it to show up. The problem with that is that it runs in RAM, and I thought the flash drive I was using was working, but... well, turns out it has gone to crap. And as fortune oft smiles upon me, so too yesterday did I have a system BSOD over night and lost a day's worth of folding. :wink: That irked me enough that I just got the GPU going again and left the SMP stuff until after several hours. I then started up an ISO that someone named linuxfah on foldingforum has, and that's seemed to work. It takes up (according to my simple test with "du -c" [I could've sworn that used to be "du -q"]) around 325 MB of drive space. It has an annoying system that doesn't let you logout (it logs you back in immediately), but otherwise is fairly efficient looking, though it seems to vary quite a bit between frames and, as with anything running on a VMWare VM, the clock becomes inaccurate very quickly. I'd prefer to modify notfred's to use the drive (though I'd also like to get a way to Putty into it from Windows machines), but this other system will do for now, and I have a feeling it's probably easier to get software to add to it since it's not quite as minimal an install.

Thanks for your input. :)
Ragnar Dan
Gerbil Elder
Silver subscriber
 
 
Posts: 5349
Joined: Sun Jan 20, 2002 6:00 pm

Re: As the Work Unit Crunches

Postposted on Wed Sep 07, 2011 4:24 pm

Well, I've been running Linux's SMP -bigadv for about a month now, and it's been enough of a PITA that I'm going to quit. It fails often enough that whatever gains in efficiency are more than wiped out by the fact that it can take an entire day to finally decide to upload a completed WU, or the fact that a restart if you fail to "sync" beforehand, can often wipe out the WU.

So I'm going back to Windows SMP. Whatever the efficiency loss, at least restarts aren't so precarious, and my system clock doesn't disagree with it, either. :-?
Ragnar Dan
Gerbil Elder
Silver subscriber
 
 
Posts: 5349
Joined: Sun Jan 20, 2002 6:00 pm

Re: As the Work Unit Crunches

Postposted on Wed Sep 07, 2011 6:05 pm

I've been running Linux SMP (without -bigadv) exclusively for quite some time now. Other than installation headaches (incompatibility with the run-time libraries in newer versions of Ubuntu) it is pretty much fire-and-forget.
(this space intentionally left blank)
just brew it!
Administrator
Gold subscriber
 
 
Posts: 36920
Joined: Tue Aug 20, 2002 9:51 pm
Location: Somewhere, having a beer

Re: As the Work Unit Crunches

Postposted on Wed Sep 07, 2011 6:43 pm

Well, I shouldn't write as though it's Linux's fault. I don't know what the problem is, but it's happening even as I type this.

Here's my current WU waiting to upload, but apparently not doing so even though the FahCore_a5.exe has finished its work, though it's still running:
Code: Select all
[22:45:13] Completed 247500 out of 250000 steps  (99%)
[23:17:19] Completed 250000 out of 250000 steps  (100%)
[23:17:33] DynamicWrapper: Finished Work Unit: sleep=10000
[23:17:43]
[23:17:43] Finished Work Unit:
[23:17:43] - Reading up to 56110368 from "work/wudata_03.trr": Read 56110368
[23:17:45] trr file hash check passed.
[23:17:45] - Reading up to 45505772 from "work/wudata_03.xtc": Read 45505772
[23:17:47] xtc file hash check passed.
[23:17:47] edr file hash check passed.
[23:17:47] logfile size: 261462
[23:17:47] Leaving Run
[23:17:49] - Writing 102047550 bytes of core data to disk...
[23:17:53]   ... Done.

I don't know what the problem is (though I wouldn't be surprised if it was related to the failure for that FahCore_a5.exe process to complete its work), but there it sits doing nothing, and until I run a different Linux than the one I'm running and find it works, I'll keep assuming it's the bigadv client code that's the problem.

Edit: It finally finished waiting long enough and finished writing the WU to disk, or whatever it was doing. So I'm back to Windows, but it welcomed me back with a non-bigadv WU. :roll:
Ragnar Dan
Gerbil Elder
Silver subscriber
 
 
Posts: 5349
Joined: Sun Jan 20, 2002 6:00 pm

Re: As the Work Unit Crunches

Postposted on Wed Sep 07, 2011 8:15 pm

This is a known issue if you install Lunux with an Ext4 file system, the default with Ubuntu and others.

Quickest fix is to reinstall with ext3. It may be also possible to fix the issues by remounting the filesystem with "nobarriers", but I don't have any instructions for that.

H.
Haitch
Gerbil In Training
 
Posts: 5
Joined: Sat Aug 28, 2010 5:47 pm

Re: As the Work Unit Crunches

Postposted on Wed Sep 07, 2011 9:00 pm

Hm. Interesting. You'd think whoever did the LinuxFAH VM setup I'm using would have known about that by now. Oh well, I'll see if I can find out anything about it with respect to that setup, and maybe play with it if necessary.

Thanks for the tip. :D
Ragnar Dan
Gerbil Elder
Silver subscriber
 
 
Posts: 5349
Joined: Sun Jan 20, 2002 6:00 pm

Re: As the Work Unit Crunches

Postposted on Wed Sep 07, 2011 9:24 pm

FAH client development seems to lag the bleeding edge distros a fair bit, and they also do some questionable stuff (like relying on the undocumented library function that causes the incompatibility with newer versions of Ubuntu). Ext4 was not considered stable enough to be the default file system by most distros until fairly recently; sounds like maybe FAH was relying on some undocumented behavior of ext3 that went away (or changed) when ext4 became the default.

You can try adding the "nobarrier" option to your /etc/fstab file. If there's a line with a mount point of "/home", add it to the <options> column of that line, otherwise add it to the line with a mount point of "/". If the existing <options> entry says "defaults" then you should replace "defaults" with "nobarrier"; otherwise, append "nobarrier" to the existing option(s), separated from them by a comma. Reboot the system to have the new options take effect.
(this space intentionally left blank)
just brew it!
Administrator
Gold subscriber
 
 
Posts: 36920
Joined: Tue Aug 20, 2002 9:51 pm
Location: Somewhere, having a beer

Re: As the Work Unit Crunches

Postposted on Wed Sep 07, 2011 9:42 pm

Turns out on running it again that it actually uses XFS for a filesystem, about which I know less than ext4 (I think ext2 was the last one I was reasonably up-to-date on).

I would not be surprised if the filesystem troubles of other distros made the choice of XFS seem most sensible, though I'll have to wade through the long thread about it on foldingforum.org to find out.
Ragnar Dan
Gerbil Elder
Silver subscriber
 
 
Posts: 5349
Joined: Sun Jan 20, 2002 6:00 pm

Re: As the Work Unit Crunches

Postposted on Wed Sep 07, 2011 9:59 pm

Heh... you probably know about as much as I do about XFS at this point. The last time I used it was on an SGI IRIX server, circa 1995; most of those brain cells are long dead! :lol:
(this space intentionally left blank)
just brew it!
Administrator
Gold subscriber
 
 
Posts: 36920
Joined: Tue Aug 20, 2002 9:51 pm
Location: Somewhere, having a beer

Re: As the Work Unit Crunches

Postposted on Thu Sep 08, 2011 6:01 pm

The barrier fix will also work for XFS.

The problem with the filesystems is specific to those that have barriers enabled, and is a problem of Stanfords making. After completing the WU the client 0's out two ( or more, don't recall all the murky details) of the temp files, one byte at a time, and some of the files are over 100MB. The filesystems with barriers enabled take a long time to do this. EXT3 with no barrier support does it a lot faster.

H.
Haitch
Gerbil In Training
 
Posts: 5
Joined: Sat Aug 28, 2010 5:47 pm

Re: As the Work Unit Crunches

Postposted on Thu Sep 08, 2011 6:20 pm

Haitch wrote:After completing the WU the client 0's out two ( or more, don't recall all the murky details) of the temp files, one byte at a time,

I think there's only one appropriate reaction to this: :roll:

They really ought to hire themselves at least one experienced software developer who's worked out in industry, instead of relying on students to do all of their coding for them! :lol:
(this space intentionally left blank)
just brew it!
Administrator
Gold subscriber
 
 
Posts: 36920
Joined: Tue Aug 20, 2002 9:51 pm
Location: Somewhere, having a beer

Re: As the Work Unit Crunches

Postposted on Thu Sep 08, 2011 9:36 pm

Yeah, its a weird thing to do.

They zero out the files, then delete them. I may have been incorrect on the byte at a time - may be 4K at a time - can't find the definitive explanation of what it was doing, but the process is:

write either 1 null or 4KB of nulls
sync to disk ( Forcing a disk write)
repeat until to done
delete the file.

Thats 25,000 or 100,000,000 forced writes per WU temp file, and F/S over head.
Apparently ext3 doesn't have as much overhead. And neither do SSD's. I have a bigadv 12 core machine doing bigadv units, on an el cheapo SSD and with ext4, and unit end to unit written is under a minute.

Barrier overhead kills those filesystems - they make the filesystems more reliable, but huge overhead for the client.

H.
Haitch
Gerbil In Training
 
Posts: 5
Joined: Sat Aug 28, 2010 5:47 pm

Re: As the Work Unit Crunches

Postposted on Thu Sep 08, 2011 10:02 pm

It explains some odd behavior I'd noticed some time back, even on the normal (no -bigadv) SMP WUs. At the end of a WU, the client appears to pause, and the hard drive audibly *buzzes* for several minutes. In fact the system I'm posting from is doing it right now!

I imagine what's going on is repeated rapid seeks between where the file itself is stored, and where the file system metadata for that file is stored.
(this space intentionally left blank)
just brew it!
Administrator
Gold subscriber
 
 
Posts: 36920
Joined: Tue Aug 20, 2002 9:51 pm
Location: Somewhere, having a beer

PreviousNext

Return to TR Distributed Computing Effort

Who is online

Users browsing this forum: No registered users and 0 guests