DOCS-297 turned info into a note

Author: Bob Grabar

source/administration/monitoring.txt

@@ -228,8 +228,6 @@ design patterns. In other situations, performance issues may indicate
 that the database may be operating at capacity and that it's time to
 add additional capacity to the database.
 
-.. _administration-monitoring-locks:
-
 Locks
 ~~~~~
 

source/core/sharding-internals.txt

@@ -352,22 +352,10 @@ sends all new writes to the "receiving" server. Finally,
 :program:`mongos` updates the chunk record in the :term:`config
 database` to reflect the new location of the chunk.
 
-Distributed Locking
-```````````````````
-
-The mongoDB distributed :ref:`locking <administration-monitoring-locks>`
-mechanism is used to coordinate activities across a multi-server mongoDB
-installation. In mongoDB versions 1.8 and earlier, the integrity of
-distributed locks depends critically on accurate timekeeping between all
-:program:`mongos` and :program:`mongod` instances creating the
-distributed locks. In particular, if the clock skew between
-:program:`mongos` instances grows beyond approximately 5 minutes, there
-is an increasing probability that locks will fail, resulting in data
-loss.
-
-For this reason, we strongly recommend that all systems running with
-mongoDB versions 1.8 and earlier use Network Time Protocol (NTP) or
-otherwise ensure that all clocks are accurate.
+.. note:: Before MongoDB version 2.0, increasing clock skew between
+   :program:`mongos` instances could lead to failed distributed locks
+   and potential data loss, particularly if the skew exceeded 5 minutes.
+   Always run ``ntpd`` to minimize clock skew.
 
 .. _sharding-migration-thresholds: