Microsecond timing accuracy?

[April Ayres-Griffiths]

Hi,

I need to do calls approximately every microsecond as i'm emulating a cpu which buzzes an emulated speaker (i'm trying to generate this audio in realtime if possible).  I've seen that there a methods that hook into things like QPC on windows for measuring intervals, but is there an accurate way to sleep for a nanosecond / microsecond interval?

The only solution seems to be to literally "busy wait" out the duration. 

Does anyone else have any pointers?

I'm using go 1.5.1

Cheers,

April

[Marvin Stenger]

IMHO sleeping should be fine, your OS will busy wait for you if it is needed.

Cheers,
Marvin

[John Souvestre]

My experience with Go on Windows is that the resolution on the time package in the standard library is 1ms.

 

Max posted an interesting way to improve this to about 550ns for duration measurements using some special Windows calls.  Check his sample code at https://play.golang.org/p/Q2BbWz0sU1.

 

John

    John Souvestre - New Orleans LA

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Bakul Shah]

Posix.1 specifies clock_nanosleep() but actual sleep time depends on the underlying OS and almost certainly you won't get down to microsecond interval or accuracy. Busy waiting won't work either since other threads or processes or operating system activities can preempt your thread or process. "Modern" OSes such as Linux or Windows don't (or can't) provide the right abstractions for such high frequency realtime work. For real work your best bet would be to offload HF computation to arduino or some such.

[Skip Tavakkolian]

I agree. My try at a temp/humidity reader in pure Go failed; it uses the "GPIO for Go" package (https://github.com/davecheney/gpio) to read a train of 40 pulses that are 30-80us wide, on a RPI/Linux. Epoll doesn't appear to be fast enough.  The user space drivers that work -- e.g. Adafruit's -- are in C and need sched_setscheduler()/busy wait, and clock_nanosleep().  I would guess that using these routines through syscall would interfere with Go's scheduler.