[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:
Depends
is depended on by SERVER-16837 Migrations should time out after 10 h... Closed
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: SERVER-16880 Timer overflows at approximately 9223 seconds
Branch: master
https://github.com/mongodb/mongo/commit/37398ff1063d8a42d075822ead009e761703fb9d

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.

Generated at Thu Feb 08 03:42:35 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.