 Show Posts
|
|
Pages: [1] 2 3
|
I don't understand why my ckpool shows different parameters than the Antminer:
In Antminer the following parameters come out:
[minerPool] [minerPoolTip] Diff Priority Accepted DiffA DiffR Rejected Stale LSDiff LSTime
But none of this matches CKPOOL, anyone who can make me understand this, also it would be nice to know what each Antiminer parameter indicates, I find information but it is not well explained.
Thank you very much in advance
I do not use Antminer pool and Antminer mining program. I just guess. Diff may be network difficulty.\ Proority ? Accepted may be how many numbers of acceptance of your submit to the pool. Rejected may be how many numbbers of rejection of your submit to the pool. DiffA: sum of all difficulty of accpted submit to the pool. DiffR: sum of all difficulty of rejected submit to pool. Actually useful information for a transparency for pool and miners, I believe, are: Network current Difficulty, eg 36.8T Last accpeted submit's difficulty by the pool, and when Maximum accpeted submit's difficulty by the pool, and when Number of accepted submit. Number of rejected submit. Other statistic? |
|
|
|
|
After I read your posts, there are missing points.
1. The nonce2 is only used to create next new local block header data. When a new block header come in, nonce2 is initialzed to 0 in cgminer, e.g. parse_notify() or gbt_decoode(). The nonce2 is 64 bits integer (very large integer). The nonce2 only affects merkleroot value in local block header data. Huge numbers of local block header data are created and are given to ASIC chips for chips to find out some nonces which produce a hash value with last 8 digits 0.
hash value: xxxx....x????00000000.
2. cgminer does not cycle nonce from 0 to 4.29G. It just sends a lot of block header data to ASIC chips. ASIC chips or hardware do cycle nonces by digital chips and frequency pulse to check and find qualified nonces. ASIC hardware do filter out qualified nonces. So, ASIC hash header data super fast.
3. Qualified or found nonces, then, are read by cgminer from ASIC chips. Then, cgminer verify those nonces with the pool's difficulty. Then, good nonces are sent to the pool for further verification by pool with network's difficulty.
|
|
|
|
|
In cgminer, any new block or any update of cuurent block will create a new "ntime" when block information is received. About 60 second, block update information is coming from pool.
see parse_notify() function.
In cgminer, nonce2 is used to create more local block header data for more hashing and is used for generating new merkleroot in local header data. it changes very quick. see gen_stratum_work or gen_solo_work funct.
It is used in submit work to pool and pool uses it to re-generate block header for verifying if block header is resolved.
|
|
|
|
|
I have tried miniZ v1.9 to mine an Equihash 144_5 coin recently.
But, I found this miniZ miner program lacks basic transparency for miners:
1. It fails to display network difficulty with new job. It also fails to display the
height of new block. These are basic information in bitcoin mining programs.
2. It fails to display submit and accepted share's difficulty or submit work's difficulty.
So this mining program fails to get a correct difficulty calculation criteria with pool calculation of
difficulty. The miners never know what difficulty of submit, accepted works they submit.
bitcoin mining programs, e.g. cgminer show accepted submit work's difficulty.
People should wait for miniZ to be improved and add above basic functions to display
basic information of new block and submit work.
|
|
|
|
|
I ping, your server change name to solo4.ckpool.org, 395 ms.
Too slow?
jack1@hp:~$ ping solo.ckpool.org -c 5
PING solo.ckpool.org (51.81.56.15) 56(84) bytes of data.
64 bytes from solo4.ckpool.org (51.81.56.15): icmp_seq=1 ttl=38 time=512 ms
64 bytes from solo4.ckpool.org (51.81.56.15): icmp_seq=2 ttl=38 time=433 ms
64 bytes from solo4.ckpool.org (51.81.56.15): icmp_seq=3 ttl=38 time=355 ms
64 bytes from solo4.ckpool.org (51.81.56.15): icmp_seq=4 ttl=38 time=379 ms
64 bytes from solo4.ckpool.org (51.81.56.15): icmp_seq=5 ttl=38 time=300 ms
--- solo.ckpool.org ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4000ms
rtt min/avg/max/mdev = 299.737/395.647/511.561/72.009 ms
|
|
|
|
The nonce you are hashing is done against many things, one of them is the coinbase transaction which must be in the block header, that transaction ensures the payout goes to the pool address, if you change anything in that transaction the hash you sumbit will be invalid to both the pool and the network as a whole.
The pool keeps all necessary data about block header and transactions for a valid submit to bitcoin network and miners are not given all data by the pool. So only the pool can submit solved block header which includes nonce. Transaction data, sometime, is a huge data; so it won't be given to miners in stratum mode. This answers your curious or doubt.
Mining on self node in BTC network has a fundamental good point is that a BTC is going to your BTC address, which can avoid a risk of operation failure in pool side or dishonourable operator of pools. So solo miner must bear this in mind.
Does this mean that the operator of a solo pool has the technical possibility of manipulation, e.g. to redirect the reward to himself in case of a block find? And this although the user of his pool had entered his own Bitcoin address as user name when started the mining? I would be interested from a technical point of view whether this would be possible in general. That would be disastrous, of course, because a pool operator could be a scammer. Can you please explain this in more detail? Thanks. Yes. solo pool operators can manipulation of your submits and rippe off you at current start of the art in software of the pool side, eg: 1. Pool can submit your found in a different bitcoin address to the bitcoin network. Because the pool got the coinbase data. This is quite wide practice in altercoin pools in terms of my watching. Some pool operators are gangs and untracable, even by Agents. 2. Current miner softwares only got a message indicates the pool accepted this submit. But it does not provide information whether this submit has beem submit to the bitcoin network? or whether bitcoin network has accepted this submit? or confirmed this submit? This is an issue which give the pool operators a back door, I believe. The altercoin pools and miner programs even got worst, they don't provide the height information of block. You never know your submits are accepted by the network or not. They got webpage only indicate few second ago you did submit a share. 3. After you submit your found to the pool, the pool firstly verify your submit with pool's share difficulty and then pool verify your submit with bitcoin network's difficulty. But, the pool never return a feedback information whether your submit is above the network's difficulty. This can be done easily in software, and this is a key issue in transparency of bitcoin network. Actually, the bitcoin core will return a message "under diff, sth like" if submit is below the diff. So, there is a real risk in crypto coin mining business. When you ran a miner for one year, and got a good submit, then, ripped off or missed. What can you do? You have to work with reliable pool operator at first place. |
|
|
|
kano, first of all my thanks for your great contributions in the development of bitcoin. Wouldn't you like to make a mining pool for other sha256 coins? for example XEC? or other sha256.. to see if we can improve income in these difficult times
The mining pools did not follow your example of transparency, and we are at their good will.
Every altcoin is a scam in my opinion. I've been involved in bitcoin before any altcoins existed and their creation made it clear that they all are. Most people just don't know the reasons. (and altcoins are off topic here also) Yes. Altcoins are scam at moment in terms: 1. GPU got huge running cost on electric 2. Mining programs don't display the height of block. So, you never can check why you miss a reward once your submit was accepted by pool. It is scam or virus program, I believe. cgminer got transparency, trusted, very good . Only xmrig display height of block which can be trusted. 3. Mining programs got develop fee, eg 1% or 2%. Tricky is your best submit may be gripped by the program with other address. It is scam behavious. 4. Some mining programs came from Russian guru. These programs are danger, I believe. |
|
|
|
|
As bitcoin price crashed down, this crypto bubble burst in the end, which like tech bubble stocks, or like Dot-com bubble.
Mega farm, mega pools will face bankrupt. So, equipment suppliers got no business in future. This market is quite small for
Intel, I believe, Intel won't do any significant development on mining chip.
But, ASIC chip for general sha256 algorithm which can output whole hash value (256 bits), may be needed for network security products
which is a mega market needs.
Mining btc is similar to lottery game. No need to speed big money which is gambling. Bitcoin will drop to $5000, then, $2000 or $1000 in next year.
|
|
|
|
Right right. I understand that all, mostly.
So, what if you are not using a "solo pool"; such as ck and literally mining to a full mining node.........you know what......nevermind. I think it's more trouble than it's worth to go down this route of FULL blown solo mining.
I think MAYBE it might be worth allocating a % of hashrate to a smaller pool or something and ultimately this is what I'm exploring: alternative ways of mining as opposed to 100% PPLNS pool mining.
Any good threads or links you know of about alternative mining strategies? Either way , thank you for your input on this.
Mining on self node in BTC network has a fundamental good point is that a BTC is going to your BTC address, which can avoid a risk of operation failure in pool side or dishonourable operator of pools. So solo miner must bear this in mind. Bad point is you has to run a node with more computer power and cost. Risk/Reward issue! Mining on PPLN in a pool. Now, it is USD 9 cent / 1TH/s per day, which only cover some cost and won't let you rich or hit a big excite. So, it may be better to run both modes, set up two mining farms or three miners, etc. |
|
|
|
Do you think i will ever hit a block with 100TH during a year?
Mining BTC is the same like buy lottery ticket. Let presume 1 TH/s mining machine is a lottery ticket. 100 TH/s mining machine are 100 lottery tickets. 1 PH/s mining machine seem got 1000 lottery tickets. Next is how many numbers on a lottery tickets? risk/reward? Cost/Profit on a long run? 1 PH/s mining machine has a chonce to hit BTC during 20 days run. Less than 1 PH/s mining machine got tiny or no chance to hit BTC during 1 year run as expectation. |
|
|
|
It's physically identical to the existing hub, but uses a high-efficiency central regulator instead of several lower-power ones. That means there's no more "6A per port pair" limit. We also put 3.5A PTC resetting fuses on each port for safety.
what could be a better power supply unit suitable for new usb hub? |
|
|
|
|
my criteria to buy a miner machine:
1. reliable for long running.
2. technical transparency on hardware and software.
3. repairable and good service.
4. low price.
5. less power consume.
|
|
|
|
Please, is there somewhere I can find the difference between mining for ckpool and kanopool?
Which would be better to mine solo with compacF sticks?
I saw that it is possible to mine for 2 different pools in the same cgminer, check? Have a problem or lose efficiency instead of mining for 1 pool only?
cgminer on compacF sticks can mine with two pools. But, reliability is reduced, I believe. The criteria for a good pool are: 1. reliable. 2. convenient or user friendly. 3. fast traffic flow. 4. less traffic flow. Too many factors affect performance of pool side and miner side. There is a problem for both pools: too often (half second to 1 second), pool re-send the same block header data to miners, which causes too many repeat calculation on block header data. Data is not steady for continue mining. It is not good for small CPU, and it produces too much internet traffic, I believe. |
|
|
|
another question for my understanding and namely what do all the numbers stand for in the accepted lines that are constantly generated by the miners? the gsf 0, 1, 2,... means that it was generated by the respective stick/miner but the other 3 things I do not come on it  [2022-09-08 19:55:06.421] Accepted 044b2614 Diff 15.3K/641 GSF 1 641 is the worker difficulty you were mining at - so each share submitted is worth 641 15.3K is what the actual share difficulty was, which of course must be greater or equal to 641 See https://kano.is/index.php?k=workdiffDoes this Accepted 044b2614 ... mean miner compacF and pool communication ok? or both sides are working correctly? Has pool side hashed submitted block and valid diff is above miner's setting diff? |
|
|
|
thanks for the numerous hints and commands but i still don't know with which cmd i can set a special mhz on my 1622 so that it doesn't restaret all the time  cmd on linux, insert: ./cgminer -o ... -u ... -p x --gekko-serial "GS-10051622" then, only 1622 stick is selected for mining. |
|
|
|
The ticket mask decides which nonces the chip returns and I set that to 16. If you set it to 32, you'd get half as many nonces in the same time, with the same average expected difficulty. Setting it higher just reduces the amount of data that travels back from the chip to cgminer by intercepting it. It has no effect on the 'quality' of the data, it just affects the average difficulty of the data by removing the lower difficulty nonces from the returned data, the chip still generates this data, it's just removed from the returned data, i.e. less data returned. Read here, coz it would appear you may not understand the meaning of difficulty: https://kano.is/index.php?k=workdiffAll mining is simply based on the fact that if you hash some data, 1 in 2^32 hashes will, on average, start with 32 zero bits. 1 in 2^16 hashes will, on average, start with 16 zero bits. 1 in 2^96 hashes will, on average, start with 96 zero bits. Asic-boost uses the idea that some of the hash processes can be reused for another hash, meaning the hash process is shorter in this case i.e. sometimes you can do the whole hash process a bit faster. It has zero effect on the value of the hash. 1. I believe that the ticket mask is no need at all. does it filt nonce output within BM1397 chip as its internal function? or just the code in cgminer do filter? It makes code more complex and cost CPU time, too. Only threshold setup within BM1397 chip, may help to reduce number of ouput nonce with more quality nonces output. One block headers only produce 0 to 3 nonces in average running. 2. I observed total nonces come from asic chips and total nonces pass 1st test, and total nonces fail to pass 1st test. I found that a lot of nonces which are from asic chips fail to pass 1st test in test_nonce() function under ASIC boost mode. Which should not happen, I believe. And this indicate ASIC boost mode can output bad nonces (or less quality nonce). 3. sha256 algorithm is very sensitive to input message. So those midstates will produce error and cause bad nonces output for sure. I believe, turning off some midstate will help the quality of output nonces, which will increase of expectation of hitting bitcoin. 4. " 1 in 2^32 hashes will, on average, start with 32 zero bits.", a lot of miners have done this amount 2^32 of hashing, but, they won't get a 32 zero hash value. This saying is aganist my observation in years. There is always some area (sub-space of sha256 space) hide more quality nonces which can produce better (or smaller) hash values. I called these nonces as quality nonces. I often observed some miners can resolved a bitcoin under 30 seconds. I think they may have few or some universal or nearest universal nonces. Otherwise, it is against the your logic (or theory). In fact, small home miners need few universal nonces to beat big miners, I believe. |
|
|
|
@jack1cryptotalk007
to adjust the screw the stick must be pulled out or can the whole thing be done during mining?
when stick is mining, do adjust screw. Watching usb tester display voltage and current, turning screw, tuning frequeucy dynamically, watching computer screen (see effect). |
|
|
|
so only the 1622 makes me some problems...
have him first switched off and will then try to adjust correctly by turning the screw
how and where can i change the read code in an extreme case and as a last option?
1. To adjust that screw, you need to get two Keweisi USB testers, google it. Then, you can watch two sticks what voltage and current are with both sticks when they are running. When you adjust one stick, you can see current change and frequeency change on the stick. 2. Modify code. enter ubuntu, git clone kano's cgminer. Then, use Microsoft code. Find code: driver-gekko.c. in compac_listen() and compac_lisyten2() functions. (1). Search ' usb_read_timeout( ' , modify waiting constant inside this sentence. (2). Search ' tmo = ', modify tmo = 100; or tmo = 200. re-compile cgminer. then, etc ....... |
|
|
|
okay, i have now started my 3 gekko compac f miner with the following command: ./cgminer -o stratum+tcp://de.kano.is:3333 -u cryptocygan.worker -p x --suggest-diff 442 --gekko-mine2 --gekko-tune2 60 --gekko-compacf-freq 555 --gekko-start-freq 555
i am now curious how long all 3 miners will run at this mhz  0: GSF 10051796: BM1397:01+ 555.00MHz T:555 P:547 (5:12) | 100% WU:100% | 316.0G / 335.4Gh/s WU:4684.9/m
1: GSF 10051622: BM1397:01+ 555.00MHz T:555 P:528 (5:12) | 71.8% WU: 67% | 181.4G / 195.0Gh/s WU:2724.8/m
2: GSF 10051619: BM1397:01+ 555.00MHz T:555 P:0 (5:12) | 100% WU:100% | 395.6G / 400.5Gh/s WU:5602.4/m
edit: did not take long and the first miner was disabled [2022-08-29 17:22:24.488] GSF 1 failure, disabling!
[2022-08-29 17:22:24.492] 1: GSF 1 - usb failure (-9)
[2022-08-29 17:22:31.153] 3: GSF 3 - CompacF Bitcoin Miner (10051622)
[2022-08-29 17:22:31.153] Hotplug: GekkoScience added GSF 3
for simple run, try don't want --gekko-mine2 --gekko-tune2 60, to see how it is going? or try to use 525 or 500. if 1622 stick alway got lower Gh/s, try to adjust that screw. If still fail, which mean that stick is not good. Quality problem. Another way, edit code, increse waiting time in read usb command, use 100 ms instead of 10 ms. This is often cause usb read not work correctly. |
|
|
|
the problem i have is that i can't get all 3 comapc miners to run at the same number of mhz at the same time
once only 2 miners get to the 570mhz and when i restart cgminer only the third one gets to the 570mhz and the others are somehow at 300-400mhz and then restart at some point to 200mhz
so from this point of view, all 3 miners are set correctly, because otherwise they wouldn't reach the 570mhz - but what is the problem, that not all 3 miners reach 570mhz or 550mhz at the same time?
you can try to insert --gekko-compacf-freq 580 --gekko-start-freq 580 into cmd. set start-freq also at 580. if one stick always fail to get computed freq to close 575 mhz after running 1 hour, then, that stick got problem for sure. when freq is higher, the stick is more steady. Another way, edit code, stop reducing freq for stick. There is a logic problem in code, it often reduce set freq or reduce requested freq. Then, freq is going down and never coming up. |
|
|
|
|
