Re: [AD] Add timeBeginPeriod(1) to wtimer.c

[AJ <aj@xxxxxxxxxx>]

Tobias Scheuer wrote:
> > On my winXP athlon64 3000+ machine.
> > setting the timeBeginPeriod(1) once globally  results in much better 
> > performance.  possibly due to better timing.
> >
> > aj.
>
>
> For the global setting it might be woth considering giving install_timer() a
> new parameter of type int, specifying the timer resolution to use. That way
> it yould be up to the programmer how üprecise things would be, and it would
> be configurable, maybe dependant on the CPU speed. Or however. 


maybe a pre-set function.. so that  install_timer() is not broken.
much like you go  setColourDepth(32);  before calling set_gfx_mode() 
its not a requirement, but you may choose to do it.

so we would go:    setTimerResolution(int ms);   as an option you *may* 
wish to set before calling  install_timer()
anyone not calling setTimerResoltuion() gets the default behaviour..
oh..oops.. i guess it should be called  set_timer_resolution()  ;)

aj.










> > Chris wrote:
> >
> > > Elias Pschernig wrote:
> > >
> > >
> > > > Not sure how high the cost would be, even in case it would work like I
> > > > think. I only know the linux scheduler has 10ms tickss, and uses every
> > > > 2nd tick to do scheduling (or something like that, didn't pay enough
> > > > attention in lectures :P) - and there must be a reason they don't use
> > > > 1ms ticks.
> > >
> > >
> > > I believe there's a kernel option to change the frequency of the timer. 
> > > At least, I remember seeing one in an older (pre-2.4.28) version. 2.4.28
> > > does, however, have a Low-latency scheduler option (which is off by 
> > > default).. I haven't been able to test it, though.
> > >
> > > But on my old 400MHz machine, I remember changing the timer option from 
> > > 100 to 1000, and my system became almost unuseable because it was so 
> > > unrepsonsive. I fear the same thing is happening with 
> > > timeBeginPeriod(1). Faster CPU's may not show as much speed defficiency 
> > > (and perhaps at some point, it'll become more efficient), but I don't 
> > > think current CPUs are ready for it, hence why the scheduler is still 
> > > 10ms by default.