Sunil Kumar wrote: > but how do you account for the HZ. I don't, the system you've been running on has a HZ of 1000 I assume? That means that they delays we have found are them minimal ones needed to mkae things work, sleeping longer with lower HZ is unfortunate but not harmfull. Lower HZ has been taken into account in that we try not to sleep much, because otherwise delays for the calling up would become unacceptable. But besides that I do not take HZ into account. Remember we are dealing with an error / exception path here. It doesn't have to be beautifull or very efficient it just has to work and not suck. > I will give the 1:3 a run. > Thanks, In combination with a TIMEOUT of 100 I assume? Regards, Hans With msleep(1), one system will sleep > for 20ms while other will sleep only 2ms for the last try. We need to > either 1. make it msleep(20), so all systems sleep for 20ms per read OR > 2. have a conditional based on HZ to do msleep(1) for 100 and do > multiple msleep(1) for HZ 1000 OR 3. have it as a configured parameter. > 1st option means that 1000HZ folks will suffer delays which they could > have avoided because they can sleep finer, but without option 2, they > will just sleep for 2ms which may not be sufficient. 2nd and 3rd options > work but 3rd works better because its simple and makes a lot of sense > for the variety of hardware and BIOSes that you could be dealing with. > >
