# Time between retries to connect for counterparty-server
**URL:** https://forums.counterparty.io/t/time-between-retries-to-connect-for-counterparty-server/1859
**Category:** Server
**Created:** [March 4, 2016, 10:52am UTC](https://forums.counterparty.io/t/time-between-retries-to-connect-for-counterparty-server/1859 "2016-03-04T10:52:24Z")
**Posts on this page:** 1
**Page:** 1
### Author:  [@something](https://forums.counterparty.io/u/something)
#### Post date: [March 4, 2016, 10:52am UTC](https://forums.counterparty.io/t/time-between-retries-to-connect-for-counterparty-server/1859/1 "2016-03-04T10:52:24Z")
These days Bitcoin is quite busy and I’ve had counterparty-server stop due to Bitcoin Core server not being responsive enough.
counterparty-server attempts to reconnect 12 times, and each time it pauses for 10 seconds (link below; there’s a separate file for btcd (currently not supported) `btcd.py`)… There’s another variable, `TRIES =` that is by default 12.
When Bitcoin Core doesn’t respond, counterparty-server throws this error:
`[2016-03-04 10:49:20][DEBUG] Could not connect to backend at http://rpc:1234@192.168.0.2:8332. (Try 1/12)`
Because “I/O storms” (due to blockchain indexing) on Bitcoin Core can take 3-5 minutes, 12 \* 10 seconds is not enough. On my instance I increased the values in
`/usr/local/lib/python3.4/dist-packages/counterparty_lib-9.53.0-py3.4.egg/counterpartylib/lib/backend/addrindex.py` to `TRIES = 20` and `time.sleep(20)`, which hopefully means counterparty-server will be able to survive without Bitcoin Core for 400 seconds (almost 7 minutes) and will monitor my server to see whether that helps.
It’s worth nothing that increasing these settings without consideration for other things isn’t a good idea. For example, there may be some apps or clients that use counterparty-server and that expect that timeouts happen sooner. But in my case I don’t have any so the risk is acceptable as the worst case scenario for my setup is that counterparty-server stops because of these timeouts and when i want to use it, I need to start it and then wait for many minutes or hours until it catches up, before I can use it.
>
EDIT: soon after restarting counterparty-server, a timeout occurred.
```auto
2016-03-04-T11:02:42+0000 [DEBUG] Could not connect to backend at http://rpc:1234@192.168.0.2:8332. (Try 1/20)
2016-03-04-T11:02:42+0000 [DEBUG] Could not connect to backend at http://rpc:1234@192.168.0.2:8332. (Try 1/20)
2016-03-04-T11:02:42+0000 [DEBUG] Could not connect to backend at http://rpc:1234@192.168.0.2:8332. (Try 1/20)
```
- `Try 1/20` shows the effect of `TRIES=20`. Here server regained access in first retry.
- In another case that happened soon after the first one, the first (Try 1/12) happened at 11:06:20, there were three of them and the second (Try 2/12) at 11:07:00 - there were two of those. Connection was reported as established at 11:07:23, so all together it took approximately one minute to regain access. I expected that there would be only 10 seconds between each retry (so I should have seen Try 7/12), but this works for me.