LHC@home

Seagate's web site lists Mean Time Between Failures (MTBF) for some drives as 1.4 million hours. That's about 160 years. Given that MTBF is an average, any drive could potentially fail at any time, but the likelihood of any specific drive failing in service is extremely low. Once a second access is trivial. It's around 86400 access per day. Many server disks run with that number of access in a few minutes, 24 hours/day. You're likely to replace the drive for other reasons long before it fails.

Flash memory does indeed wear out with repeated write and erase cycles. Estimates on the life of flash memory components can be calculated on Intel's web site here.

Their default parameters suggest that lives of 10 years should be achievable, but not if you're using Flash for extensive updates. Flash isn't designed for that sort of work anyway.

Mike W

---

Gaspode the UnDressed
http://www.littlevale.co.uk

AFAIK Sixtrack always did, and still does, write constantly to a number of work files, called fort.xx. This is done in addition to checkpointing file writing. Frequency of checkpointing can be controlled by the user, but frequency of these "ambient" writes cannot.

However, for modern operating systems this shouldn't be a problem. At least my Linux box buffers the writes and when running BOINC, it writes to the disk in about 5s intervals. When the machine is "idle" (not running BOINC), it still continues writing in about 5s intervals because there always seems to be something that needs to be written anyway.

Of course some could argue that keeping write buffers enabled is a bad idea for the sake of data security (if the power goes off, data in the buffers won't get written). For those, BOINC on RAM disk could be a better solution (at least CC 4.35 has an option to set another data directory). When using BOINC on RAM disk, I recommend having low amount of work buffering. I'm not sure how to set up a RAM disk in Windows, but in Linux that's relatively easy. Maybe somebody more experienced with Windows could help with the Windows part.

As somebody already said, I don't recommend using a flash-memory based device for Sixtrack data storage.

The best solution, of course, would be to fix Sixtrack to use only memory records instead of file records. Unfortunately that might mean rewrite of Sixtrack so don't hold your breath for that.

---

Markku Degerholm
LHC@home admin

> Maybe somebody more experienced with Windows could help with the Windows
> part.
>
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q257405
or
http://www.winsoft.sk/ramdisk.htm

or google for it... ;-)

sysfried

---

I just checked my Systems and I got the HD access every 1 Second as well, but seems to happen only on Windows (sixtrack V4.67).

My Linux Boxes don't seem to have that anymore however (sixtrack V4.66).

---

Scientific Network : 45000 MHz - 77824 MB - 1970 GB

>
> My Linux Boxes don't seem to have that anymore however (sixtrack V4.66).
>

see Markku's post... Linux does file buffering different than windows... that's why you don't see as much HD activity....

---

> see Markku's post... Linux does file buffering different than windows...
> that's why you don't see as much HD activity....

Hm, I could swear the recent sixtrack fixed that.
Before that, I could also see + hear my Linux Systems scratching their HD's every Second when running LHC, so I deemed the sixtrack Version responsible to the change.

But I never checked them all, only a repeated observation from some Linux boxes in one of 2 rooms, so I could have mis-assessed it.

---

Scientific Network : 45000 MHz - 77824 MB - 1970 GB

> Hm, I could swear the recent sixtrack fixed that.

It could be that frequency of writes have been changed, but I'm not aware of that. I guess I'll need to ask:)

> Before that, I could also see + hear my Linux Systems scratching their HD's
> every Second when running LHC, so I deemed the sixtrack Version responsible to
> the change.

It can also depend on the filesystem mount options. If you have "async" option enabled, the writes are buffered, while "sync" mode makes the writes happen immediately.

Most linux distributions usually have the asynchronous mode as the default, but many server systems use synchronous writes to ensure data integrity even in unexpected occasions such as power / hardware failure.

However, I guess you would know if the filesystem options were changed... So maybe there is something else.

---

Markku Degerholm
LHC@home admin

The tool 'Filemon' from
http://www.sysinternals.com/ntw2k/source/filemon.shtml
shows all the file accesses:
12:00:42 sixtrack_4.67_w:5188 WRITE \BOINC\slots\fort.91 Length: 15
12:00:43 sixtrack_4.67_w:5188 WRITE \BOINC\slots\fort.91 Length: 15
12:00:43 sixtrack_4.67_w:5188 WRITE \BOINC\slots\fort.91 Length: 15
12:00:43 sixtrack_4.67_w:5188 WRITE \BOINC\slots\fort.91 Length: 15
12:00:44 sixtrack_4.67_w:5188 WRITE \BOINC\slots\fort.91 Length: 15
12:00:44 sixtrack_4.67_w:5188 WRITE \BOINC\slots\fort.91 Length: 15
12:00:44 sixtrack_4.67_w:5188 WRITE \BOINC\slots\fort.91 Length: 15
12:00:44 sixtrack_4.67_w:5188 WRITE \BOINC\slots\fort.91 Length: 15
12:00:45 sixtrack_4.67_w:5188 WRITE \BOINC\slots\fort.91 Length: 15
12:00:45 sixtrack_4.67_w:5188 WRITE \BOINC\slots\fort.91 Length: 15
12:00:45 sixtrack_4.67_w:5188 WRITE \BOINC\slots\fort.91 Length: 15
12:00:45 sixtrack_4.67_w:5188 WRITE \BOINC\slots\fort.91 Length: 15
12:00:46 sixtrack_4.67_w:5188 WRITE \BOINC\slots\fort.91 Length: 15
12:00:46 sixtrack_4.67_w:5188 WRITE \BOINC\slots\fort.91 Length: 15
12:00:46 sixtrack_4.67_w:5188 WRITE \BOINC\slots\fort.91 Length: 15
12:00:46 sixtrack_4.67_w:5188 WRITE \BOINC\slots\fort.91 Length: 15

---

<img src="http://www.boincsynergy.com/images/stats/comb-1321.jpg"></img>