Date: Wed, 08 May 2013 09:00:55 -0600 From: Ian Lepore <ian@FreeBSD.org> To: Peter Jeremy <peter@rulingia.com> Cc: freebsd-arm@FreeBSD.org Subject: Re: Sawtooth ping RTT on RPi Message-ID: <1368025255.1180.200.camel@revolution.hippie.lan> In-Reply-To: <20130508104441.GC90732@server.rulingia.com> References: <20130508085901.GA90732@server.rulingia.com> <CAJ-VmomK15L_Cx=pQDFv-pRu3SfT4aRXzsYX_Rp_si8NofMZ-Q@mail.gmail.com> <20130508095414.GB90732@server.rulingia.com> <CAJ-VmomfoPCFs9=wzt8SzXY2K3MCY7owAR2thKTC2Sn0pP2_Vg@mail.gmail.com> <20130508104441.GC90732@server.rulingia.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2013-05-08 at 20:44 +1000, Peter Jeremy wrote: > On 2013-May-08 03:12:43 -0700, Adrian Chadd <adrian@freebsd.org> wrote: > >yup, that looks like two almost-but-not-in-sync sampling periods (one > >being poll, one being ping) beating against each other. > > That seems like a reasonable hypothesis. > > >Is the USB stuff being polled? > > I'm not sure. I don't think so. dmesg says: > > dwcotg0: <DWC OTG 2.0 integrated USB controller> mem 0x20980000-0x2099ffff irq 17 on simplebus0 > usbus0 on dwcotg0 > smsc0: <vendor 0x0424 product 0xec00, rev 2.00/2.00, addr 3> on usbus0 > ue0: <USB Ethernet> on smsc0 > > So there's an interrupt available and nothing else is using irq 17. > And systat shows that the interrupt rate on irq 17 goes up with > network traffic (though it idles at ~500 interrupts/sec - which seems > excessive). > Just to make all of this even more confusing, my RPi results always look like this with kern.hz set to one of 100, 500, 1000, 2500: PING revolution.hippie.lan (172.22.42.240): 56 data bytes 64 bytes from 172.22.42.240: icmp_seq=0 ttl=64 time=7.739 ms 64 bytes from 172.22.42.240: icmp_seq=1 ttl=64 time=10.130 ms 64 bytes from 172.22.42.240: icmp_seq=2 ttl=64 time=10.115 ms 64 bytes from 172.22.42.240: icmp_seq=3 ttl=64 time=10.146 ms However, with kern.hz=250, I get this: PING revolution.hippie.lan (172.22.42.240): 56 data bytes 64 bytes from 172.22.42.240: icmp_seq=0 ttl=64 time=5.839 ms 64 bytes from 172.22.42.240: icmp_seq=1 ttl=64 time=8.169 ms 64 bytes from 172.22.42.240: icmp_seq=2 ttl=64 time=8.156 ms 64 bytes from 172.22.42.240: icmp_seq=3 ttl=64 time=8.145 ms And with kern.hz=333, it looks like this: PING revolution.hippie.lan (172.22.42.240): 56 data bytes 64 bytes from 172.22.42.240: icmp_seq=0 ttl=64 time=6.757 ms 64 bytes from 172.22.42.240: icmp_seq=1 ttl=64 time=9.126 ms 64 bytes from 172.22.42.240: icmp_seq=2 ttl=64 time=9.208 ms 64 bytes from 172.22.42.240: icmp_seq=3 ttl=64 time=9.252 ms Very strange. No matter what kern.hz is set to, I always get a shorter time on the first packet, and then after that the variance from one packet to the next is always within about 100us. My other arm systems running -current don't behave like this. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1368025255.1180.200.camel>