 Show Posts
|
|
Pages: [1] 2 3 4 5 »
|
Since I updated to 2.1 yesterday the wallet is using LOTS of network bandwidth. I let it run over night and this morning it was sending at a rate of nearly 100 kb/s. Perfmon is showing Bottlecaps connections with 5-15 kb/s. Debug log is full of getblocks. Deleting peers.dat and restarting wallet doesn't fix it. What can I do?
You can then ban that IP via your firewall.. I won't be doing this personally as I will be needing to send them alerts. But there is nothing to stop you from removing a peer you deem unreliable. Banning bad peers via firewall worked, thanks. Are there plans to add some kind of peer blacklist to the wallet? Something like bannode=1.2.3.4. The Extended Peer Information window has the advantage over getpeerinfo that it shows converted date/time but it has fixed size and the text box is very small. I had to copy&paste to notepad for comfortable reading, so a variable size window would be cool. |
|
|
|
|
Since I updated to 2.1 yesterday the wallet is using LOTS of network bandwidth. I let it run over night and this morning it was sending at a rate of nearly 100 kb/s. Perfmon is showing Bottlecaps connections with 5-15 kb/s. Debug log is full of getblocks. Deleting peers.dat and restarting wallet doesn't fix it. What can I do?
|
|
|
|
I don't think it's 5% premine. If I remember correctly the the initial OP stated 5 coins per block. Probably an error. But it's 5k per block. So I think 0.5% is correct.
unfortunately No.... can check urself! Wallet -> help -> Debug console -> type : getblock thentypehashnumber // u will see whole lot of info but this is the important stuff : That's indeed interesting. Why is the explorer showing other values? |
|
|
|
I don't think it's 5% premine. If I remember correctly the the initial OP stated 5 coins per block. Probably an error. But it's 5k per block. So I think 0.5% is correct.
Check the source code. The real premine is 0.1%. Check the explorer, first 10 blocks were 50k each ExplorerExplorer is on heavy load...  |
|
|
|
I don't think it's 5% premine. If I remember correctly the the initial OP stated 5 coins per block. Probably an error. But it's 5k per block. So I think 0.5% is correct.
Check the source code. The real premine is 0.1%. Which file and line? |
|
|
|
|
I don't think it's 5% premine. If I remember correctly the the initial OP stated 5 coins per block. Probably an error. But it's 5k per block. So I think 0.5% is correct.
|
|
|
|
Sorry if this has already been asked.
Who is responsible for fast pool switching? The proxy or the rig?
If I rent a rig running a custom cgminer/sgminer/bfgminer/whatever that has been configured/patched for - say - 30 seconds pool switch. Will this rig switch pools faster than a rig running standard cgminer 3.7.2 with 300 seconds pool switch?
Yes, it will be based on the settings in your miner. I use Kalroths cgminer v3.7.3 and i think he set the default there as check every 60 seconds, worked flawlessly this morning for my first customer. Please correct me if I'm wrong, but to my understanding the rig has a permanent stratum proxy connection and does not know where it's mining and when it's switching pool, so why should a custom cgminer switch faster than a stock one? Sorry, by "if i rent a rig" you mean rent from, or put available for rent? If you're enquiring about renting for your own use, then i'm sorry, i misunderstood. In this instance, i guess it will depend on how fast the server on BetaRigs updates its proxy software to use the new address, because on the rig side the betarigs address is static. So, i would imagine it's pretty fast. This is just a semi-educated guess though, since i have no idea of how BR have things configured. But, using a custom cgminer will allow them to switch faster from their own mining pool, to the BetaRigs pool. Which means once your rental period starts, their rig will hop over to mine for you sooner. So at the very worst it could save you some minutes of otherwise lost mining allowance.  Yeah, that's exactly what I'm thinking, only the first switch is faster with custom cgminer. Time required for every further switch is driven by the proxy. Maybe mux can shed some light on this. |
|
|
|
Sorry if this has already been asked.
Who is responsible for fast pool switching? The proxy or the rig?
If I rent a rig running a custom cgminer/sgminer/bfgminer/whatever that has been configured/patched for - say - 30 seconds pool switch. Will this rig switch pools faster than a rig running standard cgminer 3.7.2 with 300 seconds pool switch?
Yes, it will be based on the settings in your miner. I use Kalroths cgminer v3.7.3 and i think he set the default there as check every 60 seconds, worked flawlessly this morning for my first customer. Please correct me if I'm wrong, but to my understanding the rig has a permanent stratum proxy connection and does not know where it's mining and when it's switching pool, so why should a custom cgminer switch faster than a stock one? |
|
|
|
|
Sorry if this has already been asked.
Who is responsible for fast pool switching? The proxy or the rig?
If I rent a rig running a custom cgminer/sgminer/bfgminer/whatever that has been configured/patched for - say - 30 seconds pool switch. Will this rig switch pools faster than a rig running standard cgminer 3.7.2 with 300 seconds pool switch?
|
|
|
|
|
Seems it takes very long for diff to come down. Currently 5.8 at 210 MH/s.
|
|
|
|
what command do you use in cgminer? Well, I have a quite complex config file - grown over several months. What are you getting? |
|
|
|
How often does difficulty re-target for this coin?
Good question, that would interest me also. Could'n find any facts on that. |
|
|
|
According to the pools blocks are coming every 85 seconds (should be 30 seconds). So IMHO diff is wrong.
Yes for the pool, but I'm more thinking about a botnet or something like this mining outside pools... Here is the last network blocks : 02/17/14 14:24:31 SetBestChain: new best=3961ab446cd876537ada height=598216 trust=984307578991 date=02/17/14 14:24:23
02/17/14 14:24:35 SetBestChain: new best=7e477a9ef08472b25c87 height=598217 trust=984326627388 date=02/17/14 14:24:27
02/17/14 14:25:03 SetBestChain: new best=64cc7000794c656eb1d4 height=598218 trust=984345747999 date=02/17/14 14:24:53
02/17/14 14:25:10 SetBestChain: new best=2d9cad58a02fa99666c7 height=598219 trust=984364879922 date=02/17/14 14:25:08
02/17/14 14:25:13 SetBestChain: new best=894ce79cc51d56deee60 height=598220 trust=984384053548 date=02/17/14 14:25:01
02/17/14 14:25:40 SetBestChain: new best=fdb091acdda7799cc3a8 height=598221 trust=984403330374 date=02/17/14 14:25:29
02/17/14 14:25:44 SetBestChain: new best=156d33769cc0322ba29c height=598222 trust=984422612947 date=02/17/14 14:25:35
02/17/14 14:26:04 SetBestChain: new best=0000000012b5e5275362 height=598223 trust=984422637285 date=02/17/14 14:25:47
02/17/14 14:26:15 SetBestChain: new best=000000001256d2091e3b height=598224 trust=984422661262 date=02/17/14 14:26:02
02/17/14 14:27:15 SetBestChain: new best=096f65cfdb815c01de8e height=598225 trust=984442011025 date=02/17/14 14:27:05
02/17/14 14:27:33 SetBestChain: new best=519c578df6fe44dacedf height=598226 trust=984461194353 date=02/17/14 14:27:25
02/17/14 14:27:49 SetBestChain: new best=c196f66ed0e0beb0d7b0 height=598227 trust=984480405500 date=02/17/14 14:27:45
02/17/14 14:28:01 SetBestChain: new best=32aa1702ed1e10ed9b69 height=598228 trust=984499644548 date=02/17/14 14:27:51
02/17/14 14:28:40 SetBestChain: new best=88ac3a6af40c87a97e8b height=598229 trust=984518950822 date=02/17/14 14:28:30
02/17/14 14:28:57 SetBestChain: new best=b0f9e3af9248df8ede61 height=598230 trust=984538232043 date=02/17/14 14:28:47
02/17/14 14:29:26 SetBestChain: new best=2ce638a39068684631ba height=598231 trust=984557549850 date=02/17/14 14:29:17
02/17/14 14:29:53 SetBestChain: new best=c1809e7b3b151d8132ae height=598232 trust=984576867657 date=02/17/14 14:29:43
02/17/14 14:30:10 SetBestChain: new best=d6babce9a9ef02306eff height=598233 trust=984596196670 date=02/17/14 14:30:24
02/17/14 14:30:34 SetBestChain: new best=060bdd0d0c702b2d8e90 height=598234 trust=984615495150 date=02/17/14 14:30:22
02/17/14 14:30:39 SetBestChain: new best=21fc4ac8e402869386f3 height=598235 trust=984634883470 date=02/17/14 14:30:29
02/17/14 14:30:51 SetBestChain: new best=a5fbeb04760a8382d162 height=598236 trust=984654336622 date=02/17/14 14:30:46
02/17/14 14:31:14 SetBestChain: new best=61d9a2267edb4dff595c height=598237 trust=984673826671 date=02/17/14 14:31:02
02/17/14 14:31:37 SetBestChain: new best=aceec4018da3bc0df28d height=598238 trust=984693356531 date=02/17/14 14:31:25
02/17/14 14:32:33 SetBestChain: new best=286647c97baeebf4aff5 height=598239 trust=984712906184 date=02/17/14 14:32:22
02/17/14 14:32:52 SetBestChain: new best=000000001e19ae2db9e2 height=598240 trust=984712931400 date=02/17/14 14:32:37
02/17/14 14:32:52 SetBestChain: new best=743f17c3a1f7e91eb1bf height=598240 trust=984732380008 date=02/17/14 14:32:41
02/17/14 14:32:54 SetBestChain: new best=000000001e19ae2db9e2 height=598240 trust=984712931400 date=02/17/14 14:32:37
02/17/14 14:33:27 SetBestChain: new best=663f96d915952f51b66c height=598241 trust=984732405224 date=02/17/14 14:33:16
02/17/14 14:33:59 SetBestChain: new best=0000000007acff511657 height=598242 trust=984732429278 date=02/17/14 14:33:26
02/17/14 14:34:51 SetBestChain: new best=00000000159dc97180aa height=598243 trust=984732453266 date=02/17/14 14:34:01
02/17/14 14:35:04 SetBestChain: new best=000000001869be327c58 height=598244 trust=984732477236 date=02/17/14 14:34:50
02/17/14 14:35:17 SetBestChain: new best=0000000022cdfd66ea4f height=598245 trust=984732501141 date=02/17/14 14:35:04
02/17/14 14:35:50 SetBestChain: new best=00000000071e02ca20be height=598246 trust=984732525101 date=02/17/14 14:35:20
02/17/14 14:35:57 SetBestChain: new best=a3d4f8c19ca9fa4f750f height=598247 trust=984751931900 date=02/17/14 14:35:48
02/17/14 14:36:22 SetBestChain: new best=00000000069b12be6157 height=598248 trust=984751956013 date=02/17/14 14:35:57 The average is WAY less than 30 seconds. Even more interesting. What is this? An attack? If those blocks make it to the regular chain, shouldn't the pools show a far less avg. time per block statistics? And a higher net hashrate? I'm confused. |
|
|
|
According to the diff, the pool factory should be the closest to the truth.
Me, and others pools are using the getmininginfo return, who says
"netmhashps" : 293.35217118,
I think it's more a display error.
I'm running several HBN daemons, and they all says the same hash.
I think getmininginfo should be the correct way to get the network hash rate. All pools (plus my client) are showing the same rate, except theblocksfactory. My theory is if the nethash is RIGHT, the diff is WRONG. And according to what I see, the last minutes, blocks are coming more frequently than every 30s, so I think the nethash is WRONG According to the pools blocks are coming every 85 seconds (should be 30 seconds). So IMHO diff is wrong. |
|
|
|
According to the diff, the pool factory should be the closest to the truth.
Me, and others pools are using the getmininginfo return, who says
"netmhashps" : 293.35217118,
I think it's more a display error.
I'm running several HBN daemons, and they all says the same hash.
I think getmininginfo should be the correct way to get the network hash rate. All pools (plus my client) are showing the same rate, except theblocksfactory. |
|
|
|
|
And when I type getmininginfo in my windows client I see "netmhashps" : 260.17686029
|
|
|
|
|
This is what the pools are showing:
theblocksfactory 728 Mh/s
smartmining.net 242 Mh/s
scrypt.io 242 Mh/s
cutk.com 242 Mh/s
Which one is correct?
|
|
|
|
This one is better, thanks. But I still have a lot of discarded shares, about 50%. However, a good progress compared to 75% with the maxcoin cgminer. |
|
|
|
I'm running cgminer from https://github.com/Max-Coin/cgminer unter Linux and get a lot of "stale share detected, discarding". Tried different pools, everywhere the same. Anyone else have this problem? |
|
|
|
|
havent had an single crash with that one
