Bitcoin Forum
June 21, 2024, 01:03:45 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 [146] 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 ... 247 »
2901  Bitcoin / Mining software (miners) / Re: BFGMiner: modular FPGA/GPU, overclk/fans, GBT, RPC, Linux/PPA/Windows 2.8.2 on: October 08, 2012, 11:24:09 PM
NEW VERSION 2.8.2, OCTOBER 8 2012

Human readable changelog:
  • Numerous fixups for Enterpoint's Cairsmore dynamic clocking; it has actually been tested this time. Smiley
  • Support for --temp-target and --temp-hysteresis controls on ModMiner FPGA devices.
  • Generic failure management for all devices, including automatically attempting to restart dead devices.
  • Improved portability to new platforms, partially including Cygwin.
  • Various minor error handling improvements and bugfixes.

Full changelog
  • Update to libblkmaker 0.1.2
  • Bugfix: --temp-target no longer has a simple default (fixes build without OpenCL support)
  • Bugfix: icarus: Silence false epoll error
  • Bugfix: icarus: Set firstrun for errors starting next job, so the current one finishes properly
  • Bugfix: icarus: Restore generic failure management for write errors
  • Use strtod not strtol for bitforce temp backup.
  • Cope with broken drivers returning nonsense values for bitforce temperatures.
  • Minor warning fixes.
  • Fix unused warnings on ming build.
  • Fix sign warning in ocl.c
  • fds need to be zeroed before set in modminer.
  • Put scrypt warning on separate line to avoid 0 being shown on windows as bufsize.
  • Prevent corrupt values returned from the opencl code from trying to read beyond the end of the buffer by masking the value to a max of 15.
  • Icarus USB write failure is also a comms error
  • api.c DEBUG message has no paramter
  • Icarus catch more USB errors and close/reopen the port
  • API-README update cgminer verison number
  • hashmeter fix stats kh/s on 32bit windows
  • cairnsmore: Increase maximum clock frequency to 210 Mhz
  • icarus: Hashrate estimates really don't need the attention of a warning, demote them to debug
  • cairnsmore: Automatically "downgrade" default FPGA-per-device to 1 for dynclock devices
  • Bugfix: cairnsmore: Get autodetection of dynclock to work consistently
  • cairnsmore: Adjust dynclock usage to react in proper time
  • dynclock: Document function usage
  • cairnsmore: Fix race on dynclock detection
  • icarus: Detect attempts to send commands via work and neuter them
  • cairnsmore: Glasswalker has a minimum multiplier of 20 Sad
  • cairnsmore: Detect frequency changing support despite hashing of commands
  • modminer: Allow clocks down to 2 Mhz just in case
  • Allow device drivers and users to properly change target temperatures for non-GPUs
  • Check that ncurses*-config installs actually work before deciding to use them
  • Bugfix: Fix multiple bugs in autogen.sh
    • Don't use readlink -f unneccesarily (it's not portable)
    • Always run autoreconf within the real source directory
    • Run configure from PWD, *not* the real source directory
  • Bugfix: Include nonce in data buffer for debugging
  • Bugfix: swap32* wants count of 32-bit blocks, not bytes
  • Initial Cygwin port
  • Revert "Remove needless roundl define.", since it is needed for Cygwin and OpenWRT
  • Bugfix: Deal with various compiler warnings
  • modminer: Implement --temp-hysteresis logic
  • Support for maximum frequency being below the default, eg when the maximum is temporarily reduced to deal with temperature
  • Bugfix: modminer: Reduce dynclock max frequency as needed to keep temperature below cutoff
  • Bugfix: Restore disabled label, needed to skip over hashrate calculations (which mess up otherwise)
  • Bugfix: bitforce: Count actual throttling as hardware errors
  • icarus: Allow failure in case of reopen failure, now that the miner core will retry on its own
  • If a device dies, attempt to reinitialize it occasionally
  • Bugfix: The REST flag is now preferred over WAIT, since the former might trigger the latter
  • Bugfix: modminer: Update temperature readings when disabled (fixes thermal cutoff recovery)
  • Bugfix: Move thermal cutoff to general watchdog code (fixes bitforce recovery)
  • Rename enable_device to register_device, since it only works for setting it up at startup
  • Move targettemp from ADL to cgpu_info, so all devices can readily use it
  • Bugfix: "REST" flag had too much padding
  • Bugfix: adl: Only warn and disable GPU due to thermal cutoff, if it's actually enabled
  • Bugfix: bitforce: Only warn and disable bitforce due to thermal cutoff, if it's actually enabled
2902  Bitcoin / Hardware / Re: High Efficiency FPGA & ASIC Bitcoin Mining Devices https://BTCFPGA.com on: October 08, 2012, 02:29:27 PM
You can read all about in the cgminer thread.  To all appearances, the bulk of what's in BFGMiner comes from cgminer.
Well, that's the impression you might get from reading the cgminer thread.
While a lot of the code in BFGMiner came from cgminer (or cpuminer, which cgminer was originally a fork of), pretty much all the modularity and FPGA-related code originated in BFGMiner.
While I didn't bother making formal releases as long as Con was copying the changes back into cgminer anyway (what'd be the point?), he left me no choice when he put Kano in control of my code and he started breaking things.
Then I called him out on claiming BFL didn't support developers (they do), and he stopped merging any updates - including bugfixes - unless someone paid him to do so. This is why FPGA support has suffered so much in cgminer.
In the case of ModMiner support, he merged the initial code (before any real production units were done) on payment from cablepair and didn't merge any of the updates when the actual units differed slightly. So cgminer probably doesn't work well at all with them (though I did avoid changing the protocol in the firmware to try to keep it somewhat compatible).

Not that I've been on every thread here... but those that I have, I've never seen anyone except LJ say anything bad about the cgminer team, and I've never seen anyone stand up for LJ.
Yeah same here, but my time here has been relatively short.  I have read a large part of the cgminer thread though.
Especially on these forums, best to ignore hearsay and base things on things you observe yourself.
If you don't like me, fine, but at least make that decision from what I say/do myself instead of what others say about me.
2903  Other / Off-topic / Re: Is this Luke-jr? on: October 08, 2012, 12:34:32 AM
Definitely needs more sleep.
I think everyone can agree on this, regardless of that 6 year old picture.
2904  Other / Off-topic / Re: Is this Luke-jr? on: October 08, 2012, 12:09:26 AM
No, he's the third most ignored user, because btctalk users like to put their fingers in their ears and sing "I can't hear you" when someone asks the questions that need to be asked.
I believe this thread clearly proves galambo's theory.
2905  Bitcoin / Bitcoin Discussion / Re: The Thai Baht (฿) has always been the most frequently used Bitcoin symbol right? on: October 07, 2012, 11:30:01 PM
Or a piece of paper.
There shouldn't be any problems writing/reading it on paper...

Suggesting that people who aren't upgraded to the latest version of something should be discounted is really elitist.
I didn't say that. His version is so old that it isn't even patched against known security vulnerabilities. It's like driving a car with known-bad brakes.
2906  Bitcoin / Bitcoin Discussion / Re: The Thai Baht (฿) has always been the most frequently used Bitcoin symbol right? on: October 07, 2012, 10:53:02 PM
OS X 10.5.8
So, an OS that is now 5 years old and beyond end of life (no more security fixes). You shouldn't even be allowed online with that.
There are plenty of older systems around, if you really want to enforce your ideal OS standard then I'll believe it when you turn up on my doorstep.  I'm easy to find.
At the very least, it's grounds for automatic ignoring complaints about standard things not working for you. The bugs were already fixed, you're just using a known-buggy version.
2907  Bitcoin / Bitcoin Discussion / Re: The Thai Baht (฿) has always been the most frequently used Bitcoin symbol right? on: October 07, 2012, 10:29:55 PM
OS X 10.5.8
So, an OS that is now 5 years old and beyond end of life (no more security fixes). You shouldn't even be allowed online with that.
2908  Bitcoin / Bitcoin Discussion / Re: The Thai Baht (฿) has always been the most frequently used Bitcoin symbol right? on: October 07, 2012, 09:40:02 PM
Luke -- here's how it renders on Mountain Lion / chrome:

Looks pretty good - except for bold and italic. Wonder why those are messed up for you.

Are you using UTF-16 instead of UTF-8?
No, I only use UTF-8.
Which version?
RFC 3629

Have you successfully rendered this symbol on a system using UTF-8?
Yep, in fact I'm pretty sure these forums use UTF-8 only.

Edit: Actually, looking at the source, I see the forum is choosing ISO-8859-1 encoding, which doesn't work with Unicode at all. This is likely the reason why many people are having technical problems.
If that's the case then the Bitcoin wiki has the same problem.
No, the wiki seems to select UTF-8 properly.
2909  Bitcoin / Bitcoin Discussion / Re: The Thai Baht (฿) has always been the most frequently used Bitcoin symbol right? on: October 07, 2012, 09:34:59 PM
My system supports Unicode 5.0 or 5.1 with UTF-8 and all my programs are configured to use UTF-8, I can assure you your pet favourite isn't displaying properly.
Obviously not then, at least if you tested with my test page (since the forums don't support Unicode properly). Unicode 5.0 chapter 3 ("Conformance") definitely covers combining characters.
2910  Bitcoin / Bitcoin Discussion / Re: The Thai Baht (฿) has always been the most frequently used Bitcoin symbol right? on: October 07, 2012, 09:17:24 PM
I made a test page for the BTC symbol in Unicode since this forum forces a non-Unicode encoding.
2911  Bitcoin / Bitcoin Discussion / Re: The Thai Baht (฿) has always been the most frequently used Bitcoin symbol right? on: October 07, 2012, 09:08:57 PM
B⃦ sucks extra hard for being 2 chars (we invented new problems for you!)
B⃦ is itself a single character, even if comprised of two codepoints.
It's also the same character the forum is using a webfont to render in BTC.
Using multiple codepoints for a single character is not new.

How many times do you need to see posts from others saying (and even showing) that it isn't displaying for the majority of people as it does for you?
Such problems are irrelevant. I'm not suggesting changing anything.

Are you using UTF-16 instead of UTF-8?
No, I only use UTF-8.

Have you successfully rendered this symbol on a system using UTF-8?
Yep, in fact I'm pretty sure these forums use UTF-8 only.

Edit: Actually, looking at the source, I see the forum is choosing ISO-8859-1 encoding, which doesn't work with Unicode at all. This is likely the reason why many people are having technical problems.

Have you viewed this symbol on any system other than your own?
Yep, just pulled it up on a Mac I have lying around and it rendered fine in Lion/Safari.
2912  Bitcoin / Bitcoin Discussion / Re: The Thai Baht (฿) has always been the most frequently used Bitcoin symbol right? on: October 07, 2012, 09:01:52 PM
My vote is for the Thai Baht. It's clean, elegant and standard.
This isn't a vote; B⃦ has been the standard symbol since the beginning, and there is no good reason to change that. This is just Atlas trying to turn Bitcoin into mere "Silk Road currency".

Except not every implementation of Unicode displays whatever symbol that is.
If they don't, it's a bug.
How long until implementations work for most people? 1 year, 5 years, a decade?
Depends on how long "most people" use broken stuff. It works in all the software I run, at least, excepting only Links.
2913  Bitcoin / Bitcoin Discussion / Re: The Thai Baht (฿) has always been the most frequently used Bitcoin symbol right? on: October 07, 2012, 08:56:12 PM
My vote is for the Thai Baht. It's clean, elegant and standard.
This isn't a vote; B⃦ has been the standard symbol since the beginning, and there is no good reason to change that. This is just Atlas trying to turn Bitcoin into mere "Silk Road currency".

Except not every implementation of Unicode displays whatever symbol that is.
If they don't, it's a bug.

The problem is that you've opted for a UTF-16 character instead of a UTF-8 character.  UTF-8 is far more common and accessible.
B⃦ is standard UTF-8, it is not UTF-16.

Once again, I don't see any problem with using the baht symbol for Bitcoin and it has the added advantage of displaying correctly on a wide range of systems.
I'm not addressing whether baht is an acceptable replacement or not; just the reality that it isn't the current standard BTC symbol.
2914  Bitcoin / Pools / Re: [GBT Protocol - ASIC] - BitArena.net - Mining Pool - Prop - 0% Fees. on: October 07, 2012, 07:49:23 PM
It`s a logic system i`l restore the users shares but you will lose all your shares if you don`t mine.
It doesn't work this way. They mined with the contract of a proportional reward. Changing the contract now is fraud.

You seem to be under the impression that pool hopping is an exploit. It's really not - it's just ratoinal miner behaviour with proportional contracts.
The problem isn't the hopping, it's the reward system being unfair. Proportional means the pool pays above market rates for blocks found in the first 50% shares, and pays below market rates for blocks found in the last 50% shares.
For an analogy, this would be like a fast food restaurant paying you much more during on-peak hours, and paying less than minimum wage during off-peak hours. What you're doing is saying "yes, you worked on-peak when we agreed to pay $50/hr; but now nobody wants to work off-peak for 50 cents per hour, so we're just not going to pay you".
2915  Bitcoin / Mining software (miners) / Re: BFGMiner: modular FPGA/GPU, overclk/fans, GBT, RPC, Linux/PPA/Windows 2.8.1 on: October 07, 2012, 12:05:43 PM
Well I hoped it was that easy,  but BFG  detects all my GPU's and is more efficient than CG miner. But not detecting BFL single. Using windows 7.
Can you run bfgminer -D -T -d? and post the output on http://pastebin.com ?
2916  Bitcoin / Mining software (miners) / Re: BFGMiner: modular FPGA/GPU, overclk/fans, GBT, RPC, Linux/PPA/Windows 2.8.1 on: October 07, 2012, 03:48:45 AM
Anybody have  step by step instructions for a newb to connect a BFL single to BFGminer? assume I know nothing...I do know some but its not apparent right now Huh
Just plug it in and run BFGMiner - it autodetects by default.
If you're using some broken Linux OS (notably Ubuntu), you may need to run a modprobe command (the exact command is in the README file).
2917  Bitcoin / Mining software (miners) / Re: BFGMiner: modular FPGA/GPU, overclk/fans, GBT, RPC, Linux/PPA/Windows 2.8.1 on: October 06, 2012, 06:08:45 PM
What is GCN
  what does GCN do
  why would I want to use it and...
  is it only supported by the diakgcn kernel?
GCN is "Graphics Core Next" aka Radeon 7xxx cards. I guess not a big deal anymore, now that we're on FPGAs and soon ASICs...

My rig is using 4-5% less power than with cgminer 2.6.5 and I'm getting the exact same hashrate. HOW?
Can't say there's any one thing that stands out as an obvious power savings (and it may in fact not be any one thing by itself).
2918  Bitcoin / Development & Technical Discussion / Re: Handle much larger MH/s rigs : simply increase the nonce size on: October 06, 2012, 03:06:48 PM
Kano, you're confused because you're only in Bitcoin for "free money". Someday, you'll need to realize "free money" is not really a goal for Bitcoin as a whole.
2919  Bitcoin / Development & Technical Discussion / Re: Handle much larger MH/s rigs : simply increase the nonce size on: October 06, 2012, 12:52:31 PM
GBT was necessary even before ASIC, because the real problem isn't the nonce range being too small, it's that pooled mining today tends to centralize control too much. The primary key feature of GBT is decentralization; that it happens to also solve the ASIC problem came as a nice side-effect.
A perceived problem that even MOST of the network disagrees with you on.

MOST of the network mines on pools - count the % of network using P2Pool or solomining and you will see your argument that GBT solves some control problem holds no water at all.
p2pool and solo, while they do require decentralization, are not unique in supporting it, and both come with their own problems.
2920  Bitcoin / Development & Technical Discussion / Re: Handle much larger MH/s rigs : simply increase the nonce size on: October 06, 2012, 12:29:29 PM
GBT was necessary even before ASIC, because the real problem isn't the nonce range being too small, it's that pooled mining today tends to centralize control too much. The primary key feature of GBT is decentralization; that it happens to also solve the ASIC problem came as a nice side-effect.
Pages: « 1 ... 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 [146] 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 ... 247 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!