On Fri May 20 15:04:48 EDT 2011, rminn...@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
