From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Fri, 20 May 2011 15:16:02 -0400 To: 9fans@9fans.net Message-ID: <9f7e3f9171e833cba1cd0e74fa56c8da@brasstown.quanstro.net> In-Reply-To: References: <309c101f23bbb6ec6a92b2bf1c525fd7@brasstown.quanstro.net> <4be7f81375a5450a8b6536d66f756703@brasstown.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] a pair nec bugs Topicbox-Message-UUID: e789b158-ead6-11e9-9d60-3106f5b1d025 On Fri May 20 15:04:48 EDT 2011, rminnich@gmail.com wrote: > I did not read your post as carefully as I should, but I still have > concerns when people use stuff like nsec() in the quest of accuracy. > Sorry, I was sort of reacting to another thread in the Go list where > somebody is using gettimeofday() and seems to think the nsec field has > meaning :-) no problems. i've since realized there's a bug (which was probablly the same bug that resulted in the really complicated current implementation) that i've reintroduced. the good news is the solution is to remove code. :-) i'll post a more complete solution in a bit. > We don't have good clocks. i totally agree with this, but in x86 land, it's worth remembering things have gotten much better since the bad old p4 days. all recent processors do have a stable tsc. i'm doing a little something like you suggest in /dev/irqalloc. fields 3 and 4 are number of calls and cumulative number of cycles. you can divide by cpumhz (in /dev/cputype) to get time in ns. the silly division is because ns just isn't good enough resolution. ether0 takes about 3.03ns/call. ; awk '$3>0' /dev/irqalloc 50 18 7140587794 16282733189984 lapic clock 65 1 141628 1482204961 ioapic kbd 73 10 209046583 2149493918790 msi ether0 97 10 896 64993576 ioapic usbohci 97 10 896 64993576 ioapic usbohci 97 10 896 64993576 ioapic usbohci 97 10 896 64993576 ioapic usbohci 97 10 896 64993576 ioapic starport-pex2s.0C040000 121 11 9 239651 msi sdE (ahci) 129 12 1972430 20894050761 ioapic kbdaux - erik