zero cache hits in games

[Support]

@Flyingcircus, what's your cache strategy? Thanks.

[Flyingcircus]

sorry forgot to put that in
it's read/write

[Support]

Thank you all, we'll check this issue.

[Incriminated]

sry

[Incriminated]

1. Well like i said I tried reloading the same data several times... my cache is 3GB in size, that's bigger than the memory footprint of any of those games so limited cache size shouldn't be the issue i hope (in case of MWO the cache is actually bigger than the game itself... and i already tried starting all of the games with an almost empty cache)

May it come to your mind that the way you test it (game) maybe read/write differently from i.e. archives, what turns out to be not cacheable? what do you mean exactly with "i tried reloading the same data"... PC/FC supports only windows filesystem FILE-read/write.

2. As I mentioned plenty of disk reads are recorded by the statistics tool however none of them are cache hits

So the plenty of disk-reads you encounter in the statistics obviously are not represented in the cache before, so they are NOT cacheable.

3. That's true for vertex data however textures and heightmaps are quite big and that's reflected in the several hundreds of MB of disk reads that do happen when loading the games

So you say your game loads every single texture and lightmaps from each singled physical file.... are you specifically sure, then please give a specific example... or does that game more likely read from a single-archive which the game-engine extracting stream indifferently by certain algorythm than a os-file-read. -> non cacheable. PC/FC cannot cache only a part of a file (stream of an game-engine archive). for beeing cachable a single file (in means of windows filesystem) needs to be completely read before.

@suport:
windows software raid + windows default cache + primocache.... extremely overheading block size... additional firmware-raid running.... running games that read/write files potentially from archived-data-streams .... you really look into this crap of these noobs xD OMG, please spend your time putting effort into developing the product, there is no such error like claimed here on real physical drives testing cacheable-data. not a single issue.

[Incriminated]

BTW:

The last 2 heros (FlyingCircus and AikenDrum) use LFU-R on all disks.... this naturally cannot work because reading the help enlightens:

LFU-R (Least Frequently Used): Counts how often a cache block is needed. Cache blocks that are used least often will be discarded first.

That menas you have to reload your game-map/scenarie plenty of times before it stays in cache, until it is counted more often than all the rest...

What all these people want is: LRU (Least Recently Used): Discards the least recently used data first.
But still it applies, that most game-r/W are simply not cacheable.
Thats the intelligence that uses software raid plus firmware raid plus software-cache-solution.... not even able to read a short manual of basic settings: Pure epic fail!

In the end LFU-R-cache of those guys may be filled up with bench data of CrystalDisk or others, because these are most frequently used than anything else possibly

And the support... not even seeing that... but tell you "they look into it"... oh really... i wouldn bet a cent, but....
..., I bet all I have that the thread-started also uses LFU-R..... xD

[Support]

Hi Incriminated,

Thank you for the thinkings.

PC/FC cannot cache only a part of a file

This is not right. PC/FC can cache a part of a file.

One of the possibilities of causing this issue is that game reads and writes plenty of data and cache is not large enough to store all data. So some existing cache data is discarded (controlled by cache algorithm).

Another possibility is that Windows has its own file cache. So when "reloading the same data several times", this data was coming from windows cache.

All these data activities can be observed from the cache statisitcs. Please see
http://www.romexsoftware.com/en-us/prim ... mance.html

[Incriminated]

Whatever LFU-R is the problem i see here.

If you want something to be read from cache on the second try, then it needs to be kept in cache at the very first read. (LRU)
SO you need to cache recent files, not frequently used ones.

[Flyingcircus]

buddy i'm not an idiot
i know how to test specifically for cache hits

of course i took care that the cache was NOT full when i tested (which i specifically mentioned before ->you're not even able to read a fucking post and try to tell me i can't read a manual?) and the software keeps ALL files in cache when they're read for the first time and if there is enough free space available.. the discard algorithm has no effect on that (which is why it's called a DISCARD algorithm) so there was no reason why game files should not be read from the cache

oh and guess what i also tested with LRU.. and guess again.. yeah didn't work
that games use uncacheable data is also absolute bullshit.. textures are always the same when loaded and they happen to provide the majority of data that's streamed from disk to memory

but thanks for "discarding"our issue like that and trying to make us look like fools
much appreciated

gotta love these know-it-alls

[Flyingcircus]

Hi Incriminated,

Thank you for the thinkings.

PC/FC cannot cache only a part of a file

This is not right. PC/FC can cache a part of a file.

One of the possibilities of causing this issue is that game reads and writes plenty of data and cache is not large enough to store all data. So some existing cache data is discarded (controlled by cache algorithm).

Another possibility is that Windows has its own file cache. So when "reloading the same data several times", this data was coming from windows cache.

All these data activities can be observed from the cache statisitcs. Please see
http://www.romexsoftware.com/en-us/prim ... mance.html

well i can already exclude the first possibility since i took care that the cache was fresh (i.e. empty) before the tests and had some empty space left afterwards

second one may be an option but that makes me wonder why it only has an effect on games
i'll try to see if the problem persists when i turn off superfetch


edit: disabling superfetch and then loading the same level several times while restarting the game client in between did nothing.. but i did notice something i hadn't noticed before
less disk reads seem to occur on each consecutive load
the first load causes a normal amount of disk reads and the other loads cause significantly less even if the client is restarted in between

that suggests something is being cached but that strikes me as odd considering superfetch should be the only windows caching service... maybe the readings of the statistics tool are off? i honestly don't understand that behaviour