Writing to HDD limits anyone?

[paris_england]

Looking to output some files from the MD to my HDD. Obviously we can poll the game engine incredibly quickly, but on the hardware side any ideas on the capabilities of an HDD (not SSD). I mean, is it prudent to write delete/write (or even just update/append) a file every 10ms? Every 100ms? Assume that the HDD can keep up.

What are the limits? Anyone have some info? Google was not my friend on this.



Thanks

[FlynTie]

I would strongly advise against doing it, HDD tend to be serious bottlenecks these days.

Small testimonial from X4. Having X4 on my HDD leads to textures being loaded late and massive lag-spikes at stations. Having it on my SSD eliminates all these problems.
And you have to factor a lot of things into it, general RPM of the HDD, fragmentation, OS Read and Write processes especially AV programs tend to interfere with your kind of idea.

I don't know what you have in mind but as long as it isn't anything ground-breaking i would strongly advise against it.

[paris_england]

This is a question about the physical limiations of an HDD and essentially a torture test ... and of course it's groundbreaking

A sql database will queue thousands of queries a second and write them, so let's just assume I want to write an external database to a 7200 rpm platter.

The question really is about the tolerance (physical limits) of an average consumer HDD regarding read/write speed and any recommendations. When would a drive break. What's a safe I/0 speed. The read write speed would allow for the design for the rest of the system.

To flesh out the picture a little, it's possible to output log files from x4. These can then be read externally and potentially manipulated (done). I'm looking at seeing how to re-import during runtime (not sure on this yet).

Regardless if they can be reread, there are some interesting possibilities here. But the functionality of the external source would be dependent on how often a drive _should_ be written to before it breaks. If it's quick enough (approx 0.015s) you could feasibly export realtime cockpit data to a second monitor. Slower than that, then the external app would have to be used for something else.

And while an SSD would be preferable, the thousands of r/w operations would destroy it before you could say "what's that frying smell?"

TLDR; I don't want to break anyone's HDD -- any recommendations for a safe r/w speed?

[jmattspartacus2]

What exactly are you trying to accomplish? Are you trying to dynamically grab variables and change them? Are you trying to Make it so you can see both outside the ship and inside the ship at the same time?
Or are you just trying to break your HDD?

Every hard drive has specs that come along with it, (and if you read further into the documentation, they will sometimes include the tolerances on those specs, or factory test data)
There are hardware bottlenecks to r/w speed with HDD's, but if you're just outputting text data from a game, it "shouldn't" be so much that it overwhelms it, SATA-III has a throughput theoretical maximum of 600MB/s.
https://kb.sandisk.com/app/answers/deta ... d-sata-iii

For safety, I'd say throttle the r/w maximum at around 25MB/s (1/6th of the SATA-I max), because if they're like me and running the game from their HDD (my SDD has my OS and work software and I'd rather they work at full speed always) they'll want the game to be playable with whatever you're doing (if you're planning on releasing something.
Even at 25MB/s my HDD will get very warm sometimes (especially if I'm downloading something that takes more than 5-10 minutes), so even that might be a stretch for some

Also, a final note, using a 3rd party software on runtime, even one that you've made (like a cheat type software that doesn't create modified save files) might be a breach of the EULA, so venture with caution.

[paris_england]

Or are you just trying to break your HDD?

Definitely not this

Dynamically grab data is the outcome. I'm not sure what direction I may take things, but one idea would be to simply create a simple instrument display on a second monitor (that would require a lot or writing to disk). Another idea may be to display the player property on a second monitor (would require less writing to disk)

And thanks for the info!

[jmattspartacus2]

Depending on your level of programming skill, you might be able to avoid the r/w barrier by storing it in some sort of temp file used by the program and only storing it in memory (and even then only till it's used to prevent memory clogging) unless you're getting debug outputs.
That's above my paygrade if I'm trying to adapt it to someone else's program, but if there's a way to do that, that's what I would do.