ume.ini sanity check

[Doozer]

Hi,

I am running several Linux groovyarcade setups. Main systems are a single core 3GHz P4 (32bit setup) and a i5 3.2 GHz 2 cores with HT (64bit setup)
core systems.

My P4 are too old and do not have 64 bit capability. I have to stick to a 32bit distro. But I use the latest groovymame (at the time 0157_015e) patch with SDL2 enabled on both.

My ume.ini core parameters are identical between the two machines. The only difference is the monitor setup.

I would like to call the community to have a sanity check on the current configuration parameters. My main concern is observable glitches in the emulation speed on my i5 based system. It does not sustain the 100% emulation speed during game (groovyume cpu load is less than 50%). Emulation speed reporting shows slow down to 94% during less than a second several time per minute.


Any information/help/protocol would be valuable to track down the issue.


ume.ini

Code: [Select]

#
# CORE CONFIGURATION OPTIONS
#
readconfig                1
writeconfig               0

#
# CORE SEARCH PATH OPTIONS
#
rompath                   /home/roms/MAME/roms;/home/roms/BIOS_roms;/home/roms/MAME/disks
hashpath                  $HOME/hash
samplepath                /home/roms/MAME/samples
artpath                   /home/roms/MAME/artwork
ctrlrpath                 /home/roms/MAME/ctrlr
inipath                   $HOME/.ume;$HOME;.;$HOME/ini
fontpath                  /home/roms/MAME/fonts
cheatpath                 /home/roms/MAME/cheat
crosshairpath             /home/roms/MAME/crosshair

#
# CORE OUTPUT DIRECTORY OPTIONS
#
cfg_directory             $HOME/cfg
nvram_directory           $HOME/nvram
memcard_directory         $HOME/memcard
input_directory           $HOME/inp
state_directory           $HOME/sta
snapshot_directory        $HOME/snap
diff_directory            $HOME/diff
comment_directory         $HOME/comments

#
# CORE OUTPUT DIRECTORY OPTIONS
#
hiscore_directory         $HOME/hi

#
# CORE STATE/PLAYBACK OPTIONS
#
state                     
autosave                  0
playback                 
record                   
mngwrite                 
aviwrite                 
wavwrite                 
snapname                  %g/%i
snapsize                  auto
snapview                  internal
statename                 %g
burnin                    0

#
# CORE PERFORMANCE OPTIONS
#
autoframeskip             0
frameskip                 0
seconds_to_run            0
throttle                  1
syncrefresh               0
sleep                     1
speed                     1.0
refreshspeed              0

#
# CORE ROTATION OPTIONS
#
rotate                    1
ror                       0
rol                       0
autoror                   0
autorol                   0
flipx                     0
flipy                     0

#
# CORE ARTWORK OPTIONS
#
artwork_crop              1
use_backdrops             0
use_overlays              0
use_bezels                0
use_cpanels               0
use_marquees              0

#
# CORE SCREEN OPTIONS
#
brightness                1.0
contrast                  1.0
gamma                     1.0
pause_brightness          0.65
effect                    none

#
# CORE VECTOR OPTIONS
#
antialias                 1
beam                      1.0
flicker                   0

#
# CORE SOUND OPTIONS
#
sound                     1
samplerate                48000
samples                   1
volume                    0

#
# CORE INPUT OPTIONS
#
coin_lockout              1
ctrlr                     
mouse                     0
joystick                  0
lightgun                  1
multikeyboard             0
multimouse                0
steadykey                 0
ui_active                 0
offscreen_reload          1
joystick_map              auto
joystick_deadzone         0.3
joystick_saturation       0.85
natural                   0
joystick_contradictory    0
coin_impulse              0

#
# CORE INPUT AUTOMATIC ENABLE OPTIONS
#
paddle_device             keyboard
adstick_device            keyboard
pedal_device              keyboard
dial_device               keyboard
trackball_device          keyboard
lightgun_device           lightgun
positional_device         keyboard
mouse_device              lightgun

#
# CORE DEBUGGING OPTIONS
#
log                       0
verbose                   0
update_in_pause           0
debug                     0
debugscript               
debug_internal            0

#
# CORE MISC OPTIONS
#
drc                       1
drc_use_c                 0
bios                     
cheat                     0
skip_gameinfo             0
uifont                    default
ramsize                   
confirm_quit              0
ui_mouse                  0
autoboot_command         
autoboot_delay            2
autoboot_script           
http                      0
http_port                 8080
http_path                 web

#
# CORE MKChamp OPTIONS
#
disable_hiscore_patch     0
disable_nagscreen_patch   0
disable_loading_patch     1

#
# CORE SWITCHRES OPTIONS
#
modeline_generation       1
monitor                   custom
orientation               horizontal
connector                 auto
interlace                 1
doublescan                1
cleanstretch              0
changeres                 1
powerstrip                0
lock_system_modes         1
lock_unsupported_modes    1
refresh_dont_care         0
dotclock_min              0
sync_refresh_tolerance    2.0
frame_delay               0
black_frame_insertion     0
modeline                  auto
ps_timing                 auto
lcd_range                 auto

crt_range0                "15250-16500, 40-80, 0.036, 4.688, 8.870, 0.190, 0.191, 1.018, 1, 1, 192, 288, 448, 576"
crt_range1                "23900-24420, 40-80, 2.910, 3.000, 4.440, 0.451, 0.164, 1.048, 1, 1, 384, 400, 0,   0"
crt_range2                "31000-32000, 40-80, 0.636, 3.813, 1.906, 0.318, 0.064, 1.048, 1, 1, 400, 512, 0,   0"
crt_range3                auto
crt_range4                auto
crt_range5                auto
crt_range6                auto
crt_range7                auto
crt_range8                auto
crt_range9                auto

#
# DEBUGGING OPTIONS
#
oslog                     0
watchdog                  0

#
# PERFORMANCE OPTIONS
#
multithreading            1
numprocessors             auto
sdlvideofps               0
bench                     0

#
# VIDEO OPTIONS
#
video                     opengl
numscreens                1
window                    0
maximize                  1
keepaspect                0
unevenstretch             0
centerh                   1
centerv                   1
waitvsync                 1
scalemode                 none

#
# OpenGL-SPECIFIC OPTIONS
#
filter                    0
prescale                  1
gl_forcepow2texture       0
gl_notexturerect          0
gl_vbo                    1
gl_pbo                    1
gl_glsl                   0
gl_glsl_filter            1
glsl_shader_mame0         /home/arcade/CRT/shader/glsl_plain
glsl_shader_mame1         /home/arcade/CRT/CRT-geom
glsl_shader_mame2         none
glsl_shader_mame3         none
glsl_shader_mame4         none
glsl_shader_mame5         none
glsl_shader_mame6         none
glsl_shader_mame7         none
glsl_shader_mame8         none
glsl_shader_mame9         none
glsl_shader_screen0       none
glsl_shader_screen1       none
glsl_shader_screen2       none
glsl_shader_screen3       none
glsl_shader_screen4       none
glsl_shader_screen5       none
glsl_shader_screen6       none
glsl_shader_screen7       none
glsl_shader_screen8       none
glsl_shader_screen9       none
gl_glsl_vid_attr          1

#
# PER-WINDOW VIDEO OPTIONS
#
screen                    auto
aspect                    auto
resolution                auto
view                      auto
screen0                   auto
aspect0                   auto
resolution0               auto
view0                     auto
screen1                   auto
aspect1                   auto
resolution1               auto
view1                     auto
screen2                   auto
aspect2                   auto
resolution2               auto
view2                     auto
screen3                   auto
aspect3                   auto
resolution3               auto
view3                     auto

#
# FULL SCREEN OPTIONS
#
switchres                 1
useallheads               0

#
# SOUND OPTIONS
#
audio_latency             2.0

#
# SDL KEYBOARD MAPPING
#
keymap                    0
keymap_file               keymap.dat
uimodekey                 SCRLOCK

#
# SDL JOYSTICK MAPPING
#
joy_idx1                  auto
joy_idx2                  auto
joy_idx3                  auto
joy_idx4                  auto
joy_idx5                  auto
joy_idx6                  auto
joy_idx7                  auto
joy_idx8                  auto
sixaxis                   0

#
# SDL LIGHTGUN MAPPING
#
lightgun_index1           WiiMote0
lightgun_index2           WiiMote1
lightgun_index3           auto
lightgun_index4           auto
lightgun_index5           auto
lightgun_index6           auto
lightgun_index7           auto
lightgun_index8           auto

#
# SDL LOWLEVEL DRIVER OPTIONS
#
videodriver               auto
audiodriver               auto
gl_lib                    auto


[nexusmtz]

I'm not a groovymame expert, so I can't comment on the ini, but I've seen similar behavior.

If groovymame seems alright for several seconds, then dips more than a percentage point, it's possible that something low-level on your machine is jumping in and claiming to be time-critical, or your CPU is changing speed. Both of those causes have been discussed here previously.

Intel's speedstep, and AMD's equivalent have caused trouble, as have fan, temperature, and CPU/GPU monitoring utilities.

On one of my machines, RivaTuner (and then MSI Afterburner) caused the problem. When it's a utility, you can sometimes catch it by running Microsoft's Sysinternals Process Explorer with the 'Cycles Delta' and 'Context Switch Delta' columns turned on, set at a 2 or 5 second refresh interval, and sorted by one of those two columns.

When the glitch happens, you should see a process jump up in the list. If the process that you see jump up is 'Interrupts', it's difficult to pin down, but for real processes, you just have to determine why that process is running and find out how to stop or change it.

To fix my problem, I had to turn off Afterburner's low level hardware monitoring. I guess it takes more cycles to gather each sample now, but I have plenty of cycles to spare as long as it doesn't mind waiting for them.

[Doozer]

Thank you for your answer. In one way I am happy to see that this is not an isolated case.

I have also thought of the CPU being used for another time critical task or some interrupts duty that could eat the CPU cycles for a short period of time. Here is what I have investigated.

My first remedy test was to completely shield the CPU used for groovymame. Only the 3x/4x groovyume processes and 2 interrupts (0_timer and 2_cpus which cannot be disabled) were running on a dedicated core. I was still able to see the speed issue with a duty cylcle of 25% maximum. 
Secondly, I looked also at Intel speed step cpu scaling, but playing with it only bring more MHz but do not cure the issue.
Thinking that the issue could be linked to the hardware timer I verified that the system use TSC and not HTPET. Which is the case.

I assume that I have no misbehavior coming from the operating system and do not consider it as the root of the speed issue. Now, I am thinking that this could come from a mame/groovyume internal behavior. Using the tekken rom, I have identified that the sound subroutine can produce some slow down depending how the system is configured (with or without -mt and in single/multiple core) the behavior is slightly different. A single core with single or multiple thread(s) gives 100% but multi cpu configuration without multithread only give 50%. To my understanding the synchronization mechanism from the sound or frame routine could play a role here. Before digging more into the details, I need to be sure that I do not have a wrongly configured parameter in my ume.ini setup file.

I am using Arch Linux (groovyarcade) distribution to conduct all my investigations. I know that some people have done latency measurements but I did not manage to see a description of their protocol. Would it be possible to have some description here?

[nexusmtz]

Good rundown of where you're at. That helps to clarify why you're looking more intently at GM itself.

We seem to troubleshoot similarly, even though we're in different environments. I had also tried the dedicated core and thought I'd have it licked that way. Sadly, in Windows, it looks like 'hold everything for me' means 'hold everything even if it's not in my way.' Also, my problem machine only had 3 cores to mess with, and trying to give 2 to GM for mt had the OS tripping on itself. Well, at least the limitations pushed me to find the root instead of just working around it.

Latency wasn't involved for me, so I can't help you there. Interested to see how it works out though.

[Calamity]

Hi Doozer,
 
I also get those 'speed percentage hiccups' in some games,, but I wouldnt worry too much. Don't trust the percentage, trust your eye. If scrolls are 100% smooth, you can say the emulation is solid.  Video card's clocking is much more accurate. Don't even trust the sound, as its rate is internally linked to the above mentioned speed percentage which can be bogus.

[Doozer]

Hi Calamity,

I must admit that scrolling is smooth and I confirm that the cracks are perceptible on the sound track when the slow down occurs.

Based on the multi-threading implementation, do you have an idea why the emulation speed jumps from 50% to 100% when all threads are moved back exclusively on the same cpu (mono core mode)? As far as I understood the new thread only handle the audio part separately from the main emulation loop. At the moment, I link the hiccups to the sound management process. But without some guidance, I do not see where to start from to track this down.

@nexusmtz, I suspect a thread synchronization issue happening during either the vertical blank retrace or audio buffer communication (perhaps buffer underrun). Normally, having multiple threads on multiple core should not produce any special effect on mame.

[Calamity]

If scrolling is smooth, then the speed fluctuations you see are artifacts of the speed measurement routine, rather than from the actual emulation. This could be due to the granularity of the system timer in use, but it would require some research to find the actual reason with some certainty.

[Calamity]

When you use -mt, rendering is moved to a separate thread. This includes the code for vsync. Usually waiting for vsync eats most cpu cycles available for a thread, so releasing it from this task may be the difference in cases where the cpu is already on its limit by the emulation itself. A sudden speed drop of 50% with vsync enabled is typical when the cpu can barely handle emulation speed at 100% without vsync. Missing the retrace forces the thread to wait for the next one for each frame causing the speed to be divided by two.

[Calamity]

With regards to why single threaded execution performs better on single cpu, one explanation could be that there's some overhead introduced by core switching. Bear in mind that even without -mt MAME uses threads for the emulation itself. The only thing you control with -mt is which thread handles the rendering.

[Doozer]

Thank you for the clarifications.

In case there is a need for investigation on some of these aspects, I am willing to help. In case I do progress on smoothing the emulation by finding what is causing the hiccups I will let you knon.

Cheers