just noticed 0820 has been posted...whats different in it?
The rest of the cgminer code was converted to the new timing code, and CPU overhead of the sha256 function was decreased and the binary made smaller so it's simply a sync with the latest cgminer git code. It might have lower CPU usage but to me appears pretty much the same since I'm only hitting 6% CPU max (with it usually lower) for cgminer. Most of the CPU load in an avalon is now all the background services. 
Topic: Avalon ASIC users thread - page 93. (Read 438516 times)
Quote
LEDs
Left: Green --> Power-on, Red --> PSU issue, OFF: --> No power
Right: Yellow --> FPGA Buffer empty(no task send out to fpga), OFF --> FPGA Buffer full(means mining)
https://en.bitcoin.it/wiki/Avalon#V1.61Left: Green --> Power-on, Red --> PSU issue, OFF: --> No power
Right: Yellow --> FPGA Buffer empty(no task send out to fpga), OFF --> FPGA Buffer full(means mining)
Maybe related.
Well that is then corresponding with when the avalon is ready/getting more work then. Why it suddenly started showing that, I don't know. Nor do I know why it doesn't show it on mine.
That's it then. The previous firmware would be checking every 40ms to see if it could send more work whereas the later (faster) firmware times it till just before the work is complete, even if the avalon is ready to take more work since loading more work sooner slows it down. The previous firmware would hammer it with no more than 40ms wait on it getting ready so the LED never really had a chance to light up for any extended period so it looked like it was always off.
just noticed 0820 has been posted...whats different in it?
flashing right now.orange led still blinking...
0820 seems to revert a previous commit.
As for the yellow blinking led, found this in Avalon wiki
Quote
LEDs
Left: Green --> Power-on, Red --> PSU issue, OFF: --> No power
Right: Yellow --> FPGA Buffer empty(no task send out to fpga), OFF --> FPGA Buffer full(means mining)
https://en.bitcoin.it/wiki/Avalon#V1.61Left: Green --> Power-on, Red --> PSU issue, OFF: --> No power
Right: Yellow --> FPGA Buffer empty(no task send out to fpga), OFF --> FPGA Buffer full(means mining)
Maybe related.
just noticed 0820 has been posted...whats different in it?
flashing right now.orange led still blinking...
just noticed 0820 has been posted...whats different in it?
Your maths is almost certainly not correct, for there is not enough information on that screen to even determine the hw error percentage.
I wish people would stop being obsessed by hw error count...
I wish people would stop being obsessed by hw error count...
I did the forumula that had been posted to arrive at the 6.7% (346,194 diff1), I cropped the screenshot just to show accepted/hw as in all the previous versions they were roughly the same number and it worked out at 1-2% (as it's 1/64).
I thought that discrepancy might be the reason for the 5GH drop in this version, was trying to help, appreciate the work you do.
Batch #3, 4 Modules and 20130819 not working so good for me, HW error rate has been 6.7% if my maths is correct, although cgminer reports 110GH pool has been saying around 105GH.
20130818 was running at 110GH, pool was reporting the same, and error rate was around 1-2% (accepted and HW were usually around the same number) so going to roll back to that and see what happens.
Your maths is almost certainly not correct, for there is not enough information on that screen to even determine the hw error percentage.20130818 was running at 110GH, pool was reporting the same, and error rate was around 1-2% (accepted and HW were usually around the same number) so going to roll back to that and see what happens.
I wish people would stop being obsessed by hw error count...
Batch #3, 4 Modules and 20130819 not working so good for me, HW error rate has been 6.7% if my maths is correct, although cgminer reports 110GH pool has been saying around 105GH.
20130818 was running at 110GH, pool was reporting the same, and error rate was around 1-2% (accepted and HW were usually around the same number) so going to roll back to that and see what happens.
20130818 was running at 110GH, pool was reporting the same, and error rate was around 1-2% (accepted and HW were usually around the same number) so going to roll back to that and see what happens.
Some of you have already spotted I uploaded a new firmware, 20130819
I upgraded my 4-module Batch 1 unit. 2h 40m later everything looks fine.
Well that is then corresponding with when the avalon is ready/getting more work then. Why it suddenly started showing that, I don't know. Nor do I know why it doesn't show it on mine.
I am on Slush's Pool if that has anything to do with it.
Should my network activity light on the router show activity with this same pattern?
I am on eligius's pool. The 20130703 software did not do this. The '14, '14-1, '18, and now '19 software do. I typically flash and do not power down the unit. I did power it down 24 hours after the '18 flash, to be sure it would start correctly. Please never-mind the lack of logic in that behavior.
I have a version 1.52 controller board, very late batch #2 unit.
Dunno if the lights are blinking, and I'm not going to check so it won't bug me if they are
I can save on Christmas decorations as well as heat.
They are blinking at regular intervals. They look synchronized as they blink
Yes, that is it. I measured roughly 10 blinks in 11.6 seconds. Both batch 2 and 3. My batch 1 design does not have the light but the fan with the blue light stopped.
My batch 2's orange light in blinking now too. It's still hashing away though.
Dunno if the lights are blinking, and I'm not going to check so it won't bug me if they are
I can save on Christmas decorations as well as heat.
They are blinking at regular intervals. They look synchronized as they blink
Some of you have already spotted I uploaded a new firmware, 20130819
http://ck.kolivas.org/apps/cgminer/avalon/20130819/
There was a substantial rewrite of the timing code going into 20130818 which is where the hashrate rise from that version came from.
http://ck.kolivas.org/apps/cgminer/avalon/20130819/
There was a substantial rewrite of the timing code going into 20130818 which is where the hashrate rise from that version came from.
Just flashed 20130819 onto my Block 2 which is in ~25 Ambient. --avalon-auto stabilized around:
349 for 20130703 (Got more than 35 days of uptime from this one)
345 for 20130814-1, with similar utility as 20130703
357 for 20130819, with much lower eligius rejects! Like, 1/3rd the reject rate.
Have yet to get a 3hr update from eligius, but my 22.5 minute accepted rate is...
88MHash/s!!
Dunno if the lights are blinking, and I'm not going to check so it won't bug me if they are
Some of you have already spotted I uploaded a new firmware, 20130819
http://ck.kolivas.org/apps/cgminer/avalon/20130819/
There was a substantial rewrite of the timing code going into 20130818 which is where the hashrate rise from that version came from. I extended the timing code to encompass all the aspects of the usb communications with the avalon in 20130819 so it's more robust with respect to staying in sync with results and not losing data. However, overall it performs identically in my testing since the previous version dropped results only very rarely anyway since it is only likely to be a problem when CPU load is high and since the recent changes to cgminer it hardly uses any CPU now - it's only the background services on the avalon that may cause spikes in CPU and affect cgminer indirectly. So consider this a minor upgrade only.
http://ck.kolivas.org/apps/cgminer/avalon/20130819/
There was a substantial rewrite of the timing code going into 20130818 which is where the hashrate rise from that version came from. I extended the timing code to encompass all the aspects of the usb communications with the avalon in 20130819 so it's more robust with respect to staying in sync with results and not losing data. However, overall it performs identically in my testing since the previous version dropped results only very rarely anyway since it is only likely to be a problem when CPU load is high and since the recent changes to cgminer it hardly uses any CPU now - it's only the background services on the avalon that may cause spikes in CPU and affect cgminer indirectly. So consider this a minor upgrade only.
I just flashed this firmware, and I can say that the HW rate has dropped about 30%-50%. Pretty amazing!
Some of you have already spotted I uploaded a new firmware, 20130819
http://ck.kolivas.org/apps/cgminer/avalon/20130819/
There was a substantial rewrite of the timing code going into 20130818 which is where the hashrate rise from that version came from. I extended the timing code to encompass all the aspects of the usb communications with the avalon in 20130819 so it's more robust with respect to staying in sync with results and not losing data. However, overall it performs identically in my testing since the previous version dropped results only very rarely anyway since it is only likely to be a problem when CPU load is high and since the recent changes to cgminer it hardly uses any CPU now - it's only the background services on the avalon that may cause spikes in CPU and affect cgminer indirectly. So consider this a minor upgrade only.
http://ck.kolivas.org/apps/cgminer/avalon/20130819/
There was a substantial rewrite of the timing code going into 20130818 which is where the hashrate rise from that version came from. I extended the timing code to encompass all the aspects of the usb communications with the avalon in 20130819 so it's more robust with respect to staying in sync with results and not losing data. However, overall it performs identically in my testing since the previous version dropped results only very rarely anyway since it is only likely to be a problem when CPU load is high and since the recent changes to cgminer it hardly uses any CPU now - it's only the background services on the avalon that may cause spikes in CPU and affect cgminer indirectly. So consider this a minor upgrade only.
Hi,
the other day I've upgraded three batch #1 three modules Avalons from 20130519 to 20130814... I've lost a good 10% of hashing capacity
Inside Avalon GUI I still see 70 GH, I'm not using --avalon-auto (nor any other option) given that I'm still using the stock PSU, but on pool graph you can clearly see when I've updated them
My question is: can I go back to 20130519 without problems or do I risk to brick them?
TIA
spiccioli
ps. I see that there is now 20130818, but I'd prefer to go back to what was working before trying next firmware.
the other day I've upgraded three batch #1 three modules Avalons from 20130519 to 20130814... I've lost a good 10% of hashing capacity
Inside Avalon GUI I still see 70 GH, I'm not using --avalon-auto (nor any other option) given that I'm still using the stock PSU, but on pool graph you can clearly see when I've updated them
My question is: can I go back to 20130519 without problems or do I risk to brick them?
TIA
spiccioli
ps. I see that there is now 20130818, but I'd prefer to go back to what was working before trying next firmware.
20130703 worked very well for me.
20130814 & 20130814-1 worked poorly.
20130818 was an improvement. It has run 24+ hours.
Hi,
the other day I've upgraded three batch #1 three modules Avalons from 20130519 to 20130814... I've lost a good 10% of hashing capacity
Inside Avalon GUI I still see 70 GH, I'm not using --avalon-auto (nor any other option) given that I'm still using the stock PSU, but on pool graph you can clearly see when I've updated them
My question is: can I go back to 20130519 without problems or do I risk to brick them?
TIA
spiccioli
ps. I see that there is now 20130818, but I'd prefer to go back to what was working before trying next firmware.
the other day I've upgraded three batch #1 three modules Avalons from 20130519 to 20130814... I've lost a good 10% of hashing capacity
Inside Avalon GUI I still see 70 GH, I'm not using --avalon-auto (nor any other option) given that I'm still using the stock PSU, but on pool graph you can clearly see when I've updated them
My question is: can I go back to 20130519 without problems or do I risk to brick them?
TIA
spiccioli
ps. I see that there is now 20130818, but I'd prefer to go back to what was working before trying next firmware.
I used --avalon-auto without upgrading my batch #2 PSU. I have flashed older firmware after newer firmware successfully without much hassle. 20130818 is awesome firmware, I'd say try that at least before going backwards.
_theJestre
My question is: can I go back to 20130519 without problems or do I risk to brick them?
Logically, there's no way for the TP-LINK router to be aware of the difference between "backwards" FW flashes and "forwards" FW flashes. Still, if you don't take my word for it, then I won't take responsibility for your new brick
. If it helps any more, I've already heard about people successfully re-flashing to older FW, in this thread I think.
Hi,
the other day I've upgraded three batch #1 three modules Avalons from 20130519 to 20130814... I've lost a good 10% of hashing capacity
Inside Avalon GUI I still see 70 GH, I'm not using --avalon-auto (nor any other option) given that I'm still using the stock PSU, but on pool graph you can clearly see when I've updated them
My question is: can I go back to 20130519 without problems or do I risk to brick them?
TIA
spiccioli
ps. I see that there is now 20130818, but I'd prefer to go back to what was working before trying next firmware.
the other day I've upgraded three batch #1 three modules Avalons from 20130519 to 20130814... I've lost a good 10% of hashing capacity
Inside Avalon GUI I still see 70 GH, I'm not using --avalon-auto (nor any other option) given that I'm still using the stock PSU, but on pool graph you can clearly see when I've updated them
My question is: can I go back to 20130519 without problems or do I risk to brick them?
TIA
spiccioli
ps. I see that there is now 20130818, but I'd prefer to go back to what was working before trying next firmware.
Jump to: