Writing to a logfile

[sinsi]

I want to log GPU temperatures to a file, probably once a second. What's the best way to handle it?
 - open the file, keep it open while logging, close after logging is finished
 - open, write that second's temp, close - every second
 - fill a memory buffer then open/create, write, close - every buffer
There is the possibility of overheating and windows freezing (that's what this is for, to see if the GPU or CPU is too hot).
For that reason, I am looking at the second option but is that too much overhead? A game will be thrashing everything.

Opinions sought.

[TouEnMasm]

The write and close immediatly seems the more usable,can be fast.
Usable also is a dll with shared memory avoiding disk access.

[sinsi]

>The write and close immediatly seems the more usable,can be fast.
That's what I am leaning towards.

>Usable also is a dll with shared memory avoiding disk access.
Because Windows may freeze, it needs to be a file I can look at later.

[hutch--]

If overhead with the logger is a factor, i would be inclined to keep an app open, log results into a buffer then lazy write the buffer content to disk at a convenient interval. If the app itself is at risk of locking up, I would use a remote app and send data to it.

[FORTRANS]

Hi,

   I would buffer a minute's worth (or 5 minutes) and
then write it out to minimize any effects on the system.
If worried about freezing, give each ~10 minute interval
a separate file.

Regards,

Steve N.

[Tedd]

Open the file with FILE_FLAG_WRITE_THROUGH, keep the file open;
Fill up your own data buffer and flush when full;
Adjust the 'full' threshold according to the current CPU temperature (lazy when low temp, crazy when high temp);
Close the file when finished (or a freeze and reboot will have the same effect.)


No repeated open-close, and no loss of data

[fearless]

MSI Afterburner (http://event.msi.com/vga/afterburner/download.htm) v2.2.4



has an option to monitor and log to file, and can display gpu temp whilst a game is running (along with other stuff - i usually just have FPS & Time displayed alongside GPU temp)

Works for both nvidia and ati cards.

For CPU temps i use CoreTemp to keep an eye on them - http://www.alcpu.com/CoreTemp/

[jj2007]

Does it matter?

include \masm32\MasmBasic\MasmBasic.inc   ; download
   Init
   .Repeat
      NanoTimer()
      Open "A", #1, "test.tmp"
      Print #1, Time$, CrLf$
      Close #1
      ; Print Str$("Writing took %i µs\n", NanoTimer(µs))
      Print Str$("Writing took %i ms\n", NanoTimer(ms))
      invoke Sleep, 500
      invoke GetKeyState, VK_SHIFT
   .Until sword ptr ax<0
   Inkey "bye"
   Exit
end start

Output:
Writing took 18 ms
Writing took 10 ms
Writing took 8 ms
Writing took 5 ms
Writing took 19 ms
Writing took 9 ms
Writing took 9 ms
bye

[dedndave]

the time consumed is not as much an issue as having the most recent data available for forensics
i like Tedd's method   :P

[sinsi]

Tedd, so if Windows freezes the file is still OK? The main problem is not the game freezing but Windows itself, with no time to close the file.
I like the idea of lazy/crazy writes too  8)

[jj2007]

Sinsi,

Keep it simple. I did the above test on my fast office machine, now again on my slow Celeron, and surprise, opening, writing and closing is done in less than a millisecond.

Even if it takes ten, and you do it once per minute, that slows down your game by 0.02%. I guess the player could live with that ;-)

[sinsi]

I didn't think there would be much if any overhead, I am from the old-school "if you open a handle you close it".
I will try Tedd's way and deliberately kill windows (reset button should do it) and see about the logfile.
If windows can't close it then is should show up as a lost cluster (by my way of thinking).

[Tedd]

The file size should be updated with each flush - which would be every write if there's no buffering - so the file should be okay as long as writes get to finish.
Closing is more of a formality, and to ensure the data has been flushed; the file still needs to be in a consistent state as much as possible, since there is always the possibility of a crash.
You will get inconsistencies if the write gets interrupted before it finishes, but there's no way around that whatever method you use.

[hutch--]

I still basically like the idea of using another app to perform the file IO so that even if the source app crashes the file data is not lost or left incomplete. Sending a HWND_BROADCAST is hardly a problem when you are talking about 1 second intervals. The slave app could also keep track of the main app sending the message to identify if it was still running or not.

[Vortex]

CoreTemp does not support Pentium IV processors.