ITS#6866

diff --git a/CHANGES b/CHANGES
index 48c9c85e033a238981994004da2abf24ba7fe9a6..5ed17c3a243b8dcc0870293f48d064007c8fe5c2 100644 (file)
--- a/CHANGES
+++ b/CHANGES
@@ -24,6 +24,7 @@ OpenLDAP 2.4.25 Engineering
        Documentation
                admin24 guide ldapi usage (ITS#6839)
                admin24 guide conversion notes (ITS#6834)
+               admin24 guide fix drawback math for syncrepl (ITS#6866)
                admin24 guide note manpages are definitive (ITS#6855)
 
 OpenLDAP 2.4.24 Release (2011/02/10)

diff --git a/doc/guide/admin/replication.sdf b/doc/guide/admin/replication.sdf
index 6baa7b292a1c57c71d77610104ed025a47856ac7..6a0c65a8272a71ac6c22d8f5b47fd9a4a439269e 100644 (file)
--- a/doc/guide/admin/replication.sdf
+++ b/doc/guide/admin/replication.sdf
@@ -317,11 +317,11 @@ only the final state of the entry is significant. But this approach
 may have drawbacks when the usage pattern involves single changes to
 multiple objects.
 
-For example, suppose you have a database consisting of 100,000 objects of 1 KB 
+For example, suppose you have a database consisting of 102,400 objects of 1 KB 
 each. Further, suppose you routinely run a batch job to change the value of 
-a single two-byte attribute value that appears in each of the 100,000 objects 
+a single two-byte attribute value that appears in each of the 102,400 objects 
 on the master. Not counting LDAP and TCP/IP protocol overhead, each time you 
-run this job each consumer will transfer and process {{B:1 GB}} of data to
+run this job each consumer will transfer and process {{B:100 MB}} of data to
 process {{B:200KB of changes!}}
 
 99.98% of the data that is transmitted and processed in a case like this will