Latest posts of: wogaut

Quote from: DavinciJ15 on June 15, 2012, 09:01:44 PM

Order Date: May, 10 2012
Shipped Date: July 10th
Quantity: 1

ALSO Ordered

Order Date: May 22, 2012
Shipped Date: July 22
Quantity: 2

Still waiting but it sucks when a company sit on your cash for more than 30 days. I would have saved in BTC and saw 20% return.
I would buy 5 more but that much cash in the wind for 60 days is just crazy.

I'm not sure where you got the 60 days, the Mini-Rig is quoted 12 to 15 weeks, that's at least 84 days!

Quote from: jaebird on June 14, 2012, 05:38:46 PM

I spent some time getting bitcoind to build on RaspberryPi. Here are my steps...

I'm using a Transcend 8GB SDHC Card (Class 10)

First I started with the Debian Wheezy test image from: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=50&t=8071
On first boot it will run raspi-config. Here you will increase the size of your root partition, set the maximum RAM to the CPU, and enable SSH server.

Get build tools and deps:
sudo apt-get install build-essential autoconf pkg-config git libcurl4-openssl-dev libncurses5-dev libssl-dev libdb5.1++-dev libboost-all-dev

Adjust virtual memory:
sudo vi /etc/dphys-swapfile
Change:
CONF_SWAPSIZE=100
to:
CONF_SWAPSIZE=400
(I was getting an "g++: internal compiler error: Killed (program cc1plus)" with the default size)

sudo dphys-swapfile setup
sudo dphys-swapfile swapon

Get source and build bitcoind:
git clone https://github.com/bitcoin/bitcoin.git
cd bitcoin/
git branch -r
git checkout origin/0.6.2

cd src/
make -f makefile.unix

Go to dinner...

bitcoind seems to run fine on the RasPi.

Very cool, thank you!

Quote from: af_newbie on June 07, 2012, 03:23:42 PM

Quote from: Epoch on June 07, 2012, 02:37:51 PM

This happens to me occasionally as well (Win7/64 here), typically once every day or two. Happens in cgminer 2.4.1 and 2.4.2; in the cgminer window the device's hashrate is listed as 'OFF'.

This never happened with 2.3.6; I ran that version for 2 weeks straight without any issue. So I'm also leaning toward it being a cgminer issue introduced in 2.4.1.

In 2.4.1+, devices are disabled (rolling rate is "OFF") when scanhash() returns 0. Check your cgminer log for reasons (all error conditions log error messages). I don't think it is an "issue". What's the point to have a device that cannot hash.

cgminer just handles errors coming from the device and disables the device. That is its error handling.
See nedbert9 post: https://bitcointalk.org/index.php?topic=76208.40

Closing and re-opening/re-initializing the port would probably be a better solution. But disable is simpler and works.

And works??? For what? Permanently disabling a perfectly good BFL single, just because there was some hiccup somewhere for a brief moment?
We seem to have a disagreement on the definition of "works" vs. "issue".

Quote from: zefir on June 07, 2012, 06:01:42 AM

Quote from: rjk on June 07, 2012, 02:34:11 AM

After 900 accepted shares, my U seems to be a little higher, but I'm going to leave it for a while.

BTW, why does cgminer occasionally (after about 50K shares) stop sending work to the BFL box? It stays running and shows longpolls as they come in, but no shares...

Since when do you observe this? One of my BFLS (running at 872) happened to just quit working two times this week. No indication that communication failed or any other log messages from cgminer. The only thing I noticed is the right LED being off, indicating that device is not hashing. Since restarting cgminer makes it work again, I assume it is only communication that hangs.

Before I updated to cgminer-2.4.2 and played with the different firmwares, the BFLS worked for weeks non-stop. Would be a pity if the FW with the higher clock caused the device idling around two nights Sad

Had the exact same thing, it's fine right now, I'm observing. BTW, I'm running cgminer-v2.4.1-9 under Debian Linux.

Quote from: rjk on June 07, 2012, 02:34:11 AM

I'm observing something similar, but not your quoted 50k, in fact it seems pretty random here, I will need to do more logging; had logging off so I wouldn't clutter the Raspberry SD card.

Quote from: imsaguy on June 06, 2012, 10:05:37 PM

Quote from: BFL-Engineer on June 06, 2012, 09:57:21 PM

Quote from: freshzive on June 06, 2012, 09:30:16 PM

When will singles begin shipping again?

Tomorrow is a very big shipping day...

For singles or for MR? Way to be vague with the answers so everyone can read what they want with it.

Right, especially since all of this is discussed in the BitForceSC ASIC thread Cheesy

Quote from: jaebird on June 06, 2012, 07:08:27 PM

I was able to get the Icarus attached to a Dlink usb hub. It seems there is a problem with either the kernel or the raspberrypi. I have three icarus connected and they show up as /dev/ttyUSB0, 1, and 2. However, cgminer and RG7Miner clients cannot open more than 2 at a time. The last port opened gives an error that the port does not exist, even though it is clearly listed in /dev. It appears to be random of which of the 3 is not available. When I use my regular ubuntu pc everything works as expected (even using the dlink usb hub).

Anyone have similar info? solutions?

Thanks,
J

Are those two showing up always ttyUSB0 and ttyUSB1? I.e. Does the problem specifically occur when a ttyUSB higher than 0 or 1 is needed?
How is it when you open two FPGA devices manually in cgminer (instead of the -S auto option), one of them being attached to ttyUSB2?
What I'm trying to get at is, is this specific to the used ttyUSB port (like only ttyUSB0 and ttyUSB1 work), which would point to an issue with the USB kernel model then.

Please keep us updated, that is very concerning indeed.

Quote from: Inaba on June 05, 2012, 01:49:35 AM

Hmm, yeah you don't seem to have any strange or misbehaving routes.

How often is this happening? Do you happen to have a log of the times it's happened in the past?

OK, without the --failover-only option there's indeed some occasional delay in the route that can cause a switch to the backup pool; running mtr for a while suggests that (so that part seems to be related to my ISP).

With the --failover-only option it's more stable against short delays, so it happens less frequent, only every other day or so, so not dramatic enough to jump to conclusions. I'll keep an eye on it and will collect some logging data (haven't done that yet, I didn't want to clutter the SD card on my RaspberryPi) before reporting back.

Quote from: P_Shep on June 05, 2012, 12:16:15 AM

I think I might have found what's been causing my high stales, though not specifically...
It seems with load-balance I get very a poor stale rate, which seems to get worse the more pools involved. with 3 pools I get around 1.5% stale, with 5 it's up to 3-4%. When it's fail-over-only I'm looking at < 0.5%
Trouble is, the CGminer reported stats are not the same as the pools report. it seems the pools (some more than others) often report a share as valid to cgminer, then decide in it's own stats that it's stale.

I have a 10Mb debug log file taken over 1.5hrs if it'll be useful to diagnose anything.

Would that possibly explain the dips every now and then my hashrate as reported by the pool (i.e. Eclipse) takes (really short and then it comes up again) while my cgminer seems to be working at a constant rate?

Quote from: punin on June 04, 2012, 06:34:31 PM

Quote from: jaebird on June 04, 2012, 02:10:41 AM

I used the Debian preinstall image from raspberrypi.org then

apt-get install git build-essential autoconf pkg-config libcurl4-openssl-dev libncurses5-dev

got the latest from github and built it. Binaries seem to be GTG!

Just make sure your micro usb charger is at least 1 amp or it will act squirrely. I'm using an HP 2 amp designed for their no defunct webos tablet (you can pick one up for about 5 bucks).

I tried this, run autogen.sh then tried CFLAGS="-O2 -Wall -march=native" ./configure --enable-ztex but I get:

Code:

checking whether the C compiler works... no
configure: error: in `/home/pi/git/cgminer':
configure: error: C compiler cannot create executables
See `config.log' for more details

I really don't think you need to use the CFLAGS="-O2 -Wall -march=native" directive.

Have you tried following my guide I linked in the above post? Do it in the suggested order, and I don't think you should get the C compiler issue, that doesn't sound like a ztex issue at all. Given that you downloaded the Debian squeeze for your Raspberry and if you follow my instructions like a cooking recipe (and don't forget the apt-get update at the beginning, or the aclocal before autogen.sh, ...) I don't really see the issue (unless cgminer changed since release ckolivas-cgminer-v2.4.1-9-gb69d735.zip).

Probably add the 'sudo apt-get install' commands for libudev and libusb in the first section too, just to make sure.

Check out the post I have made here:
https://bitcointalk.org/index.php?topic=69183.msg919685#msg919685

It's BFL, but the cgminer install is very similar, just activate the proper FPGA type for ./configure

Quote from: Inaba on June 04, 2012, 02:29:15 AM

Can you try running a traceroute to the server and see if you are dropping packets anywhere? Something like ping plotter would be really helpful in diagnosing it as well.

But starting with a post of your traceroute might reveal some clues.

And here's the mtr report:

HOST: wogaut Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.1.254 0.0% 50 1.6 1.6 1.5 2.4 0.2
2.|-- 99-63-172-2.lightspeed.mi 80.0% 50 23.3 23.5 22.2 25.5 1.0
3.|-- 71.144.192.62 92.0% 50 36.5 26.6 22.6 36.5 6.6
4.|-- 71.144.192.126 90.0% 50 23.0 22.9 22.6 23.4 0.3
5.|-- 71.144.192.120 98.0% 50 23.5 23.5 23.5 23.5 0.0
6.|-- 12.83.79.141 0.0% 50 22.6 22.5 21.7 23.9 0.4
7.|-- cgcil03jt.ip.att.net 0.0% 50 24.6 32.8 23.9 116.7 20.9
8.|-- 192.205.37.178 0.0% 50 25.4 25.3 24.5 28.1 0.6
| `|-- 192.205.37.174
| |-- 154.54.12.85
9.|-- te0-4-0-1.ccr21.ord01.atl 0.0% 50 25.9 26.2 24.6 39.6 2.5
10.|-- te0-1-0-3.ccr21.mci01.atl 0.0% 50 49.8 49.8 48.6 58.6 1.4
11.|-- te0-2-0-0.mpd22.mci01.atl 0.0% 50 50.1 49.9 48.9 53.4 0.7
12.|-- everest.demarc.cogentco.c 0.0% 50 50.0 49.7 48.5 61.6 1.8
13.|-- 69.30.209.1 0.0% 50 49.8 48.1 47.1 50.3 1.0
14.|-- us1.eclipsemc.com 0.0% 50 47.2 47.7 46.7 49.8 0.8

IMO the loss values reported above are no reason for concern, I would think they are a result of rate limiting, since there's 0% loss down the chain.

Quote from: Inaba on June 04, 2012, 02:29:15 AM

Here's my traceroute output:

traceroute to us2.eclipsemc.com (208.110.68.114), 30 hops max, 40 byte packets using UDP
1 192.168.1.254 (192.168.1.254) 1.885 ms 1.596 ms 1.338 ms
2 99-63-172-2.lightspeed.milwwi.sbcglobal.net (99.63.172.2) 23.900 ms 24.105 ms 27.475 ms
3 * * *
4 * * *
5 * * *
6 12.83.79.141 (12.83.79.141) 22.846 ms 22.825 ms 21.674 ms
7 cgcil03jt.ip.att.net (12.122.84.93) 24.986 ms 24.823 ms 25.978 ms
8 192.205.37.178 (192.205.37.178) 27.058 ms 26.021 ms te0-2-0-2.ccr22.ord03.atlas.cogentco.com (154.54.12.85) 24.909 ms
9 te0-5-0-7.ccr22.ord01.atlas.cogentco.com (154.54.44.165) 27.581 ms te0-5-0-1.ccr22.ord01.atlas.cogentco.com (154.54.43.233) 26.491 ms te0-0-0-1.ccr22.ord01.atlas.cogentco.com (154.54.1.97) 26.200 ms
10 te0-4-0-5.ccr21.mci01.atlas.cogentco.com (154.54.45.145) 48.498 ms te0-5-0-1.mpd22.ord01.atlas.cogentco.com (154.54.44.177) 26.073 ms te0-1-0-3.ccr22.mci01.atlas.cogentco.com (154.54.5.173) 49.963 ms
11 te0-2-0-0.mpd22.mci01.atlas.cogentco.com (154.54.30.158) 49.552 ms te0-1-0-0.mpd22.mci01.atlas.cogentco.com (154.54.30.154) 50.029 ms 48.918 ms
12 everest.demarc.cogentco.com (38.104.86.2) 51.064 ms 51.869 ms 50.723 ms
13 69.30.209.1 (69.30.209.1) 48.612 ms 48.400 ms 47.694 ms
14 us1.eclipsemc.com (208.110.68.114) 49.585 ms 48.473 ms 48.097 ms

Quote from: ckolivas on April 03, 2012, 06:06:44 AM

The normal failover mechanism in cgminer will allow some work to go to the backup pools if there is a delay in getting work from the primary pool you have set. This can be as much as 10% if the pool has latency issues. It then only fails to the backup pool if the primary pool stops giving work for 1 minute. failover-only does not change the failover mechanism, but it does not allow work to go to the backup pools unless the primary pool has failed completely for at least a minute. It then will switch to the backup pool. If cgminer considers a pool dead or down, it tries to contact that pool 1 minutely.

Can that 1 minute value be changed on the command line?

It seems I am experiencing time lags with Eclipse; cgminer even tries to get work from the failover pool (if I don't set --failover-only it says primary pool is lagging and tries to fetches work from secondary pool).

Any idea, or things I should look for?

Edit: I checked into possible issues and noticed that some users described a timeout with cgminer 2.3
It's sort of similar, but I'm running cgminer 2.4.1-9 under Linux. It's running great for a while and than suddenly there's some wait time, and then it recovers. No idea. The network seems ok though.

Quote from: Lethos on June 01, 2012, 12:08:51 PM

Okay, maybe I see why, most places that sell these chips or the boards they come on have a price tag of $2k+ for these.
They must be getting a really nice deal of them. Shocked

Yes, I'm sure they do.

Ah yes, and subscribing Tongue

YABMTTF (yet another BFL message thread to follow)

Quote from: gigavps on June 01, 2012, 12:57:44 AM

Someone is getting excited......

* gigavps thinks it might him Grin

Seems you are still waiting too? Isn't today 'End of May'?

Quote from: Beaflag VonRathburg on June 01, 2012, 02:49:09 AM

If the mini rig is supposed to have 17-18 units inside why does this board have 24 connectors?

Noooo, 29 connectors! That's how many cards are supposed to 'fit' into the rigbox (according to some old info, but they keep changing these things...)

Cool, some mini-rig porn to look at while waiting impatiently... Cool