Pages:
Author

Topic: [Work in progess] Burnins Avalon Chip to mining board service - page 64. (Read 624200 times)

full member
Activity: 154
Merit: 100
When your order is shipped your order status will change to Complete and you will receive a mail with a tracking number, if applicable
sr. member
Activity: 490
Merit: 250
Burnin, any word on when order #824 will ship.  I placed an order for a BitBurnerXX with zefir batch #1 chips and attached heatsink on August 6th.  I lost access to my lavabit account because of Edward Snowden and the NSA unfortunately.  It still shows my order as "Processing" in my burninmining account.  I would really like to receive a tracking number or at least hear that it has or hasn't shipped.

Thanks!
hero member
Activity: 826
Merit: 1001
Tried the horizontal CAN-BUS ports, no change...
...
Try a canbus cable that only has as many connectors as you have boards.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
I have new firmware for you, that will increase the effective hashrate.
But it requires the newest cg-miner build from source to function.

https://www.dropbox.com/s/0lo1t40yhkbsq25/BB_Firmware_1.0.2.hex

This one now has a  number  Grin

And don't mix different FW-revisions in a cluster.

Source from ckolivas or Kano's repository?
I've committed it into ckolivas master git now
Though it does only add a "version" to the API stats
We don't use it for anything quite yet Smiley
However, ckolivas has been making some sweeping changes tonight so I'll post again here when we've finished with what he's doing - and thus when it's back to ideal to get current git

Edit: it shows 1.0.0 if your firmware doesn't have it
full member
Activity: 154
Merit: 100
I have new firmware for you, that will increase the effective hashrate.
But it requires the newest cg-miner build from source to function.

https://www.dropbox.com/s/0lo1t40yhkbsq25/BB_Firmware_1.0.2.hex

This one now has a  number  Grin

And don't mix different FW-revisions in a cluster.

Source from ckolivas or Kano's repository?
sr. member
Activity: 243
Merit: 250
ALTCOM Ab9upXvD7ChnJxDRZgMmwNNEf1ftCGWrsE
I have new firmware for you, that will increase the effective hashrate.
But it requires the newest cg-miner build from source to function.

https://www.dropbox.com/s/0lo1t40yhkbsq25/BB_Firmware_1.0.2.hex

This one now has a  number  Grin

And don't mix different FW-revisions in a cluster.
member
Activity: 70
Merit: 10
Is it normal that the last miner in a row of 5 is having the red led shining nearly all the time? Only blinking going out instead like the others that go on blinking?

Its this way:

Miner 1: Green normal blinking, Yellow not blinking, Red normal blinking
Miner 2-4: Green normal blinking, Yellow normal blinking, Red normal blinking
Miner 5: Green normal blinking, Yellow normal blinking, Red constantly on and going out blinking occassionally

Is this how it should be?

By the way. Till now i didnt find a way to get above a 42.34GH/s (The amount reaching the pool. No rejected shares and >1% HW) Settings are 29ms 440MHz 1330mV for this. Running at 50°C (Less when its night and its cooler.)

What is the power consumption?
legendary
Activity: 2674
Merit: 1083
Legendary Escrow Service - Tip Jar in Profile
Is it normal that the last miner in a row of 5 is having the red led shining nearly all the time? Only blinking going out instead like the others that go on blinking?

Its this way:

Miner 1: Green normal blinking, Yellow not blinking, Red normal blinking
Miner 2-4: Green normal blinking, Yellow normal blinking, Red normal blinking
Miner 5: Green normal blinking, Yellow normal blinking, Red constantly on and going out blinking occassionally

Is this how it should be?

By the way. Till now i didnt find a way to get above a 42.34GH/s (The amount reaching the pool. No rejected shares and >1% HW) Settings are 29ms 440MHz 1330mV for this. Running at 50°C (Less when its night and its cooler.)
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
The current firmware doesn't report the fw-version.

OK, yep got the email from Mr Firmware Smiley
I'll try adding it so that it reports 0.0.0 if it is missing or whatever it is if it is there.
(I can also try with some of the older firmware I have to make sure it works)
sr. member
Activity: 243
Merit: 250
ALTCOM Ab9upXvD7ChnJxDRZgMmwNNEf1ftCGWrsE
The current firmware doesn't report the fw-version.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
A completely aside comment ... just in case you didn't spot the obvious Smiley
Until the problem is sorted, you can of course mine with 4 independent BTBs with 4 USB cables

The later firmware is supposed to report a version number, I'll track down that to find out how I can check for it in cgminer so to be able to check exactly what the version number is.
I don't know the control transfer codes to read it.
Burnin, if you happen to know, could you post/PM me the info.
sr. member
Activity: 322
Merit: 250
Tried cgminer 3.2, no change :/

Tried just 2 boards / 3 , no combination seems to work....

Tried the horizontal CAN-BUS ports, no change...


put my multimeter up to the jumpers, it showed no resistance over the jumpers in the direction of the photo example on the website (front to back), however, in the other direction (left to right), resistance was there .... moved the jumpers into that configuration, and no change...... Sad


Code:

Aug 17 10:58:06 sol kernel: [431166.353607] usb 6-2: new full-speed USB device number 34 using uhci_hcd
Aug 17 10:58:06 sol mtp-probe: checking bus 6, device 34: "/sys/devices/pci0000:00/0000:00:1d.0/usb6/6-2"
Aug 17 10:58:06 sol mtp-probe: bus: 6, device: 34 was not an MTP device
Aug 17 10:58:06 sol kernel: [431166.523836] generic-usb 0003:04D8:003C.000D: hiddev0,hidraw0: USB HID v1.11 Device [Microchip Technology Inc. USB HID Bootloader] on usb-0000:00:1d.0-2/input0
Aug 17 10:58:18 sol kernel: [431178.140626] usb 6-2: USB disconnect, device number 34
Aug 17 10:58:19 sol kernel: [431179.372112] usb 6-2: new full-speed USB device number 35 using uhci_hcd
Aug 17 10:58:19 sol mtp-probe: checking bus 6, device 35: "/sys/devices/pci0000:00/0000:00:1d.0/usb6/6-2"
Aug 17 10:58:19 sol mtp-probe: bus: 6, device: 35 was not an MTP device
Aug 17 10:58:19 sol kernel: [431179.536550] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected
Aug 17 10:58:19 sol kernel: [431179.536585] usb 6-2: Detected FT232RL
Aug 17 10:58:19 sol kernel: [431179.536588] usb 6-2: Number of endpoints 2
Aug 17 10:58:19 sol kernel: [431179.536591] usb 6-2: Endpoint 1 MaxPacketSize 64
Aug 17 10:58:19 sol kernel: [431179.536593] usb 6-2: Endpoint 2 MaxPacketSize 64
Aug 17 10:58:19 sol kernel: [431179.536596] usb 6-2: Setting MaxPacketSize 64
Aug 17 10:58:19 sol kernel: [431179.538614] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0

This *looks* ok .... stumped....

I would take photos, but they look exactly like the the website + other photos here,

Tried my spare can-bus cable .... no change ....


Code:
root@sol:~/cgminer# ./cgminer -n
 [2013-08-17 11:09:09] USB all: found 9 devices - listing known devices
.USB dev 0: Bus 6 Device 38 ID: 0403:6001
  Manufacturer: 'Burnin Electronics'
  Product: 'BitBurner'
 [2013-08-17 11:09:09] 1 known USB devices
root@sol:~/cgminer#
sr. member
Activity: 322
Merit: 250
That shouldn't make a difference.
When CAN is working the yellow LED on both boards should flash when running cgminer.
Could you triple check those jumpers?

Have you read the instructions?
http://www.burninmining.com/news/

yellow light only flashing on one board that i have the USB plugged into

reflashed 4 devices, using

https://www.dropbox.com/s/q22eb8f85ybtxzm/BitBurner_08.05b.hex

triple checked the jumpers - using the jumper supplied in the box, they are aligned in the same fashion as the pics on your news section, two jumpers on the first board, two jumpers on the last board in the chain

plugged the CAN cable by using the top 4 plugs in the chain, tried others also.

only one board seems to be doing work, the one that the usb is plugged into only, switching the usb cable around doesnt change anything else either, only the board thats plugged in does the work

using settings:

Code:
./cgminer --avalon-options 115200:8:10:35:282 --avalon-temp 45 -u xxx -p 12345 -o eu-stratum.btcguild.com:3333

Code:
[P]ool management [S]ettings [D]isplay options [Q]uit
 BTB 0: 38/ 38C 1221mV | 86.48M/2.862Gh/s | A:6 R:0 HW:0 WU: 80.0/m
--------------------------------------------------------------------------------

 [2013-08-17 09:40:07] Started cgminer 3.3.4
 [2013-08-17 09:40:07] BTB0: Reset succeeded
 [2013-08-17 09:40:07] BTB0: Idling 1 miners
 [2013-08-17 09:40:08] BTB0: Core voltage set to 1200 millivolts
 [2013-08-17 09:40:08] Probing for an alive pool
 [2013-08-17 09:40:08] Pool 0 difficulty changed to 2
 [2013-08-17 09:40:08] Network diff set to 50.8M
 [2013-08-17 09:40:08] Stratum from pool 0 detected new block
 [2013-08-17 09:40:09] Avalon: Discarding 32 bytes from buffer
 [2013-08-17 09:40:14] Accepted 2b6307a5 Diff 5/2 BTB 0
 [2013-08-17 09:40:14] Accepted 062d3b04 Diff 41/2 BTB 0
 [2013-08-17 09:40:15] Accepted 2f272947 Diff 5/2 BTB 0

Code:

root@atom:~/cgminer# ./cgminer -V
cgminer 3.3.4
root@atom:~/cgminer#

Code:
root@sol:~/cgminer# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.04
DISTRIB_CODENAME=precise
DISTRIB_DESCRIPTION="Ubuntu 12.04.2 LTS"
root@sol:~/cgminer#


root@sol:~/cgminer# uname -a
Linux sol 3.2.0-39-generic #62-Ubuntu SMP Thu Feb 28 00:28:53 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux



Cant understand why this isnt working, version of cgminer perhaps?!

recompiled cgminer from github, no errors anywhere, on a different server, same issue, only one bitburner is doing work.


legendary
Activity: 966
Merit: 1000
Burnin, my chips have been awaiting you at your post office.  Tracking says "Addressee requests own pick-up - Item being held, addressee being notified"

See my PM for the tracking number.

They are at the customs office.

Does that mean there is a fee due?  What does it take to get them from the customs office?
legendary
Activity: 2674
Merit: 1083
Legendary Escrow Service - Tip Jar in Profile
Thanks for all the explaination.

I guess i dont have Java installed then on the rpi, i used a noob image for raspi. Raspberian or so. But i will try again when im home.

Is WU including rejected shares too? I found an interesting thing in the morning when i tested with the timeout a bit. I sat 1340mV, 450MHz and 25, or was it 20ms? timeout. After 10 minutes there were zero rejected shares. ZERO. While normally 13% rejected shares appear. I cant explain but the hashrate at the pool went from 38GH to 42GH by doing this. So it looks it really has an effect. The hashrate in cgminer didnt change by doing that so i think rejected shares are included and its not a safe value to judge efficient. Maybe its best to use the pool for the value since it only seems to count hashrate that delivers correct shares.
So at the moment i believe WU includes rejected shares too since they didnt change.

Im still puzzled about the drop in hashrate, wattage and all when using higher values. I hope burnin finds an explaination.
Meh, I wish my 2nd RPi would hurry up and arrive.
I run Arch on my RPi now and it's in my garage, so it's annoying to switch it back to Raspbian temporarily to check anything
(also one of the reasons why I bought a 2nd RPi)

Anyway I think the package is:
apt-get install openjdk-7-jdk

Rejected shares are not HW errors.
Rejected shares should only be during an LP - coz of:
1) Your hardware latency is high
  This can be reduced by aborting the work at LP rather than waiting for it to finish.
  I'm pretty sure it can't be done with an Avalon, but there was mention of adding an abort to the BTB firmware
  Reducing the timeout will also reduce this, but reducing the timeout too much is also bad as I mentioned before
2) Your pool latency is high
  Speed up your connection to the pool (too many hops, too much latency through the net from you to the pool ...)
  Tell the pool to do better when supplying you with LP information - e.g. use Stratum (not GetWork or GBT)
3) Some pools don't handle diff changes properly or don't handle a stratum reconnect properly ...

Some pools also pay Stale shares (which is what a Rejected share is in cgminer) so you shouldn't get them on those pools
The pool itself also replies with the reason why the share was rejected - that's what's in the () at the end

HW is ignore since indeed it is a fault of the hardware.

I was able to install that java package but when i run that command in cgminer dir and cgminer is running "bash: java: unknown command" for all commands you wrote.

Anyway. I know the formula now. I calculated that 450MHz should be 28.2ms timeout. Im not sure if its perfect because when i tested it at the day i got 10% rejected shares. One ms less zero rejected shares. But now, at the evening i cant replicate that anymore. The d param works now and no rejected shares. I dont know why.
My pool doesnt count rejected shares and i wouldnt want my pool paying out rejected shares to others when i know how i can prevent rejected shares.

Based on this i started another test. I sat the mhz to 450 and didnt bother with HW. Only WU was of interest for me. Even with >50% HW the WU calculates all shares. Every test i ran for 15minutes after that my htc ringed to read the values. After that time the values have relatively good settled. So i tested and found that the optimum voltage is 1228mV with 670WU. Unfortunately when it became later and the temperature went down outside the bitburner cooled down too. Which leaded to the effect that the temperature went from 50°C to 46°C and at the same time 1228mV only was 630WU anymore. Instead the optimum voltage was at 1224 now. 4mV less because 4°C less. So 4mV does have such a big impact. I tend to believe a settings per °C is needed because one cant change it back and forth when you host it at a datacentre.

*sigh* And i hoped to find an ideal setting...

At least its interesting to know that the voltage always has a sweet spot at a working temperature. Going 100mV above or below has a big impact. Even one mV can have a not small effect. I cant explain why.
sr. member
Activity: 243
Merit: 250
ALTCOM Ab9upXvD7ChnJxDRZgMmwNNEf1ftCGWrsE
Burnin, my chips have been awaiting you at your post office.  Tracking says "Addressee requests own pick-up - Item being held, addressee being notified"

See my PM for the tracking number.

They are at the customs office.
legendary
Activity: 966
Merit: 1000
Burnin, my chips have been awaiting you at your post office.  Tracking says "Addressee requests own pick-up - Item being held, addressee being notified"

See my PM for the tracking number.
sr. member
Activity: 243
Merit: 250
ALTCOM Ab9upXvD7ChnJxDRZgMmwNNEf1ftCGWrsE
That shouldn't make a difference.
When CAN is working the yellow LED on both boards should flash when running cgminer.
Could you triple check those jumpers?

Have you read the instructions?
http://www.burninmining.com/news/
sr. member
Activity: 322
Merit: 250
ah! i didnt click "run application", im assuming thats the issue here

going back to reflash....
sr. member
Activity: 322
Merit: 250
im stuck anyone got any clues what to do?

ive double checked the jumpers, moved the stacking cable around, but no luck, what am i doing wrong?

cheers..

Sounds like you didn't update the firmware.


Hmm, i upgraded using this hex file on all bitburners: (as per the link on your website)

https://www.dropbox.com/s/q22eb8f85ybtxzm/BitBurner_08.05b.hex

Got this as the output on all of them

Code:
Device connected
Bootloader Firmware Version: 1.0
Hex file loaded successfully
Flash Erased
Programming completed
Verification successfull
Verification successfull
Device disconnected


Pages:
Jump to: