|
I suppose ppl are going to say it can be traded on the Blocknet DX. If I have XC and I want to be able to exchange it for BTC (or ETH, ETC, ZEC, XMR, LTC, et cetera) using the DX, can someone ELI5 how I go about that? Is there a site you can go to to see the charts/order book/volume of the DX?
|
|
|
|
|
Balls....well this is burning my VRMs anyway so back to folding I guess. Was hoping to find a quick lucky block when polo first listed it but the price already tanked anyway.
|
|
|
|
** PascalCoin miner ** Version: 0.2
Mining using 3 devices
Connected to 127.0.0.1:4009
MINER VALUES: (My miner name="BARD1")
Current block: 55857 Wallet Name: "bardacuda" Target: 2C543ECE
MINING STATUS:
10:35:39 Miner:"bardacudaBARD1/0------------------" at 580.61 MH/s - Rounds: 13487.88 G Found: 1
10:35:39 Miner:"bardacudaBARD1/1------------------" at 573.58 MH/s - Rounds: 13302.57 G Found: 0
10:35:39 Miner:"bardacudaBARD1/2------------------" at 281.31 MH/s - Rounds: 6524.27 G Found: 0
MY VALID BLOCKS FOUND: 0 Working time: 0d 06:26:45
10:32:56 Block:55856 NOnce:2375023682 Timestamp:1485268377 Miner:bardacudaBARD1/0------------------
LOGS:
10:32:56 Info FOUND VALID NONCE!!! Timestamp:1485268377 Nonce:2375023682
10:32:56 Info Received response method:miner-submit JSON:{"result":{},"error":"Error: Invalid Operations Hash
10:35:06 Update New miner values. Block 55857 Payload bardacuda
10:35:06 Info Updated MinerValuesForWork: Payload:bardacudaBARD1/0------------------
10:35:06 Info Updated MinerValuesForWork: Payload:bardacudaBARD1/1------------------
10:35:06 Info Updated MinerValuesForWork: Payload:bardacudaBARD1/2------------------
10:35:17 Update New miner values. Block 55857 Payload bardacuda
10:35:17 Info Updated MinerValuesForWork: Payload:bardacudaBARD1/0------------------
10:35:17 Info Updated MinerValuesForWork: Payload:bardacudaBARD1/1------------------
10:35:17 Info Updated MinerValuesForWork: Payload:bardacudaBARD1/2------------------ Ummm.......what just happened? |
|
|
|
|
Tried Vorksholk's miner from the OP link...crashes immediately. Tried the 0.2 miner and the intensity is wayy too high. Is there a way to set intensity for PascalCoinMiner 0.2? Also are there any pools?
|
|
|
|
|
Amen to everything cryptohunter said.
|
|
|
|
I really hope that means the price would stop dropping.. I got a feeling pump and dump coming soon.. That means the rate of supply growth is at its maximum. Supply will double by the end of December. |
|
|
|
are you working on proper support for the RX 480 cards? currently they get 33% less than the 390s in zcash but only 5% less in ETH/ETC
 |
|
|
|
While my initial analysis was focused on the external GDDR5 bandwidth limits, current ZEC GPU mining software seems to be limited by the memory controller/core bus. On AMD GCN, each memory controller can xfer 64 bytes (1 cache line) per clock. In SA5, the ht_store function, in addition to adding to row counters, does 4 separate memory writes for most rounds (3 writes for the last couple rounds). All of these writes are either 4 or 8 bytes, so much less than 64 bytes per clock are being transferred to the L2 cache. A single thread (1 SIMD element) can transfer at most 16 bytes (dwordX4) in a single instruction. This means a modified ht_store thread could update a row slot in 2 clocks. If the update operation is split between 2 (or 4 or more) threads, one slot can be updated in one clock, since 2 threads can simultaneously write to different parts of the same 64-byte block. This would mean each row update operation could be done in 2 GPU core clock cycles; one for the counter update, and one for updating the row slot.
Even with those changes, my calculations indicate that a ZEC miner would be limited by the core clock, according to a ratio of approximately 5:6. In other words, when a Rx 470 has a memory clock of 1750Mhz, the core would need to be clocked at 1750 * 5/6 = 1458Mhz in order to achieve maximum performance.
If the row counters can be kept in LDS or GDS, the core:memory ratio required would be 1:2, thereby allowing full use of the external memory bandwidth. There is 64KB of LDS per CU, and the AMD GCN architecture docs indicate the LDS can be globally addressed; i.e. one CU can access the LDS of another CU. However the syntax of OpenCL does not permit the local memory of one work-group to be accessed by a different work-group. There is only 64KB of GDS shared by all CUs, and even if the row counters could be stored in such a small amount of memory, OpenCL does not have any concept of GDS.
This likely means writing a top performance ZEC miner for AMD is the domain of someone who codes in GCN assembler. Canis lupus?
Core speed has more of an effect on 480s but they are still limited by memory bandwidth. I'm very funny that you even still protect 290,390 here is about the memory of 4xx According to AMD According to a CU efficiency increased by 15% compared to the Radeon R9 290. When processing tessellation in conjunction with heavy duty AA efficiency gains can be double or even triple. Supported data compression, thus improving memory bandwidth. In particular, supported by Delta Color compression algorithm that allows you to encode the color difference. On this technique we described in the description of the architecture NVIDIA Pascal. AMD has such compression is maintained including the Radeon Fury X, but the effectiveness of the algorithms at Polaris 10 above. With this increase in the efficiency of a data chip content bus word length of 256 bits. The Radeon RX 480 uses GDDR5 memory chips with an effective rate of communication 8 GHz. And for that AMD has introduced new regulations of memory !!! such as FP16 and 16 Int. Which I think Claymore's does not use, for this reason, the new data on the time of top 480 does not operate at full capacity. And at the same time using the old manual of memory with which he revived the old 7xxx to work at such speeds And compared to the 7xxx, 290 and 390 may be given even greater speed, including 480 if you use the new instructions of memory that only support new models 290-390-480, though only suffer 7xxx model that greatly impact on mining in overall, since the data pattern immediately lose their significance in mining http://i11.pixs.ru/storage/1/6/0/03amdradeo_6383058_24215160.pngI'm not "protecting" anything. I'm simply explaining why the Hawaii cards are faster and will remain faster than Ellesmere given that they have +50% higher memory bandwidth and this algo relies on memory bandwidth, and this has been reinforced by the devs that code these miners. Memory bandwidth:
RX480: 256 GB/s
390X: 384 GB/s
ZEC uses a lot of memory operations. Do you still think that RX480 can work as fast as 390X?
I'm just letting you guys know so ppl stop whining in here that Claymore is somehow intentionally gimping the RX cards. Not only does he have no incentive to do that, he has a big incentive to do exactly the opposite. Otherwise, there's a large chance that people with RX cards are going to switch to Optiminer or ETH. In the case of Optiminer he gets no fees at all, and in the case of ETH he gets a much lower fee and that's only if they use his miner...which they probably won't because the no-fee miners like Genoil's are on par with his. The fact that you quote AMD marketing stuff about color compression just shows that you are grasping at straws and wishing upon stars. Any speedup by these tweaks is only for changes in pixel colors in gaming scenarios, not compute tasks. You have to look at the "uncompressible data" part of the graph and you see that RX 480 gets no speedup due to delta color compression algos. Same thing goes for tesselation and AA optimizations in the compute units. You also can't draw conclusions by underclocking the memory unless you use the same memory straps for every frequency...otherwise, every 125 or 250MHz drop the timings tighten, so a lot of the loss in bandwidth is made up in lower latency. |
|
|
|
do you have a monitor connected to gpu0
Yes. It goes black. I plugged in a Kill A Watt meter, the PSU is 650 watts, and it's only drawing 350 from the wall mining zcash. Wattage rating means nothing. What is the brand/model and how many amps are on the +12V rail? Also, are you using risers? Are they power or unpowered? USB or ribbon? |
|
|
|
|
For you Linux guys, Optiminer just posted v0.6.0 and claims 20-30% increase over v0.5.0
|
|
|
|
XFX pro 850W 80+ bronze
box says 2x 6/8 pin, 2x 6-pin, 24-pin mobo, 8-pin cpu along with abunch of molex and SATA connectors.
You can try to plug one 6-pin and one 8-pin plug to your card. Or you can look for PCI-E 6 to 8 pin adapter, like this one  Thx for your help, gonna order a couple of those right now. @bardacuda good luck mate, tell us how it went Thanks, I'm gonna need it!  EDIT: Check your 6-pin connectors and make sure they have all 6 pins. Most of them do but one of the 3 +12V pins is not actually required by PCI-E standard. If it only has 2 +12V pins I wouldn't try to adapt it into an 8 pin. |
|
|
|
it is 390, sry about the typo
what numbers to set for "easy" OC that doesnt cut into card lifespan much?
btw, I was thinking about getting another one, but my psu doesnt have anymore connectors. R9 390 uses 2x 8 pin. I believe my psu can handle the load, its 850W, but it doesnt have any more 8 pin connectors...
Is there any adaptors molex-> 8pin? Or something like that?
What is exact model of your PSU? You must have at least 2*6 pin and 2*8 pin PCI-E connectors. XFX pro 850W 80+ bronze box says 2x 6/8 pin, 2x 6-pin, 24-pin mobo, 8-pin cpu along with abunch of molex and SATA connectors. so i got 2x 6 pin left to use, along with molex and sata connectors. So there is no room to add 1 more r9 390? That is actually a Seasonic unit and should be fine with 2 390s. I'm actually going to try stuffing 3 Hawaii cards into my M12II 850 after I build a new rig, albeit with some heavy undervolting. |
|
|
|
I don`t know how exact you can adjust memory access to GPU memory, but ppl that compare and cry here thet RX 4xx should be fast as 390x should first learn that any architecture is different, the driver is accessing GPU memory as best as it can, if zcash need many small accesses and if 256bit bus is not wide enough its logical that 384 or 512bit bus will be better
Fiji should be faster,but maybe code isnt be suited for HBM i feel 280x the cards Claymore loves the most - will have 200 sols per card i nthe update  ) I like 390-390X the most - I'm going to reach 300H/s on stock clocks. RX480 will show about 190-200 I think. 280X - about 200 or a bit more. and what about nano/fury ? They have 512 gGB of bandwith... Nano will show about 250H/s, may be I will reach a bit more. |
|
|
|
While my initial analysis was focused on the external GDDR5 bandwidth limits, current ZEC GPU mining software seems to be limited by the memory controller/core bus. On AMD GCN, each memory controller can xfer 64 bytes (1 cache line) per clock. In SA5, the ht_store function, in addition to adding to row counters, does 4 separate memory writes for most rounds (3 writes for the last couple rounds). All of these writes are either 4 or 8 bytes, so much less than 64 bytes per clock are being transferred to the L2 cache. A single thread (1 SIMD element) can transfer at most 16 bytes (dwordX4) in a single instruction. This means a modified ht_store thread could update a row slot in 2 clocks. If the update operation is split between 2 (or 4 or more) threads, one slot can be updated in one clock, since 2 threads can simultaneously write to different parts of the same 64-byte block. This would mean each row update operation could be done in 2 GPU core clock cycles; one for the counter update, and one for updating the row slot.
Even with those changes, my calculations indicate that a ZEC miner would be limited by the core clock, according to a ratio of approximately 5:6. In other words, when a Rx 470 has a memory clock of 1750Mhz, the core would need to be clocked at 1750 * 5/6 = 1458Mhz in order to achieve maximum performance.
If the row counters can be kept in LDS or GDS, the core:memory ratio required would be 1:2, thereby allowing full use of the external memory bandwidth. There is 64KB of LDS per CU, and the AMD GCN architecture docs indicate the LDS can be globally addressed; i.e. one CU can access the LDS of another CU. However the syntax of OpenCL does not permit the local memory of one work-group to be accessed by a different work-group. There is only 64KB of GDS shared by all CUs, and even if the row counters could be stored in such a small amount of memory, OpenCL does not have any concept of GDS.
This likely means writing a top performance ZEC miner for AMD is the domain of someone who codes in GCN assembler. Canis lupus?
Core speed has more of an effect on 480s but they are still limited by memory bandwidth. |
|
|
|
I don`t know how exact you can adjust memory access to GPU memory, but ppl that compare and cry here thet RX 4xx should be fast as 390x should first learn that any architecture is different, the driver is accessing GPU memory as best as it can, if zcash need many small accesses and if 256bit bus is not wide enough its logical that 384 or 512bit bus will be better, even when we know with 2xx and 39x GPU and memory clock is more "aligned" and in sync then on RX cards which usualu work 11xx/2000
CRYING here RX4xx is pointless if you know NOTHING about internel GPU arhitecture and even less about zcash prof of work algo and how its computed
Even if 480 and memory bandwidth 256bit bus still only used 50% of its capacity !!! And I think that the manufacturer knowingly went to such a move is likely for this new chip Polaris dostochno and bandwidth 256bit bus, with his new memory controller that provides a slightly lower performance than the 390 !!! Sorry for my English That would see the controller load from 390 models think it will give a small concept in this issue R9 290 MC usage: 
Do you also know if you want to check if a algo is memory limited, you can go into GPUZ and check out the MCU (memory controller unit) and see the load on it?
I think this is wrong. Although I primarily mine using Linux, I have a Windoze box that I use for testing cards. GPU-z appears to show only external bus bandwidth use (to the GDDR), and not the utilization of the bandwidth between the controller and core. In practical terms, a miner kernel may be using 200GB/s of memory bandwidth, but a significant percentage of it can be from the L2 cache. The collision counter tables in SA5 would be an example of this. Do you have a source for this hypothesis? In all memory restricted algos that correlates to MCU usage. Pretty sure it pertains to any sort of memory overload, bandwidth or bus width... My knowledge of the AMD GCN architecture (and computer architecture in general), and my experience writing OpenCL. |
|
|
|
Hi,
just to know: who could tell me the hashrate for 7850 and r9 270 not overclocked and undervolted.
Since Version 8.0 i'am thinking about to switch my rigs from ethos (ethereum) to W 7 64-Bit and claymore (zcash)
thx
r7 370 currently 110h/s stock 985mhz core. 7850 is the same? r7 265 too.... right now i'm confused (thanks amd) Let's mak it more easy: r7 370 is a rebranded r7 265... r7 265 is a rebranded HD 7850.... TDP 110w, doing 110H/s (Trinidad / Pitcairn pro) r7 370x is a rebranded r9 270x... r9 270x is a rebranded HD 7870 XT... TDP 150-180w, doing a bit less than 110H/s. (Trinidad xt, Pitcairn XT) Why a r7 370 (7850) beats a 270x? I don't know... theyre the same "chip" in different editions (pro vs xt)...somehow it does, thanks to the drivers, and AMD. note: R7 265 overclocks like a motherf*cker. It's one of the weirdest cards AMD has ever made thx but as far as i know ist a R7 265 a rebranded HD 7850 and a r7 370 a rebranded r 9 270 (without x)so R7 370 = R9 270 = 110 H/s so R7 265 = HD7850 = 92 H/s ?? have a nice day 7870 XT is actually a Tahiti chip with more disabled cores and a smaller memory bus which is more similar to Pitcarn. It's a weird card but think of it as more of a 7930. r7 370 is actually a "pro" chip meaning it has 1024 sps like the 7850 and r7 265, but for some reason seems to perform more like a 1280 sp "XT" chip. They must have made some minor performance tweaks. The r9 270s are the same as 7870s and 270Xs with 1280 sps but most were voltage locked and so just couldn't clock as high without BIOS mods. chip wise/core count wise: 7850 = r7 265 = r7 370 < 7870 = r9 270 = r9 270X = 370X < 7870XT Newegg has some sales. Buying a card today.
Which is better for Zcash now and Eth later?
1- PowerColor PCS+ Radeon R9 390 DirectX 12 AXR9 390 8GBD5-PPDHE 8GB 512-Bit GDDR5 PCI Express 3.0 CrossFireX Support ATX Video Card
2- XFX Radeon RS RX 480 DirectX 12 RX-480P836BM 8GB 256-Bit GDDR5 PCI Express 3.0 CrossFireX Support Video Card
Thanks
r9 390 is better for ZCash now purely in Sol/s terms because of it's ~+50% more memory bandwidth (and more cores)...but if your power cost is a significant portion of your revenue it could be less profitable in $/day terms (though not likely). It depends on your power cost and price of the coin. RX 480 is much closer to (though still slower than) a 390 in ETH mining. The lower power cost makes it almost surely more profitable in terms of $/day. |
|
|
|
Memory bandwidth:
RX480: 256 GB/s
390X: 384 GB/s
ZEC uses a lot of memory operations. Do you still think that RX480 can work as fast as 390X?
my 390x claim to have a 512 gb bandwidth have i been lied to by the manufactures  Edit: i thoguth that the 7950"s have 384 gb bandwidth You're thinking of memory bus, 512 bit. here i thought memory bandwidth pertain to memory bus It does pertain to the bus, but is not equivalent to the bus. Bandwidth is the product of bus width and memory clock speed. 512 bits / 8 = 64 Bytes 64 Bytes * (1500 MHz * 4) = 384GB/s I'm running two reference 290's at 400h/s at 1030/1250 -100mv core -100mv aux 0 power level. Fans are now at 50-55% at 85C, this is inside of a Corsair 750D.
I need to put a kill-a-watt on it but it's made a significant difference on the temp with only a 20h/s loss. That's the highest core I can get to at the moment, stable.
Stock BIOS, should I load in the 390 STILT's bios?
One of TheStilt bios for the R9 290 should let you kick the temps down quite a bit while still bumping the clocks up some. On ETH I'm routinely seeing 80C more or less at 1100/1250 under LINUX though I'm running the fans a bit higher than you are. Thanks it means R9 290 and 390 have same speed with big price difference ? 390s can have a bit higher memory clock (and 8GB instead of the usual 4 on a 290) but are otherwise the same. Today Claymore said
He likes 390-390X the most and he is going to reach 300H/s on stock clocks..
Hows this possible on stock clock on 390
Because they are already doing 230S/s+ and he is going to add more optimization. |
|
|
|
Seems the platform for that unit is CWT-PUO1350V. jonnyguru did a review for that unit here. There were a few questionable things...mainly the power cord it came with (which is only an issue in a 115V system)...but overall nothing too bad. I think your main problem was having unpowered risers. A good rule of thumb is to run PCI-E power through the motherboard for no more than two cards...but the fewer the better. This includes cards plugged directly into the board and any on unpowered risers, but it's a good idea to only use powered risers. Anything more than 2 cards should definitely be on powered risers only. Use Molex rather than SATA for your powered risers, and don't power more than 2 risers on one Molex chain. Good luck with your RMAs. |
|
|
|
Is Claymore's miner any faster if not dual mining?
no, if ANY gains are noticed they are negated by the "donation" mining deductions. but then again i'm running an older genoil version before some features i enjoy seeing were removed for the sake of esthetics. same setting(same oc) and i only get 178MH instead of 176, but you need to remove 1% fee, and you have about the same profit if not worse in the end
Ok, thanks! Hi ,
I am just trying ethminer/genoil for the first time and run into some issues:
Allocating/mapping DAG buffer failed with clCreateBuffer(-61). GPU can't Allocate THE DAG in a single chunk. Bailing.
clEnqueueWriteBuffer(-38)
any help with that ?
thanks
It's been a while since I mined ETH, but I know the DAG was supposed to bump 2GB cards out around this time. Make sure you set your environment variables. Use 'setx' to make them permanent, or 'set' to make them only for the current session. I think if you use 'set' you have to use '=' before the value instead of a space but don't quote me on that. So once you open up the command prompt (or in your batch file) you'd type in this: setx GPU_FORCE_64BIT_PTR 0 setx GPU_MAX_HEAP_SIZE 100 setx GPU_USE_SYNC_OBJECTS 1 setx GPU_MAX_ALLOC_PERCENT 100 setx GPU_SINGLE_ALLOC_PERCENT 100 You may have to reboot first for it to take effect. If you type: ethminer --list-devices You should be able to see how much available memory you have on each card. (Apparently you have to add -G to that command now for AMD cards or -U for nVidia). If your available memory (CL_DEVICE_MAX_MEM_ALLOC_SIZE) is less than the size of the DAG, then you can't mine on that card. In my case I see this: c:\Program Files\Ethereum\ethminer-0.9.41-genoil-1.1.7>ethminer --list-devices -G
Genoil's ethminer 0.9.41-genoil-1.1.7
=====================================================================
Forked from github.com/ethereum/cpp-ethereum
CUDA kernel ported from Tim Hughes' OpenCL kernel
With contributions from nicehash, nerdralph, RoBiK and sp_
Please consider a donation to:
ETH: 0xeb9310b185455f863f526dab3d245809f6854b4d
Listing OpenCL devices.
FORMAT: [deviceID] deviceName
[0] Hawaii
CL_DEVICE_TYPE: GPU
CL_DEVICE_GLOBAL_MEM_SIZE: 4294967296
CL_DEVICE_MAX_MEM_ALLOC_SIZE: 4024925276
CL_DEVICE_MAX_WORK_GROUP_SIZE: 256
[1] Hawaii
CL_DEVICE_TYPE: GPU
CL_DEVICE_GLOBAL_MEM_SIZE: 4294967296
CL_DEVICE_MAX_MEM_ALLOC_SIZE: 4024925276
CL_DEVICE_MAX_WORK_GROUP_SIZE: 256
[2] Hawaii
CL_DEVICE_TYPE: GPU
CL_DEVICE_GLOBAL_MEM_SIZE: 4294967296
CL_DEVICE_MAX_MEM_ALLOC_SIZE: 4024925276
CL_DEVICE_MAX_WORK_GROUP_SIZE: 256
[3] Pitcairn
CL_DEVICE_TYPE: GPU
CL_DEVICE_GLOBAL_MEM_SIZE: 2147483648
CL_DEVICE_MAX_MEM_ALLOC_SIZE: 1878490204
CL_DEVICE_MAX_WORK_GROUP_SIZE: 256 So if the DAG is larger than 1.75GB (or 1878490204 bytes), then I won't be able to mine on my Pitcairn card. There was supposed to be some kind of 'chunking' implemented to break the DAG into smaller pieces so you could use the full 2GB, but I don't know if that happened or not. |
|
|
|
|
Show Posts
