That's excellent news. It's looking like the miner side is working and it's just a wallet issue now.
That means it should work with almost any coin who's wallet already supports getwork.
Keep me updated on your progress. The next release will be 3.6.0 with getwork support.
i have thought about writing a small tool to setup multiple wallets and only mine when nethashrate is below a certain limit this is intended for me walking through the ann section, finding a new coin with no pools which just launched, setting it up in the tool and boom, miner starts working there till there are enough other people so its unlikely to be profitable awesomeminer might be able to do that already im not sure, but i want it to be able to run on linux as well will see if this project is possible in a short timeframe and if mining even works, so im glad getwork/gbt is being worked on  edit: im interested in testing as well, i have noticed the api hashrate isnt updated when using getwork it seems, it always returns 0 |
|
|
|
Hmm - switched to MPH with 3 Baikal Giants today - algo switching setup - been mining with 2750 MH/s for 11 hours and so far I can see I made a "whopping" $16 when I calculate all coins incl non confirmed etc and convert them manually to USD - which absolutely no sense when checking whattomine.com and calculate for the past 24 hours - any ideas to what I might be doing wrong, as I see the system as pretty fool proof when setting it up  see my last posts: The DGB-qubit issue seems to still persist?
over the last few weeks i tested mph in comparison to nicehash with baikal miners, mph is more profitable on the paper 99% of the time, but the real payout in btc is by far less than the expected return and nicehash payout is in fact more
in return i have switched back to nicehash
i tested that some time before and at that time dgb-qubit was the culprit: it displayed incorrect estimates which where far off and thus the miner often switched to it for some time and then back to "stable" coins, might be something else additionally as well, all i can tell is that the profit is off by much (tested for 48 hrs)
It's because digibyte's difficulty value goes up and down toooooo frequently. Here you can see difficulty history from Blocks page. https://digibyte-qubit.miningpoolhub.com/index.php?page=statistics&action=blocksIt goes up around 463 and crashes to 147 for last 30 minutes which means profitability goes up like x3 for very short period of time. It doesn't mean that you earn less always. You would earn much more sometimes but much less sometimes. well, the profit is almost half of the displayed expected, thats all i can tell |
|
|
|
im not sure about the latest image (not using it), but before that the temp sensor was definitely working as i tested it with various airflow scenarios edit: what you are looking at is probably this part: // Debug miner data
if(!empty($_REQUEST['dev']) && $r['status']['minerUp']){
$r['status']['devs'][]=array('Name'=>'Hoeba','ID'=>0,'Temperature'=>rand(20,35),'MHS5s'=>rand(80000,100000),'MHSav'=>rand(90000,100000),'LongPoll'=>'N','Getworks'=>200,'Accepted'=>$....
$r['status']['devs'][]=array('Name'=>'Debug','ID'=>1,'Temperature'=>rand(20,35),'MHS5s'=>rand(40000,50000),'MHSav'=>rand(45000,50000),'LongPoll'=>'N','Getworks'=>1076,'Accepted'=>1$....
$r['status']['devs'][]=array('Name'=>'Wut','ID'=>2,'Temperature'=>rand(20,35),'MHS5s'=>rand(6000,9000),'MHSav'=>rand(7000,8000),'LongPoll'=>'N','Getworks'=>1076,'Accepted'=>1324,'R$....
$r['status']['devs'][]=array('Name'=>'Wut','ID'=>4,'Temperature'=>rand(20,35),'MHS5s'=>0,'MHSav'=>0,'LongPoll'=>'N','Getworks'=>400,'Accepted'=>0,'Rejected'=>0,'HardwareErrors'=>0,$....
$r['status']['devs'][]=array('Name'=>'More','ID'=>3,'Temperature'=>rand(20,35),'MHS5s'=>rand(500,1000),'MHSav'=>rand(600,800),'LongPoll'=>'N','Getworks'=>1076,'Accepted'=>1324,'Rej$....
$r['status']['pools'][]=array('POOL'=>5,'URL'=>'http://stratum.mining.eligius.st:3334','Status'=>'Alive','Priority'=>9,'LongPoll'=>'N','Getworks'=>10760,'Accepted'=>50430,'Rejected$....
}
but that is only for debugging purposes, the real temps (and other stats) are gathered right at the top: |
|
|
|
|
ot: afaik the 4gb image is newer
you can check the miner output when you open the terminal, login, sudo su, and execute screen -r
this will show you the sgminer instance and might tell you what the problem is, in general a sd reflash as suggested above fixes 99% of all errors
i used dd image tool for that (linux) and win32 disk imager (windows), worked like a charm
|
|
|
|
The DGB-qubit issue seems to still persist?
over the last few weeks i tested mph in comparison to nicehash with baikal miners, mph is more profitable on the paper 99% of the time, but the real payout in btc is by far less than the expected return and nicehash payout is in fact more
in return i have switched back to nicehash
i tested that some time before and at that time dgb-qubit was the culprit: it displayed incorrect estimates which where far off and thus the miner often switched to it for some time and then back to "stable" coins, might be something else additionally as well, all i can tell is that the profit is off by much (tested for 48 hrs)
It's because digibyte's difficulty value goes up and down toooooo frequently. Here you can see difficulty history from Blocks page. https://digibyte-qubit.miningpoolhub.com/index.php?page=statistics&action=blocksIt goes up around 463 and crashes to 147 for last 30 minutes which means profitability goes up like x3 for very short period of time. It doesn't mean that you earn less always. You would earn much more sometimes but much less sometimes. well, the profit is almost half of the displayed expected, thats all i can tell |
|
|
|
Kommen die Baikal Miner auch an? Also werden diese verschickt? Gibt´s die wirklich?
das würde ich auch gern wissen! wenn nämlich jemand nur btc und dash als zahlung akzeptiert, hat das halt leider noch immer einen Beigeschmack.
ja - wie bereits geschrieben - sie existieren, werden verschickt und kommen auch an   Und weiß jemand ob die Miner auch vorrätig sind?
aktuell nicht, aber bald wieder (ca ein monat) ich selbst hatte ein paar minis über kleinanzeigen verkauft, habe jetzt allerdings auch keine mehr |
|
|
|
I just saved my 0,01*zillion by not falling for this scam -,- 2547 BTC recieved my 'scam miners' in 280 days - so lol! That pic!  notice how the db field for the btc paid is incremented every now and then but the time is not (its always 280 days since launch) i have thought about creating a similar site, just to see if people really fall for it, or the people posting are just the devs behind it |
|
|
|
I might have figured out the problem
I kept the modular PSU cable on the PCIe riser that came from the PSU in my main computer. Although it fits on the PSU in the other computer where it burned the PCIe slot, I notice that this molex power cord and the one that came from the bag to that PSU have a different metal prong missing in the PSU end of the plug.
Yeah that can happen. I now try to have only evga p2 psus I all my gear. not meant to hijack, do you think the p2 series (750W or higher) can power a 7990 (2x8pin) with two separate pcie cables without frying the cable at some point? |
|
|
|
|
@claymore: can you decrease the wait time when reboot.bat is executed so the miner closes faster? (with cmd option -r 1)
right now i have some kind of problem where the miner hangs in opencl calls and reboot.bat is tried to be executed (the miner shall only exit, no reboot.bat present), but after the execution of reboot.bat the miner doesnt exit but sits there for like 20-30 secs or something and only then exits
would be great if you could reduce that time down to some 1-2 secs
|
|
|
|
ich habe 4 giants im einsatz, bisher keine probleme und auch wesentlich leiser als antminer  |
|
|
|
|
The DGB-qubit issue seems to still persist?
over the last few weeks i tested mph in comparison to nicehash with baikal miners, mph is more profitable on the paper 99% of the time, but the real payout in btc is by far less than the expected return and nicehash payout is in fact more
in return i have switched back to nicehash
i tested that some time before and at that time dgb-qubit was the culprit: it displayed incorrect estimates which where far off and thus the miner often switched to it for some time and then back to "stable" coins, might be something else additionally as well, all i can tell is that the profit is off by much (tested for 48 hrs)
|
|
|
|
haha i hope they dont open up new miners to buy for a long time as i dont intend to buy more till it gets colder (aka 5 months) and more miners means less profit |
|
|
|
I've got a very strange problem on one of my machines: EthDcrMiner seems to lock up of some kind and the process cant be killed via taskmanager (access denied) seems to happen sometimes when killing it to start another miner with higher profitability, as a result i now have 6 instances of the miner running which cant be killed, and any new ones started dont start mining and lockup as well:  i have not seen this happening with other miners, will monitor with eth miner disabled - im using eth only mode - i have set 16GB of virtual ram - im using 2x 290 with a single instance per gpu - im using win8.1 x64 - im using amd drivers 16.12.2 anyboy knows why that might be? |
|
|
|
if possible use a good brand/quality of psu & pcie if & when possible. from what i see, you are using a single pcie cable with the split at the end (6 + (6+2) 8 pin) to power a power hungry gpu & that could be the main reason it started to melt. try to use individual cables. i disagree on the plugging & unplugging of 30 times shortens or have any impact on pcie cables, agree on the poorer quality ones but if well taken care & checked properly before each use, it should last much longer than that. another good way/tip to check on your cables is to make sure they get some sort of airflow over them, normally the yellow cable +12v would start to turn yellowish & thats a good indication to STOP using that cable or do something about it. the area of the yellowish part is normally harder to twist and bend, it becomes hard & if you have some tools & have no other choice, you can snip away that part & re-pin them with a new pcie plastic housing. always check on your cables if you are in doubt, visually & physically such as the temp on the cables if they're too hot to touch. happy mining & always be safe indeed id prefer single cables but most psu come with split ones sadly (the cx 750 is an exception here) from the screens available this one seems to have single cables: Zalman EBT Series ZM1200-EBT anybody used it / is it good quality? another option would be dual psu with add2psu, but id need to check availability in my country |
|
|
|
|
i have noticed some other connector also got pretty hot it seems (yellow turned brown-ish a bit, but not melted yet) and my supplier offers partly refunds (80%) on the RMA so ill just buy a new (different) one
it should be able to handle about 4 x 7970
my current config is: 7870(6+6pin) + 280x(8+6pin) + 7990(8+8pin)
in another system i have a FSP Fortron/Source Aurum Pro 1200W working fine, but im looking for alternatives as well (it was the cheapest 1200W with 8x 8pin psu)
suggestions?
edit: another option would be: Seasonic Prime Gold 1200W
|
|
|
|
as the connector on the PSU got burned and it has warranty ill just RMA it, thanks though, might come in handy for others without warranty cheers as reference the burned connector, gpu side is fine:  |
|
|
|
It has nothing to do with the amount of power the GPU uses because the 280x has usually 1x6 pin + 1x8pin connector, so 6 +12V wires.
This usually happens because the female end of the modular PSU keeps getting looser and looser everytime you plug it in and out. Either that or you had the wire hanging at an angle and it wasn't in horizontally but was tilted at an angle and caused a bad connection.
This is why I hate modular PSUs and usually love PSUs like the Corsair CX750 however most 1000Watt > PSUs are modular.
This is very common and if you search it happens to people with $500 Platinum PSUs who never mined in their life they were just gamers.
hmm, no angles at the psu side (where it broke), only at the gpu side i also own a cx750, so far it has been working great  |
|
|
|
taken from "Optiminer -h": USAGE:
Optiminer.exe [--pci-mode <0-3>] [--benchmark <seconds>]
[--list-devices] [--force-generic-kernel]
[--experimental-kernel] [--nodevfee] [-i <number>] ...
[-m <port>] [--watchdog-cmd <command>]
[--watchdog-timeout <seconds>] [--max-log-files <count>]
[--max-log-file-size <bytes>] [-l <filename>] [-v] [-p
<string>] [-u <string>] [-s <host:port>] [-d <integer>]
... [-c <integer>] [--] [--version] [-h]
Where:
--pci-mode <0-3>
Communicate mode between host and GPU. Valid values are 0-3.
--benchmark <seconds>
If specified runs a benchmark for the given number of seconds on all
specified devices and then exists the miner.
--list-devices
List all recognized devices with their platform and device id and
quit.
--force-generic-kernel
Force use of generic kernel even when a device-specific kernel is
available
--experimental-kernel
Unlock faster experimental kernel for certain graphic cards.
--nodevfee
If set, the dev fee will be disabled. Miner will run a bit slower.
Enable this if you do not want any more improvements of the miner and
want to earn less.
-i <number>, --intensity <number> (accepted multiple times)
Worker intensity. 0 means auto-detect based on available memory.
Higher values use more GPU memory. Can be specified once applying the
same intensity to all devices or once per device (same order as -d).
-m <port>, --monitoring-port <port>
The monitoring port to listen on for HTTP requests. Disabled by
default. If enabled, accepts requests from everywhere.
--watchdog-cmd <command>
The watchdog command to execute. See --watchdog-timeout.
--watchdog-timeout <seconds>
Timeout after which the watchdog triggers if a GPU does not produce
any solutions. It will execute the command specified by
--watchdog-cmd. You can use this command to do an appropriate action
(e.g. reset driver or reboot). 0 disables watchdog.
--max-log-files <count>
Maximum number of rotated log files to keep.
--max-log-file-size <bytes>
Maximum size of log file before it gets rotated.
-l <filename>, --log-file <filename>
Write logs to given file
-v, --verbose
Verbose logging.
-p <string>, --password <string>
Stratum password.
-u <string>, --user <string>
Stratum user.
-s <host:port>, --stratum <host:port>
Host and port of the stratum server to use.
-d <integer>, --device <integer> (accepted multiple times)
A OpenCL device id to use. If no devices are specified, all are used.
-c <integer>, --platform <integer>
The OpenCL platform id to use.
--, --ignore_rest
Ignores the rest of the labeled arguments following this flag.
--version
Displays version information and exits.
-h, --help
Displays usage information and exits.
(C) by Optiminer 2017
|
|
|
|
|
Show Posts
