Ohh by the way
What is the temperature on that board (nr 4)?
Check the other values and see so there isnt any strange things that can lead you in any direction...
In 10 hours i am in front of my machine again and can compare numbers...
// U
Topic: 1 TH/s-miner with only 16 GH/s (Read 3466 times)
Okidoki
I had some problems the first start and when i changed IP-adress.
Sometimes Asic 4 is not showing up for me, but perfoming a coldstart normally fix it.
You can also check the lights on each asic blade, there is around 10 green leds in a row and they should be green. If some of them are red that means that some chips are offline because of a failure. It could happen when power is to low or something else spoky :-)
Just restart the machine and hopefully all go green.
I have this problem on another miner, sometimes i need 3-4 restart until its all green.
If the problem persist it could be a fault in the machine and you need to get it fixed.
// U
I had some problems the first start and when i changed IP-adress.
Sometimes Asic 4 is not showing up for me, but perfoming a coldstart normally fix it.
You can also check the lights on each asic blade, there is around 10 green leds in a row and they should be green. If some of them are red that means that some chips are offline because of a failure. It could happen when power is to low or something else spoky :-)
Just restart the machine and hopefully all go green.
I have this problem on another miner, sometimes i need 3-4 restart until its all green.
If the problem persist it could be a fault in the machine and you need to get it fixed.
// U
Hi,
I fixed this error on my machine.
I have found out that you should never use 1024 on the machine side.
Normally CGMINER and pool communicates about best difficulty, and to start at highest level is a very bad idea from machine side.
Set the machine to 256 (default) and the it works flawlessly.
If you wanna raise difficulty set the minimum diff in the pool. The parameters is called "minimum difficulty" and the difficulty starts at the value you choose. If yu choose 16 it will very soon automaticly raise.
In my 1 Th machines i use 1024 "minimum diff" and in my 200 Gh machines i use 512 or 256.
It doesnt effect the hashpower that much but the 1 Th machines works more stable with 1024 and it also minimize network traffic.
So problem solved :-)
// Urbie
I fixed this error on my machine.
I have found out that you should never use 1024 on the machine side.
Normally CGMINER and pool communicates about best difficulty, and to start at highest level is a very bad idea from machine side.
Set the machine to 256 (default) and the it works flawlessly.
If you wanna raise difficulty set the minimum diff in the pool. The parameters is called "minimum difficulty" and the difficulty starts at the value you choose. If yu choose 16 it will very soon automaticly raise.
In my 1 Th machines i use 1024 "minimum diff" and in my 200 Gh machines i use 512 or 256.
It doesnt effect the hashpower that much but the 1 Th machines works more stable with 1024 and it also minimize network traffic.
So problem solved :-)
// Urbie
Hi Urbie. Thanks for the advise. I tried what you said, but alas still having troubles with my machine.
You can see in the pic, error rate on module #4 is very high, and therefor the speed is only 700-800 GH/s. Speed on module #4 is obviously wrong.
https://i.imgur.com/s6fcfrv.jpg
Also I have a customer with another machine where the module #4 is not showing up at all, so he's only getting 650-750 GH/s.
https://i.imgur.com/ANd0gue.jpg
Any thoughts?
Hi,
I fixed this error on my machine.
I have found out that you should never use 1024 on the machine side.
Normally CGMINER and pool communicates about best difficulty, and to start at highest level is a very bad idea from machine side.
Set the machine to 256 (default) and the it works flawlessly.
If you wanna raise difficulty set the minimum diff in the pool. The parameters is called "minimum difficulty" and the difficulty starts at the value you choose. If yu choose 16 it will very soon automaticly raise.
In my 1 Th machines i use 1024 "minimum diff" and in my 200 Gh machines i use 512 or 256.
It doesnt effect the hashpower that much but the 1 Th machines works more stable with 1024 and it also minimize network traffic.
So problem solved :-)
// Urbie
I fixed this error on my machine.
I have found out that you should never use 1024 on the machine side.
Normally CGMINER and pool communicates about best difficulty, and to start at highest level is a very bad idea from machine side.
Set the machine to 256 (default) and the it works flawlessly.
If you wanna raise difficulty set the minimum diff in the pool. The parameters is called "minimum difficulty" and the difficulty starts at the value you choose. If yu choose 16 it will very soon automaticly raise.
In my 1 Th machines i use 1024 "minimum diff" and in my 200 Gh machines i use 512 or 256.
It doesnt effect the hashpower that much but the 1 Th machines works more stable with 1024 and it also minimize network traffic.
So problem solved :-)
// Urbie
Could you have gotten one of these: http://bitmine.ch/?p=5178
Nope. I've ordered with Bitmine (yeah, beat me), so I would recognize them :-)
Hello. Any luck with this? One of these machines I ordered is showing only 600-700 GH/s on BTCGuild dashboard. The machine itself thinks its doing 936 GH/s. I have the minimum difficulty on BTCGuild and the machine set to 1024. Thanks for any help or pointers.
I think its honestly just a compatibility issue with the getwork software poolside.
The miner is showing actual hashrate clientside and then share hashrate poolside and its submitting shares at a rate of 16gh aka 1.06% share submission rate(99% stales/rejects). My guess...
getwork has nothing to do with modern mining. It's almost certainly just a minimum share diff in their broken driver implementation, as discussed before. The miner is showing actual hashrate clientside and then share hashrate poolside and its submitting shares at a rate of 16gh aka 1.06% share submission rate(99% stales/rejects). My guess...
I have this machine and it is getting 1.05 terrhash per second no problem. I used btc guild at difficulty 1024. No problems.
My guess is that lower difficulty settings result in so many hits that it cannot communicate them fast enough. At 1024 I am getting a hit every few seconds. It may also be optimized for that difficulty.
Thanks to the guy who told me the ssh username and password!
My guess is that lower difficulty settings result in so many hits that it cannot communicate them fast enough. At 1024 I am getting a hit every few seconds. It may also be optimized for that difficulty.
Thanks to the guy who told me the ssh username and password!
I think its honestly just a compatibility issue with the getwork software poolside.
The miner is showing actual hashrate clientside and then share hashrate poolside and its submitting shares at a rate of 16gh aka 1.06% share submission rate(99% stales/rejects). My guess...
The miner is showing actual hashrate clientside and then share hashrate poolside and its submitting shares at a rate of 16gh aka 1.06% share submission rate(99% stales/rejects). My guess...
I think the saler cheat you
You should return it
You should return it
That's sound like a true ! I guess that company would like to get money despite everything
I think the saler cheat you
You should return it
You should return it
Could you have gotten one of these: http://bitmine.ch/?p=5178
Nope. I've ordered with Bitmine (yeah, beat me), so I would recognize them :-)
Could you have gotten one of these: http://bitmine.ch/?p=5178
It may be a problem with the machines ability to handle low difficulties, causing it to basically create a backlog it can't escape from. Have you tried setting your difficulty to 1024 on another pool? You're going to be running at 512-1024 diff no matter what, standard variable difficulty on all pools is going to put you in that range if your machine is functioning properly.
Yeah it may have internal firmware diff mining and if it is mining at 1k diff (i.e. only returning nonces at 1k diff) while the pool is asking for 10diff, it will effectively be returning only 1/100 of the nonces the pool wants and this would make it appear 100 times slower than it is. 
That is weird.
Have you tried a packet sniffer to see if it is mining somewhere else as well?
I have heard complaints of some of the miners that are run with Pi's using a small amount of mining power to mine to a different pool with out showing up.
I wonder if that is going on here but it malfunctioned and instead is mining mostly to the hidden setup.
See:
https://www.gnu.org/copyleft/gpl.html
Interesting for me is the fact that there is a lot of references to bitmine in the history. For example here in the history of user "pi":
173 gvim bitmine.h
392 cd cgminer-bitmine-A1-scratchpad/
395 cd cgminer-bitmine-A1-scratchpad/
398 cd cgminer-bitmine-A1-scratchpad/
399 gvim driver-SPI-bitmine-A1.c
402 cd lichen/cgminer-bitmine-A1-scratchpad/
404 cd lichen/cgminer-bitmine-A1-scratchpad/
406 cd lichen/cgminer-bitmine-A1-scratchpad/
408 cd lichen/cgminer-bitmine-A1-scratchpad/
445 cd lichen/old/cgminer-bitmine-A1-scratchpad/
447 cd lichen/old/cgminer-bitmine-A1-scratchpad/
454 cd lichen/old/cgminer-bitmine-A1-scratchpad/
457 cd lichen/old/cgminer-bitmine-A1-scratchpad/
460 cd lichen/old/cgminer-bitmine-A1-scratchpad/
464 gvim ./lichen/old/cgminer-bitmine-A1-scratchpad/driver-SPI-bitmine-A1.c
466 gvim ./lichen/old/cgminer-bitmine-A1-scratchpad/run.sh
469 cd lichen/old/cgminer-bitmine-A1-scratchpad/
474 cd lichen/old/cgminer-bitmine-A1-scratchpad/
480 cd lichen/old/cgminer-bitmine-A1-scratchpad/
487 cd lichen/old/cgminer-bitmine-A1-scratchpad/
488 gvim driver-SPI-bitmine-A1.c
495 cd lichen/old/cgminer-bitmine-A1-scratchpad/
509 cd lichen/old/cgminer-bitmine-A1-scratchpad/
519 gvim /home/pi/lichen/old/cgminer-bitmine-A1-scratchpad/run.sh
520 /home/pi/lichen/old/cgminer-bitmine-A1-scratchpad/run.sh &
521 sudo /home/pi/lichen/old/cgminer-bitmine-A1-scratchpad/run.sh &
523 cd lichen/old/cgminer-bitmine-A1-scratchpad/
548 cd /home/pi/lichen/old/cgminer-bitmine-A1-scratchpad
550 cd lichen/old/cgminer-bitmine-A1-scratchpad/
562 cd lichen/old/cgminer-bitmine-A1-scratchpad/
637 cd lichen/old/cgminer-bitmine-A1-scratchpad/
Now given the fact that Bitmine in Switzerland can't deliver, but here obviously some software from Bitmine pops up in a Chinese machine which is sold from a Swiss company, I guess I'll use some forensic tools to examine this issue further...
Have you tried a packet sniffer to see if it is mining somewhere else as well?
I have heard complaints of some of the miners that are run with Pi's using a small amount of mining power to mine to a different pool with out showing up.
I wonder if that is going on here but it malfunctioned and instead is mining mostly to the hidden setup.
It seems as if they have produced their own little hacks for running cgminer....
Since cgminer is released under a free license that insists all code modifications distributed in binary form must be available on request, since you have received a cgminer binary that is modified from the original, you can ask them for the source code to their modifications and they will be obliged to provide their source modifications within 30 days or they will be in violation of the license agreement and not be allowed to further distribute their binaries or be up for legal action.See:
https://www.gnu.org/copyleft/gpl.html
Interesting for me is the fact that there is a lot of references to bitmine in the history. For example here in the history of user "pi":
173 gvim bitmine.h
392 cd cgminer-bitmine-A1-scratchpad/
395 cd cgminer-bitmine-A1-scratchpad/
398 cd cgminer-bitmine-A1-scratchpad/
399 gvim driver-SPI-bitmine-A1.c
402 cd lichen/cgminer-bitmine-A1-scratchpad/
404 cd lichen/cgminer-bitmine-A1-scratchpad/
406 cd lichen/cgminer-bitmine-A1-scratchpad/
408 cd lichen/cgminer-bitmine-A1-scratchpad/
445 cd lichen/old/cgminer-bitmine-A1-scratchpad/
447 cd lichen/old/cgminer-bitmine-A1-scratchpad/
454 cd lichen/old/cgminer-bitmine-A1-scratchpad/
457 cd lichen/old/cgminer-bitmine-A1-scratchpad/
460 cd lichen/old/cgminer-bitmine-A1-scratchpad/
464 gvim ./lichen/old/cgminer-bitmine-A1-scratchpad/driver-SPI-bitmine-A1.c
466 gvim ./lichen/old/cgminer-bitmine-A1-scratchpad/run.sh
469 cd lichen/old/cgminer-bitmine-A1-scratchpad/
474 cd lichen/old/cgminer-bitmine-A1-scratchpad/
480 cd lichen/old/cgminer-bitmine-A1-scratchpad/
487 cd lichen/old/cgminer-bitmine-A1-scratchpad/
488 gvim driver-SPI-bitmine-A1.c
495 cd lichen/old/cgminer-bitmine-A1-scratchpad/
509 cd lichen/old/cgminer-bitmine-A1-scratchpad/
519 gvim /home/pi/lichen/old/cgminer-bitmine-A1-scratchpad/run.sh
520 /home/pi/lichen/old/cgminer-bitmine-A1-scratchpad/run.sh &
521 sudo /home/pi/lichen/old/cgminer-bitmine-A1-scratchpad/run.sh &
523 cd lichen/old/cgminer-bitmine-A1-scratchpad/
548 cd /home/pi/lichen/old/cgminer-bitmine-A1-scratchpad
550 cd lichen/old/cgminer-bitmine-A1-scratchpad/
562 cd lichen/old/cgminer-bitmine-A1-scratchpad/
637 cd lichen/old/cgminer-bitmine-A1-scratchpad/
Now given the fact that Bitmine in Switzerland can't deliver, but here obviously some software from Bitmine pops up in a Chinese machine which is sold from a Swiss company, I guess I'll use some forensic tools to examine this issue further...
why wouldnt the company tell you about this before figuring it your self tho?
It may be a problem with the machines ability to handle low difficulties, causing it to basically create a backlog it can't escape from. Have you tried setting your difficulty to 1024 on another pool? You're going to be running at 512-1024 diff no matter what, standard variable difficulty on all pools is going to put you in that range if your machine is functioning properly.
Well it shouldn't be hard to see where the device is actually mining.
A tcpdump on the network should show where packets are going to and coming from.
More so, if you start the log when it is first powered on, it should show all pools and accounts it is connecting to.
A tcpdump on the network should show where packets are going to and coming from.
More so, if you start the log when it is first powered on, it should show all pools and accounts it is connecting to.
Or Wireshark for people who like GUI.
tststststs... as an old bash-er, I do not like GUIs :-)
Well it shouldn't be hard to see where the device is actually mining.
A tcpdump on the network should show where packets are going to and coming from.
More so, if you start the log when it is first powered on, it should show all pools and accounts it is connecting to.
A tcpdump on the network should show where packets are going to and coming from.
More so, if you start the log when it is first powered on, it should show all pools and accounts it is connecting to.
Or Wireshark for people who like GUI.
..
In the display and also in webinterface all looks perfect. 1.02 Th and WU 12m somethings. Looks OK.
...
WU 12/m means 829MH/s ... so not what it should be.In the display and also in webinterface all looks perfect. 1.02 Th and WU 12m somethings. Looks OK.
...
for 1TH/s WU should be around 14000/m
A1 chips need a high diff or a pool that supports 0 diff (auto).
I run my Hex8A1 (8x A1 chips) on BitMinter and BTCGuild.
I've also thought the new Dragon miner (4 boards x 8 chips) may be running too low voltage which would result in high hardware errors/rejects.
I run my Hex8A1 (8x A1 chips) on BitMinter and BTCGuild.
I've also thought the new Dragon miner (4 boards x 8 chips) may be running too low voltage which would result in high hardware errors/rejects.
Jump to: