 Show Posts
|
|
Pages: [1]
|
You'd want it configurable to pull profit data for different coins/algos for different sites to differnt slots. Could be messy.
Could be. But luckily modern programming languages make that easy. Some OO pseudo code: before parsing:
nicehash_parent = nil
westhash_parent = nil
=> These are the object to do the actual pulling work. We don't yet know if we need them.
while parsing:
if cfg.currentslot.provider <startswith> 'nicehash'
if nicehash_parent == nil
nicehash_parent = new nicehash_main()
slot[cfg.currentslot.slotnumber] = new nicehash_accesss(nicehash_parent, afterthecolon(cfg.currentslot.provider))
done
|
|
|
|
I may have to put a base URL parameter in to allow users to select which site to go to. Haven't decided yet. If this turns into too much of a debacle I may start looking at other options for mining instead.
maybe just do a bit like bfgminer does. Lose the fixed binding "slot to coin" and add a parameter for name and provider to the config. e.g. { "slot":0, "provider":"nicehash:0", "name":"Scrypt", "hashrate":350, "power":50, "folder":"", "command":"cmd.exe", "arguments":"/c MINERS.bat scrypt _ADDRESS_" },
{ "slot":1, "provider":"westhash:0", "name":"Scrypt, too", "hashrate":350, "power":50, "folder":"", "command":"cmd.exe", "arguments":"/c MINERS_w.bat scrypt _ADDRESS_" },
{ "slot":2, "provider":"fixprice:0.68965", "name":"Scrypt, three", "hashrate":350, "power":50, "folder":"", "command":"cmd.exe", "arguments":"/c mypool.cmd" },
With time you could add more providers. |
|
|
|
It appears to be an issue with nicehash control -- I have this issue with any CCminer 1.1, 1.2, and the latest NVMiner build.
Behavior only present on auto-switching.
The behavior is present across multiple rigs (780 rigs, 750ti rigs). Running the miner with a built in pause command does not change the behavior either.
Again, it still generates shares, but they are either not submitted to my deposit address, or it is running in benchmark mode.
I tried to diagnose a bit what might be happening here, but with no luck. NiceHash Control only starts a process and later kills it. There seem to be no other IPC, no OpenCl/Gl calls, or such things. The only thing I can think of is that maybe ccminer leaves the GPU in a bad state when it is being killed. Do you start ccminer directly from NiceHash Control or do you use a batch file? How current are your GPU's drivers? Have you tried NiceHash Control 1.1? (That version uses a different way to kill the miner.) Also, have a look at ccminer's window. Any messages there? (Both at startup and while it is running.) Does it go "yay!!!"? Does it say "benchmark mode"? If that doesn't help, please post your nicehashcontrol.conf and batch files (remove your passwords!!! and user names). |
|
|
|
How does this compare to the numbers coming out of the miner? If the red line is close to what the miner reports then you really have something here.
Near enough to be believable. And remember that the speed Nicehash "sees" is more important than what your miner reports. Nicehash does the payouts, not your miner  Update with data up till now: http://jacob.j-e-b.net/nicehash2.odsIt also contains the raw readings (columns are in pairs, algo0-raw, algo0-calc, algo1-...), so you can try out other formulas. Mine was just "speed = (speed*99+new_value)/100" with a check of "new_value > 0". Note: Real implementation would need to make sure to not take readings in the 5-minute ramping up phase. You can see the negative effects in my graphs above after each blue spike. It also should use some recover logic, e.g. what I outlined above, so a bad phase does not disable an algo forever. |
|
|
|
I'll be curious to see your results.
 http://jacob.j-e-b.net/nicehash.odsThis was taken using a 1 minute counter and a 1% averaging. No compensation for ramp up/ramp down (integrated solution would have that) and no hashrate recovery. The lower two are X11 and X13 on "nicehash control", the upper two are scrypt and sha256 on "p=xx", with the initial hashrate for scrypt misconfigured. Looks good to me (looks better when the graph is not that compressed), more after work... |
|
|
|
You can't get the hash values from NiceHash because if you have more than one miner running you are seeing cumulative values rather than for one miner. Also, the accept/reject rates jump around a lot and are not reliable gauges of actual speed.
The hash rate Nicehash reports is the important one, as that is what generates the payment. Yes, it jumps around a lot, but that is what the running average is for. Also, nowadays Nicehash supports workers and reports their hashrate. Edit: I'm running a script to test the averaging at the moment. Give me a couple of hours to get some results. |
|
|
|
Nice tool. Good work. Just one little feature request: Auto-tuning for hash rate. Pseudo-code: @startup (all algos):
speed = read_cache_file()
if (speed.remember != configfile.speed) {
speed.remember = configfile.speed
speed.current = configfile.speed
speed.max = 0
}
// to reset the speed just change the value in the config file
@every 5 minutes (active algo):
if (activity.accept > 0) {
speed.current = (speed.current*95 + activity.accept*5) / 100
}
if (speed.current < configfile.speed and speed.current > speed.max) {
speed.max = speed.current
}
@every 5 minutes (inactive algos) (optional):
if (speed.max > 0) {
if (speed.max > speed.current) {
speed.current = (speed.current*99 + speed.max*0.9) / 100
// need to test if 0.9 or 0.95 or 0.85 works better
}
} else {
speed.current = (speed.current*99 + configfile.speed*1) / 100
}
@every 5 minutes:
save_cache_file()
I chose 5 minutes and 5% because I like the reaction that gives. It isn't too jumpy but still follows reasonable fast. A "half change" is an hour and a "full change" takes 12 hours. However, to avoid flickering when two algos are very close, a >10 minutes switchtime may be advisable. The optional block is to recover deteriorated values. That way a "bad" pool won't kill an algo for good. With this enabled algos might flicker somewhat if the configfile speeds are (much) too high, or not recover if they are too low, so the user should have an eye on the auto-tuned values for a while and adapt the config file if that happens. |
|
|
|
It seems the pool recently died. Yesterday, at about 2am UTC, the sha-256 pool EU stratum server died and with it block confirmations and payouts stopped. Later in the day the sha-256 pool US stratum server died, too. Individual coin servers are still running, but without block confirmations... Over the last days I noticed some other strange behaviors, e.g. MZC never built any balance, even though I definitely had shares and the pool reported found blocks. Luckily the only thing I had pointing there were 2 lonely antminer U2s |
|
|
|
What would be some FOUTs to fill out this little table  E.g., 222.5, 220, and/or 217.5. TIA All possible values: chip_freq timeout freq_value(s)
37.50 373 0583, 0b87
39.06 358 0c07
40.62 344 0603, 0c87
42.19 331 0d07
43.75 320 0683, 0d87
45.31 308 0e07
46.88 298 0703, 0e87
48.44 289 0f07
50.00 280 0783, 0f87
51.56 271 1007
53.12 263 0803, 1087
54.69 256 1107
56.25 248 0883, 1187
57.81 242 1207
59.38 235 0903, 1287
60.94 229 1307
62.50 224 0983, 1387, 4983, 5387
64.06 218 1407, 5407
65.62 213 0a03, 1487, 4a03, 5487
67.19 208 1507, 5507
68.75 203 0a83, 1587, 4a83, 5587
70.31 199 1607, 5607
71.88 194 0b03, 1687, 4b03, 5687
73.44 190 1707, 5707
75.00 186 0582, 0b83, 0b86, 1787, 4b83, 5787
76.56 182 5807
78.12 179 0c06, 4c03, 5887
79.69 175 5907
81.25 172 0602, 0c86, 4c83, 5987
82.81 169 5a07
84.38 165 0d06, 4d03, 5a87
85.94 162 5b07
87.50 160 0682, 0d86, 4d83, 5b87
89.06 157 5c07
90.62 154 0e06, 4e03, 5c87
92.19 151 5d07
93.75 149 0702, 0e86, 4e83, 5d87
95.31 146 5e07
96.88 144 0f06, 4f03, 5e87
98.44 142 5f07
100.00 140 0782, 0f86, 4f83, 5f87
101.56 137 6007
103.12 135 1006, 5003, 6087
104.69 133 6107
106.25 131 0802, 1086, 5083, 6187
107.81 129 6207
109.38 128 1106, 5103, 6287
110.94 126 6307
112.50 124 0882, 1186, 5183, 6387
114.06 122 6407
115.62 121 1206, 5203, 6487
117.19 119 6507
118.75 117 0902, 1286, 5283, 6587
120.31 116 6607
121.88 114 1306, 5303, 6687
123.44 113 6707
125.00 112 0982, 1386, 4982, 5383, 5386, 6787
128.12 109 1406, 5406
131.25 106 0a02, 1486, 4a02, 5486
134.38 104 1506, 5506
137.50 101 0a82, 1586, 4a82, 5586
140.62 99 1606, 5606
143.75 97 0b02, 1686, 4b02, 5686
146.88 95 1706, 5706
150.00 93 0581, 0b82, 0b85, 1786, 4b82, 5786
153.12 91 5806
156.25 89 0c05, 4c02, 5886
159.38 87 5906
162.50 86 0601, 0c85, 4c82, 5986
165.62 84 5a06
168.75 82 0d05, 4d02, 5a86
171.88 81 5b06
175.00 80 0681, 0d85, 4d82, 5b86
178.12 78 5c06
181.25 77 0e05, 4e02, 5c86
184.38 75 5d06
187.50 74 0701, 0e85, 4e82, 5d86
190.62 73 5e06
193.75 72 0f05, 4f02, 5e86
196.88 71 5f06
200.00 70 0781, 0f85, 4f82, 5f86
203.12 68 6006
206.25 67 1005, 5002, 6086
209.38 66 6106
212.50 65 0801, 1085, 5082, 6186
215.62 64 6206
218.75 64 1105, 5102, 6286
221.88 63 6306
225.00 62 0881, 1185, 5182, 6386
228.12 61 6406
231.25 60 1205, 5202, 6486
234.38 59 6506
237.50 58 0901, 1285, 5282, 6586
240.62 58 6606
243.75 57 1305, 5302, 6686
246.88 56 6706
250.00 56 0981, 1385, 4981, 5382, 5385, 6786
256.25 54 1405, 5405
262.50 53 0a01, 1485, 4a01, 5485
268.75 52 1505, 5505
275.00 50 0a81, 1585, 4a81, 5585
281.25 49 1605, 5605
287.50 48 0b01, 1685, 4b01, 5685
293.75 47 1705, 5705
300.00 46 0580, 0b81, 0b84, 1785, 4b81, 5785
306.25 45 5805
312.50 44 0c04, 4c01, 5885
318.75 43 5905
325.00 43 0600, 0c84, 4c81, 5985
331.25 42 5a05
337.50 41 0d04, 4d01, 5a85
343.75 40 5b05
350.00 40 0680, 0d84, 4d81, 5b85
356.25 39 5c05
362.50 38 0e04, 4e01, 5c85
368.75 37 5d05
375.00 37 0700, 0e84, 4e81, 5d85
381.25 36 5e05
387.50 36 0f04, 4f01, 5e85
393.75 35 5f05
400.00 35 0780, 0f84, 4f81, 5f85
406.25 34 6005
412.50 33 1004, 5001, 6085
418.75 33 6105
425.00 32 0800, 1084, 5081, 6185
431.25 32 6205
437.50 32 1104, 5101, 6285
443.75 31 6305
450.00 31 0880, 1184, 5181, 6385
456.25 30 6405
462.50 30 1204, 5201, 6485
468.75 29 6505
475.00 29 0900, 1284, 5281, 6585
481.25 29 6605
487.50 28 1304, 5301, 6685
493.75 28 6705
500.00 28 0980, 1384, 4980, 5381, 5384, 6785
512.50 27 1404, 5404
525.00 26 0a00, 1484, 4a00, 5484
537.50 26 1504, 5504
550.00 25 0a80, 1584, 4a80, 5584
562.50 24 1604, 5604
575.00 24 0b00, 1684, 4b00, 5684
587.50 23 1704, 5704
600.00 23 0b80, 1784, 4b80, 5784
612.50 22 5804
625.00 22 4c00, 5884
637.50 21 5904
650.00 21 4c80, 5984
662.50 21 5a04
675.00 20 4d00, 5a84
687.50 20 5b04
700.00 20 4d80, 5b84
712.50 19 5c04
725.00 19 4e00, 5c84
737.50 18 5d04
750.00 18 4e80, 5d84
762.50 18 5e04
775.00 18 4f00, 5e84
787.50 17 5f04
800.00 17 4f80, 5f84
812.50 17 6004
825.00 16 5000, 6084
837.50 16 6104
850.00 16 5080, 6184
862.50 16 6204
875.00 16 5100, 6284
887.50 15 6304
900.00 15 5180, 6384
912.50 15 6404
925.00 15 5200, 6484
937.50 14 6504
950.00 14 5280, 6584
962.50 14 6604
975.00 14 5300, 6684
987.50 14 6704
1000.00 14 5380, 6784 With the definition of "possible" of "fits the formula". I'm quite sure it's impossible to get any results but fried chips with values like 5380... |
|
|
|
|
