diff --git a/README.md b/README.md
index bf351b3..b886e4a 100644
--- a/README.md
+++ b/README.md
@@ -40,5 +40,12 @@
 time_interval_between_subs [default: 5]
 kv_store_host[default: 192.168.1.11]
 kv_store_port [default: 2379]
-tp_ids [ default: 64] 
+tp_ids [ default: 64]
 ```
+
+# Known Limitations and Issues
+
+The following are known issues and limitations with the openolt-scale-tester tool.
+
+* This tool configures fake ONUs which does not really exist on the PON tree. Hence all the BAL resources (if you are using a Broadcom BAL integrated agent) it continues to remain in CONFIGURED state and never move to ACTIVE. The goal is to test the scale-limits on the number of resources we can configure and see if it meets the operator requirements.
+* There are timeouts seen in the openolt-agent logs during ITUPON-Alloc object creation (if you are using Broadcom BAL3.x integrated openolt-agent). Right after ITUPON-Alloc object creation, the BAL tries to sync over PLOAM channel with ONU. But, since the ONUs we configure are fake, the PLOAM channel does not exist and ITUPON-Alloc object cannot move to ACTIVE state and times-out. Since the ITUPON-Alloc object is CONFIGURED and that serves our purpose, you may ignore this error.
diff --git a/VERSION b/VERSION
index b393606..3eefcb9 100644
--- a/VERSION
+++ b/VERSION
@@ -1 +1 @@
-0.0.2-dev
+1.0.0
diff --git a/compose/openolt-scale-tester.yml b/compose/openolt-scale-tester.yml
index f3d83ef..1993059 100644
--- a/compose/openolt-scale-tester.yml
+++ b/compose/openolt-scale-tester.yml
@@ -27,7 +27,7 @@
       "--openolt_agent_ip_address=${OPENOLT_AGENT_IP_ADDRESS}",
       "--openolt_agent_port=9191",
       "--openolt_agent_nni_intf_id=0",
-      "--num_of_onu=128",
+      "--num_of_onu=512",
       "--subscribers_per_onu=1",
       "--workflow_name=ATT",
       "--time_interval_between_subs=0",