Topic: HoboNickels - HBN - High Fast Stake - Version 2.0! More Secure, Less Intensive - page 63. (Read 478852 times)

I have not experienced this on any machine yet, more information would be helpful. Have you tried restart of the wallet?  Can you also give me information about your system? Win Ver/CPU/RAM, how many wallets and How many blocks up for stake? Are you using S4C? 

Just trying to get information for future improvements. Going forward the hard forks will be coded into 1.5.5+ so need to ensure it is working well for everyone. So a debug may help as well. Especially if you use the -debug startup switch and let it run for a bit.

You can also try to use the "Stop Staking" command in the wallet menu and see if that is helps, and then after the wallet is caught up and well connected try to start it back up.

Even worse than the 1.5.3 here.
Wallet use "only" 20% cpu, but can't do anything within the wallet.  Wallet not responding for 2 - 3min each clic, he try to stake even when arrow is grey telling not stacking while acquiring node.

Back to 1.5.3 here 

Actually seeing a big improvement in orphans. 2 in 30
Could be network conditions but client is much more responsive in general.

I'll shout if I get another long spate of failures, They have been become a "feature" for me recently

Good deal, thanks!


You will still get Orphans, no way to prevent that with such a fast chain. I am getting about 50% maybe less orphans with 1000 blocks of 5HBN up for stake.

Well seeing 0% and lots of 0.x% CPU

synced 3 hours of chain fast, despite seeming a bit slow to acquire peers ( bit subjective )

It's gone back up to 2GB ram usage from 1.6 ..... meh ....

I'm going to post now before the first stake orphans and ruins this glowing school report.



*EDIT** oooh and clicking on the little staking arrow now works ... every time without delay *thumbs*

Good/bad timing. It's less than 2 hrs since I got 1.5.3 running on linux. Which on its own, feels alot smoother than running on windows.

Time to do some comparisons across both version and platform.

No, but I will have a look.

-----------------------------------------------

Version 1.5.5.0 is released.

https://github.com/Tranz5/HoboNickels/releases/tag/1.5.5.0

Please try this and give me your feedback regarding CPU usage.

Tranz, have you looked at the HUSH and ZEN wallets? They forked from ZCASH in some way and are java based, clean and quick to sync with minimal connections. HUSH also joined SuperNET DEX.

ZEN is implementing NODE incentive where 3.5% of every block mined is paid to the node operators. Just requires static IP and creating a certificate for your node, but I think that is more for ZEN's encrypted transactions than the node itself.

POS is nice but it doesn't encourage keeping wallets online except when they are ready to stake. Node incentive makes for a good sized pool of wallets online at all times in order to reap incentive payments as block creation continues.

HBN with the following would become a defacto coin to be held and used for a long time:

1. 90 second POS blocktime to reduce resource overhead
2. Removal of PoW as a block creation method to stabilize the blockchain and reduce orphans
3. Change in coin production per block to accommodate the change in block times, plus possible node incentives
4. Change in code base from a QT based client to the newer Java swing wallets will lower resource usage and encourage more users to be online, and possibly run incentive nodes
5. Possibly look at adding the SuperNET DEX to the core... join SuperNET and we would no longer need to worry about any exchange hosting HBN for trading

All of those are challenging and time consuming and I (we) in no way expect you to do any of that Tranz, though you have already made such good progress on 1 and 2 above. But the possibilities there are awesome!

I am wondering hove comes 20 second blocktime? Why difficulty for staking doesnt go up to make it 30?
It still sits on minimum for a long time.

I support Tranz approach totweak the chain no to swap.
But I would ask you all for your preference. So community please vote: https://www.surveymonkey.com/r/8RBZ9DQ

Take into account your little netbook prob has a tiny 5400 rpm sata HDD on a board with minimal RAM available (are you hitting page file?) and that has a huge impact on the performance of this fast blocktime coin.

FWIW I do understand your point... a POS coin should be able to run on a 2GB+ RAM dual core netbook no questions asked. Tranz is working his Jedi powers to make it so... give it time there really is only room for this coin to gain value.

If this is still the case I would like a full copy of the debug.log file. Especially if you can run it in -debug mode for a while.  I have never experienced a blank wallet pegging a CPU for so long, unless it is catching up or the block chain is getting spammed. Otherwise is should idle between 1-5%.
[/quote]

No problem I shut the wallet down in that state so the ed of the log should catch it.

I'll restart it again tomorrow in -debug and see if it replicates or if it was transient network activity or not send you that one too.



ooops buggered up the quotes

Yes, I have also had this problem. It comes from someone spamming blocks seconds apart. Sometimes the wallet misses one in the middle and is waiting for it to come in but it doesn't know for sure if it is part of the main block chain or not. So eventually it creates its own block and the other wallets tell it sorry no good, so it ask again for the missing block. All the while all of rest of the wallets are also very busy with the huge number of block coming in quickly, and they may not get to your request right away.  Eventually you get it and any bock that you staked you now know is no good, and they are orphaned.

If you notice this, it is best to shut down and restart.    I also notice using the repair wallet and removing the orphan transactions does help as well. It can take a long time. like 30 mins or more if you haven't done it for years, like me.

Again this can be solved with a slower block time!!!!


If this is still the case I would like a full copy of the debug.log file. Especially if you can run it in -debug mode for a while.  I have never experienced a blank wallet pegging a CPU for so long, unless it is catching up or the block chain is getting spammed. Otherwise is should idle between 1-5%.

I now you are working on a new version that probably addresses some of these, but just in case ...
Often when I stake the chain gets stuck. I will have  my new staked block, and then nothing happens (except cpu works overtime) for up to 15 minutes. Then suddenly it realises, the blockchain has moved on, invalidates my new found block, and catches up on the missing blocks.

Either way, looking forward to the coming version

No this poor CPU was solid at 60-62% and it's been synced for hours now with a blank wallet.



Yeah I guessed the ping times may be software related as I added a node on my LAN which did seem to improve sync
as one machine soon pushed 4M at the other but both were reporting some wayward pings from 10-15ms to 100s of seconds

I believe they did eventually part company as the connected time got reset along the way ...

Mine idles at 1-2% CPU, then spikes to 50% with a new block, then back down in 5 seconds or less. This with the staking improvements I am testing!

90 sec block time and plus other improvement will use 1-5% of a core average over 24 hrs.



These are wallet to wallet ping times, not computer ping times. If their wallet is very busy, it could take a while to respond or it may never respond. You wallet will eventually drop any ping that that is too high

So if I understand you correctly the wallet is crushing that machine simply accepting new blocks with nothing else to do?
I wouldn't call it spiking exactly, more .. erm balls out.

Come to mention it I don't think it was working that hard while it was syncing (I wasn't watching particularly) more CPU variance for sure
So possible it could be current network activity making it work harder?

Roll on improvements

Watch the debug log file tail -f using msys. You will notice each time a new block comes in the CPU spikes.  Blocks roll in VERY fast so the CPU is high a lot.  Ala 20 second block time. You can also turn off stake via version 1.5.4+ or by encrypting the wallet.

Not having done this for a long time I think there might be a more fundamental issue than the staking algo

I have a synced client with a fresh and empty wallet.dat using 61% of an A6 6400. OK its only 2 cores but 4GHz

By my reckoning it should be doing next to nothing.

much appreciated here.

I hope you can bring the client back to todays standards
For me on a shitty i3 Netbook with 4gb ram its just a Mess at its current State.
Will try the nodes above soon.

Good luck and thank you for efforts.
Make hobo great again.

This is strange, my 1.5.3 HBN wallet when fully synced and staking takes no more then 10-15% on FX-8320E (stock).
And orphan rates are usually no more then 10% on big stakes (2000-5000 HBN). Memory usage is big, yes.

Im using this addnodes in hobonickels.conf if it may help someone:
addnode=118.102.74.85
addnode=141.5.104.227
addnode=149.202.98.161
addnode=153.172.167.168
addnode=172.4.177.229
addnode=173.208.164.34
addnode=178.248.4.130
addnode=183.159.51.234
addnode=184.164.129.202
addnode=185.104.184.187
addnode=188.116.34.66
addnode=194.219.107.159
addnode=208.54.90.197
addnode=216.218.222.12
addnode=217.175.119.125
addnode=24.247.194.72
addnode=24.5.224.146
addnode=47.223.61.135
addnode=5.9.48.68
addnode=67.149.188.138
addnode=72.184.183.243
addnode=72.241.235.204
addnode=73.228.39.117
addnode=75.71.127.100
addnode=76.169.57.92
addnode=77.239.37.12
addnode=77.240.98.41
addnode=77.9.199.237
addnode=79.246.233.206
addnode=79.69.5.223
addnode=83.255.65.50
addnode=84.158.236.239
addnode=84.169.198.55
addnode=84.217.169.178
addnode=85.140.56.132
addnode=86.0.127.13
addnode=87.153.244.140
addnode=88.99.68.228
addnode=90.156.106.253
addnode=91.121.177.181
addnode=92.232.94.171
addnode=92.39.213.37
addnode=93.77.76.185
addnode=94.113.207.67
addnode=94.210.174.118
addnode=98.115.147.74
maxconnections=50