Meanwhile back in BFL land ...
I realised there was a rather important command missing - how do you get the temperature?
If it has no built in protection (unlike a GPU) then you'd want to monitor the temp and lower the intensity (well increase the inactivity) if it's getting too hot.
Some people live in hot places (e.g. Perth Australia - not me though) and well sometimes the ambient temperature may already be 40 degrees so the devices could possibly get hot and kill themselves - knowing about that before it dies would be good also.
(I guess I could add 'how do you get the fan speed' but these I think will use your standard fans without any regulation so they'll just run 100% 24/7 until they die)
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 702. (Read 5805728 times)
January 15, 2012, 09:57:47 PM
legendary
Activity: 1862
Merit: 1011
Reverse engineer from time to time
January 15, 2012, 05:40:13 PM
Can't be Satoshi... I haven't mysteriously disappeared 
But you mysteriously appeared 
January 15, 2012, 05:37:15 PM
Can't be Satoshi... I haven't mysteriously disappeared
January 15, 2012, 05:12:26 PM
You ever written any software?
I'm an anaesthetist like ckolivas.
Who are you?
Zelda Skyward Sword master (well he beat me to the finish 
) January 15, 2012, 05:06:08 PM
You ever written any software?
I'm an anaesthetist like ckolivas.
You've written a linux kernel scheduler, great compression code, cgminer among I don't know what else
So I guess his answer to my question means "Yes"?
I'm not sure.
legendary
Activity: 1862
Merit: 1011
Reverse engineer from time to time
January 15, 2012, 05:03:45 PM
You ever written any software?
I'm an anaesthetist like ckolivas.
Who are you?
January 15, 2012, 04:58:30 PM
You ever written any software?
I'm an anaesthetist like ckolivas.
January 15, 2012, 04:51:21 PM
It doesnt really matter. From the UUAFAQ(*)
Q: Why is my efficiency above/below 100%?
A: Efficiency simply means how many shares you return for the amount of work
you request. It does not correlate with efficient use of your hardware, and is
a measure of a combination of hardware speed, block luck, pool design and other
factors.
*Usually Unread Answers to frequently asked questions.
I can tell you how to gain 3-4% mining efficiency though; switch pools!
Q: Why is my efficiency above/below 100%?
A: Efficiency simply means how many shares you return for the amount of work
you request. It does not correlate with efficient use of your hardware, and is
a measure of a combination of hardware speed, block luck, pool design and other
factors.
*Usually Unread Answers to frequently asked questions.
I can tell you how to gain 3-4% mining efficiency though; switch pools!
Ya try slush the thief
I suggest use another miner
I switched to ufasoft and got much better hash rate for a few more stales/rejects
legendary
Activity: 1862
Merit: 1011
Reverse engineer from time to time
January 15, 2012, 04:47:34 PM
Another way to increase efficiency is for you to roll the work a bit. Deepbit is a big pool, I don't understand how it doesn't support x-rollntime.
My efficiency for an example is 150% or so.
My efficiency for an example is 150% or so.
January 15, 2012, 04:45:10 PM
It doesnt really matter. From the UUAFAQ(*)
Q: Why is my efficiency above/below 100%?
A: Efficiency simply means how many shares you return for the amount of work
you request. It does not correlate with efficient use of your hardware, and is
a measure of a combination of hardware speed, block luck, pool design and other
factors.
*Usually Unread Answers to frequently asked questions.
I can tell you how to gain 3-4% mining efficiency though; switch pools!
Q: Why is my efficiency above/below 100%?
A: Efficiency simply means how many shares you return for the amount of work
you request. It does not correlate with efficient use of your hardware, and is
a measure of a combination of hardware speed, block luck, pool design and other
factors.
*Usually Unread Answers to frequently asked questions.
I can tell you how to gain 3-4% mining efficiency though; switch pools!
January 15, 2012, 04:39:20 PM
My Effiency rating on CGminer is really low... I assume that it's a bad thing... What can i do to increse my effeciency?, Here is a sample of me mining overnight...
23% effiency in my head means that i COULD be running 60%better than what i am (in one form or another, Such as latency or ping. LOL no i dont think i can Hash 60%faster)
Code:
cgminer version 2.1.2 - Started: [2012-01-15 02:24:44]
--------------------------------------------------------------------------------
(5s):626.7 (avg):628.0 Mh/s | Q:25863 A:5880 R:7 HW:0 E:23% U:8.76/m
TQ: 1 ST: 60 SS: 0 DW: 13941 NB: 59 LW: 0 GF: 5 RF: 2
Connected to http://pit.deepbit.net:8332 with LP as user **************
Block: 00000895f065faa4d888a41726628c7f... Started: [13:12:11]
--------------------------------------------------------------------------------
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
GPU 0: 82.0C 95% | 313.0/313.9Mh/s | A:2933 R:4 HW:0 U: 4.37/m I: 3
GPU 1: 78.0C 91% | 314.1/314.1Mh/s | A:2947 R:3 HW:0 U: 4.39/m I: 3
--------------------------------------------------------------------------------
[2012-01-15 13:35:11] Accepted 00000000.9d469bde.e003ba74 GPU 1 thread 1
[2012-01-15 13:35:13] Accepted 00000000.5ac6a84b.4a1bb2e6 GPU 1 thread 3
[2012-01-15 13:35:17] Accepted 00000000.65d13bac.c8c04c01 GPU 1 thread 3
[2012-01-15 13:35:21] Accepted 00000000.97673eae.068efc3a GPU 0 thread 0
[2012-01-15 13:35:22] Accepted 00000000.0e7fcef9.8c00532d GPU 0 thread 2
[2012-01-15 13:35:25] Accepted 00000000.cf02dc7f.854de865 GPU 1 thread 3
[2012-01-15 13:35:26] Accepted 00000000.9aaca65e.45eb5ace GPU 1 thread 1
[2012-01-15 13:35:35] Accepted 00000000.ea3a40bb.2f126e1c GPU 0 thread 2
[2012-01-15 13:35:36] Accepted 00000000.3bec37cc.8e9e1479 GPU 0 thread 0
[2012-01-15 13:35:41] Accepted 00000000.7680de5d.5f6e366f GPU 1 thread 3
[2012-01-15 13:35:43] Accepted 00000000.4c4b0a97.52b5924e GPU 0 thread 0
[2012-01-15 13:35:50] Accepted 00000000.f3211e51.2fb7fe1e GPU 0 thread 2
23% effiency in my head means that i COULD be running 60%better than what i am (in one form or another, Such as latency or ping. LOL no i dont think i can Hash 60%faster)
January 15, 2012, 04:36:22 PM
You ever written any software?
I'm an anaesthetist like ckolivas.
January 15, 2012, 04:33:26 PM
Hmm more BFL questions:
Is there a nonce range? And an abort code?
These things will supposedly hash at something like 800Mh/s
So a job will take 5.37 seconds (if there is no nonce range control)
If you get an LP (and there is no nonce range control) you will have to wait for (and waste) on average 2.68 seconds (on average 0.45% per block) per LP per device before you can get it to start producing valid work for the next block.
So I guess there must be either some nonce range control or a job abort code?
But it wasn't mentioned in the post at all.
Is there a nonce range? And an abort code?
These things will supposedly hash at something like 800Mh/s
So a job will take 5.37 seconds (if there is no nonce range control)
If you get an LP (and there is no nonce range control) you will have to wait for (and waste) on average 2.68 seconds (on average 0.45% per block) per LP per device before you can get it to start producing valid work for the next block.
So I guess there must be either some nonce range control or a job abort code?
But it wasn't mentioned in the post at all.
Not quite, kano. If an LP comes in while the device is already processing a job, the mining software simply needs to issue a NEW job to the device; this will abort the current job and processing will start on the new job immediately. It says right in the original post:
* BUSY
(Device is busy processing a block. You can still issue a job, but the previous process will be
discarded and new process will start)
(Device is busy processing a block. You can still issue a job, but the previous process will be
discarded and new process will start)
However, nonce ranges relate to intensity and if that is still missing, it will have lost a rather important tunable item in cgminer (but of course it may or may not make any difference on an FPGA how long it processes vs the breaks between work requests)
Quote
How efficient mining will be will depend mostly on the mining software, not the BFL box.
Really?Quote
That being said, with ufasoft and diablo already supporting BFL, it will be interesting to see who has the better implementation. CGMiner has a chance to be better, but it can also drop the ball. Depends how clever the respective code authors have been / will be.
LOL that's funny - rush in try and get there first - you will certainly have the best code and the best results that way ... or NOT.IF these things ever arrive (that is still somewhat questionable) the best miner program will be the one that is well designed, tested and implemented ... AFTER the BFL people have fixed their problems also.
Rushing in and trying to be first before the final product even exists will usually result in being the WORST.
You ever written any software?
January 15, 2012, 04:16:52 PM
The ones who are complaining, are you programmers?
No, I'm an anaesthetist.Perhaps a poor choice of words on my part. Apologies.
I am still a forum noob here, and that is quite apparent at times. 
Still, a polling interface isn't necessarily synonymous with 'poor design choice'.
Just out of curiosity, are you deliberately trying to distract from the points raised since you have no answer and don't want people to notice?
In any case, no answer at all may be better than a cryptic non-answer...
And to counter your attempt at an answer:
In many situations a polling interface is a 'poor design choice'.
If you want to go another round at meaningless word-fencing, could you do that in another thread, please? No need to pollute this one...
January 15, 2012, 04:07:23 PM
The ones who are complaining, are you programmers?
No, I'm an anaesthetist.Perhaps a poor choice of words on my part. Apologies.
I am still a forum noob here, and that is quite apparent at times. Still, a polling interface isn't necessarily synonymous with 'poor design choice'.
January 15, 2012, 04:04:44 PM
The ones who are complaining, are you programmers?
No, I'm an anaesthetist. January 15, 2012, 04:00:19 PM
Hmm more BFL questions:
Is there a nonce range? And an abort code?
These things will supposedly hash at something like 800Mh/s
So a job will take 5.37 seconds (if there is no nonce range control)
If you get an LP (and there is no nonce range control) you will have to wait for (and waste) on average 2.68 seconds (on average 0.45% per block) per LP per device before you can get it to start producing valid work for the next block.
So I guess there must be either some nonce range control or a job abort code?
But it wasn't mentioned in the post at all.
Is there a nonce range? And an abort code?
These things will supposedly hash at something like 800Mh/s
So a job will take 5.37 seconds (if there is no nonce range control)
If you get an LP (and there is no nonce range control) you will have to wait for (and waste) on average 2.68 seconds (on average 0.45% per block) per LP per device before you can get it to start producing valid work for the next block.
So I guess there must be either some nonce range control or a job abort code?
But it wasn't mentioned in the post at all.
Not quite, kano. If an LP comes in while the device is already processing a job, the mining software simply needs to issue a NEW job to the device; this will abort the current job and processing will start on the new job immediately. It says right in the original post:
* BUSY
(Device is busy processing a block. You can still issue a job, but the previous process will be
discarded and new process will start)
(Device is busy processing a block. You can still issue a job, but the previous process will be
discarded and new process will start)
How efficient mining will be will depend mostly on the mining software, not the BFL box. That being said, with ufasoft and diablo already supporting BFL, it will be interesting to see who has the better implementation. CGMiner has a chance to be better, but it can also drop the ball. Depends how clever the respective code authors have been / will be.
Take the polling issue which many of you seem to take issue with. The ones who are complaining, are you programmers? Sure, polling may not seem elegant/efficient, but it really depends on the miner software implementation. If I had 10 devices to poll, I wouldn't code it in a single thread polling each device serially one after another ... that would be silly. Instead, spawn a separate polling thread for each device. That way polling is done 'in parallel' (so to speak) and whether you have 1 device or 10 or 100 doesn't much matter.
January 15, 2012, 03:58:15 PM
FWIW, if you mine in a KVM and your GPU crashes, this will recover without a (real) reboot (obviously you will need to adapt it for your setup a bit):
killall -9 qemu-system-x86_64
echo 1 > /sys/bus/pci/drivers/pci-stub/0000:01:00.0/remove # this is the Radeon's HDMI audio on my system
echo 1 > /sys/bus/pci/drivers/pci-stub/0000:01:00.1/remove # the GPU
echo mem > /sys/power/state # this will put your computer to sleep! don't do remotely
# YOU NEED TO ACTUALLY WAIT 10 SECONDS HERE, to power the card down COMPLETELY
# AFTER PRESSING YOUR POWER BUTTON TO GET THE SYSTEM RUNNING AGAIN
echo 1 > /sys/bus/pci/rescan
# now just start KVM like you usually do
killall -9 qemu-system-x86_64
echo 1 > /sys/bus/pci/drivers/pci-stub/0000:01:00.0/remove # this is the Radeon's HDMI audio on my system
echo 1 > /sys/bus/pci/drivers/pci-stub/0000:01:00.1/remove # the GPU
echo mem > /sys/power/state # this will put your computer to sleep! don't do remotely
# YOU NEED TO ACTUALLY WAIT 10 SECONDS HERE, to power the card down COMPLETELY
# AFTER PRESSING YOUR POWER BUTTON TO GET THE SYSTEM RUNNING AGAIN
echo 1 > /sys/bus/pci/rescan
# now just start KVM like you usually do
January 15, 2012, 03:52:57 PM
January 15, 2012, 03:36:39 PM
Hmm more BFL questions:
Is there a nonce range? And an abort code?
These things will supposedly hash at something like 800Mh/s
So a job will take 5.37 seconds (if there is no nonce range control)
If you get an LP (and there is no nonce range control) you will have to wait for (and waste) on average 2.68 seconds (on average 0.45% per block) per LP per device before you can get it to start producing valid work for the next block.
So I guess there must be either some nonce range control or a job abort code?
But it wasn't mentioned in the post at all.
Is there a nonce range? And an abort code?
These things will supposedly hash at something like 800Mh/s
So a job will take 5.37 seconds (if there is no nonce range control)
If you get an LP (and there is no nonce range control) you will have to wait for (and waste) on average 2.68 seconds (on average 0.45% per block) per LP per device before you can get it to start producing valid work for the next block.
So I guess there must be either some nonce range control or a job abort code?
But it wasn't mentioned in the post at all.
Jump to: