HellDiverUK
|
|
August 25, 2013, 04:00:03 PM |
|
Windbloze 7.
Grow up.
|
|
|
|
os2sam
Legendary
Offline
Activity: 3583
Merit: 1094
Think for yourself
|
|
August 25, 2013, 04:01:36 PM |
|
Windbloze 7.
Grow up. That was just for your enjoyment
|
A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
|
|
|
os2sam
Legendary
Offline
Activity: 3583
Merit: 1094
Think for yourself
|
|
August 25, 2013, 04:08:44 PM |
|
Wrong. I am not a CGMiner developer. I have no responsibility or interest in personally debugging CGMiner.
Both developers and users are part of the Open Source Software community, users have responsibility to report problems and help ascertain what the cause is, when possible. but he chose to just blindly attack me instead.
He didn't "blindly" attack you, You, gave first offense, now your refusing to take responsibility for it. You want Kano to take responsibility for his offensive post, but why should he when YOU refuse?
|
A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
|
|
|
Its About Sharing
Legendary
Offline
Activity: 1442
Merit: 1000
Antifragile
|
|
August 25, 2013, 04:21:31 PM |
|
Outside of the documentation, are there any concise examples of the overclocking commands in action, that I could study before my rigs get here? Going through this entire thread is not possible! (I am running MinePeon with CG Miner on a Raspberry Pi. I'll be overclocking a Burnin Mining rig and then a Bitfury chip custom rig).
Thanks, IAS
No bitfury drivers yet. Burnin's BitBurner is simply a case of adjusting the freq and the volts - the higher the volts the bigger the risk of hardware failure. The higher the frequency, the larger the volts required to reduce HW errors. Update of what I posted in the Burnin thread BTB 0: 56C 400 1346mV | 7.192G/7.991Gh/s | A:243645 R:2216 HW:12 WU:111.6/m [Device Hardware%] => 0.0049 (yes that's a %) It's documented in the README, ASIC-README and API-README ... To set the start voltage: --bitburner-voltage nnnn nnnn - from 1200 to 1400 Warning it can kill your power supply or even your board ... be careful adjusting it too high To set the start frequency (for one board with 20 chips) --avalon-options 115200:2:10:d:nnn nnn from 282 up to 450 When it's running you can change them also via the API, but it doesn't really help to work out the performance coz you need to run it for a few hours to get marginally reliable statistics - the Avalon driver doesn't count hashes, it estimates them. Thanks a lot Kano. I know how some newb questions can be a pain. I'll watch the voltage closely and wasn't aware of it being able to do so much harm. Had no idea it could hurt a PS. Hopefully Burnin Mining and SebastianJu find some good settings to settle on and post them. Barntech will help, I think, with the drivers. At least he is talking about overclocking the rigs he is producing with Bitfury's. Said he got it from 2Ghash/s to 2.7Ghash/s. That is a lot. Burnin Minding talked about getting them to 5Ghash/s and I asked him how as it made no sense, but he never replied. Hmmmmm.... Have you heard of anyone using the --avalon-auto option? I see quite a few other interesting options there. Thanks, IAS
|
BTC = Black Swan. BTC = Antifragile - "Some things benefit from shocks; they thrive and grow when exposed to volatility, randomness, disorder, and stressors and love adventure, risk, and uncertainty. Robust is not the opposite of fragile.
|
|
|
xyzzy099
Legendary
Offline
Activity: 1065
Merit: 1077
|
|
August 25, 2013, 04:31:02 PM |
|
Wrong. I am not a CGMiner developer. I have no responsibility or interest in personally debugging CGMiner.
Both developers and users are part of the Open Source Software community, users have responsibility to report problems and help ascertain what the cause is, when possible. but he chose to just blindly attack me instead.
He didn't "blindly" attack you, You, gave first offense, now your refusing to take responsibility for it. You want Kano to take responsibility for his offensive post, but why should he when YOU refuse? You failed to quote my whole post - as I said, I was willing to help debug the problem, but was not afforded that opportunity. Exactly HOW did I "give first offense" I did NOTHING but point out a problem I had. I said NOTHING to offend anyone. I did not know that Kano had some kind of bizarre hatred of [THE MINER THAT DARE NOT SAY ITS NAME IN THIS THREAD]. Clearly Kano read offense into a post that contained NONE. Since you seem to possess the OSS community spirit, maybe you and I could talk about the problem in more detail, so we can identify the part where I did something stupid that resulted in my problem? I installed the Windows binary distribution of CGMiner - 3.3.1, I believe, was the current release at that time. I read the README, and downloaded the Zadig binary linked on page 1, and installed the WinUSB driver for my block erupters, and for my BFL devices. I then (just to be careful) rebooted the PC. All devices appeared to be using the correct WinUSB drivers, so I then started CGMiner. The devices were all recognized, and seemed to function as expected. Over the next few days, however, I found that at least one Block Erupter would stop working after, on average, ~2-3 hours. CGMiner would be constantly printing a communications error with the failed device, and the device itself would have an LED that was fully on constantly. Manually unplugging and re-plugging the device would fix the problem, and CGMiner would autodetect the newly-reinserted device. So what did I do wrong? I did not try CGMiner under Linux, but whether or not that works would not change the fact that there was a problem with the Win 7 configuration, and that is the problem I reported.
|
Libertarians: Diligently plotting to take over the world and leave you alone.
|
|
|
Xian01
Legendary
Offline
Activity: 1652
Merit: 1067
Christian Antkow
|
|
August 25, 2013, 05:15:48 PM |
|
When you have a notable antagonist like Kano involved with this project, it's hard to avoid shit talking It's actually very easy to avoid. I agree in theory. Unfortunately, I have an obsessive compulsion to call people on their bullshit We all have our quirks.
|
|
|
|
os2sam
Legendary
Offline
Activity: 3583
Merit: 1094
Think for yourself
|
|
August 25, 2013, 05:21:43 PM |
|
I installed the Windows binary distribution of CGMiner - 3.3.1, I believe, was the current release at that time. I read the README, and downloaded the Zadig binary linked on page 1, and installed the WinUSB driver for my block erupters, and for my BFL devices. I then (just to be careful) rebooted the PC. All devices appeared to be using the correct WinUSB drivers, so I then started CGMiner. The devices were all recognized, and seemed to function as expected. Over the next few days, however, I found that at least one Block Erupter would stop working after, on average, ~2-3 hours. CGMiner would be constantly printing a communications error with the failed device, and the device itself would have an LED that was fully on constantly. Manually unplugging and re-plugging the device would fix the problem, and CGMiner would autodetect the newly-reinserted device.
That sounds like a hub not supplying enough power. What hub(s) are you using and what is the current and voltage rating of the Power Supplies. Sam
|
A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
|
|
|
xyzzy099
Legendary
Offline
Activity: 1065
Merit: 1077
|
|
August 25, 2013, 05:39:40 PM |
|
I installed the Windows binary distribution of CGMiner - 3.3.1, I believe, was the current release at that time. I read the README, and downloaded the Zadig binary linked on page 1, and installed the WinUSB driver for my block erupters, and for my BFL devices. I then (just to be careful) rebooted the PC. All devices appeared to be using the correct WinUSB drivers, so I then started CGMiner. The devices were all recognized, and seemed to function as expected. Over the next few days, however, I found that at least one Block Erupter would stop working after, on average, ~2-3 hours. CGMiner would be constantly printing a communications error with the failed device, and the device itself would have an LED that was fully on constantly. Manually unplugging and re-plugging the device would fix the problem, and CGMiner would autodetect the newly-reinserted device.
That sounds like a hub not supplying enough power. What hub(s) are you using and what is the current and voltage rating of the Power Supplies. Sam The hubs are DLink DUB-H7 7-port hubs, with 5 sticks in each hub with 3A power supplies. It's my understanding that each BE should use 0.5A, so this should provide sufficient overhead for 5 sticks. These hubs are well-known to work well with BEs in groups of 5. Most importantly though, they work flawlessly when attached to a Linux box running different S/W, so I think blaming the hardware is probably a dead-end.
|
Libertarians: Diligently plotting to take over the world and leave you alone.
|
|
|
albon
Legendary
Offline
Activity: 1848
Merit: 1504
|
|
August 25, 2013, 06:39:02 PM |
|
I have a bit of a problem.
I have 2 gpu's and 4 usb asci's
I run -o stratum.d7.lt:3333 -u xxxx -p xxxx -d 0 -d 1 -d 2 -d 3 -d 4 -d 5 --api-listen --api-port 4028 --api-allow W:127.0.0.1 -T and cgminer probes for an alive pool than crashes.
I have also tried -o stratum.d7.lt:3333 -u xxxx -p xxxx -w 256 -g 1 --thread-concurrency 6144,24000 -I 14,20 -d 0 -d 1 -d 2 -d 3 --api-listen --api-port 4029 --api-allow W:127.0.0.1 -T to try and set up the gpu's but the same thing happens
Any ideas?
|
|
|
|
os2sam
Legendary
Offline
Activity: 3583
Merit: 1094
Think for yourself
|
|
August 25, 2013, 07:08:05 PM |
|
The hubs are DLink DUB-H7 7-port hubs, with 5 sticks in each hub with 3A power supplies. It's my understanding that each BE should use 0.5A, so this should provide sufficient overhead for 5 sticks. These hubs are well-known to work well with BEs in groups of 5.
Most importantly though, they work flawlessly when attached to a Linux box running different S/W, so I think blaming the hardware is probably a dead-end.
Yep, I agree. Is it always the same Erupter/USB port. I'm not trying to "blame" your hardware just trying to cover all the bases, in the unlikely event you haven't. How many instances of CGMiner were you running? Were you trying to use any command line options?
|
A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
|
|
|
xyzzy099
Legendary
Offline
Activity: 1065
Merit: 1077
|
|
August 25, 2013, 07:12:43 PM |
|
The hubs are DLink DUB-H7 7-port hubs, with 5 sticks in each hub with 3A power supplies. It's my understanding that each BE should use 0.5A, so this should provide sufficient overhead for 5 sticks. These hubs are well-known to work well with BEs in groups of 5.
Most importantly though, they work flawlessly when attached to a Linux box running different S/W, so I think blaming the hardware is probably a dead-end.
Yep, I agree. Is it always the same Erupter/USB port. I'm not trying to "blame" your hardware just trying to cover all the bases, in the unlikely event you haven't. How many instances of CGMiner were you running? Were you trying to use any command line options? No it was not always the same erupter or port or hub. It seemed to be completely random. Even the erupters plugged into the 1.2A fast-charge ports had the issue randomly, with the same frequency as the sticks in the normal ports. I was only using one instance of CGMiner, and the only options on the command line were '-G' to avoid using the GPU, and -c to load the correct config file.
|
Libertarians: Diligently plotting to take over the world and leave you alone.
|
|
|
os2sam
Legendary
Offline
Activity: 3583
Merit: 1094
Think for yourself
|
|
August 25, 2013, 08:31:14 PM |
|
The hubs are DLink DUB-H7 7-port hubs, with 5 sticks in each hub with 3A power supplies. It's my understanding that each BE should use 0.5A, so this should provide sufficient overhead for 5 sticks. These hubs are well-known to work well with BEs in groups of 5.
Most importantly though, they work flawlessly when attached to a Linux box running different S/W, so I think blaming the hardware is probably a dead-end.
Yep, I agree. Is it always the same Erupter/USB port. I'm not trying to "blame" your hardware just trying to cover all the bases, in the unlikely event you haven't. How many instances of CGMiner were you running? Were you trying to use any command line options? No it was not always the same erupter or port or hub. It seemed to be completely random. Even the erupters plugged into the 1.2A fast-charge ports had the issue randomly, with the same frequency as the sticks in the normal ports. I was only using one instance of CGMiner, and the only options on the command line were '-G' to avoid using the GPU, and -c to load the correct config file. The only other the "I" could suggest is to try the latest CGMiner. But I understand that you have a working rig now. So you may not want to fix what is no longer broken for you. I have not seen this behavior with 3.3.1, .2, .3, .4 and I just updated to 3.4.0 yesterday and have not seen this behavior. My setup is very similar to what you described, Win7 32 bit, 64 bit since yesterday, 15 BE's on 5/7 Port Rosewill hubs and one Jalapeno. When changing versions I would recommend rebooting the machine to make sure the new .dll is loaded vs. the old one. But I doubt the usb .dll's would effect this since your on USB 2.0 hubs. Sam
|
A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
|
|
|
xyzzy099
Legendary
Offline
Activity: 1065
Merit: 1077
|
|
August 25, 2013, 08:46:06 PM |
|
The only other the "I" could suggest is to try the latest CGMiner.
But I understand that you have a working rig now. So you may not want to fix what is no longer broken for you.
I have not seen this behavior with 3.3.1, .2, .3, .4 and I just updated to 3.4.0 yesterday and have not seen this behavior.
My setup is very similar to what you described, Win7 32 bit, 64 bit since yesterday, 15 BE's on 5/7 Port Rosewill hubs and one Jalapeno.
When changing versions I would recommend rebooting the machine to make sure the new .dll is loaded vs. the old one. But I doubt the usb .dll's would effect this since your on USB 2.0 hubs. Sam
You're right, I don't want to interrupt a working set-up. I could troubleshoot the issue all the way to the hardware level, if I needed to - I have a nice LeCroy O-Scope with a USB analyzer module at work. Maybe I would have been willing to go that route just to help out the CGMiner project, if I had not been greeted with such animosity by Kano. Well, we didn't manage to figure out what the problem was, but at least we managed to have a civilized conversation about the issue. Thanks for your help.
|
Libertarians: Diligently plotting to take over the world and leave you alone.
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
August 25, 2013, 09:25:09 PM |
|
... I installed the Windows binary distribution of CGMiner - 3.3.1, I believe, was the current release at that time. I read the README, and downloaded the Zadig binary linked on page 1, and installed the WinUSB driver for my block erupters, and for my BFL devices. I then (just to be careful) rebooted the PC. All devices appeared to be using the correct WinUSB drivers, so I then started CGMiner. The devices were all recognized, and seemed to function as expected. Over the next few days, however, I found that at least one Block Erupter would stop working after, on average, ~2-3 hours. CGMiner would be constantly printing a communications error with the failed device, and the device itself would have an LED that was fully on constantly. Manually unplugging and re-plugging the device would fix the problem, and CGMiner would autodetect the newly-reinserted device.
So what did I do wrong? I did not try CGMiner under Linux, but whether or not that works would not change the fact that there was a problem with the Win 7 configuration, and that is the problem I reported.
Can someone just go delete every post related to this moron in this thread ... I answered it with my very first post. https://bitcointalk.org/index.php?topic=28402.msg2960179#msg2960179Quote from: xyzzy099 on August 18, 2013, 10:23:09 PM ...
So which is it? Wrong version? Wrong libusb.dll? You built it yourself and didn't follow the libusb instructions? ... and cgminer will be rock solid on linux also if you do it as per instructions. You were running an old version of cgminer for fucked if I know what reason. So indeed you are a complete fucking waste of time here 3.3.2 came out on the 9th of August that used a replacement fixed libusb ...
|
|
|
|
xyzzy099
Legendary
Offline
Activity: 1065
Merit: 1077
|
|
August 25, 2013, 09:38:47 PM Last edit: August 25, 2013, 09:54:20 PM by xyzzy099 |
|
... I installed the Windows binary distribution of CGMiner - 3.3.1, I believe, was the current release at that time. I read the README, and downloaded the Zadig binary linked on page 1, and installed the WinUSB driver for my block erupters, and for my BFL devices. I then (just to be careful) rebooted the PC. All devices appeared to be using the correct WinUSB drivers, so I then started CGMiner. The devices were all recognized, and seemed to function as expected. Over the next few days, however, I found that at least one Block Erupter would stop working after, on average, ~2-3 hours. CGMiner would be constantly printing a communications error with the failed device, and the device itself would have an LED that was fully on constantly. Manually unplugging and re-plugging the device would fix the problem, and CGMiner would autodetect the newly-reinserted device.
So what did I do wrong? I did not try CGMiner under Linux, but whether or not that works would not change the fact that there was a problem with the Win 7 configuration, and that is the problem I reported.
Can someone just go delete every post related to this moron in this thread ... I answered it with my very first post. https://bitcointalk.org/index.php?topic=28402.msg2960179#msg2960179Quote from: xyzzy099 on August 18, 2013, 10:23:09 PM ...
So which is it? Wrong version? Wrong libusb.dll? You built it yourself and didn't follow the libusb instructions? ... and cgminer will be rock solid on linux also if you do it as per instructions. You were running an old version of cgminer for fucked if I know what reason. So indeed you are a complete fucking waste of time here 3.3.2 came out on the 9th of August that used a replacement fixed libusb ... Actually I was mistaken when I said 3.3.1 was current at that time. I just checked and verified that I had 3.3.2 installed on the Windows machine, if you really even care about this issue. Actually, it looks like the last version I installed - which would be the one I was using when I initially posted - was 3.3.4.
|
Libertarians: Diligently plotting to take over the world and leave you alone.
|
|
|
LordTheron
|
|
August 25, 2013, 09:42:59 PM |
|
Kano, quick question. Does cgminer control when avalon fan speed argument kicks in? On my bitburners, 100% fan setting doesn't kick in for about 3-5 min so temp is rising very quickly to 55-60c then fans go to 100% and its cooling down to about 48C and stays like that. Do you think its something in the firmware that can be improved or cgminer? Shouldn't fan speed go to 100% if set by arg straight from the start of cgminer?
|
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
August 25, 2013, 10:06:59 PM |
|
Kano, quick question. Does cgminer control when avalon fan speed argument kicks in? On my bitburners, 100% fan setting doesn't kick in for about 3-5 min so temp is rising very quickly to 55-60c then fans go to 100% and its cooling down to about 48C and stays like that. Do you think its something in the firmware that can be improved or cgminer? Shouldn't fan speed go to 100% if set by arg straight from the start of cgminer?
Probably a cgminer change I need to do? I've found that my fan (from the start) didn't always spin up the expected way (and sometimes didn't for a while) I use --avalon-fan 99-100 Maybe the fan control on the BTB is different to the Avalon? However, I thought it was just my fan coz I hadn't heard any problems. I'll look into it.
|
|
|
|
LordTheron
|
|
August 25, 2013, 10:18:47 PM |
|
Cheers for that. If I use --avalon-fan x-100 it takes even longer for the fans to spin up.
|
|
|
|
-ck (OP)
Legendary
Offline
Activity: 4242
Merit: 1644
Ruu \o/
|
|
August 25, 2013, 10:24:56 PM |
|
The avalon fan speed control is very specific for the fan type and the pwm values used on the original avalon itself. There is no guarantee of it working on another combination. If it suddenly speeds up with BTBs then perhaps the pwm curve for the fan or hardware is totally different.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
milkbottlec
Member
Offline
Activity: 95
Merit: 10
|
|
August 26, 2013, 12:13:37 AM |
|
Hi Kano, just got a quick question. With rpi and BE, does 3.4.0 works great on it? Or should go with an earlier version? And with the latest updates, should I go with arch or raspbian? As I saw the LCD module in adafruit with raspbian seems nice
|
Will be handling Drillbit System UK/EU replacement components soon (waiting to confirm details, stay tunes) If I helped you and could pop me some treats for this Christmas, donate some BTC to: 1QEhKaUnFoEBaWmXsrE5AUvbAt95254DXr
|
|
|
|