Date: Wed, 18 Aug 2010 18:55:50 -0700 From: Neel Natu <neelnatu@gmail.com> To: "Jayachandran C." <c.jayachandran@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: <AANLkTinYe9UodckMFXLBcot2nH7YB73-Ug%2BApr2nNden@mail.gmail.com> In-Reply-To: <AANLkTimWc1-X=thdqu=Mk4h7pBwNmC4xooH9XcQz-UeL@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 pat= ch: >>> http://people.freebsd.org/~neel/tick_diff.txt >> >> Seems fine. >> >>> On Sun, Aug 1, 2010 at 4:39 AM, Alexander Motin <mav@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=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". best Neel > Thanks, > JC. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTinYe9UodckMFXLBcot2nH7YB73-Ug%2BApr2nNden>