BRAD YOU ROCK!! LOL..
It works!!!
I'm not sure what you meant by "you would most certainly want a HZ value of
1000 to try this", but I simply changed the #define to 4096 as you
suggested, put it on my fastest machine, and it works perfectly! I didn't
even get the message saying to echo > 1024 (or in this case 4096), it just
worked!!
DUDE! I owe you a beer! THANK YOU!! :)
So why when I googled - did I see everywhere it talk about linux having a
1ms max resolution for timers? I can dig up some links if you need me to.
This is confusing and what led me down the road to thinking I needed RTLinux
or some other thing. I"m so thrilled not to have to go there! Perhaps linux
can't guarantee a reliable and consistent frequency for the timer at speeds
above 1ms, and any one needing 100% reliable timing would need an RT OS?
Sure seemed pretty rock solid for me when I ran it, though it's a peppy
machine.
Anyway, your reply really made my day, no, heck it made my last 2 weeks,
since my project is now nearing completion and is running perfectly so far
thanks to this tiny change!
It's funny, I had thought to try it myself a few days ago, but was
discouraged by what I read on google, and never bothered. DOH!
-Steve
Not at all.. for a single qemu instance on linux it tries to use the PIT
in the rtc, and I've seen this run upto 8192hz. Why not crank it up in the
qemu source t0 4096 and see what happens. It's not going to hurt anything
in any case.
You would most certainly want a HZ value of 1000 to try this.
Brad
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
