[RFC] Event timers on MIPS

[Neel Natu]

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".

best
Neel

> Thanks,
> JC.
>