On Tue, Jun 04, 2013 at 03:13:10PM +0200, Martin Husemann wrote: > > If your NAT device causes persistent enough packet handling delays in the > order of 2 seconds (or enough to make NTP erroneously drift that far), > you have a serious problem. >[...] > What timecounter source did your machine pick and what other choices do you > have? > > sysctl kern.timecounter > $ sysctl kern.timecounter kern.timecounter.choice = TSC(q=3000, f=2594231400 Hz) clockinterrupt(q=0, f=100 Hz) hpet0(q=2000, f=14318180 Hz) ACPI-Fast(q=1000, f=3579545 Hz) lapic(q=-100, f=99820760 Hz) i8254(q=100, f=1193182 Hz) dummy(q=-1000000, f=1000000 Hz) kern.timecounter.hardware = TSC kern.timecounter.timestepwarnings = 0
So the precision should be adequate enough (I have just switched to hpet0 since it is here...). But I suspect that the NAT is in cause, since it is a Windows machine, not dedicated to the task, used for browsing the Web, directly connected to a DSL modem (note: I has to do with it; I'm putting a NetBSD server---for KerGIS---inside a LAN I do not own). -- Thierry Laronde <tlaronde +AT+ polynum +dot+ com> http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C