Date: Wed, 25 Aug 2010 19:37:08 +0530 From: "Jayachandran C." <c.jayachandran@gmail.com> To: Neel Natu <neelnatu@gmail.com> Cc: Randall Stewart <rrs@freebsd.org>, Alexander Motin <mav@freebsd.org>, freebsd-mips@freebsd.org Subject: Re: [RFC] Event timers on MIPS Message-ID: <AANLkTi=6%2BcJ8MRjPd6zqhJvmNq_hgW=OQcvr_pQAK4AJ@mail.gmail.com> In-Reply-To: <AANLkTinYe9UodckMFXLBcot2nH7YB73-Ug%2BApr2nNden@mail.gmail.com> References: <4C41A248.8090605@FreeBSD.org> <AANLkTilKYw4UqmfEee9zHGosEDzy4hiFob1d8R9jcB25@mail.gmail.com> <4C41B4CF.6080409@FreeBSD.org> <AANLkTik8_NGm7nKYXT1d1E4Vj6vYQPWHnnLDi78YnvQD@mail.gmail.com> <4C4205CC.6080700@FreeBSD.org> <AANLkTikUpqLeogkqxqWzzejp=7FstHX2wVRWNrYoWGCp@mail.gmail.com> <4C4ED247.80701@FreeBSD.org> <AANLkTiktMt87V5jXV0%2BnagHjpfTkBQ8Fu6CK7HqNXff3@mail.gmail.com> <AANLkTinH1itTauurEFCZVyz%2BW4T02niPV1jQeNART1Gm@mail.gmail.com> <4C555CF7.5080101@FreeBSD.org> <AANLkTimqAitBoFyKT-8bE%2BS6%2B1wjnso569E3exrY6EWB@mail.gmail.com> <4C5977BC.1060104@FreeBSD.org> <AANLkTimWc1-X=thdqu=Mk4h7pBwNmC4xooH9XcQz-UeL@mail.gmail.com> <AANLkTinYe9UodckMFXLBcot2nH7YB73-Ug%2BApr2nNden@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Aug 19, 2010 at 7:25 AM, Neel Natu <neelnatu@gmail.com> wrote: > Hi JC, > > On Wed, Aug 18, 2010 at 7:45 AM, Jayachandran C. > <c.jayachandran@gmail.com> wrote: >> On Wed, Aug 4, 2010 at 7:52 PM, Alexander Motin <mav@freebsd.org> wrote: >>> Neel Natu wrote: >>>> Thanks for taking the time to review the patch. Here is the updated pa= tch: >>>> http://people.freebsd.org/~neel/tick_diff.txt >>> >>> Seems fine. >>> >>>> On Sun, Aug 1, 2010 at 4:39 AM, Alexander Motin <mav@freebsd.org> wrot= e: >>>>> "t_upper++;" there looks a bit strange, as it is not written back. Th= e >>>>> 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=3D0 ttl=3D64 time=3D0.649 ms >> 64 bytes from 192.168.30.1: icmp_seq=3D1 ttl=3D64 time=3D362.624 ms >> 64 bytes from 192.168.30.1: icmp_seq=3D2 ttl=3D64 time=3D0.219 ms >> 64 bytes from 192.168.30.1: icmp_seq=3D3 ttl=3D64 time=3D362.631 ms >> 64 bytes from 192.168.30.1: icmp_seq=3D4 ttl=3D64 time=3D-362.168 ms >> 64 bytes from 192.168.30.1: icmp_seq=3D5 ttl=3D64 time=3D362.628 ms >> 64 bytes from 192.168.30.1: icmp_seq=3D6 ttl=3D64 time=3D0.234 ms >> 64 bytes from 192.168.30.1: icmp_seq=3D7 ttl=3D64 time=3D362.631 ms >> 64 bytes from 192.168.30.1: icmp_seq=3D8 ttl=3D64 time=3D0.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. =A0Also on XLR the >> count registers are not synchronized across cores, so the values will >> be different for each CPU. >> >> =A0I will look at some more, but meanwhile, any clue on what might be >> wrong would be helpful. =A0I 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTi=6%2BcJ8MRjPd6zqhJvmNq_hgW=OQcvr_pQAK4AJ>