Port-amiga archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Timer issues?



John Klos wrote:

> On all of my Amigas, I'm seeing:
> 
> timecounter: Timecounter "CIA B" frequency 715909 Hz -- Insufficient hz,
> needs at least 191

Yes, I'm observing that since 5.0 as well.

After having a look I found out that the problem is caused by the last
modification in amiga/dev/clock.c by Michael Hitch:

revision 1.48
date: 2008/12/07 03:48:43;  author: mhitch;  state: Exp;  lines: +10 -3
Fix timecounters using interval timers:  amiga counters are not 32 bits,
so the tc_counter_mask needs to be set based on the interval timer.
Process cpu usage was returning negative or very large values.

There is obviously a problem with the counter_mask, which was introduced
in 1.48 (function clockattach):

        amiga_clk_interval = (eclockfreq / hz);
        counter_mask = 0x8000;
        while (counter_mask != 0 && (counter_mask & amiga_clk_interval) == 0)
                counter_mask >>= 1;
        counter_mask -= 1;

        clk_timecounter.tc_name = clockchip;
        clk_timecounter.tc_frequency = eclockfreq;
        clk_timecounter.tc_counter_mask = counter_mask;

For an eclockfreq of 715909 the amiga_clk_interval becomes 7159. Following
the algorithm from above it will render a counter_mask of 0xfff.

IMHO it is wrong when applying a mask of 0xfff to the result of the
tc_get_timecount() function, which, in the amiga/dev/clock.c case, returns
the hardclock_ticks * amiga_clk_interval + clock_tick (read directly from
CIA timer). A mask of ~0 should work better.

But I would not dare to revert the code, because Michael wrote that he fixed
a bug with negative values. There may be a problem somewhere else. Maybe
Michael could comment on that.


> Is this why my ping times are in multiples of 10 ms?

Yes. The CIA-B timecounter failed and cannot be used. So the kernel falls
back to the default "clockinterrupt" timecounter, which has just a resolution
of 100Hz. And 100Hz means a precision of 10ms.


> What's the "191" mean? 191 x 10^5? It doesn't make much sense.

With the initialized timecounter structure the kernel function tc_init() is
called to utilize the new timecounter, and it does the following check:

        u_int u;
        u = tc->tc_frequency / tc->tc_counter_mask;
        /* XXX: We need some margin here, 10% is a guess */
        u *= 11
        u /= 10;
        if (u > hz && tc->tc_quality >= 0) {
                tc->tc_quality = -2000;
                aprint_verbose(
                    "timecounter: Timecounter \"%s\" frequency %ju Hz",
                            tc->tc_name, (uintmax_t)tc->tc_frequency);
                aprint_verbose(" -- Insufficient hz, needs at least %u\n", u);

tc_frequence is 715909 (for NTSC) and tc_counter_mask is 0xfff, so we get a
value for u of 715909 / 0xfff = 174. Multiplied with 11 and divided by 10
gives 191!

When 191 is larger than hz (which is 100) then the timecounter is disabled
with a warning.


> On mac68k and VAX, similar values are suitable:

Yes, 700kHz should be enough. It's a bug in Amiga's clock.c.


Regards,

-- 
Frank Wille



Home | Main Index | Thread Index | Old Index