[SERVER-21538] Choose clock source for reading current time dynamically at startup Created: 18/Nov/15  Updated: 01/Jul/19  Resolved: 24/Mar/17

Status: Closed
Project: Core Server
Component/s: Internal Code
Affects Version/s: None
Fix Version/s: 3.4.22, 3.5.5

Type: Improvement Priority: Major - P3
Reporter: Andy Schwerin Assignee: Mathias Stearn
Resolution: Done Votes: 3
Labels: platforms-re-triaged
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Related
is related to SERVER-2114 Don't use select timeouts for fast co... Closed
is related to SERVER-18922 Choose time source for measuring shor... Closed
is related to SERVER-1279 Get more accurate elapsed time in the... Closed
Backwards Compatibility: Fully Compatible
Backport Requested:
v3.4
Sprint: Repl 2017-03-06, Repl 2017-03-27
Participants:
Linked BF Score: 62

 Description   

On different hardware and under different virtualization environments, the latency of reading the system clock can fluctuate by over 1000x. When the clock may be read with extremely low latency, we would like to leverage it to provide very precise current time inside the server. When the system clock is of higher latency, we would like to emulate a low-resolution clock that can be read very quickly, so that time calls on such systems do not interfere with the execution of actual user operations.



 Comments   
Comment by Githook User [ 01/Jul/19 ]

Author:

{'name': 'Mathias Stearn', 'email': 'mathias@10gen.com', 'username': 'RedBeard0531'}

Message: SERVER-21538 Use mockable cv wait in background_thread_clock_source_test

This both makes the test run much faster and avoids spurious failures when
the system scheduler decides not to run a thread for over a second.

(cherry picked from commit d55eaad5cdfcfbe8458658d39f8c57102c3b3504)
Branch: v3.4
https://github.com/mongodb/mongo/commit/af3b8d9af0ee9a8d16d68d4f09feb9696a15c35d

Comment by Githook User [ 01/Jul/19 ]

Author:

{'name': 'Mathias Stearn', 'email': 'mathias@10gen.com', 'username': 'RedBeard0531'}

Message: SERVER-21538 Put BGThreadClockSource to sleep when it isn't needed

If it goes through a full granularity of sleeping without being read from, it
will sleep with no timeout until the next attempt to read the clock.

(cherry picked from commit b283aecc3a6e65e805c5ffe57b0ad4368faacbfd)
Branch: v3.4
https://github.com/mongodb/mongo/commit/e7d30fab84dde1c786e2b173fe555314c2298970

Comment by Githook User [ 22/Mar/17 ]

Author:

{u'username': u'RedBeard0531', u'name': u'Mathias Stearn', u'email': u'mathias@10gen.com'}

Message: SERVER-21538 Use mockable cv wait in background_thread_clock_source_test

This both makes the test run much faster and avoids spurious failures when
the system scheduler decides not to run a thread for over a second.
Branch: master
https://github.com/mongodb/mongo/commit/d55eaad5cdfcfbe8458658d39f8c57102c3b3504

Comment by Githook User [ 20/Mar/17 ]

Author:

{u'username': u'RedBeard0531', u'name': u'Mathias Stearn', u'email': u'mathias@10gen.com'}

Message: SERVER-21538 Put BGThreadClockSource to sleep when it isn't needed

If it goes through a full granularity of sleeping without being read from, it
will sleep with no timeout until the next attempt to read the clock.
Branch: master
https://github.com/mongodb/mongo/commit/b283aecc3a6e65e805c5ffe57b0ad4368faacbfd

Comment by super [ 29/Jun/16 ]

Hi Andrew,

Just to clarify when I was referring to "the issue" I was focused on the one unwanted side effect (meta issue) that results from all of these specific technical mongodb-developer issues, that a mongodb-user experiences: "MongoD kills laptop battery".

Thanks for clarifying the meaning/relevance of all the issues mentioned!

Thanks for your efforts to improve MongoDB. It is much appreciated!

====

For anyone else reading if you'd like better laptop battery life while developing with mongod, in addition to my above trick of pinning it to a specific CPU core to reduce interprocessor interrupts. You can also create 2 keybindings or script this before/after your mongodb queries.
#write code
killall -CONT mongod
#use MongoDB
killall -STOP mongod
#write code
I'm not sure if it would have side effects on Mongo storing time inaccurately, but it might be fine for development.

Comment by Andrew Morrow (Inactive) [ 28/Jun/16 ]

supersonic - The two tickets differ because one is about obtaining time deltas, and the other is about obtaining the current clock time. These are distinct operations, and we need to address both, potentially with different implementations. It is not the case that the larger issue is being ignored, as we are actively working to address it. The first step in that process was to disassociate the clocks and timers from the networking layer, which we have done (see SERVER-23243). Per the changes made for SERVER-23243, we are no longer using select timeouts for fast coarse timing (the specific issue identified in SERVER-2114), and therefore that issue was closed. The new issues more accurately describe the remaining work to be done to eliminate (when possible) excess power draw by an idle mongod. Our developers certainly use laptops to develop MongoDB, and while we do find the battery issue problematic, it doesn't rise to the level of a critical issue. Such issues are typically reserved for "production down" level problems, which this is not. Please note that both this ticket and SERVER-18922 have a fixVersion of '3.3 Desired', meaning that we would like to see them resolved for the upcoming MongoDB 3.4 release.

Comment by super [ 28/Jun/16 ]

As a temporary relief/workaround, which helps alleviate the problem a bit...
I noticed I was getting nearly 900 interprocessor interrupts/sec on my quad core machine. Then I pinned MongoDB to a single core. Now I'm only getting +-200 interprocessor interrupts/sec.

Comment by super [ 28/Jun/16 ]

How is this issue different to https://jira.mongodb.org/browse/SERVER-18922 ? it looks like most of the description is copy/pasted.
It's a pity that this issue only has 2 votes and 12 people watching it.

The original issue where the problem (excessive power consumption, excessive number of wakeups shown in powertop) was reported in 2010 should not have been closed because it's STILL UNRESOLVED.
The original issue
https://jira.mongodb.org/browse/SERVER-2114
Has 49 watchers and 36 votes as of now.
Closing the original issue and fragmenting it into multiple issues just makes it seem like:

  • its not a big deal
  • nobody cares
  • It's not an old neglected issue.

But the opposite of the above points is true.

  • It is a big deal
  • Many people have expressed concern/support, someone even submitted a patch in the original issue.
  • The issue is nearly 6 years old and has been neglected.

MongoDB is painful to use on a laptop, because it makes the battery die. It's hard to work on a dead laptop. That means this issue is critical.
One might repond saying that MongoDB runs on servers.
Well I've got news for you, software is written by developers before it finds it's way onto a server, and developers use laptops.

I don't understand why this has gotten so little attention...

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