elasticband
Legendary
Offline
Activity: 1036
Merit: 1000
Nighty Night Don't Let The Trolls Bite Nom Nom Nom
|
|
February 23, 2014, 02:45:05 PM |
|
okay it is not as back and white as just yes or no things can go up down left right or just straight sideways
|
|
|
|
jelin1984
Legendary
Offline
Activity: 2408
Merit: 1004
|
|
February 23, 2014, 02:52:30 PM |
|
You think leave it as it is
Hashing at 640 gh Code 211
And firmware 1.00
|
|
|
|
crashoveride54902
|
|
February 23, 2014, 03:00:14 PM |
|
Got my second October 4VRM Jupiter in and on first bootup worked fine for a few hours. I updated to 1.0 to test and I noticed when I turned off SPI Auto this: I've tried the hit it with SPI 3.3 and max voltage. Let it run a few hours like that. I have had them drop when OC to high but this I can't seem to rescue. There is it at max voltage on that one. I've swapped back to .99.1 , .99.2 and 1.0 and can't seem to get it to jump back up. I've tried running 231 and 221 but sadly nothing helped kick that one up even. Any other suggestions so I can put this Jupiter to a happy # I've been having the same problem until today on my O S+1. Now SPI @3.3V and die1 with -0.0806V and 675MHz made it work. I was getting higher rates with 231 around 450GH/s. Now with all other dies @775MHz total close to 425GH/s with less errors.... Also with all other dies at -0.1465V, power dropped from 560W (w/ Stock values) to 460W at the wall. Is there a way to 231 the other ASICs and leave this slepy die1 on ASIC alone @675MHz? yes read the thread and find the msg where it talks about making every die different oc
|
Dreams of cyprto solving everything is slowly slipping away...Replaced by scams/hacks
|
|
|
jelin1984
Legendary
Offline
Activity: 2408
Merit: 1004
|
|
February 23, 2014, 04:52:27 PM |
|
Advanced Tuning SPI voltage
Auto SPI Voltage SPI Frequency
Power Consumption
666.498 W
ASIC 1
die 1 die 2 die 3 die 4
Temp : 54.0 °C
Power : 161.148 W
DC/DC Voltage (V) Current (A) Power (W) 0 0.7822 50.0000 39.110 2 0.7822 49.8750 39.012 4 0.8008 53.0625 42.492 7 0.7861 51.5625 40.533 ASIC 3
die 1 die 2 die 3 die 4
Temp : 58.5 °C
Power : 174.061 W
DC/DC Voltage (V) Current (A) Power (W) 0 0.8135 53.0625 43.166 2 0.7969 53.5625 42.684 4 0.8047 54.5625 43.906 7 0.8037 55.1250 44.304 ASIC 4
die 1 die 2 die 3 die 4
Temp : 57.0 °C
Power : 169.884 W
DC/DC Voltage (V) Current (A) Power (W) 0 0.7832 51.3750 40.237 2 0.7949 53.6875 42.676 4 0.8096 55.0625 44.579 7 0.8008 52.9375 42.392 ASIC 5
die 1 die 2 die 3 die 4
Temp : 43.0 °C
Power : 161.405 W
DC/DC Voltage (V) Current (A) Power (W) 0 0.7891 48.8125 38.518 2 0.8076 49.6875 40.128 4 0.7832 51.1875 40.090 7 0.7920 53.8750 42.669 Apply changes
|
|
|
|
jelin1984
Legendary
Offline
Activity: 2408
Merit: 1004
|
|
February 23, 2014, 04:52:42 PM |
|
|
|
|
|
DPoS
|
|
February 23, 2014, 05:11:40 PM |
|
I've been having the same problem until today on my O S+1. Now SPI @3.3V and die1 with -0.0806V and 675MHz made it work. I was getting higher rates with 231 around 450GH/s. Now with all other dies @775MHz total close to 425GH/s with less errors.... Also with all other dies at -0.1465V, power dropped from 560W (w/ Stock values) to 460W at the wall. Is there a way to 231 the other ASICs and leave this slepy die1 on ASIC alone @675MHz? So you ran the whole board at 1A1 and the dead die came back to life? Did you have to roast it to 80c first? I just tried to run the dead die at that speed and keep the rest overclocked and it didn't wake up.. maybe the whole board huh? no magic bullet yet
|
|
|
|
jelin1984
Legendary
Offline
Activity: 2408
Merit: 1004
|
|
February 23, 2014, 05:25:13 PM |
|
Mining Status
CGMiner Status Running (pid=22518) Last Checked Sun Feb 23 17:25:03 UTC 2014 Avg. Hash Rate 644 Gh/s Difficulty Accepted 198,080 Difficulty Rejected 2,496 (1.4 %) Hardware Errors 2,110 (1.2 %) WU 9,000 Difficulty Stale 0 Network Blocks 3 Pool Rejected 1.2 % Pool Stale 0 Best Share 288,540 Found Blocks 0 HW Status
ASIC slot #1 51.5 ℃ ASIC slot #2 - ASIC slot #3 56.0 ℃ ASIC slot #4 59.0 ℃ ASIC slot #5 45.0 ℃ ASIC slot #6 -
|
|
|
|
kendog77
|
|
February 23, 2014, 06:24:20 PM Last edit: February 23, 2014, 07:06:54 PM by kendog77 |
|
The 1.0 firmware works really well with November Jupiters.
I simply changed the speed of all cores from 900 to 1000 and did nothing more, and my best November Jupiter increased from 675 GH to 750 GH. My other November Jupiter increased from 650 GH to 725 GH. Hardware errors also did not increase after overclocking, so the systems have been very stable after the overclock.
The 1.0 firmware really does nothing for October Jupiters though, as the overclocking options are very limited since the core speed can only be increased from 750 to 775. Custom hacking / overclocking still works best for October Jupiters.
|
|
|
|
jelin1984
Legendary
Offline
Activity: 2408
Merit: 1004
|
|
February 23, 2014, 07:37:01 PM |
|
Is safe to go at 1000 .?
|
|
|
|
crashoveride54902
|
|
February 23, 2014, 10:14:03 PM |
|
Is safe to go at 1000 .?
not on 4vrm units
|
Dreams of cyprto solving everything is slowly slipping away...Replaced by scams/hacks
|
|
|
Tigggger
Legendary
Offline
Activity: 1098
Merit: 1000
|
|
February 23, 2014, 11:14:44 PM |
|
The 1.0 firmware works really well with November Jupiters.
I simply changed the speed of all cores from 900 to 1000 and did nothing more, and my best November Jupiter increased from 675 GH to 750 GH. My other November Jupiter increased from 650 GH to 725 GH. Hardware errors also did not increase after overclocking, so the systems have been very stable after the overclock.
The 1.0 firmware really does nothing for October Jupiters though, as the overclocking options are very limited since the core speed can only be increased from 750 to 775. Custom hacking / overclocking still works best for October Jupiters.
I noticed similar on my november one. I had to leave one die at 950 as the voltage/amps on it kept dropping to 0, but all the rest at 1000 and gone from 650 to 725 so very happy, and the reduction in HW errors is massive, previously around 1.5% now down to 0.07% Changed my october one as well to reduce the hardware errors, changed them all to 775 but only getting 570GH which is down from the previous 620GH Went to change the cgminer.sh file but the line I used to edit has gone cmd=$(printf "0x86,0x%02X,0x01,0xF1" $c)
to this:
cmd=$(printf "0x86,0x%02X,0x02,0x11" $c)
Will I have to roll back firmware or is there a new edit ?
|
|
|
|
capa
|
|
February 23, 2014, 11:18:14 PM |
|
I am in the same position, I've tried rolling back the firmware but it just trashed the miner and i had to put 1.0 firmware back on Contemplating using the recovery file now
|
|
|
|
Scoobypup
Newbie
Offline
Activity: 39
Merit: 0
|
|
February 24, 2014, 04:35:36 AM |
|
If the 1.0.0 firmware now has an "overclocking" feature built into the web interface, couldn't we just modify the web interface files to include increases past the 775/1000 limit that the stock firmware has? That seems like it would be an easier method (if possible) for those unfamiliar with a *nix interface and editing files with vi. Just an open thought of course.
|
|
|
|
DPoS
|
|
February 24, 2014, 04:39:38 AM |
|
If the 1.0.0 firmware now has an "overclocking" feature built into the web interface, couldn't we just modify the web interface files to include increases past the 775/1000 limit that the stock firmware has? That seems like it would be an easier method (if possible) for those unfamiliar with a *nix interface and editing files with vi. Just an open thought of course.
I was thinking that.. but currently running ~43Gh per die (at the pool) so don't want to mess with anything
|
|
|
|
electrox
Newbie
Offline
Activity: 11
Merit: 0
|
|
February 24, 2014, 11:38:39 AM |
|
Hi out there. I am quite newbie to overclocking my October Saturn and have so far limited myself to using the new 1.00 firmware to increase clock frequenzy from 750 to 775 Mhz and it worked out fine. I made a configuration backup (under the 'Upgrade' tab) and looking into 'advanced.conf' I can read the clock frequenzies mentioned at 775 Mhz as expected. Since the miner probably does not actually uses the value '775' directly when setting the settings internally in the miner I would assume these frequencies/values refer to a list somewhere which interprets the clock frequenzy into a hex. For example 775 interprets into 1E1 if I read the list correctly. 1E1 is then used to configure the clock frequenzy. Am I correct? So my thinking is that maybe the user interface of firmware 1.00 limits me from going higher than 775 Mhz on my October Saturn but I think KNC use the same firmware also for November units. So maybe the dropdown list is limited to max 775 Mhz (because the firmware recognizes my miner as an October unit) but the actual list used for interpreting 775Mhz into 1E1 may be complete up to 1000Mhz (but only used for November units). So my idea (which I did not dare to test yet...) is that I could change the 'advanced.conf' file to mention a higher clock frequenzy value and up load this new configuration to the miner which then finds a corresponding setting in the (hidden) list and voila... the overclocking is a reality. Did somebody already try this approach? What do you think about this? Could it work?
|
|
|
|
capa
|
|
February 24, 2014, 12:13:04 PM |
|
I've tried editing the advanced.conf and changing the 775 value up to 975, the only thing that happened was, it blanked out the mhz value in the web interface.
|
|
|
|
electrox
Newbie
Offline
Activity: 11
Merit: 0
|
|
February 24, 2014, 12:16:32 PM |
|
@ capa Thanks for the feedback. Did you try a more modest increase. For example 800? You say it blanked out the value in the web interface. But did the miner continue to run at 775Mhz?
|
|
|
|
electrox
Newbie
Offline
Activity: 11
Merit: 0
|
|
February 24, 2014, 12:40:18 PM |
|
Looking at the source code for the 'Advanced' tab I find in line 44-46 the following: var dieFreqTemplate = $('<select/>'); $.each(config.valid_die_frequencies, function(i, frequency) { dieFreqTemplate.append('<option value="' + frequency + '">' + frequency + ' MHz</option>'); it looks like this is a lookup of valid die frequencies from a file named 'config.valid_die_frequencies'. Maybe we just have to find this file and amend it?
|
|
|
|
padrino
Legendary
Offline
Activity: 1428
Merit: 1000
https://www.bitworks.io
|
|
February 24, 2014, 03:53:06 PM |
|
Looking at the source code for the 'Advanced' tab I find in line 44-46 the following: var dieFreqTemplate = $('<select/>'); $.each(config.valid_die_frequencies, function(i, frequency) { dieFreqTemplate.append('<option value="' + frequency + '">' + frequency + ' MHz</option>'); it looks like this is a lookup of valid die frequencies from a file named 'config.valid_die_frequencies'. Maybe we just have to find this file and amend it? In short the CGI backend calls "waas -i valid-config" to determine which settings the ASIC allows. "config.valid_die_frequencies" is the JSON element reqturned from waas that is used to populate the drop down. waas itself also applies all settings and it will not accept anything outside of the range supported, be it 775 on the October and 1000 on the November. I hacked up the firmware to allow settings outside of the range, I am working through one issue now and will post it when it's done..
|
|
|
|
idee2013
|
|
February 24, 2014, 03:59:34 PM |
|
Hi,
does anyone know, if it is ok to flash the 99.2E FW and flash back to 99.2 oct unit FW with a 4vmrs asic board
the problem is, that i have 3x8vmrs and 1x4vrms boads after a RMA. And now i woul like to activate all 8 vrms on the 3 8vrms boards and do not know what will happen with the last 4vrm board.
|
|
|
|
|