Bitcoin Forum
May 26, 2024, 07:17:35 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 [12] 13 14 »
221  Bitcoin / Pools / Re: [12000 GH/s] Slush's Pool (mining.bitcoin.cz); TX FEES + UserDiff; ASIC tested on: July 14, 2013, 09:44:27 AM
Obviously, if some ppl do not get points on quick blocks, some other will do. This is, however, another unpleasant factor that you can hardly affect.

Umm... no offense bitdude, but if your hardware isn't submitting shares quickly enough in short rounds... maybe its your hardware.  Up until recently I was only running GPUs and the VAST majority of short blocks were well within the acceptable variability one should expect in a short round.  Short rounds are unpredictable. If your miner(s) happen to be working on a higher diff share(s) during the short round you may not submit those in time to get in the round.  Its the nature of mining.  If you've changed your diff on your workers, maybe consider lowering it. 
All in all, the scoring system has some flaws that usually get fixed by Slush, but for the most part it works.  If you don't like the variations in pay, thats ok, there are plenty of pools with very consistent pay (PPS or PPLNS).  But don't go bashing Slush's system just cause you don't like it. Feel free to share concerns or ask questions, but bashing a system you don't seem to understand or like is kind of pointless.

None taken Smiley

Well my setup is as recommended - i.e. I have picked up the expected hash rate, which I did deliver in fact and the difficulty was selected. Hence if the difficulty setting is a problem here then the recommendation is poor in the combination with the scoring system. I'm not really saying that Slush's system is useless, it just does not handle these situations fairly - in my opinion. The scoring system itself should not, in my opinion again, force people to submit large number of low difficulty shares instead of working normal. I really think the suggested difficulty is correct here and it is the flaw of the scoring system. I think the problem is that it starts from the scratch with every new round.

I do not really want to offend anyone here, just explaining why I left this pool - i.e. it might be the case that more people did not leave just because of poor luck ...
222  Bitcoin / Pools / Re: [12000 GH/s] Slush's Pool (mining.bitcoin.cz); TX FEES + UserDiff; ASIC tested on: July 13, 2013, 02:35:57 PM
well I left because
- namecoin merged mining does not work at all for me although it is said it should work
- slush's score system is poor because when a block is found really quickly many ppl get so little of it because of the scoring system

My eruptor actually gets a pretty good number of shares on quick blocks, but my GPUs don't.  Not sure if it has anything to do with it. 

Obviously, if some ppl do not get points on quick blocks, some other will do. This is, however, another unpleasant factor that you can hardly affect.
223  Bitcoin / Pools / Re: [12000 GH/s] Slush's Pool (mining.bitcoin.cz); TX FEES + UserDiff; ASIC tested on: July 13, 2013, 01:40:46 PM
well I left because
- namecoin merged mining does not work at all for me although it is said it should work
- slush's score system is poor because when a block is found really quickly many ppl get so little of it because of the scoring system
224  Bitcoin / Hardware / Re: Avalon ASIC users thread on: July 13, 2013, 07:46:43 AM
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?

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.
225  Bitcoin / Hardware / Re: Avalon ASIC users thread on: July 13, 2013, 07:42:20 AM
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!
226  Bitcoin / Hardware / Re: Avalon ASIC users thread on: July 12, 2013, 06:09:41 AM
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!

227  Bitcoin / Hardware / Re: Official Avalon Technical Support Thread on: July 08, 2013, 05:59:01 AM
try firmware 0703 from CKolivas, that helped me a lot

also, if even after updating firmware there is still the very same problems it implies it is a HW problem
what are all the symptoms? does LAN work? does WIFI work? everything works except the hashing itself - i.e. cgminer?
228  Bitcoin / Hardware / Re: Avalon batch [2] countdown! on: July 07, 2013, 11:48:51 AM
..... But somehow DHL people were nice and kind and everything was very smooth and better than expected. It is just about reaching the good guy in the first place.
In which country it all happened, bitdude?
And how you managed to pay al those taxes, VAT?  In the airport? 
All sounds a bit hard to believe...

Czech Republic, EU it is. Yes, DHL actually does have its office and customs department in the airport here, so probably everything that comes in from a foreign country has to go through that depot. And this office cares about these VAT payments, which was 21 % (standard CR VAT) from the declared 580 USD value ($500 HW + $80 shipping). So they counted it, printed an invoice and I paid it and that was it.

The only thing that I was quite shocked about is that absolutely no verification of my identity was done. Any guy from the street that would know the tracking number would be able to track it on the web and arrange the personal pickup just as I did, paid the VAT and go with my package.
229  Bitcoin / Hardware / Re: Avalon batch [2] countdown! on: July 07, 2013, 08:55:47 AM
I have picked up mine personally at the airport and thus saved 3 precious days Smiley
How did you manage to do that???

I saw it in DHL system online that it arrived to my city. Then there was a note that the package was put on hold due to Friday state holiday + weekend, which means 3 extra days. So I picked up a phone and tried to reach DHL, but only reached automatic response that it is not a work day ... However, there was an option to have connected to some express delivery operator, which means a guy that cares about you when you want to SEND something out. Anyway I tried to ask him and he was kind to give me a contact to the airport DHL personal and after a few calls I was able to arrange holiday personal pickup. Did not expect that really. But somehow DHL people were nice and kind and everything was very smooth and better than expected. It is just about reaching the good guy in the first place.
230  Bitcoin / Hardware / Re: Avalon stable @ 98,986Mhash/sec on: July 07, 2013, 07:18:50 AM
Just to sum up things just to make sure I understand it well ...

Assuming I am able to cool it down properly (server housing room with low temp), what is possible with the very default batch #2 Avalon? It's default clock is 300. Would it be somehow dangerous with the default PSU to try to overclock it? If I set the conf to 300 and range 300-350, should it handle it?
231  Bitcoin / Hardware / Re: Official Avalon Technical Support Thread on: July 07, 2013, 06:19:05 AM
Hi,

I am having some problems with my Avalon since it arrived yesterday. I don't really mind if it restarts a few (like 2-5) times a day. If it automatically gets back up working in a minute, it is fine for me. What is crucial for me is to prevent it manually switching off and on. It happened this (its first) night that it somehow crashed and in the morning I thought it was operating well (fans worked normally) but I was not able to connect to it at all. Had to manually switch it off and on to have it on the network and hashing again.

... TEXT REMOVED ...

Thanks for any help, clues, links.

are u finding these in the System Log or the cgminer API log?

That was the system log.

But it should be noted that since I have add made two configuration changes:
  • --avalon-temp 45
  • disable DHCP server on LAN interface


it works perfectly. It had 6 hours of work without event restarting cgminer and then I had to turn it off in order to transfer it to another location and there it now has 14h 50m 31s cgminer uptime, which is great. So this is 21 hours without even restarts since those two changes. There are no -71 bad guys in the log since then. However, I would consider it fixed when I have something like 5+ days uptime ...


232  Bitcoin / Hardware / Re: Avalon batch [2] countdown! on: July 07, 2013, 06:11:43 AM
I have picked up mine personally at the airport and thus saved 3 precious days Smiley
233  Bitcoin / Hardware / Re: Avalon ASIC users thread on: July 06, 2013, 06:31:27 PM
So which pools are people using for their Avalons?

i've used ozcoin and slush.

I'm using EclipseMC.com.  No fees and it's a good size pool (7TH/s).

and does it work well for you ?
234  Bitcoin / Hardware / Re: Avalon ASIC users thread on: July 06, 2013, 01:15:58 PM
i'm trying bitminter
235  Bitcoin / Hardware / Re: Official Avalon Technical Support Thread on: July 06, 2013, 07:44:33 AM
By "deleting LAN" you mean disabling it using Stop button in Network -> Interfaces ?



And one more question: If the temperature changes I can hear fans going down and up again, would it not be a good idea just to put all fans on 100 % in order to get the lowest temperature possible and at the same time not putting stress on fans by changing their operational conditions?
236  Bitcoin / Hardware / Re: Official Avalon Technical Support Thread on: July 06, 2013, 07:22:57 AM
Hi,

I am having some problems with my Avalon since it arrived yesterday. I don't really mind if it restarts a few (like 2-5) times a day. If it automatically gets back up working in a minute, it is fine for me. What is crucial for me is to prevent it manually switching off and on. It happened this (its first) night that it somehow crashed and in the morning I thought it was operating well (fans worked normally) but I was not able to connect to it at all. Had to manually switch it off and on to have it on the network and hashing again.

I am using firmware 20130703 from CKolivas (runs much better than the original, which restarted every 10-15 minutes), flashed with Keep settings enabled, default settings mostly (except for my new attempts to solve the problems - see below), default clock 300.



I would like to ask you some questions:

1) The default "ideal" operating temperature is set to 50 C. How sensitive is Avalon to this? Might it help if I lower it down to 45 C? I might be able to cool it down even to 40 C, so I would like to know if there is any benefit of doing so. Any clues?

2) It is quite simple to "analyze" what is happening there if it just stops hashing and restart cgminer. That can be seen in the logs and I do have these ugly guys when it restarts:

Code:
...
Sat Jul  6 05:55:10 2013 auth.emerg kernel: [ 3266.570000] usb 1-1: clear tt 1 (0030) error -71
Sat Jul  6 05:55:15 2013 auth.emerg kernel: [ 3271.630000] usb 1-1: clear tt 1 (0030) error -71
Sat Jul  6 05:55:20 2013 auth.emerg kernel: [ 3276.690000] usb 1-1: clear tt 1 (0030) error -71
Sat Jul  6 05:55:21 2013 auth.info kernel: [ 3277.860000] usb 1-1.1: USB disconnect, device number 3
Sat Jul  6 05:55:22 2013 auth.info kernel: [ 3278.000000] usb 1-1: reset high-speed USB device number 2 using ehci-platform
Sat Jul  6 05:55:22 2013 auth.info kernel: [ 3278.460000] usb 1-1.1: new full-speed USB device number 4 using ehci-platform
Sat Jul  6 05:55:22 2013 auth.info kernel: [ 3278.600000] ftdi_sio 1-1.1:1.0: FTDI USB Serial Device converter detected
Sat Jul  6 05:55:22 2013 auth.info kernel: [ 3278.600000] usb 1-1.1: Detected FT232RL
Sat Jul  6 05:55:22 2013 auth.info kernel: [ 3278.610000] usb 1-1.1: Number of endpoints 2
Sat Jul  6 05:55:22 2013 auth.info kernel: [ 3278.610000] usb 1-1.1: Endpoint 1 MaxPacketSize 16384
Sat Jul  6 05:55:22 2013 auth.info kernel: [ 3278.620000] usb 1-1.1: Endpoint 2 MaxPacketSize 16384
Sat Jul  6 05:55:22 2013 auth.info kernel: [ 3278.620000] usb 1-1.1: Setting MaxPacketSize 64
Sat Jul  6 05:55:22 2013 auth.info kernel: [ 3278.630000] usb 1-1.1: FTDI USB Serial Device converter now attached to ttyUSB0
Sat Jul  6 05:55:25 2013 auth.info kernel: [ 3281.740000] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
Sat Jul  6 05:55:25 2013 auth.info kernel: [ 3281.760000] ftdi_sio 1-1.1:1.0: device disconnected
...

But my question is now - how to analyze what happened after I had to switch it off and on - i.e. logs gone. Or is this just try/fail all the time?

Those error -71 are quite known here. Some of you get rid of them just using the new firmware. Somehow this did not work for me. I now tried to use avalon-temp 45 + disable DHCP server and we'll see. But since the problem with total network disconnect happened after several hours of working, I'm not sure how to test it properly. I do not know if this -71 has something to do with that total crash, I just know it is related to cgminer restarts.

I would really hate to have to open the case. I do not really trust myself with this Smiley Switching jumpers, playing with cables, screwing something somewhere up and get brick ...
So unless it is necessary I would like to operate on the level of web interface and ssh.

Thanks for any help, clues, links.
237  Bitcoin / Hardware / Re: Avalon ASIC users thread on: July 06, 2013, 05:14:57 AM
So, suddenly, in the middle of the night, my Avalon stopped working (latest ckolivas' firmware, default clock, default settings). In the morning I found out I can not connect to its IP, it was not hashing on the pool, and I had to turn it off and on again to restart it. Is there anything I can do to get information what actually happened?

Are there any logs that are kept over the reboot? Or can this be set so?
238  Bitcoin / Hardware / Re: Avalon ASIC users thread on: July 05, 2013, 04:24:31 PM
Maybe a noobish question, but can't find answer to that:

How do I display UI of cgminer in my ssh session when cgminer runs as default (automatic service)?
I like the UI, want to play with pools, change them easily ...

And if it is not possible to bring that cgminer to my ssh session terminal, how do you switch pools? -> using cgminer-api
239  Bitcoin / Hardware / Re: [AVALON] - I got my ASIC Thread (Batch #2) on: July 05, 2013, 02:01:43 PM
Well, 44 minutes uptime looks promising. So once more - thank you BenTuras!
Better thank CKolivas!

Thank you both then!
240  Bitcoin / Hardware / Re: [AVALON] - I got my ASIC Thread (Batch #2) on: July 05, 2013, 12:44:50 PM
hmm so it did not help  Huh

what to do now? anyone with batch #2 with same problems?
Have a look here: https://bitcointalk.org/index.php?topic=140539.msg2643763#msg2643763

will do, thanks!

Well, 44 minutes uptime looks promising. So once more - thank you BenTuras!
Pages: « 1 2 3 4 5 6 7 8 9 10 11 [12] 13 14 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!