Looks Shamazing mate  Thanks. Originally I intended to have a separate shelf for the PSUs, but it turned out each PSU next to its miner is the better way. I even made holes for the cables to pass through the shelves, which are now unused. I am now thinking to buy some CoolerMaster Megaflow 200mm and put them behind the miners for extra airflow as the height of each shelf is 210mm. 2 more pictures:   |
|
|
|
Can anybody link step-by-step instructions how to upgrade cgminer to the latest version on Jupiters?
Chill a few about to share the latest firmware with the latest CGMiner binary 3.9.0. compiled within as well as a couple of bug fixes. Hold tight a few minutes... Note: The problems addressed have been observed to manifest largely with the Eligius pool, however we can't say for definite it is exclusively associated with that pool, but the settings within Eligius previously compounded the issue. So expect to see a drop in HW error rate. I will drop it in this thread, but don't currently have access to the site to update the main page, no doubt Sam will do that when he has an opportunity, but I have a flight to catch. V and I just want you to have this to play with sooner, than later... In any case as always keep us abreast of what you observe and constructive feedback is always welcome!  Merry Xmas, God Jul, Joyeux Noel, Feliz Navidad, Fröhliche Weihnachten, Sheng Dan Kuai Le, S rozhdyestvom Hristovym! etc...sorry if i've missed anyone out I could be here all night otherwise, you get the idea  Marry xmas I have already prepared my red xmas outfit  |
|
|
|
Thanks.
How many of these should I see in the list?
323 root 2148 S udhcpc -b -x hostname Jupiter-1 eth0
14003 root 2152 S grep dhcp
29312 root 2148 S udhcpc -b -x hostname Jupiter-1 eth0
I think that one is enough. you should kill the one with the lower pid. But i'd prefer if you check it with someone else that is using the dhcp network settings. usually there's only one dhclient for each network interface. If I were you I would simply reboot the miner and check how many udhcpc will be running. but i'd dare to say that you could do this the next time a network glitch appear, this way you could use the downtime to test this solution without wasting mining time. Thank you. I posted my problem at my ISP forum and someone suggested a possible solution where Static IP addresses would not get changed by the router - I should set Static IP addresses that are not in the DHCP pool - anything below .64: https://i.imgur.com/3giMtIs.pngso you have set a static IP that belongs to your dhcp address pool, right? the fact is that if you did not have any dhcp client hanging around there's no way that the BBB let the dhcp server change its own static ip address. now that I've checked better /www/pages/cgi-bin/network.cgi I've found that there's also an avhai deamon involved... Yes, before when I tried using the Static way. But once in a while the IP address of a random Jupiter would change and so I decided to go the other route, which was manually editing the DHCP table via telnet - I just gave my miners Indefinite lease time on their IP addresses. Fast forward to 2 days ago, when all of them started to disappear from my network all of a sudden. If it happens again I will just set them Static again, but outside the DHCP pool range. Spitballing here, high speed routers and switches use a complex signal to get the speed. Perhaps there's noise on your AC line that gets thru to your switch. If the Jupiters disconnect and other equipment doesn't then it might be as a result of the Jupiter signal quality. Are your Jupiters open or closed? Have your tried adding additional cooling to the controller boards and BBBs? Is something turning on in the area around the time the Jupiters show connection difficulties? I think I might have solved the problem, so will leave it for now. If it happens again I will just set Static IP addresses outside the DHCP pool and see what happens. Thanks for the suggestions though |
|
|
|
There will be a tuning suite for Nov, but not this side of Jan, as everything there is winding down. There's just some ongoing Neptune work. There will also be the means to vary SPI clock frequency. I saw it in the original tuning suite as a feature, but that hadn't been developed into the recent release. It was purely part of a template I saw.
Can you please elaborate on what that option does as I believe many of us are just changing values without knowing what they actually do The voltage settings are clear, but the SPI voltage and frequency not so much. I know they are related to the communication between each board and the controller board, so do they increase the signal to noise ratio or am I talking rubbish By changing the voltage you are altering the power consumption and the noise to signal ratio (communication error rate - although reported by CGMiner as hardware errors they are not actual hardware errors so don't worry) The less voltage the higher noise to signal ratio, the higher the probability of hardware errors. The greater the voltage the less noise to signal ratio, the smaller the probability of hardware errors. The higher the frequency, again the higher noise to signal ratio, which is not what you want. 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. Also, my bad, the future firmware update is not about SPI frequency, it's about configuring the PLL settings, which is directly correlated with the hashing speed as you are directly altering the clock speed of the die. The SPI is not the hashing speed, but the speed of the communication between the dies and the controller board. Hope that clears things up bud, and Merry Christmas, or if you're not into all that happy holidays all the same.  Thanks for the info I have one other concern in relation to changing certain hex values, that increase some other values, that lead to increased hashrate which bothers me lately: according to one KNC engineer, which I met in person anything above 50Amps per VRM is considered not safe for long term usage. Or 200Amps per board. He wasn't very clear about it. Yet the 0.99 Tune firmware has the option to increase the current per VRM up to 64Amps, which brings the question: if over 50Amps is considered not safe, why then we have 64Amps at our disposal? What is considered safe? Judging by the latest firmware I would assume 64Amps to be safe or at least any logical, non-technical person would believe that as it is included in the Advanced tab options. Happy holidays and don't drink too much We need you back here in the new year  The GE modules are rated for 40 Amps, but can safely be clocked above that. 64 Amps is the max where we feel comfortable clocking the VRMs to, and strongly advise against considering anything higher. Obviously pushing things too far reduces operational life expectancy, but if it's been included in an official firmware then be confident that we are comfortable releasing it as such. Not sure where you can take the Ericssons. That said i was out of the office for a couple of weeks touring with a Nov Jupiter, and then back briefly for a week before heading home for Christmas tonight. I know precisely who you are talking about and will bend his ear when we next see eachother, he's not in today, they celebrate Christmas earlier here so i'll pick his brains when we next catch up, unless you catch him first. I am even more confused now He literally scared me and I lowered my Amps below 52 and you say that up to 64 should be OK as KNC feels comfortable with that. I like your position better Please verify it with him and come up with a uniform position  In regards to November Jupiters: they are hashing like beasts, so no point trying to change anything there. But just as a comparison: the total current for a November board is around 200Amps (8x 25Amps), so maybe there is some correlation between that and the proposed max safe limit of 50Amps (200 in total) for an October board? But then again that 8x 25Amps might just be fairly reserved and not close to the true safe maximum. I wish we can get an official response, just for the sake of people who decide to set all to max voltage (64Amps) and have no clue that it might be dangerous. |
|
|
|
Thanks.
How many of these should I see in the list?
323 root 2148 S udhcpc -b -x hostname Jupiter-1 eth0
14003 root 2152 S grep dhcp
29312 root 2148 S udhcpc -b -x hostname Jupiter-1 eth0
I think that one is enough. you should kill the one with the lower pid. But i'd prefer if you check it with someone else that is using the dhcp network settings. usually there's only one dhclient for each network interface. If I were you I would simply reboot the miner and check how many udhcpc will be running. but i'd dare to say that you could do this the next time a network glitch appear, this way you could use the downtime to test this solution without wasting mining time. Thank you. I posted my problem at my ISP forum and someone suggested a possible solution where Static IP addresses would not get changed by the router - I should set Static IP addresses that are not in the DHCP pool - anything below .64: https://i.imgur.com/3giMtIs.pngso you have set a static IP that belongs to your dhcp address pool, right? the fact is that if you did not have any dhcp client hanging around there's no way that the BBB let the dhcp server change its own static ip address. now that I've checked better /www/pages/cgi-bin/network.cgi I've found that there's also an avhai deamon involved... Yes, before when I tried using the Static way. But once in a while the IP address of a random Jupiter would change and so I decided to go the other route, which was manually editing the DHCP table via telnet - I just gave my miners Indefinite lease time on their IP addresses. Fast forward to 2 days ago, when all of them started to disappear from my network all of a sudden. If it happens again I will just set them Static again, but outside the DHCP pool range. |
|
|
|
There will be a tuning suite for Nov, but not this side of Jan, as everything there is winding down. There's just some ongoing Neptune work. There will also be the means to vary SPI clock frequency. I saw it in the original tuning suite as a feature, but that hadn't been developed into the recent release. It was purely part of a template I saw.
Can you please elaborate on what that option does as I believe many of us are just changing values without knowing what they actually do The voltage settings are clear, but the SPI voltage and frequency not so much. I know they are related to the communication between each board and the controller board, so do they increase the signal to noise ratio or am I talking rubbish By changing the voltage you are altering the power consumption and the noise to signal ratio (communication error rate - although reported by CGMiner as hardware errors they are not actual hardware errors so don't worry) The less voltage the higher noise to signal ratio, the higher the probability of hardware errors. The greater the voltage the less noise to signal ratio, the smaller the probability of hardware errors. The higher the frequency, again the higher noise to signal ratio, which is not what you want. 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. Also, my bad, the future firmware update is not about SPI frequency, it's about configuring the PLL settings, which is directly correlated with the hashing speed as you are directly altering the clock speed of the die. The SPI is not the hashing speed, but the speed of the communication between the dies and the controller board. Hope that clears things up bud, and Merry Christmas, or if you're not into all that happy holidays all the same. Thanks for the info I have one other concern in relation to changing certain hex values, that increase some other values, that lead to increased hashrate which bothers me lately: according to one KNC engineer, which I met in person anything above 50Amps per VRM is considered not safe for long term usage. Or 200Amps per board. He wasn't very clear about it. Yet the 0.99 Tune firmware has the option to increase the current per VRM up to 64Amps, which brings the question: if over 50Amps is considered not safe, why then we have 64Amps at our disposal? What is considered safe? Judging by the latest firmware I would assume 64Amps to be safe or at least any logical, non-technical person would believe that as it is included in the Advanced tab options. Happy holidays and don't drink too much We need you back here in the new year |
|
|
|
Out of 6 nov jupiters, I now have 3 dead moduals, and a completely dead Jupiter. RMA is pretty fast... but Ill be down almost $1k in shipping by the time this is done. Seriously thinking about just chaging back the dead one... Not worth it after 2 weeks dead then another 3 weeks in RMA.
They make you pay for shipping? $100 per module back to sweden for each, then they want me to ship the entire Jupiter back that wont work. I don't even have RMA numbers for the last module yet. Hm, I never knew they segregate customers like that. All I know is that us people in Europe don't pay for return shipping. Have you asked them about this? |
|
|
|
Out of 6 nov jupiters, I now have 3 dead moduals, and a completely dead Jupiter. RMA is pretty fast... but Ill be down almost $1k in shipping by the time this is done. Seriously thinking about just chaging back the dead one... Not worth it after 2 weeks dead then another 3 weeks in RMA.
They make you pay for shipping? |
|
|
|
Thanks.
How many of these should I see in the list?
323 root 2148 S udhcpc -b -x hostname Jupiter-1 eth0
14003 root 2152 S grep dhcp
29312 root 2148 S udhcpc -b -x hostname Jupiter-1 eth0
I think that one is enough. you should kill the one with the lower pid. But i'd prefer if you check it with someone else that is using the dhcp network settings. usually there's only one dhclient for each network interface. If I were you I would simply reboot the miner and check how many udhcpc will be running. but i'd dare to say that you could do this the next time a network glitch appear, this way you could use the downtime to test this solution without wasting mining time. Thank you. I posted my problem at my ISP forum and someone suggested a possible solution where Static IP addresses would not get changed by the router - I should set Static IP addresses that are not in the DHCP pool - anything below .64:  |
|
|
|
I've to say that the miners' network stack is not the best their part, more than once I've found two or more dhclients running on the miner side. For me, switching to a manual network configuration have solved all the problems and glitches that seem related to the network stack, so far.
What do you mean when you say "manual network configuration"? Static IP addresses setup at the miner? or Reserved IP addresses setup at the router like me? The former (static ip at the miner) I tried that at first, but my router kept changing the IP addresses randomly. I think this is due so a stale "udhcpc" (dhcpclient) floating around. If my theory is correct the problem will be fixed by a reboot or by killing the stale dhcpclient process (login via ssh; ps | grep dhcp; kill <stale_process_pid>). Thanks. How many of these should I see in the list? 323 root 2148 S udhcpc -b -x hostname Jupiter-1 eth0 14003 root 2152 S grep dhcp 29312 root 2148 S udhcpc -b -x hostname Jupiter-1 eth0 |
|
|
|
I've to say that the miners' network stack is not the best their part, more than once I've found two or more dhclients running on the miner side. For me, switching to a manual network configuration have solved all the problems and glitches that seem related to the network stack, so far.
What do you mean when you say "manual network configuration"? Static IP addresses setup at the miner? or Reserved IP addresses setup at the router like me? The former (static ip at the miner) I tried that at first, but my router kept changing the IP addresses randomly. |
|
|
|
I've to say that the miners' network stack is not the best their part, more than once I've found two or more dhclients running on the miner side. For me, switching to a manual network configuration have solved all the problems and glitches that seem related to the network stack, so far.
What do you mean when you say "manual network configuration"? Static IP addresses setup at the miner? or Reserved IP addresses setup at the router like me? |
|
|
|
Guys, I need you help with the weirdest problem: Since yesterday my miners have started to disappear from my local network all of a sudden and that happens too often now. All my miners are connected to a TP-Link TL-SF1008D 8-Port 10/100Mbps Unmanaged Desktop Switch, which is then connected to my router Technicolor TG582n (given by ISP): https://i.imgur.com/8HmLmKO.pngWhen the problems happens the blinking light at the back of the router, where the switch is connected has gone off, yet the all 7 lights (6 miners + incoming cable) are ON. Until yesterday I wasn't sure what is the problem, but now I know: when I unplug the switch from the router and plug it back in = they appear back in the network. Additionally this morning my own PC reported network conflict: some other machine on the network got its IP too, which never happened. + I have setup the DHCP table manually. The 101 to 106 are the miners. Before it said state USED and now it is free, but they are hashing. https://i.imgur.com/GPiLxxb.pngDo you have any experience with bad switches? Any ideas what is causing the issue? Thank you. if you could, just go down the road and buy a new switch, hopefully it is the cause of the problem. A 8 port switch cost almost nothing. buy a good one while at it. Just clicked Apply in each miner Networking Tab and the FREE changed to USED in the DHCP table:  That was probably the cause, but I have no idea why. That is a good switch according to Amazon reviews - it is the best selling one with an average score of 4.7 out out of 5: http://www.amazon.co.uk/TP-Link-TL-SF1008D-100Mbps-Unmanaged-Desktop/dp/B000MGBOHA |
|
|
|
Guys, I need you help with the weirdest problem: Since yesterday my miners have started to disappear from my local network all of a sudden and that happens too often now. All my miners are connected to a TP-Link TL-SF1008D 8-Port 10/100Mbps Unmanaged Desktop Switch, which is then connected to my router Technicolor TG582n (given by ISP):  When the problems happens the blinking light at the back of the router, where the switch is connected has gone off, yet the all 7 lights (6 miners + incoming cable) are ON on the switch. Until yesterday I wasn't sure what is the problem, but now I know: when I unplug the switch from the router and plug it back in = they appear back in the network. Additionally this morning my own PC reported network conflict: some other machine on the network got its IP too, which never happened. + I have setup the DHCP table manually. The 101 to 106 are the miners. Before it said state USED and now it is free, but they are hashing.  Just clicked Apply in each miner Networking Tab and the FREE changed to USED in the DHCP table: Do you have any experience with bad switches? Any ideas what is causing the issue? Thank you. |
|
|
|
Please post more videos for the next 2-3 months, so we KNC customers can mine for longer with almost no competition. You are doing great |
|
|
|
Obviously, if the value of bitcoin skyrocketed, one would have done better by simply buying and holding. If I knew the future and knew that bitcoin would significantly increase in value, I would buy and hold.
I suppose significantly is the key word there. It's definitely going to rise over time. No surefire way to know how much time or value. B&H is one solid thing to do with these coins, in addition to mining. With these numbers, I expect a Neptune to generate 7.5 BTC before it stops being profitable. I had no illusions about receiving more BTC than the ~12/each I spent. And yet I still bought three.
Finally, one of only a couple of us who is making a realistic projection. Mine was 4-6 with an upper of 12 depending on factors. All I could do was shake my head in disbelief at the folks who bought Neptunes thinking they would crank out like 50 coins. Realistic? 8 billion jump in one change in July? 57266 TH/s added to the network in a 10-12 days period? That's 10K Neptunes at 5TH/s. |
|
|
|
As far as helping people overclock their KNC rigs, it's probably a wash. So few people have the skills to follow really simple command line instructions, I figure an overclocking guide will brick as many machines as it overclocks! What percentage of the average public has ever used a non-gui based text editor? Try to explain vi to them!
Next, throw some cryptic pseudo-MS-DOS (I know it's the other way around) shit like manually copying files and changing directories. Did you know the slashes / \ go the opposite directions in windows and unix? And in Unix directories can have a . in the middle of it's name? Holy crap, that alone is gonna screw half the people right there.
So you changed my mind, PLEASE WRITE AN OVERCLOCKING GUIDE. Gonna fuck some shit up, yes we are.
-Dana
Good points. I am no Linux guru, but back in 2011 when I was GPU mining I managed to run a headless Ubuntu rig with no prior unix experience. Most of it is having good computer skills in general and using Google. Until today I've never used vi, but again using Google I got all the required information: hint use xxdd to delete a specific number of lines - example 85dd to delete 85 lines. |
|
|
|
I think I managed to make it work. Please have a look at my code and tell me if it is OK: This code is for overclocking each individual die on each board to 850Mhz, so 16 total individual settings for boards at position 0, 1, 2, 3: http://pastebin.com/dSWrP4jFIt works, so I assume it is all good. I think I understand it better now, so I will probably write a very detailed tutorial tomorrow for people who are not sure what they are doing. But first I will try to switch to BFGMiner to better fine tuning. Looks good. But please, don't help add a couple hundred THs to the network by being the hero and writing an overclocking tutorial! Anyway, you can change each individual die to whatever clock speed you want with your code. It's great for people who have issues with bad boards, but simply changing the preceeding 0x86 register will cover 95% of the people who have no bad dies without over complicating things: if [ -n "$good_ports" ] ; then
for p in $good_ports ; do
# Re-enable PLL
i2cset -y 2 0x71 1 $((p+1))
for c in 0 1 2 3 ; do
cmd=$(printf "0x84,0x%02X,0,0" $c)
spi-test -s 50000 -OHC -D /dev/spidev1.0 $cmd >/dev/null
cmd=$(printf "0x86,0x%02X,0x02,0x11" $c) True that. I will refrain from making it easy for the average joe then. Btw what are your observations in regards to unhappy dies? One of my miners clocked with 201 is showing this: https://i.imgur.com/NSl59Iz.pngShall I increase the voltage at the Advanced tab, then /config/zzz.sh restart or try first with more/less OC? @CYPER Please DO write a very detailed tutorial for people who are not sure what they are doing? I made a contribution to tolip_wen for his shared work and will do the same for you and as well encourage others to as well. None of us would be here without some help from someone else at some point. Thanks I would rather help individual people in person like ElGabo did, than write a tutorial Find me on Skype and I can help when I am free. |
|
|
|
|
Show Posts
