[SERVER-16880] Timer overflows at approximately 9223 seconds Created: 15/Jan/15 Updated: 23/Jan/15 Resolved: 20/Jan/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Code |
| Affects Version/s: | 2.8.0-rc5 |
| Fix Version/s: | 3.0.0-rc6 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Randolph Tan | Assignee: | Randolph Tan |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Operating System: | ALL | ||||||||
| Participants: | |||||||||
| Description |
|
The main culprit can be attributed to the multiplication of the time delta by a very big number here. |
| Comments |
| Comment by Githook User [ 20/Jan/15 ] |
|
Author: {u'username': u'renctan', u'name': u'Randolph Tan', u'email': u'randolph@10gen.com'}Message: |
| Comment by Randolph Tan [ 16/Jan/15 ] |
|
We initially though of computing the greatest common denominator when we setup the clock settings so we can keep the computation in the integer space. We decided to use float instead because we can't say for certain that QueryPerformanceFrequency will always return a value for _countsPerSecond can effectively simplify the fraction of microsPerSecond/_countsPerSecond and the fact that integer division is relatively expensive. |
| Comment by Andy Schwerin [ 16/Jan/15 ] |
|
Maybe. Infuriatingly, the hardware instructions for integer multiply produce a 128-bit result and for divide consume a 128-bit quotient, but there's no way to put that to use. That is, the hardware is already doing arithmetic with sufficient precision, if we could only explain to the compiler what we wanted. |
| Comment by Kevin Pulo [ 16/Jan/15 ] |
|
Right. Like pre-computing _countsPerMicro, _countsPerMilli, and _countsPerMinute, and then just dividing the tick deltas by the right one (once)? Even if clock ticks are at sub-nanosecond resolution, a long long should be plenty (eg. with a 10GHz clock _countsPerHour would be 36e12, which easily fits in a 64 bit int, and such a timer could still store up to 29 years). Any casting to int should be done after the division, though. |
| Comment by Andy Schwerin [ 15/Jan/15 ] |
|
I think we can avoid FP math here. |
| Comment by Eric Milkie [ 15/Jan/15 ] |
|
Our idea to fix this is to use floating point division (carefully) here to scale the timer values to micros. |