Author

Topic: Avalon ASIC users thread - page 176. (Read 438600 times)

legendary
Activity: 1246
Merit: 1002
May 27, 2013, 06:56:13 PM
Thank you for your work.
I really do not understand Avalon ... Would be so easy to get you at least a one module device
1. thx too  Smiley
2. best thing they could do to send you and/or kano only one module for free...
(IMHO)
Send 2 modules to him Smiley
I'm not sure why they say they wont do it ...

There are about 900 Avalons scheduled.  Proceeds of about BTC 0.1 from each one to the ckolivas Asic account would buy him one.  There is just as much reason for us to do that as there is for Avalon to do it.
sr. member
Activity: 448
Merit: 250
May 27, 2013, 06:38:36 PM
I'm not sure why they say they wont do it ...

Obviously they don't want a working market for their hardware?
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
May 27, 2013, 06:37:48 PM
Thank you for your work.
I really do not understand Avalon ... Would be so easy to get you at least a one module device
1. thx too  Smiley
2. best thing they could do to send you and/or kano only one module for free...
(IMHO)
Send 2 modules to him Smiley
I'm not sure why they say they wont do it ...
legendary
Activity: 2955
Merit: 1049
May 27, 2013, 06:10:10 PM
Thank you for your work.
I really do not understand Avalon ... Would be so easy to get you at least a one module device
1. thx too  Smiley
2. best thing they could do to send you and/or kano only one module for free...
(IMHO)
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
May 27, 2013, 06:03:16 PM
I'm planning on using the built in TP-LINK WR703N. It's trivial to flash the unit with new a new .bin file. I'd rethink my plan if there was a substancial performance boost, but it doesn't seem that would be the case.

All that being said, if / when the TP-Link eats it, I'll probably replace it with whatever I have laying around.

It's not that I'm opposed to building my own binaries, just don't see the benefit for the time spent on it.
Performance will be identical because the serial driver is not rate limiting. However reliability may be different, but only time will tell that for sure.
yxt
legendary
Activity: 3528
Merit: 1116
May 27, 2013, 05:58:22 PM
Thank you for your work.
I really do not understand Avalon ... Would be so easy to get you at least a one module device

as already said. Allow hashing donations in cgminer  Smiley
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
May 27, 2013, 05:31:08 PM
Will SSH access to a retail TP-Link 703n, or even a (to be delivered Real Soon Now) Avalon help you?
Specifically what I need is an equivalent mips router like the 703n with a kernel that has usbmon support built into it that is attached to a real Avalon via USB so I can monitor the communications that way.
legendary
Activity: 1764
Merit: 1002
May 27, 2013, 04:58:22 PM
i was wondering how i can connect remotely to the rig? Usually i do this with Teamviewer, but i guess thats not an option with the Avalons.

So how to remote control the rig?

As the TP-LINK TL-WR703N runs an embedded version of Linux, you connect to it (command line) with SSH as root. Or you use a web browser to log into the web interface.

how would you get to it if you're solo mining from a data center?
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
May 27, 2013, 04:36:45 PM
So I have completed 3 major rewrites of the avalon driver code to improve it. One was playground for testing things out and never really built, but I'm left with two different rewrites, and a question for existing users.

The first is a complete rewrite of the read/write mechanism using the existing serial usb driver (ftdi) which should be much more robust at staying in sync with results coming in from the device, as well as more accurately picking when the device is misbehaving and hopefully be more reliable at resetting it. This code is currently in a git branch called avalon-serialdev .


Will SSH access to a retail TP-Link 703n, or even a (to be delivered Real Soon Now) Avalon help you?


Hi ckolivas,

is new code and/or are new avalons able to fully restart the control unit (FPGA)?

I'm asking because this would be the real advantage, if not I'd go with the new serial code since a stuck avalon would need a full restart anyway.

spiccioli
The previous code used the fpga reset command but at some stage the fpga stopped responding to that command. It's hard to know if that was because it reached a point where it needed to be power cycled or the old code was not able to send the command in sync at the right time ever again. I'm hoping that with the new code it will avoid the latter situation but will be unable to do anything about the former. So the answer is: I'm not sure.
legendary
Activity: 1379
Merit: 1003
nec sine labore
May 27, 2013, 02:10:20 PM
So I have completed 3 major rewrites of the avalon driver code to improve it. One was playground for testing things out and never really built, but I'm left with two different rewrites, and a question for existing users.

The first is a complete rewrite of the read/write mechanism using the existing serial usb driver (ftdi) which should be much more robust at staying in sync with results coming in from the device, as well as more accurately picking when the device is misbehaving and hopefully be more reliable at resetting it. This code is currently in a git branch called avalon-serialdev .


Will SSH access to a retail TP-Link 703n, or even a (to be delivered Real Soon Now) Avalon help you?


Hi ckolivas,

is new code and/or are new avalons able to fully restart the control unit (FPGA)?

I'm asking because this would be the real advantage, if not I'd go with the new serial code since a stuck avalon would need a full restart anyway.

spiccioli
legendary
Activity: 1246
Merit: 1002
May 27, 2013, 10:45:52 AM
So I have completed 3 major rewrites of the avalon driver code to improve it. One was playground for testing things out and never really built, but I'm left with two different rewrites, and a question for existing users.

The first is a complete rewrite of the read/write mechanism using the existing serial usb driver (ftdi) which should be much more robust at staying in sync with results coming in from the device, as well as more accurately picking when the device is misbehaving and hopefully be more reliable at resetting it. This code is currently in a git branch called avalon-serialdev .

The second is an even more complete rewrite, built on the avalon-serialdev one with direct USB bypassing the ftdi driver entirely. The avalon does some weird and (not so) wonderful things to emulate running serial at 115200 baud, and the ftdi chip has some serious limitations I never would have known about had I not started poking around (for instance, the driver reads from the device every 1 millisecond because the buffer is so small it easily overflows). The modified code is more efficient and uses a lot less OS-kernel time but the demonstrable CPU usage of cgminer itself looks the same. This code works reliably and solidly... on a linux PC. This code is currently in a git branch called avalon-usbdev .

Now this is where it gets tricky. The direct USB code does not really work at all on the MIPS router that is built into the Avalon device itself. I'm not really sure if it's a libusb limitation, a different implementation or what, but it just does not work, and what does work appears extraordinarily slow. Only installing usbmon onto the device will tell me for sure, and that's not as trivial as I wish it were. We'll see how much time I get in the future to investigate this and whether it's even worth doing or not.

So down to my questions. How many avalon users here wish to be running them via a PC instead of as the standalone device it is? I suspect precious few. How many of you even want to be building your own binaries versus the number downloading the latest firmware? It would be possible to release a new version of cgminer that has both drivers but that will become a maintenance burden long term - and without having an avalon myself, it could end up going to bitrot. I've already made massive improvements to the serial usb based code and would be happy to push that alone into the next cgminer version and Xiangfu should be able to make you all new firmware with it.

I should add the Avalon team have made it clear they will not be providing me with a free Avalon outright to further development. Talks continue on that front...

Will SSH access to a retail TP-Link 703n, or even a (to be delivered Real Soon Now) Avalon help you?
sr. member
Activity: 351
Merit: 250
May 27, 2013, 10:29:03 AM

So down to my questions. How many avalon users here wish to be running them via a PC instead of as the standalone device it is? I suspect precious few. How many of you even want to be building your own binaries versus the number downloading the latest firmware? It would be possible to release a new version of cgminer that has both drivers but that will become a maintenance burden long term - and without having an avalon myself, it could end up going to bitrot. I've already made massive improvements to the serial usb based code and would be happy to push that alone into the next cgminer version and Xiangfu should be able to make you all new firmware with it.

My first request would be for the Avalon team to get you a unit! The amount of work you, kano, and I don't know who else, have put into developing the cgminer code for the Avalon is simply amazing. Thanks!

I'm planning on using the built in TP-LINK WR703N. It's trivial to flash the unit with new a new .bin file. I'd rethink my plan if there was a substancial performance boost, but it doesn't seem that would be the case.

All that being said, if / when the TP-Link eats it, I'll probably replace it with whatever I have laying around.

It's not that I'm opposed to building my own binaries, just don't see the benefit for the time spent on it.

-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
May 27, 2013, 07:09:05 AM
So I have completed 3 major rewrites of the avalon driver code to improve it. One was playground for testing things out and never really built, but I'm left with two different rewrites, and a question for existing users.

The first is a complete rewrite of the read/write mechanism using the existing serial usb driver (ftdi) which should be much more robust at staying in sync with results coming in from the device, as well as more accurately picking when the device is misbehaving and hopefully be more reliable at resetting it. This code is currently in a git branch called avalon-serialdev .

The second is an even more complete rewrite, built on the avalon-serialdev one with direct USB bypassing the ftdi driver entirely. The avalon does some weird and (not so) wonderful things to emulate running serial at 115200 baud, and the ftdi chip has some serious limitations I never would have known about had I not started poking around (for instance, the driver reads from the device every 1 millisecond because the buffer is so small it easily overflows). The modified code is more efficient and uses a lot less OS-kernel time but the demonstrable CPU usage of cgminer itself looks the same. This code works reliably and solidly... on a linux PC. This code is currently in a git branch called avalon-usbdev .

Now this is where it gets tricky. The direct USB code does not really work at all on the MIPS router that is built into the Avalon device itself. I'm not really sure if it's a libusb limitation, a different implementation or what, but it just does not work, and what does work appears extraordinarily slow. Only installing usbmon onto the device will tell me for sure, and that's not as trivial as I wish it were. We'll see how much time I get in the future to investigate this and whether it's even worth doing or not.

So down to my questions. How many avalon users here wish to be running them via a PC instead of as the standalone device it is? I suspect precious few. How many of you even want to be building your own binaries versus the number downloading the latest firmware? It would be possible to release a new version of cgminer that has both drivers but that will become a maintenance burden long term - and without having an avalon myself, it could end up going to bitrot. I've already made massive improvements to the serial usb based code and would be happy to push that alone into the next cgminer version and Xiangfu should be able to make you all new firmware with it.

I should add the Avalon team have made it clear they will not be providing me with a free Avalon outright to further development. Talks continue on that front...
ImI
legendary
Activity: 1946
Merit: 1019
May 26, 2013, 06:56:18 PM

OK, thx. Seems to be not a big issue then.
legendary
Activity: 1112
Merit: 1000
May 26, 2013, 06:03:32 PM
i was wondering how i can connect remotely to the rig? Usually i do this with Teamviewer, but i guess thats not an option with the Avalons.

So how to remote control the rig?

As the TP-LINK TL-WR703N runs an embedded version of Linux, you connect to it (command line) with SSH as root. Or you use a web browser to log into the web interface.
ImI
legendary
Activity: 1946
Merit: 1019
May 26, 2013, 05:54:29 PM

Hi there,

i was wondering how i can connect remotely to the rig? Usually i do this with Teamviewer, but i guess thats not an option with the Avalons.

So how to remote control the rig?

ImI

legendary
Activity: 1792
Merit: 1047
May 26, 2013, 06:54:07 AM
Mad props and huge thanks to Sitarow who has given me uninterrupted remote access to an avalon this past week, including the ability to power cycle one  Grin. This has allowed me to write a major overhaul of the avalon code which should make it into the next cgminer release.

Thank you.

The time and effort made by people like kano and yourself on getting cgminer and other similar miners refined is very much appreciated.

This holds true even by those that may not directly participate in mining.

However new "miners" should not forget efforts spent to refine projects like cgminer will further decentralize ASIC hardware access and promote other DIY projects down the road.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
May 26, 2013, 02:29:55 AM
Mad props and huge thanks to Sitarow who has given me uninterrupted remote access to an avalon this past week, including the ability to power cycle one  Grin. This has allowed me to write a major overhaul of the avalon code which should make it into the next cgminer release.
hero member
Activity: 956
Merit: 1001
May 25, 2013, 12:31:42 PM
xiangfu,

any further info on the fpga firmware/bitstream?

http://downloads.qi-hardware.com/people/xiangfu/avalon/fpga-controller/

is a JTAG required to flash the fpga?
full member
Activity: 120
Merit: 100
Jump to: