regular
|
|
October 10, 2013, 02:56:27 PM |
|
We definitely need to keep track of performance as more chips go. Perhaps the foundry process improves and there will be minor revisions to the chips as time goes on to reduce the HW errors and inconsistencies.
|
|
|
|
DPoS
|
|
October 10, 2013, 02:59:59 PM |
|
The unit at my home is hashing perfectly. around 550 for a full 24 hours.
at the pool or just cgminer boasting? (I don't really pay attention to what cgminer says) tough to get 540 at the pool for any length of time
|
|
|
|
WastedLTC
|
|
October 10, 2013, 03:15:39 PM |
|
The unit at my home is hashing perfectly. around 550 for a full 24 hours.
at the pool or just cgminer boasting? (I don't really pay attention to what cgminer says) tough to get 540 at the pool for any length of time that rate is from BTCGuild, it goes from 540 to 570 but looks to average around 550.
|
|
|
|
WastedLTC
|
|
October 10, 2013, 03:22:17 PM |
|
emailed Sam about the low hashing rate on hosted units asking him for a bit more detail and to be sure the issue is known. Hope this helps, some detail, they know about the issue, and they are working on it. --response We have been aware of reports with underperforming Jupiter’s and we are working to fix it Right now the engineers have a solution that is going through coding and then through testing. It will then be sent out to all customers and applied automatically to all hosting customers, This fix will improve the hashing speed, by placing more intelligence inside the FPGA and not using the mining software to spot bad routes through the chip, so any issues won’t have an effect on the mining performance the software will then be able to concentrate on mining and thus increase the performance Sam Thanks, Sam Med vänlig hälsning | Best regards Sam Cole Kncminer www.kncminer.comOffice: +46 8559 253 20 --end respond
|
|
|
|
Puppet
Legendary
Offline
Activity: 980
Merit: 1040
|
|
October 10, 2013, 03:26:51 PM |
|
Im at a loss what could cause apparently all hosted units to exhibit this problem, whereas nearly none of the shipped units have this. Datacenter only has to provide: - electricity (which could cause all kinds of trouble, but is unlikely to cause extreme low hashrates), - internet, with nearly zero bandwidth, not something that should be difficult to achieve in Sweden, and the webinterfaces seem to work, so thats not likely it either - Cooling. That could be a real issue, but these reported hashrates are soo low, I could only believe that to be the cause if its like 40-50C in that datacenter. Im sure they would notice...?
Anyone else have theories? Do these hosted machines run any software that the non hosted machines do not run?
(posted before I read the post above me, but that doesnt shed much light on it either, or does it?)
|
|
|
|
WastedLTC
|
|
October 10, 2013, 03:29:30 PM |
|
Im at a loss what could cause apparently all hosted units to exhibit this problem, whereas nearly none of the shipped units have this. Datacenter only has to provide: - electricity (which could cause all kinds of trouble, but is unlikely to cause extreme low hashrates), - internet, with nearly zero bandwidth, not something that should be difficult to achieve in Sweden, and the webinterfaces seem to work, so thats not likely it either - Cooling. That could be a real issue, but these reported hashrates are soo low, I could only believe that to be the cause if its like 40-50C in that datacenter. Im sure they would notice...?
Anyone else have theories? Do these hosted machines run any software that the non hosted machines do not run?
(posted before I read the post above me, but that doesnt shed much light on it either, or does it?)
Support started mentioning that the configuration of the hosted units were different than the shipped units and when I asked more questions they quickly stopped and said they don't want to give bad info. I have a feeling the setup is different so they can manage all the units and through that routing something is messed up. All we can do is wait.
|
|
|
|
Tehfiend
|
|
October 10, 2013, 03:31:58 PM |
|
Another data point: I received my "day 1" Jupiter on Monday which had a heavily damaged box, slight dent in the case, three fans knocked loose but has been mining at around 500GHASH. However, not long after upgrading to 0.94 the hashrate dipped to around 400-450MHASH which might have been related to a DDOS against BTCguild since my Avalons also experienced a slight dip around the same time. I simply rebooted it via the web console and it has been running at 485-535GHASH for the last 12 hours in a 72F ambient room with the following internal temps: ASIC slot #1: 51.5 ℃ ASIC slot #2: - ASIC slot #3: 57.5 ℃ ASIC slot #4: 63.0 ℃ ASIC slot #5: 54.0 ℃ ASIC slot #6: -
|
|
|
|
Puppet
Legendary
Offline
Activity: 980
Merit: 1040
|
|
October 10, 2013, 03:33:46 PM |
|
I have a feeling the setup is different so they can manage all the units and through that routing something is messed up. All we can do is wait.
Sounds plausible. Even more when I read that the non hosted machines seem to run with very high cpu loads and they sometimes work faster with 3 instead of 4 asics. Problem might be in the beagleboard..
|
|
|
|
loktang1125
|
|
October 10, 2013, 03:41:31 PM |
|
Im at a loss what could cause apparently all hosted units to exhibit this problem, whereas nearly none of the shipped units have this. Datacenter only has to provide: - electricity (which could cause all kinds of trouble, but is unlikely to cause extreme low hashrates), - internet, with nearly zero bandwidth, not something that should be difficult to achieve in Sweden, and the webinterfaces seem to work, so thats not likely it either - Cooling. That could be a real issue, but these reported hashrates are soo low, I could only believe that to be the cause if its like 40-50C in that datacenter. Im sure they would notice...?
Anyone else have theories? Do these hosted machines run any software that the non hosted machines do not run?
(posted before I read the post above me, but that doesnt shed much light on it either, or does it?)
i guess it is about the cooling i have my miner improved from 80ghs to about 500ghs as i put a fan on the top it run faster if i use better and bigger fan
|
|
|
|
uski
Newbie
Offline
Activity: 18
Merit: 0
|
|
October 10, 2013, 03:42:10 PM |
|
I have a feeling the setup is different so they can manage all the units and through that routing something is messed up. All we can do is wait. If you look into the strings in the firmware, there's the name for the unit depending on the number of ASICs : 0 ASICs: 0_The_Headless_Horseman 1 ASICs: Mercury 2 ASICs: Saturn 3 ASICs: 3_Cerberus 4 ASICs: Jupiter 5 ASICs: 5_Five_Headed_Monkey 6 ASICs: 6_Hosted_Max_Speed The name of the 6 ASICs miner makes me think (pure speculation) that they actually host miners with 6 ASICs and, using a modified cgminer, they distribute the hashing power depending on what "miner" the customer bought initially. When you ask to get "your" miner out of the hosting, they just send you a miner with the correct number of ASICs (pure speculation again). That would make sense : more uptime for the customers (no problem if just one miner goes down), less costs for KnC (less controller boards), easier to manage for KnC (just run a huge "cloud" mining farm and distribute the hashing power through software only, it's much more flexible). It would also explain why they have a "private pool" which is actually their way to redistribute the earnings. I could be all wrong... or totally right
|
|
|
|
ImI
Legendary
Offline
Activity: 1946
Merit: 1019
|
|
October 10, 2013, 03:43:51 PM |
|
Have i just killed the Jupiter!?! Just setup a new miner. Fired it up and recognized that one front-fan didnt work. I didnt care cause without the case airflow should be OK. I started to change the setting via the webinterface and then the miner suddenly shut down. I checked everything and found that the front-fan wasnt working cause a blade was STUCK! So i "unstuck" it and fired the miner up again but NOTHING happens........... Whats going on???
|
|
|
|
crumbs
|
|
October 10, 2013, 03:44:18 PM |
|
|
|
|
|
DPoS
|
|
October 10, 2013, 03:44:51 PM |
|
here's some food for thought One of my Jupiters has a module with 8 VRMs while the other 3 have 4VRMs you can see even with status OFF, voltage still goes in/out but no out current And this module has been running 10c degrees lower than the rest
|
|
|
|
Puppet
Legendary
Offline
Activity: 980
Merit: 1040
|
|
October 10, 2013, 03:44:57 PM |
|
I have a feeling the setup is different so they can manage all the units and through that routing something is messed up. All we can do is wait. If you look into the strings in the firmware, there's the name for the unit depending on the number of ASICs : 0 ASICs: 0_The_Headless_Horseman 1 ASICs: Mercury 2 ASICs: Saturn 3 ASICs: 3_Cerberus 4 ASICs: Jupiter 5 ASICs: 5_Five_Headed_Monkey 6 ASICs: 6_Hosted_Max_Speed The name of the 6 ASICs miner makes me think (pure speculation) that they actually host miners with 6 ASICs and, using a modified cgminer, they distribute the hashing power depending on what "miner" the customer bought initially. When you ask to get "your" miner out of the hosting, they just send you a miner with the correct number of ASICs (pure speculation again). That would make sense : more uptime for the customers (no problem if just one miner goes down), less costs for KnC (less controller boards), easier to manage for KnC (just run a huge "cloud" mining farm and distribute the hashing power through software only, it's much more flexible). It would also explain why they have a "private pool" which is actually their way to redistribute the earnings. I could be all wrong... or totally right Nice catch, and excellent theory.
|
|
|
|
ImI
Legendary
Offline
Activity: 1946
Merit: 1019
|
|
October 10, 2013, 03:46:03 PM |
|
Have i just killed the Jupiter!?! Just setup a new miner. Fired it up and recognized that one front-fan didnt work. I didnt care cause without the case airflow should be OK. I started to change the setting via the webinterface and then the miner suddenly shut down. I checked everything and found that the front-fan wasnt working cause a blade was STUCK! So i "unstuck" it and fired the miner up again but NOTHING happens........... Whats going on??? Had the same prob... Just switch it a few times on and of... OK i will try that. thx!
|
|
|
|
Bargraphics
|
|
October 10, 2013, 03:47:21 PM |
|
I finally got my 2 miners online via hosting.
Jupiter 1 = 172 Gh/s Jupiter 2 = 12 Gh/s
(past hour)
kill me
|
|
|
|
-Redacted-
|
|
October 10, 2013, 03:48:10 PM |
|
Probably short for: "Just kill me now because I can't stand the pain"....
|
|
|
|
DPoS
|
|
October 10, 2013, 03:49:44 PM |
|
If you look into the strings in the firmware, there's the name for the unit depending on the number of ASICs : 0 ASICs: 0_The_Headless_Horseman 1 ASICs: Mercury 2 ASICs: Saturn 3 ASICs: 3_Cerberus 4 ASICs: Jupiter 5 ASICs: 5_Five_Headed_Monkey 6 ASICs: 6_Hosted_Max_Speed
Some customers are now running Cerberus and Headless Horseman miners.....(bad boards)
|
|
|
|
uski
Newbie
Offline
Activity: 18
Merit: 0
|
|
October 10, 2013, 03:51:10 PM |
|
here's some food for thought One of my Jupiters has a module with 8 VRMs while the other 3 have 4VRMs you can see even with status OFF, voltage still goes in/out but no out current And this module has been running 10c degrees lower than the rest https://i.imgur.com/yDTHPNB.jpgYou're using bertmod 0.1,which does not yet support boards with 4 DC/DCs : ignore the "OK" for the ASIC slots which are not there (those with voltage 0 and "OK"). It's normal for the boards with 8 DC/DCs to "see" voltage at their output even while they are not active : when they are not active, they don't supply current, but they are still able to measure voltage. uski
|
|
|
|
bobsmoke
|
|
October 10, 2013, 03:52:27 PM |
|
Finally got my day 1 device with order 58 online and hashing on hosting. Its a Saturn and will give more details as soon since the Knc pool doesn't show any kind of statistics about your miner.
|
|
|
|
|