[RFC] Event timers on MIPS

[Jayachandran C.]

On Thu, Aug 19, 2010 at 7:25 AM, Neel Natu <neelnatu at gmail.com> wrote:
> Hi JC,
>
> On Wed, Aug 18, 2010 at 7:45 AM, Jayachandran C.
> <c.jayachandran at gmail.com> wrote:
>> On Wed, Aug 4, 2010 at 7:52 PM, Alexander Motin <mav at freebsd.org> wrote:
>>> Neel Natu wrote:
>>>> Thanks for taking the time to review the patch. Here is the updated patch:
>>>> http://people.freebsd.org/~neel/tick_diff.txt
>>>
>>> Seems fine.
>>>
>>>> On Sun, Aug 1, 2010 at 4:39 AM, Alexander Motin <mav at freebsd.org> wrote:
>>>>> "t_upper++;" there looks a bit strange, as it is not written back. The
>>>>> wrapping stuff won't work if this timer interrupts were not used.
>>>>
>>>> This part is intentional.
>>>>
>>>> I wanted only clock_intr() to update the cached values of
>>>> 'counter_upper' and 'counter_lower_last' and tick_ticker() to sample a
>>>> consistent snapshot of the tuple and then operate on it.
>>>>
>>>> I have added an XXX comment to describe the dependency. We can revisit
>>>> this if we change the default timer in mips.
>>>
>>> It's not about default timer, but about having any other timer. But if
>>> you wish so, it should be enough for now.
>>
>> I'm seeing a problem with the timer code on XLR, when I run ping:
>>
>> xlrboard# ping 192.168.30.1
>> PING 192.168.30.1 (192.168.30.1): 56 data bytes
>> 64 bytes from 192.168.30.1: icmp_seq=0 ttl=64 time=0.649 ms
>> 64 bytes from 192.168.30.1: icmp_seq=1 ttl=64 time=362.624 ms
>> 64 bytes from 192.168.30.1: icmp_seq=2 ttl=64 time=0.219 ms
>> 64 bytes from 192.168.30.1: icmp_seq=3 ttl=64 time=362.631 ms
>> 64 bytes from 192.168.30.1: icmp_seq=4 ttl=64 time=-362.168 ms
>> 64 bytes from 192.168.30.1: icmp_seq=5 ttl=64 time=362.628 ms
>> 64 bytes from 192.168.30.1: icmp_seq=6 ttl=64 time=0.234 ms
>> 64 bytes from 192.168.30.1: icmp_seq=7 ttl=64 time=362.631 ms
>> 64 bytes from 192.168.30.1: icmp_seq=8 ttl=64 time=0.483 ms
>>
>> This happens with the current XLR code, and even after updating it
>> from mips/mips/tick.c (to take in Neel's changes).
>>
>> Due to the way our network driver works, there is a likely that the
>> ping packets are received by different CPUs every time, but having the
>> negative time there seems to indicate some issue.  Also on XLR the
>> count registers are not synchronized across cores, so the values will
>> be different for each CPU.
>>
>>  I will look at some more, but meanwhile, any clue on what might be
>> wrong would be helpful.  I still haven't done the PIC timer based
>> timecount, that might fix it, if it is due to the count registers
>> being out of sync.
>>
>
> Can you try pinning the ping process to cpu 0 and repeat your test?
>
> Something like "cpuset -l 0 ping a.b.c.d".

With cpuset, I get a negative time about every few seconds, I have not
tried to debug this further.

I ended up providing a PIC based platform_timecounter, which I needed
to do anyway, and now I get sane values.

JC.