How do we avoid the image block? It makes drawing lines on charts less appealing this way.
Image block? ChartBuddy is kicking asses again, no? I think it's a matter of which kind of img format you're going to use. avoid gif, use png and you should be safe. |
|
|
|
|
Btccharts.com
Create an account to unlock all the cool features...
|
|
|
|
I just wanted to report that my Oct Jupiter has been running at ~950GH/s (6-modules) and pulling an between 57-60 amps per VRM for about a week now. Temps range between 57-78.5 degrees Celsius. So far so good! You are a brave man for pulling much more than the recommended max safe current  You use 211 I assume? I use different settings for each die, but many of them are using 231 Wow, that is a crazy overclock then  Do you mind posting a screenshot of your Status and Advanced Tab + SSH Scgminer Tab + your settings. Also are you not worried about drawing more than 200A per board? Thank you. Yes, I am worried about the 200A per board, but I'm willing to risk it. Here's the info you requested: FW version: 0.99-tuning (October) cgminer version: 3.9.0 Status PageAdvanced Tabmodified cgminer.sh fileI want to congrat for your setup and for your achievement  having said that, the temps showed in the status page is very high for the two 4 VRMs asic slots (68 and 78). Have you bought this two from KNC's expansion batch? One last thing I saw is that, always for this 2 4 VRMs slots, you have setted negative voltage for each die, what does it mean? Anyway after seeing this it seems that 8 VRMs are better suited for OC. Many thanks for sharing those info, really appreciated. |
|
|
|
nothing.
your overclock settings will stay in place, but your change to voltage won't get applied :/
So the voltages I have set would not get back to default when I apply the overclocking? right, they would not get back. restarting cgminer through cgminer.sh does not overwrite the voltage settings you apply via "Advanced" tab. |
|
|
|
from my limited experience I think that both points apply to everyone. For what is worth I've been albe to verify only the second one: every time I overclock the miner a good number of cores will be disabled during the first two minutes of the new cgminer session. Usually they're concentrated in one or two die.
In my case dies are being disabled (1 die = 48 cores). If just cores are disabled then that is easy to fix - just apply more voltage to stabilize them. ok got it On the other hand I've never tried
to verify the first point, mainly because I don't know how to do it. How do you know for sure that the clock has been reset, do you look at the Amps or is there anyway to read the value of a PLL registry?
Yes, voltage drops. For example you apply the overclock and you see a VRM working at 54A. You change the voltage setting just 1-2 values lower and after you hit apply the Amps drop from 54 to 44, which means the higher overclock frequency is no longer applied. ok. next time I've to do it I will pay attention to Amps values just after changing the voltage. in the meantime I'll try also to find a way to read the PLL register that contain clock settings. Instead of increasing the voltage to the maximum value, I just set it a little bit higher take into accounts on how many
cores are disabled in a particular die. the I restart cgminer and wait 1 minute to see if changes make any difference.
I use this approch because I don't want to cook my asics/vrms. I've tried that, but it doesn't work as effective as applying max voltage. With max voltage the sleepy dies usually kick in immediately. Also I have a 2nd theory, which I haven't tested a lot, but if you supply sufficient voltage to a sleepy die it might awake after 2-3-4-5-6 hours. But I don't think there is any consistency in results with this method and I prefer to wake them up immediately with stress/shock voltage that waiting hours for them to wake up naturally, which is not guaranteed to happen. since any other methods you have tried have failed just give this theory of yours a try, no? I've also increased the SPI frequency because of what 'orama said in one of hist last post said:
How much? I played with this and I usually stick to 256000Mhz. I tried even more, but I can't see any correlation between this and any results. actually I'm OC quite slightly, using 1F1, and I'm using as SPI freq 299707 and prev I 've used 256000, I haven't seen now difference, though. Another think I do is taking not of all the changes I apply along the way (a goodthing is coping /config/adavanced.conf at differnet moment in time)
To check the distribution of disabled cores I use a modified version of a pl script included in bertmod. It is an ASCII version, it only outputs temps and disabled core per die, e.g.
How exactly did you do that? bertmode 0.2.X bin file contained a perl script, asic_status.pl, used to generate a modified version of the status page. A btctalk user (don't rember the name sorry) have changed it to just puts on standard output a few info. You created an additional page within the lighttpd server?
no I've just placed the modifed script into /config (just to make persistent across reboost), to use it I just log in using ssh and execute from the command line: perl /config/asice_status_ascii.pl
if you find it useful I could upload the file somewhere... |
|
|
|
sorry off topic... Hey Phoenix1969 we both got a nice Christmas gift.. we both graduated to senior members at same time  congratulations and Merry Christmas to you and everyone here  somewhat off topic but how exactly does that work?...time since you first made an account? |
|
|
|
i was looking at an ebay auction of a jupiter, and it showed a picture of the laptop screen and it showed his hashrate and then i noticed something on the right side
HW status then it had ACIS 1,2,3,4,5,6 but 2 are empty, is there a way to get the 2 empty slots filled to get more hashrate? i mean does knc sell them or is it possible?
they already sold a batch of expansions boards for october miners. actually it was only for saturn/mercury owners that want to expand their machine. In reality a lot of people with a jupiter have the luck of having the control board with 6 funtioning asics plug, and somene who hasn't this luck just mod the board to add two more plugs since it was the only missing piece and everything else were in place already. They just bought the plugs and then soldered it onto the controll board. As result there're a few people running a miner with 6 asic modules. Of course there were also people that buy the expansion boards to resell it on ebay If memory serves it takes less than ten minutes to sell all the exapnskion boards, actually they've oversold due to sw glitch. |
|
|
|
so you're impling that setting the clock to the default value lower the Amps, despite the fact that you're increasing the voltage per die?
I have 2 problems with the current state of overclocking: Problem 1 applies to everyone: Setting the voltage on the Advanced tab resets the clock. Problem 2 applies to me only (and maybe other people): Setting any overclock in cgminer.sh kills a number of dies. I think it happens because when you increase the frequency of the chip the current required increases, which creates a change in the voltage/current values and so this change makes the dies sleepy. from my limited experience I think that both points apply to everyone. For what is worth I've been albe to verify only the second one: every time I overclock the miner a good number of cores will be disabled during the first two minutes of the new cgminer session. Usually they're concentrated in one or two die. On the other hand I've never tried to verify the first point, mainly because I don't know how to do it. How do you know for sure that the clock has been reset, do you look at the Amps or is there anyway to read the value of a PLL registry? This is what I do: on boards with sleepy dies I increase voltage to the max and when I see they kick in and are alive I immediately lower it to safe values, but not too low so they don't fall asleep again.
Then I restart cgminer.sh where the overclock values are and this makes the dies to fall asleep again even though the voltage hasn't changed (just the current changes as higher frequency results in higher current).
Instead of increasing the voltage to the maximum value, I just set it a little bit higher take into accounts on how many cores are disabled in a particular die. the I restart cgminer and wait 1 minute to see if changes make any difference. I use this approch because I don't want to cook my asics/vrms. I've also increased the SPI frequency because of what 'orama said in one of hist last post said:
If the SPI frequency is too low then there is not enough bandwidth to collect all the good nonces found. So you want to find an equilibrium where by SPI frequency is high enough not to miss any of the nonces found, but low enough to retain a healthy noise to signal ratio and thus minimise hardware errors.
Another think I do is taking not of all the changes I apply along the way (a goodthing is coping /config/adavanced.conf at differnet moment in time) To check the distribution of disabled cores I use a modified version of a pl script included in bertmod. It is an ASCII version, it only outputs temps and disabled core per die, e.g. Board 0: Temperature sensor: 47.5C
DIE 0 ON: 46 OFF: 2 95.8% OK
DIE 1 ON: 48 OFF: 0 100% OK
DIE 2 ON: 48 OFF: 0 100% OK
DIE 3 ON: 48 OFF: 0 100% OK
Board 2: Temperature sensor: 64.0C
DIE 0 ON: 47 OFF: 1 97.9% OK
DIE 1 ON: 48 OFF: 0 100% OK
DIE 2 ON: 48 OFF: 0 100% OK
DIE 3 ON: 48 OFF: 0 100% OK
Board 3: Temperature sensor: 55.0C
DIE 0 ON: 48 OFF: 0 100% OK
DIE 1 ON: 48 OFF: 0 100% OK
DIE 2 ON: 48 OFF: 0 100% OK
DIE 3 ON: 48 OFF: 0 100% OK
Board 4: Temperature sensor: 49.0C
DIE 0 ON: 48 OFF: 0 100% OK
DIE 1 ON: 48 OFF: 0 100% OK
DIE 2 ON: 48 OFF: 0 100% OK
DIE 3 ON: 48 OFF: 0 100% OK
|
|
|
|
PSU for Neptune: 30 % less power consumption, mean 0,7 Watt per GigaHash/s, mean 3000 * 0,7 = 2100 Watt for one Neptune !  2 x PSU or how will we power on the neptune? who knows. maybe a PSU will be included or, more likely, they'll give you a pointer on what upo need to buy. |
|
|
|
so everytime you hit click on "Apply" button on the "Adavenced" tab, the clock is resetted to default? edit: I've gone through the code and it seems that what happened when you click on apply is the execution of this command: waas -c /config/advanced.conf > /dev/null
killall monitordcdc
in /config/advanced.conf there's a JSON rappresentation of the data contained in the Advanced tab. This means that waas command reset all the default value for the PLL. Unluckily there's no source code for waas executable. Yes, I believe so as the Amps drop. so you're impling that setting the clock to the default value lower the Amps, despite the fact that you're increasing the voltage per die? So what would happen if I remove that command?
nothing. your overclock settings will stay in place, but your change to voltage won't get applied :/ edit: give IRC a try and see if hno is hanging around.. |
|
|
|
So I have this very temperamental miner with around 6-7 sleepy dies on 3 boards with the 4th board being OK. At stock clock I can easily awaken them by applying max voltage to all 4 dies of a single board and when I see them kick in I quickly lower them back to safe values. But whenever I try to overclock it the dies fall asleep and because I need to change voltage settings to awaken them the overclock disappears  And that same miner used to be overclocked with all dies working, but I don't remember how I did it. Any ideas? Is there a way to NOT remove the overclock when changing voltage settings? so everytime you hit click on "Apply" button on the "Adavenced" tab, the clock is resetted to default? edit: I've gone through the code and it seems that what happened when you click on apply is the execution of this command: waas -c /config/advanced.conf > /dev/null
killall monitordcdc
in /config/advanced.conf there's a JSON rappresentation of the data contained in the Advanced tab. This means that waas command reset all the default value for the PLL. Unluckily there's no source code for waas executable. |
|
|
|
Update: I tried holding down the small button on the front of the control board while powering the unit on, and it came to life now and booted normally. I don't know if the button press did it, or if it was just luck. I'm afraid to touch it again now.
good to know. I have a bad unit that is very prone to this kind of behaviour: it simply don't want to boot after been switched off. the only way to resurrect it is reflashing the fw through the SD card. next time i'll give this method a try. Did you try it by luck or did you read somewhere, maybe on some BBB forums? |
|
|
|
My November Jupiter hashed at 670GH/s when it was working perfectly. Last week something went wrong in it and I've got a die off and it gets 630GH/s now.
did you try to increase the voltage for switched off die? There is no voltage adjustment available on the November units, so no. sorry don't have a nov miner so I thought they've released the "advanced" tab also for the nov batch |
|
|
|
November Jupiters have been hashing at ~700GH/s
consistently? links please. My Nov Jup is consistant at 670 GH/s. My November Jupiter hashed at 670GH/s when it was working perfectly. Last week something went wrong in it and I've got a die off and it gets 630GH/s now. did you try to increase the voltage for switched off die? |
|
|
|
How is your october one hashing at 604?
in two words: Over Clocking |
|
|
|
Found interesting. Think it's my problem, please look in yours (October miner) - ls /sys/class/gpio/ What the last gpiochip ? I have only 96, and it is my enables core, no directory for other (must be 192).
How can i copy /sys/class/gpio/gpiochipXXX whith new name or from other device to /sys/class/gpio/*.*
dunno what you mean, but this is the content of aforementioned dir on my october miner. root@mine:~# ls -l /sys/class/gpio/
--w------- 1 root root 4096 Jan 1 2000 export
lrwxrwxrwx 1 root root 0 Jan 1 2000 gpio49 -> ../../devices/virtual/gpio/gpio49
lrwxrwxrwx 1 root root 0 Jan 1 2000 gpio59 -> ../../devices/virtual/gpio/gpio59
lrwxrwxrwx 1 root root 0 Jan 1 2000 gpio66 -> ../../devices/virtual/gpio/gpio66
lrwxrwxrwx 1 root root 0 Jan 1 2000 gpio67 -> ../../devices/virtual/gpio/gpio67
lrwxrwxrwx 1 root root 0 Jan 1 2000 gpio69 -> ../../devices/virtual/gpio/gpio69
lrwxrwxrwx 1 root root 0 Jan 1 2000 gpio70 -> ../../devices/virtual/gpio/gpio70
lrwxrwxrwx 1 root root 0 Jan 1 2000 gpio71 -> ../../devices/virtual/gpio/gpio71
lrwxrwxrwx 1 root root 0 Jan 1 2000 gpio76 -> ../../devices/virtual/gpio/gpio76
lrwxrwxrwx 1 root root 0 Dec 24 20:57 gpiochip0 -> ../../devices/virtual/gpio/gpiochip0
lrwxrwxrwx 1 root root 0 Dec 24 20:57 gpiochip32 -> ../../devices/virtual/gpio/gpiochip32
lrwxrwxrwx 1 root root 0 Dec 24 20:57 gpiochip64 -> ../../devices/virtual/gpio/gpiochip64
lrwxrwxrwx 1 root root 0 Dec 24 20:57 gpiochip96 -> ../../devices/virtual/gpio/gpiochip96
--w------- 1 root root 4096 Dec 24 20:57 unexport
anyway I don't think you can just "create/copy" something in /sys. sysfs it is the way moderm linuxes export information about hw to user space, so if something is missing there is probably because there's no such a thing on the hw side, or at least the kernel is not albe to deal with it. |
|
|
|
Looks good. But please, don't help add a couple hundred THs to the network by being the hero and writing an overclocking tutorial!
wow this is bold. I have no words. Imagine what would have happened if tolip_wen had applied the same reasoning... We would had to wait until January till the new firmware comes with built-in overclocking You can't be sure, because tolip_wen's findings could have influenced KnC's choice to release a OC-ready firmware. The thing that really annoys me is the attitude. Without the sharing of knowledge almost all the bitcoin ecosystem would not exist at all. What is stopping you from providing such a tutorial? I'm not knowledgeable enough otherwise I would have done it , as simple as that. |
|
|
|
Looks good. But please, don't help add a couple hundred THs to the network by being the hero and writing an overclocking tutorial!
wow this is bold. I have no words. Imagine what would have happened if tolip_wen had applied the same reasoning... We would had to wait until January till the new firmware comes with built-in overclocking You can't be sure, because tolip_wen's findings could have influenced KnC's choice to release a OC-ready firmware. The thing that really annoys me is the attitude. Without the sharing of knowledge almost all the bitcoin ecosystem would not exist at all. |
|
|
|
Looks good. But please, don't help add a couple hundred THs to the network by being the hero and writing an overclocking tutorial!
wow this is bold. I have no words. Imagine what would have happened if tolip_wen had applied the same reasoning... |
|
|
|
DC\DC - Off after diagnostic tool for November . I try enable-core, recovery and different firmware. you try the nov diagnostic on a october miner? |
|
|
|
|
Show Posts
