Can someone upload a recent blocks.nxt file please?
Are you unable to connect to any nodes? Once my client finishes syncing I will.
Topic: NXT :: descendant of Bitcoin - Updated Information - page 2511. (Read 2761645 times)
Are you unable to connect to any nodes? Once my client finishes syncing I will.
My client was working fine with 110 peers, all of a sudden the block counter started going backwards into the negative and saying "catching up."
I suspect this may be because my server, http://nxt.c4c.io/, might've been added as a bootstrapping node, but I'm not sure.
Down to 65 now since I had to clear the .nxt and restart the client... still redownloading the blockchain.
Can someone upload a recent blocks.nxt file please?
A quick question:
How can I know to which block (height) a transaction belongs?
How can I know to which block (height) a transaction belongs?
I'm now showing a 0 balance with no transactions (I had 3 transfers sent to me... all 3 were listed before heading to bed last night). Running a local copy and currently in the web interface: 127.0.0.1:7875 Any ideas where to start?
Address: 7877011898990800828
Address: 7877011898990800828
First, make sure you have the lastest Nxt.zip.
Next, delete all .nxt files in your Nxt folder.
Then relauch next.
Worked for me.
just a quick note.
after some benchmarks and monitoring i have seen a very high usage of tcpsockets.
seems they are increasing fast but reducing very slow, which leads into an out of socks
when using the api repetitive. on your vps you can check your limits like this:
cat /proc/user_beancounters | grep numtcpsock
perhaps this would explain some crashes, since many vps having small limits.
another thing is a 100% cpu client usage from time to time for ~120 seconds.
i guess the numtcpsock creating these problems, using my local machine without
these limits the client runs stable even with and after 10.000 serial api request.
the vps is freezing quickly with these numbers.
edit: my limits are 550 (soft(hard), set by the provider. the client breaking this limit quickly.
after some benchmarks and monitoring i have seen a very high usage of tcpsockets.
seems they are increasing fast but reducing very slow, which leads into an out of socks
when using the api repetitive. on your vps you can check your limits like this:
cat /proc/user_beancounters | grep numtcpsock
perhaps this would explain some crashes, since many vps having small limits.
another thing is a 100% cpu client usage from time to time for ~120 seconds.
i guess the numtcpsock creating these problems, using my local machine without
these limits the client runs stable even with and after 10.000 serial api request.
the vps is freezing quickly with these numbers.
edit: my limits are 550 (soft(hard), set by the provider. the client breaking this limit quickly.
Each API request is responded with "Connection: close" header. This means that client closes connection. Do sockets in TIME_WAIT state counted against the limit? If yes, then a quick fix would be to decrease time for TIME_WAIT state.
just a quick note.
after some benchmarks and monitoring i have seen a very high usage of tcpsockets.
seems they are increasing fast but reducing very slow, which leads into an out of socks
when using the api repetitive. on your vps you can check your limits like this:
cat /proc/user_beancounters | grep numtcpsock
perhaps this would explain some crashes, since many vps having small limits.
another thing is a 100% cpu client usage from time to time for ~120 seconds.
i guess the numtcpsock creating these problems, using my local machine without
these limits the client runs stable even with and after 10.000 serial api request.
the vps is freezing quickly with these numbers.
edit: my limits are 550 (soft(hard), set by the provider. the client breaking this limit quickly.
after some benchmarks and monitoring i have seen a very high usage of tcpsockets.
seems they are increasing fast but reducing very slow, which leads into an out of socks
when using the api repetitive. on your vps you can check your limits like this:
cat /proc/user_beancounters | grep numtcpsock
perhaps this would explain some crashes, since many vps having small limits.
another thing is a 100% cpu client usage from time to time for ~120 seconds.
i guess the numtcpsock creating these problems, using my local machine without
these limits the client runs stable even with and after 10.000 serial api request.
the vps is freezing quickly with these numbers.
edit: my limits are 550 (soft(hard), set by the provider. the client breaking this limit quickly.
My client was working fine with 110 peers, all of a sudden the block counter started going backwards into the negative and saying "catching up."
Do I need nxt coins to start mining? If so please send a few to 3937699229213236762. Thanks!
I'd love to start mining. Could someone please send me a nxt?
17405231906428949483
thx
17405231906428949483
thx
I'm now showing a 0 balance with no transactions (I had 3 transfers sent to me... all 3 were listed before heading to bed last night). Running a local copy and currently in the web interface: 127.0.0.1:7875 Any ideas where to start?
Address: 7877011898990800828
Address: 7877011898990800828
just a quick note.
after some benchmarks and monitoring i have seen a very high usage of tcpsockets.
seems they are increasing fast but reducing very slow, which leads into an out of socks
when using the api repetitive. on your vps you can check your limits like this:
cat /proc/user_beancounters | grep numtcpsock
perhaps this would explain some crashes, since many vps having small limits.
another thing is a 100% cpu client usage from time to time for ~120 seconds.
i guess the numtcpsock creating these problems, using my local machine without
these limits the client runs stable even with and after 10.000 serial api request.
the vps is freezing quickly with these numbers.
edit: my limits are 550 (soft(hard), set by the provider. the client breaking this limit quickly.
after some benchmarks and monitoring i have seen a very high usage of tcpsockets.
seems they are increasing fast but reducing very slow, which leads into an out of socks
when using the api repetitive. on your vps you can check your limits like this:
cat /proc/user_beancounters | grep numtcpsock
perhaps this would explain some crashes, since many vps having small limits.
another thing is a 100% cpu client usage from time to time for ~120 seconds.
i guess the numtcpsock creating these problems, using my local machine without
these limits the client runs stable even with and after 10.000 serial api request.
the vps is freezing quickly with these numbers.
edit: my limits are 550 (soft(hard), set by the provider. the client breaking this limit quickly.
My client was working fine with 110 peers, all of a sudden the block counter started going backwards into the negative and saying "catching up."
Come from beyond, I just wanted to say thank you, you are doing a great job! Without you Nxt would be a dead horse, so I would like to say thanks and donate 10k Nxt to you 
Please post your Nxt account so I can send them to you
Please post your Nxt account so I can send them to you
11541844302056663007
Thank u too.
Send them
just a quick note.
after some benchmarks and monitoring i have seen a very high usage of tcpsockets.
seems they are increasing fast but reducing very slow, which leads into an out of socks
when using the api repetitive. on your vps you can check your limits like this:
cat /proc/user_beancounters | grep numtcpsock
perhaps this would explain some crashes, since many vps having small limits.
another thing is a 100% cpu client usage from time to time for ~120 seconds.
i guess the numtcpsock creating these problems, using my local machine without
these limits the client runs stable even with and after 10.000 serial api request.
the vps is freezing quickly with these numbers.
edit: my limits are 550 (soft(hard), set by the provider. the client breaking this limit quickly.
after some benchmarks and monitoring i have seen a very high usage of tcpsockets.
seems they are increasing fast but reducing very slow, which leads into an out of socks
when using the api repetitive. on your vps you can check your limits like this:
cat /proc/user_beancounters | grep numtcpsock
perhaps this would explain some crashes, since many vps having small limits.
another thing is a 100% cpu client usage from time to time for ~120 seconds.
i guess the numtcpsock creating these problems, using my local machine without
these limits the client runs stable even with and after 10.000 serial api request.
the vps is freezing quickly with these numbers.
edit: my limits are 550 (soft(hard), set by the provider. the client breaking this limit quickly.
Would someone be kind of enough to add a step by step instructions on how to mine NXT for beginners? It would be great to add it to the Wiki as well.
1. Unlock ur account
2. Make sure u have at least 1 NXT
3. Make sure the very 1st transaction has at least 1440 confirmations
4. Open [Recent blocks]
5. Keep on watching the timer that says "You can generate the next block in 36 minutes 5 seconds"
6. U can close the webpage, but don't lock the account
Is it OK to do this with "http://88.198.210.245:7875/"?
It runs on a low-end VPS. I'm going to block access to its web interface tomorrow. U should install a local copy.
Would someone be kind of enough to add a step by step instructions on how to mine NXT for beginners? It would be great to add it to the Wiki as well.
1. Unlock ur account
2. Make sure u have at least 1 NXT
3. Make sure the very 1st transaction has at least 1440 confirmations
4. Open [Recent blocks]
5. Keep on watching the timer that says "You can generate the next block in 36 minutes 5 seconds"
6. U can close the webpage, but don't lock the account
Is it OK to do this with "http://88.198.210.245:7875/"?
Would someone be kind of enough to add a step by step instructions on how to mine NXT for beginners? It would be great to add it to the Wiki as well.
1. Unlock ur account
2. Make sure u have at least 1 NXT
3. Make sure the very 1st transaction has at least 1440 confirmations
4. Open [Recent blocks]
5. Keep on watching the timer that says "You can generate the next block in 36 minutes 5 seconds"
6. U can close the webpage, but don't lock the account
Thx for the report.
Anytime, but hopefully not again.
Would someone be kind of enough to add a step by step instructions on how to mine NXT for beginners? It would be great to add it to the Wiki as well.
Come from beyond, I just wanted to say thank you, you are doing a great job! Without you Nxt would be a dead horse, so I would like to say thanks and donate 10k Nxt to you
Please post your Nxt account so I can send them to you
Please post your Nxt account so I can send them to you
11541844302056663007
Thank u too.
Jump to: