Difference between revisions of "Memory cvars"
(taken from http://bani.anime.net/banimod/forums/viewtopic.php?t=3335&postdays=0&postorder=asc&start=60 with minimal changes) |
(→Hunk and Zone) |
||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 9: | Line 9: | ||
105060 bytes (0.10MB) free sound buffer memory, 50521500 bytes (48.18MB) total used | 105060 bytes (0.10MB) free sound buffer memory, 50521500 bytes (48.18MB) total used | ||
| − | 92463100 bytes (88.18MB) sound buffer memory have been allocated since the last SND_setup | + | 92463100 bytes (88.18MB) sound buffer memory have been allocated since the last SND_setup |
This example is with <tt>com_soundmegs 48</tt>, and it shows that if I wanted to keep ''all'' the sound in memory, I'd want to shoot for soundmegs 96 or so. In reality, that's probably overkill (some large sounds, like the per-level voiceover in the limbo menu, are rarely used), but I'm pretty sure they're all loaded when you load the level, regardless (and just freed again if you use up soundmegs.) So, basically, a high-ish soundmegs is good, but setting it ''really'' high probably won't help much unless you have a really slow/busy disk but a lot of RAM. | This example is with <tt>com_soundmegs 48</tt>, and it shows that if I wanted to keep ''all'' the sound in memory, I'd want to shoot for soundmegs 96 or so. In reality, that's probably overkill (some large sounds, like the per-level voiceover in the limbo menu, are rarely used), but I'm pretty sure they're all loaded when you load the level, regardless (and just freed again if you use up soundmegs.) So, basically, a high-ish soundmegs is good, but setting it ''really'' high probably won't help much unless you have a really slow/busy disk but a lot of RAM. | ||
| + | |||
| + | Note that sample rate affects sound memory needs (s_khz 44 will use twice as much memory as 22, which in turn uses twice as much as 11). | ||
===Hunk and Zone=== | ===Hunk and Zone=== | ||
| Line 38: | Line 40: | ||
(note the comments to the right of each line) | (note the comments to the right of each line) | ||
So, the client uses a fair bit of hunk memory (adding together the total hunk and the unused highwater, my com_hunkmegs of 64 looks pretty good), a ''lot'' of sound memory, and very little zone memory. | So, the client uses a fair bit of hunk memory (adding together the total hunk and the unused highwater, my com_hunkmegs of 64 looks pretty good), a ''lot'' of sound memory, and very little zone memory. | ||
| + | |||
| + | The value of com_zonemegs can only be set via commandline (+set com_zonemegs xx). If set in the config, the desired value will only show as "latched." Regardless, meminfo always lists zone as 24 (the default), which would imply that this value cannot be changed. | ||
Latest revision as of 01:55, 3 September 2006
Determining memory usage
Sound
s_list will display a list of all sounds and whether they're currently in RAM, along with a summary at the end, e.g.:
0[16bit] : sound/weapons/mortar/mortarf1.wav[paged out] 53950[16bit] : sound/etpro/osp_fight.wav[resident ] 52808[16bit] : sound/etpro/osp_goat.wav[resident ] Total resident: 45634975 105060 bytes (0.10MB) free sound buffer memory, 50521500 bytes (48.18MB) total used 92463100 bytes (88.18MB) sound buffer memory have been allocated since the last SND_setup
This example is with com_soundmegs 48, and it shows that if I wanted to keep all the sound in memory, I'd want to shoot for soundmegs 96 or so. In reality, that's probably overkill (some large sounds, like the per-level voiceover in the limbo menu, are rarely used), but I'm pretty sure they're all loaded when you load the level, regardless (and just freed again if you use up soundmegs.) So, basically, a high-ish soundmegs is good, but setting it really high probably won't help much unless you have a really slow/busy disk but a lot of RAM.
Note that sample rate affects sound memory needs (s_khz 44 will use twice as much memory as 22, which in turn uses twice as much as 11).
Hunk and Zone
meminfo will display information about the hunk and the zone:
67108864 bytes ( 64.00 MB) total hunk <- current com_hunkMegs
25165824 bytes ( 24.00 MB) total zone <- current com_zoneMegs
0 bytes ( 0.00 MB) low mark
42606880 bytes ( 40.63 MB) low permanent
5864568 bytes ( 5.59 MB) low tempHighwater <- top low hunk usage from temporary allocations
0 bytes ( 0.00 MB) high mark
384 bytes ( 0.00 MB) high permanent
82624 bytes ( 0.08 MB) high temp
18769504 bytes ( 17.90 MB) high tempHighwater <- top high hunk usage from temporary allocations
42607264 bytes ( 40.63 MB) total hunk in use <- current hunk in use
18769120 bytes ( 17.90 MB) unused highwater <- temporary hunk memory that wasn't reused
2055832 bytes ( 1.96 MB) in 3088 zone blocks <- current zone usage
0 bytes ( 0.00 MB) in dynamic botlib
1110492 bytes ( 1.06 MB) in dynamic renderer
945340 bytes ( 0.90 MB) in dynamic other
82888 bytes ( 0.08 MB) in small Zone memory
(note the comments to the right of each line) So, the client uses a fair bit of hunk memory (adding together the total hunk and the unused highwater, my com_hunkmegs of 64 looks pretty good), a lot of sound memory, and very little zone memory.
The value of com_zonemegs can only be set via commandline (+set com_zonemegs xx). If set in the config, the desired value will only show as "latched." Regardless, meminfo always lists zone as 24 (the default), which would imply that this value cannot be changed.
