how about the cgminer API log?
The API log in the web interface just shows the current state of the system. Is there an actual log file somewhere else?
Topic: Avalon ASIC users thread - page 119. (Read 438516 times)
how about the cgminer API log?
The API log in the web interface just shows the current state of the system. Is there an actual log file somewhere else?
My cgminer is restarting too frequently. Is there a log showing why it was restarted?
System Log.try a hard reboot.
syslog is simply showing that cgminer-monitor is running regularly. It doesn't show why cgminer died/restarted.
how about the cgminer API log?
i'm puzzled why my NMW and MWC are both so low even after being up for over 30 hours. and NMW 0?
http://i.imgur.com/CnyGxSV.png
... check Elapsed ... if it reboots or cgminer restarts, of course it wont add up to 30 hours of mining http://i.imgur.com/CnyGxSV.png
i've taken that into account. for some reason, on this machine, i get NMW=0 no matter how high the MWC goes. and then the MWC never gets that high despite the Elapsed.
i know the machine is hashing and reaching the network as i'm monitoring the hashrate at the exit port, so it doesn't make sense to me. perhaps the sensor responsible for these stats is malfunctioning?
My cgminer is restarting too frequently. Is there a log showing why it was restarted?
System Log.try a hard reboot.
syslog is simply showing that cgminer-monitor is running regularly. It doesn't show why cgminer died/restarted.
i'm puzzled why my NMW and MWC are both so low even after being up for over 30 hours. and NMW 0?
http://i.imgur.com/CnyGxSV.png
... check Elapsed ... if it reboots or cgminer restarts, of course it wont add up to 30 hours of mining http://i.imgur.com/CnyGxSV.png
My cgminer is restarting too frequently. Is there a log showing why it was restarted?
System Log.
try a hard reboot.
My cgminer is restarting too frequently. Is there a log showing why it was restarted?
Same problem here.
You have to disable wifi interface. This will unload kernel module I think. Deleting wifi interface will not help. Since than several days uptime @ 340Mhz.
So you can keep wifi network device but in menu Network->Wifi disable the device.
I think this has something to do with unattached wifi antena. I havent tried it but its possible that this problem will disappear with attached wifi antena even when not using wifi.
You have to disable wifi interface. This will unload kernel module I think. Deleting wifi interface will not help. Since than several days uptime @ 340Mhz.
So you can keep wifi network device but in menu Network->Wifi disable the device.
I think this has something to do with unattached wifi antena. I havent tried it but its possible that this problem will disappear with attached wifi antena even when not using wifi.
Sorry if this has been asked already:
Is it possible to run just wired (ethernet, no WAN)? I tried disabling the WAN hoping the packets would route through ethernet, no dice.
--S
Is it possible to run just wired (ethernet, no WAN)? I tried disabling the WAN hoping the packets would route through ethernet, no dice.
--S
It is possible. You need to reserve a fixed IP address on your home router, then connect the WR703N through an Ethernet port (most WiFi routers come with extra Ethernet ports). The WR703N has a fixed IP address (I believe it's 192.168.0.100). Once you do this, I believe you can also connect to the WR703N though your home WiFi router.
Here's a sample setup: http://www.kraterminer.com
i'm puzzled why my NMW and MWC are both so low even after being up for over 30 hours. and NMW 0?
Sorry if this has been asked already:
Is it possible to run just wired (ethernet, no WAN)? I tried disabling the WAN hoping the packets would route through ethernet, no dice.
--S
Is it possible to run just wired (ethernet, no WAN)? I tried disabling the WAN hoping the packets would route through ethernet, no dice.
--S
Hey there,
sorry if this question has been already asked, but couldn't find any answer.
My avalon says 82171.28 MHS and I'm currently mining in two pools.... it's been mining all day. When I check the Mhash in the pools I got this:
slush: 36368.844 and 50btc: 37185.844
so, I got 73553 MHS total.... where are the other 8617.436?
are they lost? or those numbers are not exact? what is more reliable?
thanks!
B.
The pool figures don't really mean much since they can vary a lot and even vary by pool.sorry if this question has been already asked, but couldn't find any answer.
My avalon says 82171.28 MHS and I'm currently mining in two pools.... it's been mining all day. When I check the Mhash in the pools I got this:
slush: 36368.844 and 50btc: 37185.844
so, I got 73553 MHS total.... where are the other 8617.436?
are they lost? or those numbers are not exact? what is more reliable?
thanks!
B.
Your actual mined H/s figure is: 2^32 * ( Difficulty Accepted / Elapsed )
i.e. that is the hash rate that the pool is accepting so that is, in the end, all that matters.
If Elapsed is small then of course it will vary a lot.
If Elapsed is a day or more then it should be quite accurate depending upon your mining difficulty.
(Higher difficulty will of course mean a higher variance)
Quote
Would I get a higher hash rate if I cooled the unit even more? I've seen the hash rate spike to 87000+, and am wondering if it would stay around there, or higher, if it were cooled even further (ie - provide 68F air straight to the fans).
Not really, no. Extra cooling will only marginally improve hardware error rates, power consumption, and longevity; probably not worth the extra electric bill. Based on your quoted hashrates, it sounds like you've already clocked up to ~350MHz, which is all you will get out of a stock Avalon, cooling or not. Going past ~350MHz will require overvolting, which cannot be done without modifying the electronics in the unit.Regarding the spikes, those are just due to variance and don't indicate potential hashrates. Remember, these are mathematical slot machines; sometimes you win a lot, sometimes you lose a lot.
That makes sense- and maybe I'm splitting hairs, but at current conditions, an increased average from say 82k to 88k is about $270/month. If I pumped chilled air through the fans, that seems worth it. I just don't know if the variation is due to heat or simply chip design (I admit I don't really know how the chips work).
I thought about this a bit and it seems that having it connected to a single pool means that you want to bet on the pool's luck. Having it spread among 2 or more pools means to eliminate the luck factor a little bit. Of course that it works on both sides, if you have it spread and one of the pools is extremely lucky, you just lost a bunch of BTCs.
If you mine longer than a few weeks (you'll have to do that for months to ever break even ;-), it all evens out. That is the nature of luck
My avalon says 82171.28 MHS and I'm currently mining in two pools.... it's been mining all day. When I check the Mhash in the pools I got this:
slush: 36368.844 and 50btc: 37185.844
so, I got 73553 MHS total.... where are the other 8617.436?
are they lost? or those numbers are not exact? what is more reliable?
slush: 36368.844 and 50btc: 37185.844
so, I got 73553 MHS total.... where are the other 8617.436?
are they lost? or those numbers are not exact? what is more reliable?
I prefer to use the Failover mode, so the first pool gets 100% and if it fails, the cgminer process moves over to the second pool.
But even then, there is variance in the numbers. My 365 MHz avalon displays
MHSav 86239.66, HMS5s 87079.58 and the pools shows 86586.54
I'm sure if I look at other machines, I'll see bigger difference based on how the moving averages are calculated
I thought about this a bit and it seems that having it connected to a single pool means that you want to bet on the pool's luck. Having it spread among 2 or more pools means to eliminate the luck factor a little bit. Of course that it works on both sides, if you have it spread and one of the pools is extremely lucky, you just lost a bunch of BTCs.
i'm getting a fair # of these on one unit. can someone tell me what they mean?
Code:
Thu Jul 11 14:56:03 2013 auth.emerg kernel: [16129.320000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:04 2013 auth.emerg kernel: [16130.420000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:10 2013 auth.emerg kernel: [16136.490000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:15 2013 auth.emerg kernel: [16141.550000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:20 2013 auth.emerg kernel: [16146.600000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:25 2013 auth.emerg kernel: [16151.660000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:30 2013 auth.emerg kernel: [16156.720000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:35 2013 auth.emerg kernel: [16161.780000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:40 2013 auth.emerg kernel: [16166.840000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:45 2013 auth.emerg kernel: [16171.900000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:50 2013 auth.emerg kernel: [16176.950000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:55 2013 auth.emerg kernel: [16182.010000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:57:01 2013 auth.emerg kernel: [16187.070000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:57:06 2013 auth.emerg kernel: [16192.130000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:57:11 2013 auth.emerg kernel: [16197.190000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:57:16 2013 auth.emerg kernel: [16202.240000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.140000] usb 1-1.1: USB disconnect, device number 3
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.280000] usb 1-1: reset high-speed USB device number 2 using ehci-platform
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.730000] usb 1-1.1: new full-speed USB device number 4 using ehci-platform
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.870000] ftdi_sio 1-1.1:1.0: FTDI USB Serial Device converter detected
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.880000] usb 1-1.1: Detected FT232RL
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.880000] usb 1-1.1: Number of endpoints 2
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.880000] usb 1-1.1: Endpoint 1 MaxPacketSize 16384
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.890000] usb 1-1.1: Endpoint 2 MaxPacketSize 16384
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.890000] usb 1-1.1: Setting MaxPacketSize 64
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.910000] usb 1-1.1: FTDI USB Serial Device converter now attached to ttyUSB0
Thu Jul 11 14:57:21 2013 auth.info kernel: [16207.300000] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
Thu Jul 11 14:57:21 2013 auth.info kernel: [16207.300000] ftdi_sio 1-1.1:1.0: device disconnected
You have exactly the same problems as I do. I tried to disable DHCP server and WiFi + install the latest ckolivas firmware + set max temp to 45C, but it was not enough. It is better now but there was a warm day where the temperature went up and that day the cgminer restartarted 4-5 times. Another day it did not restarted at all. The OpenWRT itself is up for almost 5 days now, but cgminer keeps restarting. However, it did not need manual intervention for those 5 days, which I am happy about.
If you ever manage to fully fix this, please let me know!
looks like Niteshdws recommendation was good. up 5h now w/o the error. also from the wiki:
About [usb 1-1: clear tt 1 (8030) error -71]
Not all 703n have this problem. ignore this section if you never meet this error
There is a power issue with the 703N, The 703N is drawing to much power it caused the USB HUB chip on Senseless's FPGA controller to nearly destroy itself. See the destruction [ http://www.mysenselesslife.com/avalon/DSCN5212.JPG here]
In order to fix it you need had to power down the WiFi modem by disable it, use Eithernet instead. The kernel no long report -71 errors. thanks to senseless and others who help on identify the issue.
note that disabling the wifi by itself did not do it for me. i had to go the extra step of deleting the WWAN.
Interesting, will try deleting WWAN, will not use it anyway. However, it seems to me that the problems are occurring with my Avalon when it overheats and by overheating I am talking about >45C. I am not certain on this yet, but for example for last 24 hours the temp was below 45C and I have not experienced a single cgminer restart. OpenWRT is now up for more than 5 days. But will delete WWAN anyway. Thanks for the tip!
Quote
Would I get a higher hash rate if I cooled the unit even more? I've seen the hash rate spike to 87000+, and am wondering if it would stay around there, or higher, if it were cooled even further (ie - provide 68F air straight to the fans).
Not really, no. Extra cooling will only marginally improve hardware error rates, power consumption, and longevity; probably not worth the extra electric bill. Based on your quoted hashrates, it sounds like you've already clocked up to ~350MHz, which is all you will get out of a stock Avalon, cooling or not. Going past ~350MHz will require overvolting, which cannot be done without modifying the electronics in the unit.Regarding the spikes, those are just due to variance and don't indicate potential hashrates. Remember, these are mathematical slot machines; sometimes you win a lot, sometimes you lose a lot.
i'm getting a fair # of these on one unit. can someone tell me what they mean?
Code:
Thu Jul 11 14:56:03 2013 auth.emerg kernel: [16129.320000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:04 2013 auth.emerg kernel: [16130.420000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:10 2013 auth.emerg kernel: [16136.490000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:15 2013 auth.emerg kernel: [16141.550000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:20 2013 auth.emerg kernel: [16146.600000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:25 2013 auth.emerg kernel: [16151.660000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:30 2013 auth.emerg kernel: [16156.720000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:35 2013 auth.emerg kernel: [16161.780000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:40 2013 auth.emerg kernel: [16166.840000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:45 2013 auth.emerg kernel: [16171.900000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:50 2013 auth.emerg kernel: [16176.950000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:55 2013 auth.emerg kernel: [16182.010000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:57:01 2013 auth.emerg kernel: [16187.070000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:57:06 2013 auth.emerg kernel: [16192.130000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:57:11 2013 auth.emerg kernel: [16197.190000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:57:16 2013 auth.emerg kernel: [16202.240000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.140000] usb 1-1.1: USB disconnect, device number 3
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.280000] usb 1-1: reset high-speed USB device number 2 using ehci-platform
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.730000] usb 1-1.1: new full-speed USB device number 4 using ehci-platform
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.870000] ftdi_sio 1-1.1:1.0: FTDI USB Serial Device converter detected
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.880000] usb 1-1.1: Detected FT232RL
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.880000] usb 1-1.1: Number of endpoints 2
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.880000] usb 1-1.1: Endpoint 1 MaxPacketSize 16384
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.890000] usb 1-1.1: Endpoint 2 MaxPacketSize 16384
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.890000] usb 1-1.1: Setting MaxPacketSize 64
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.910000] usb 1-1.1: FTDI USB Serial Device converter now attached to ttyUSB0
Thu Jul 11 14:57:21 2013 auth.info kernel: [16207.300000] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
Thu Jul 11 14:57:21 2013 auth.info kernel: [16207.300000] ftdi_sio 1-1.1:1.0: device disconnected
You have exactly the same problems as I do. I tried to disable DHCP server and WiFi + install the latest ckolivas firmware + set max temp to 45C, but it was not enough. It is better now but there was a warm day where the temperature went up and that day the cgminer restartarted 4-5 times. Another day it did not restarted at all. The OpenWRT itself is up for almost 5 days now, but cgminer keeps restarting. However, it did not need manual intervention for those 5 days, which I am happy about.
If you ever manage to fully fix this, please let me know!
looks like Niteshdws recommendation was good. up 5h now w/o the error. also from the wiki:
About [usb 1-1: clear tt 1 (8030) error -71]
Not all 703n have this problem. ignore this section if you never meet this error
There is a power issue with the 703N, The 703N is drawing to much power it caused the USB HUB chip on Senseless's FPGA controller to nearly destroy itself. See the destruction [ http://www.mysenselesslife.com/avalon/DSCN5212.JPG here]
In order to fix it you need had to power down the WiFi modem by disable it, use Eithernet instead. The kernel no long report -71 errors. thanks to senseless and others who help on identify the issue.
note that disabling the wifi by itself did not do it for me. i had to go the extra step of deleting the WWAN.
Does anyone have a useful means of contacting Avalon?
I have two orders from February 3rd, neither of which is showing in the store. I also have two tickets in their system, neither of which has been answered.
I waited patiently when batch 2 was delayed for everyone. But now that they are talking about batch 3 shipping, I'm pissed.
I have two orders from February 3rd, neither of which is showing in the store. I also have two tickets in their system, neither of which has been answered.
I waited patiently when batch 2 was delayed for everyone. But now that they are talking about batch 3 shipping, I'm pissed.
I am in a similar situation.
I received confirmation that my entire order was shipping, but what arrived was 1/2 the machines.
I have tried to contact them via tickets, PM's & email.... 9 days and not a single word from them.
I have started a thread dedicated to Batch 2 Buyers who have a current unresolved problem.
https://bitcointalksearch.org/topic/avalon-asic-batch-2-problem-orders-bitsyncom-please-help-255130
My avalon is humming along nicely between 79000 MH/s and 85000 MH/s (usually around 82000). Current room temp is between 72-75 F (22-24 C). Would I get a higher hash rate if I cooled the unit even more? I've seen the hash rate spike to 87000+, and am wondering if it would stay around there, or higher, if it were cooled even further (ie - provide 68F air straight to the fans).
Jump to: