Will upgrading the S1s to this latest version affect the use of the Slush proxy between the miners and the pool?
No, but if the slush proxy supports mining redirection then you are still open to the attack of being redirected and are not being protected by cgminer. |
|
|
|
|
Software wise, clocking/voltage control is all done in binary firmware (not the free software cgminer driver) so we have no control over it unless you wish to try hacking the firmware. Hardware wise, the power and cooling is also close to its limits even in a cool environment anyway.
|
|
|
|
hello,
any informations there about overclocking of TerraMiner IV
You cannot. |
|
|
|
Any indications of when CGMiner will support full speed for NF2's?
In case you've missed it: I've added support for NF2 and NF6 into cgminer git master branch. (...) The NF2s are behaving very nicely. This is at --nfu-bits 54: 14: NF2 00001099: | 4.670G / 4.655Gh/s WU: 65.2/m
23: NF2 00000753: | 4.447G / 4.509Gh/s WU: 63.6/m
Thank you, I did miss that. Hmm, windows build instructions here I come. Any known cgminer nightly build resources our there? Here you go: http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe |
|
|
|
is there a 4.3.3 update for the s1 yet. 4.3.3 only has driver changes for unrelated hardware so there is no reason to update S1s from 4.3.2 to 4.3.3 |
|
|
|
EDIT: no occurence of "generic NFU name" in any file... Searched by notepad++ in all files...
It's just updated hours ago. I guess it's not ready for next rev. package. You should go to github to get the latest source. I've added support for NF2 and NF6 into cgminer git master branch. |
|
|
|
I've added support for NF2 and NF6 into cgminer git master branch. I'm not getting much love out of the NF6 just yet but they may well need so much power that even a regular USB3 port is not enough. The NF2s are behaving very nicely. This is at --nfu-bits 54: 14: NF2 00001099: | 4.670G / 4.655Gh/s WU: 65.2/m
23: NF2 00000753: | 4.447G / 4.509Gh/s WU: 63.6/m
NFU?? Is that a question, statement, exasperation, disgust, or what? |
|
|
|
|
You've told us now (and I'm not interested). I would prefer you post it in service announcements or similar and not PM me/us.
|
|
|
|
Any pattern you see is pure coincidence. Trying to predict luck is madness.
|
|
|
|
I've added support for NF2 and NF6 into cgminer git master branch. I'm not getting much love out of the NF6 just yet but they may well need so much power that even a regular USB3 port is not enough. The NF2s are behaving very nicely. This is at --nfu-bits 54: 14: NF2 00001099: | 4.670G / 4.655Gh/s WU: 65.2/m
23: NF2 00000753: | 4.447G / 4.509Gh/s WU: 63.6/m
|
|
|
|
|
No. There is no such thing as work harder. Anything below difficulty of the network is purely evidence that you're working and only affects network bandwidth, it has no effect on hashing.
|
|
|
|
To clarify how our system at miningrigrentals.com works -- when you connect to our system initially, you are issued a client.reconnect that redirects you to your own dedicated port. This is what is required to allow our service to control what pool your miner is pointing at. After the initial connection, no further reconnects are sent.
In that case then, if you are redirected to a different port on the same domain it should work fine even with the security redirect limiter in place. |
|
|
|
|
I just posted a new version of cgminer, 4.3.3, which has a fix for a huge memory leak which has always been there with the driver for this particular hardware, along with support for the experimental firmware which discretely recognises these devices as OSM. All users mining with this hardware on cgminer are urged to upgrade.
|
|
|
|
|
I just posted a new version of cgminer, 4.3.3, which has a fix for a huge memory leak which has always been there with the driver for this particular hardware. All users mining with this hardware on cgminer are urged to upgrade.
|
|
|
|
|
I just posted a new version of cgminer, 4.3.3, which has a fix for a huge memory leak which has always been there with the driver for this particular hardware. All users mining with this hardware on cgminer are urged to upgrade.
|
|
|
|
|
New release: Version 4.3.3, 4th May 2014
Human readable changelog:
- Fox for a huge long-standing memory leak with the BXF driver which affected bi*fury, hex*fury and OneString miners.
- Formatting fixes for miner.php
Full changelog:
- Fix typo
- Work should be freed when aged, fixing a massive memory leak for bxf devices
- miner.php fix single rig summary/config field formatting
- miner.php fix single rig total formatting
|
|
|
|
How many orphans do you see here from btcguild?
Less than 1% (the general 'rule of thumb' that has been fairly accurate for the past 3 years is ~1%) in 2014. Right. But the time needed to propagate a smaller block to the network should be slightly shorter, giving the miner a slightly advantage in orphan block race.
And what's discus fish and ghash's orphan rate? |
|
|
|
|
Yes I wrote and continue to maintain cgminer. No I don't have any hex8 code in cgminer so I'm guessing you're using a fork of cgminer in which case you need to ask whoever's maintaining that fork.
|
|
|
|
I have been researching pool centralization and manipulation, one of the things I found is that discus fish and ghash set their accepted block size very low. Discus fish obscenely low.
This allows them to plow through more of the smaller blocks faster than pools that play fair.
There's no such thing. "Smaller blocks" (presumably by that you mean ones with less transactions) take just as long on average to solve as larger ones. The time the block should be the same, in statistical sense. But the time needed to propagate a smaller block to the network should be slightly short, giving the miner a slightly advantage in orphan block race. How many orphans do you see here from btcguild? |
|
|
|
|
Show Posts
