Hi,
I'm considering purchasing a custom mining rig that's made out of these BFL chips that are for sale as part of the following Group Buy listed at this URL: https://bitcointalksearch.org/topic/closed-bfl-4-ghs-chips-06-btc-per-chip-batch-29-236103
I'd like to know before I commit to buying it whether or not the device will work with bfgminer running in Windows.
Does anyone know who can tell me if it would work?
Thanks.
Topic: OLD: BFGMiner 3.10.0: modular ASIC+FPGA, GBT+Strtm, RPC, Mac/Lnx/W64, AntU1, DRB - page 115. (Read 1193219 times)
September 30, 2013, 01:08:52 PM
September 30, 2013, 12:46:12 PM
The thing is: it's not a specific port, but rather a random one, which will be different between bfgminer restarts.
Also I run bfgminer unattended in my Crypto Miners in Tray with -T command line arguments, so an automatic rescan of failed ports with some command-line defined delay/interval would be welcome.
I also tried removing all USB-COM port mappings (https://bitcointalksearch.org/topic/windows-many-usb-hubs-and-besfuries-clean-up-in-your-devices-manager-300638) and re-inserting the miners from scratch, allowing Windows to reinitialise all hubs and BEs.
In the meantime, I'll try uninstalling the UPS monitoring software and see if the problem goes away.
Also I run bfgminer unattended in my Crypto Miners in Tray with -T command line arguments, so an automatic rescan of failed ports with some command-line defined delay/interval would be welcome.
I also tried removing all USB-COM port mappings (https://bitcointalksearch.org/topic/windows-many-usb-hubs-and-besfuries-clean-up-in-your-devices-manager-300638) and re-inserting the miners from scratch, allowing Windows to reinitialise all hubs and BEs.
In the meantime, I'll try uninstalling the UPS monitoring software and see if the problem goes away.
September 30, 2013, 12:32:01 PM
My request: could you for ports that give that "privileges" error, make a retry at a later point. It seems that time-out for failure is too short or something...
You can always ask BFGMiner to rescan...But sounds like your UPS program has it locked.
September 30, 2013, 12:29:38 PM
Luke-jr, I have a problem with bfgminer on Windows 7 (both 32 and 64 bit builds), which appeared recently (possibly after I installed monitoring software for UPS units). It appeared on both machines, running about 60 BEs each.
The problem is that when bfgminer starts, I would get
where 'x' is some random port (it tends to be in the range 1-15, but will sometimes pick ports in the higher range).
The port will then light solid green and will not hash.
Restarting bfgminer will yield another "failed" port. Sometimes all ports will get recognised and will not light green, but then all miners will blink a little and one port will light solid green again. I have double-checked and have enough power for all miners. I also tried with a smaller subset.
My request: could you for ports that give that "privileges" error, make a retry at a later point. It seems that time-out for failure is too short or something...
if may be that that COMx is now reserved by windows for the UPS monitor. If you are running bfgminer as a user not administrator a -S all or -S COM(that x) will fail. you can try running bfgminer as admin but the will allow bfgminer to send a data string as part of it's scan over a reserved COM port (Might mess up UPS monitor) The problem is that when bfgminer starts, I would get
Code:
Do not have user privileges required to open \\.\COMx
where 'x' is some random port (it tends to be in the range 1-15, but will sometimes pick ports in the higher range).
The port will then light solid green and will not hash.
Restarting bfgminer will yield another "failed" port. Sometimes all ports will get recognised and will not light green, but then all miners will blink a little and one port will light solid green again. I have double-checked and have enough power for all miners. I also tried with a smaller subset.
My request: could you for ports that give that "privileges" error, make a retry at a later point. It seems that time-out for failure is too short or something...
September 30, 2013, 12:10:06 PM
Luke-jr, I have a problem with bfgminer on Windows 7 (both 32 and 64 bit builds), which appeared recently (possibly after I installed monitoring software for UPS units). It appeared on both machines, running about 60 BEs each.
The problem is that when bfgminer starts, I would get
where 'x' is some random port (it tends to be in the range 1-15, but will sometimes pick ports in the higher range).
The port will then light solid green and will not hash.
Restarting bfgminer will yield another "failed" port. Sometimes all ports will get recognised and will not light green, but then all miners will blink a little and one port will light solid green again. I have double-checked and have enough power for all miners. I also tried with a smaller subset.
My request: could you for ports that give that "privileges" error, make a retry at a later point. It seems that time-out for failure is too short or something...
The problem is that when bfgminer starts, I would get
Code:
Do not have user privileges required to open \\.\COMx
where 'x' is some random port (it tends to be in the range 1-15, but will sometimes pick ports in the higher range).
The port will then light solid green and will not hash.
Restarting bfgminer will yield another "failed" port. Sometimes all ports will get recognised and will not light green, but then all miners will blink a little and one port will light solid green again. I have double-checked and have enough power for all miners. I also tried with a smaller subset.
My request: could you for ports that give that "privileges" error, make a retry at a later point. It seems that time-out for failure is too short or something...
September 30, 2013, 02:59:41 AM
i runed it on opnwrt thanks
i want to see the detailS of process (speed hw etc)
how can i do
i want to see the detailS of process (speed hw etc)
how can i do
September 30, 2013, 02:50:42 AM
0 is highest.
September 30, 2013, 12:07:14 AM
on a side note regarding pool priorities. 0 is default and 1-? lower is higher or reverse?
September 29, 2013, 01:40:32 PM
What do you all think about changing the 2nd or 3rd hashrate to be based on nonces found adjusted by accepts/total shares?
Basically the idea is to get a "hashrate after hw errors and rejects" with better accuracy.
Basically the idea is to get a "hashrate after hw errors and rejects" with better accuracy.
So it would show "Instant", "Average", & "Pool + Error Corrected" ?
Go for it!!!!!!!!!!
1++
September 29, 2013, 10:16:38 AM
What do you all think about changing the 2nd or 3rd hashrate to be based on nonces found adjusted by accepts/total shares?
Basically the idea is to get a "hashrate after hw errors and rejects" with better accuracy.
Basically the idea is to get a "hashrate after hw errors and rejects" with better accuracy.
So it would show "Instant", "Average", & "Pool + Error Corrected" ?
Go for it!!!!!!!!!!
September 29, 2013, 09:13:41 AM
What do you all think about changing the 2nd or 3rd hashrate to be based on nonces found adjusted by accepts/total shares?
Basically the idea is to get a "hashrate after hw errors and rejects" with better accuracy.
Basically the idea is to get a "hashrate after hw errors and rejects" with better accuracy.
So it would show "Instant", "Average", & "Pool + Error Corrected" ?
September 29, 2013, 03:30:37 AM
Testing/comments please
"bfgminer" main branch ("3.2.90") now has stratum proxy support that could use some testing.
From my release notes draft: "Support for proxy virtual devices has been extended to include the stratum protocol when the upstream pool selected is also stratum and supplies sufficient extranonce2 space. If the upstream pool does not meet this criteria, stratum clients will be disconnected and new ones will fail to subscribe. You can take advantage of this to failover to the getwork proxy. Support for upstream getwork pools is impossble, but GBT is planned."
I've also put together a "rpc_fulldev" branch with some proposed RPC changes (removal of redundant "devdetail" method, and splitting processor-detail-level into new methods to make the original ones more cgminer-like). Testing and comments appreciated.
I'll be back to working on bitfury code tomorrow.
What do you all think about changing the 2nd or 3rd hashrate to be based on nonces found adjusted by accepts/total shares?
Basically the idea is to get a "hashrate after hw errors and rejects" with better accuracy.
"bfgminer" main branch ("3.2.90") now has stratum proxy support that could use some testing.
From my release notes draft: "Support for proxy virtual devices has been extended to include the stratum protocol when the upstream pool selected is also stratum and supplies sufficient extranonce2 space. If the upstream pool does not meet this criteria, stratum clients will be disconnected and new ones will fail to subscribe. You can take advantage of this to failover to the getwork proxy. Support for upstream getwork pools is impossble, but GBT is planned."
I've also put together a "rpc_fulldev" branch with some proposed RPC changes (removal of redundant "devdetail" method, and splitting processor-detail-level into new methods to make the original ones more cgminer-like). Testing and comments appreciated.
I'll be back to working on bitfury code tomorrow.
What do you all think about changing the 2nd or 3rd hashrate to be based on nonces found adjusted by accepts/total shares?
Basically the idea is to get a "hashrate after hw errors and rejects" with better accuracy.
So it would show "Instant", "Average", & "Pool + Error Corrected" ?
September 29, 2013, 02:29:17 AM
Testing/comments please
What do you all think about changing the 2nd or 3rd hashrate to be based on nonces found adjusted by accepts/total shares?
Basically the idea is to get a "hashrate after hw errors and rejects" with better accuracy.
What do you all think about changing the 2nd or 3rd hashrate to be based on nonces found adjusted by accepts/total shares?
Basically the idea is to get a "hashrate after hw errors and rejects" with better accuracy.
That sounds a very nice idea!
would give me a better idea of actual hashrate
September 28, 2013, 11:25:19 PM
Testing/comments please
"bfgminer" main branch ("3.2.90") now has stratum proxy support that could use some testing.
From my release notes draft: "Support for proxy virtual devices has been extended to include the stratum protocol when the upstream pool selected is also stratum and supplies sufficient extranonce2 space. If the upstream pool does not meet this criteria, stratum clients will be disconnected and new ones will fail to subscribe. You can take advantage of this to failover to the getwork proxy. Support for upstream getwork pools is impossble, but GBT is planned."
I've also put together a "rpc_fulldev" branch with some proposed RPC changes (removal of redundant "devdetail" method, and splitting processor-detail-level into new methods to make the original ones more cgminer-like). Testing and comments appreciated.
I'll be back to working on bitfury code tomorrow.
What do you all think about changing the 2nd or 3rd hashrate to be based on nonces found adjusted by accepts/total shares?
Basically the idea is to get a "hashrate after hw errors and rejects" with better accuracy.
"bfgminer" main branch ("3.2.90") now has stratum proxy support that could use some testing.
From my release notes draft: "Support for proxy virtual devices has been extended to include the stratum protocol when the upstream pool selected is also stratum and supplies sufficient extranonce2 space. If the upstream pool does not meet this criteria, stratum clients will be disconnected and new ones will fail to subscribe. You can take advantage of this to failover to the getwork proxy. Support for upstream getwork pools is impossble, but GBT is planned."
I've also put together a "rpc_fulldev" branch with some proposed RPC changes (removal of redundant "devdetail" method, and splitting processor-detail-level into new methods to make the original ones more cgminer-like). Testing and comments appreciated.
I'll be back to working on bitfury code tomorrow.
What do you all think about changing the 2nd or 3rd hashrate to be based on nonces found adjusted by accepts/total shares?
Basically the idea is to get a "hashrate after hw errors and rejects" with better accuracy.
September 28, 2013, 11:37:31 AM
can BFL Singles be overclocked and what are safe temps to aim for if they can be?
I`m not sure they can, but there is a thread re firmware hacking of jallies.
September 28, 2013, 08:50:18 AM
can BFL Singles be overclocked and what are safe temps to aim for if they can be?
September 28, 2013, 03:44:05 AM
Hi Luke-Jr
Is work_division enabled by default in 3.2.1 ?
Edit:- and will it work with devices other than Icarus?
Edit:- Found it
Is work_division enabled by default in 3.2.1 ?
Edit:- and will it work with devices other than Icarus?
Edit:- Found it
September 28, 2013, 03:23:57 AM
How does BFGMiner compute the perecentage of Rejects and Hardware Errors? I have tried figuring them out manually (R/A and HW/A) but somehow, the quotients don't match the indicated % values. Also, why is "R" expressed as N+N. Are these numbers added to get the total "R"?
Edit: Oh, I see. Never mind. Thanks just the same.
Edit: Oh, I see. Never mind. Thanks just the same.
September 28, 2013, 02:48:17 AM
I RUN IT ON OPENWRT BUT HOW CAN I ADD MY POOL , user passward
USE THE TUI LIKE EVERYONE ELSE. OR EDIT BFGMINER.CONF AND ADD THEM THERE! LIKE EVERYONE ELSE.
September 27, 2013, 10:52:01 PM
Thanks Luke-Jr. for a good program and a new version ready to support new devices I have on order
tip sent
tip sent
Jump to: