Topic: Introducing CherryPicking - new Windows & Linux Pool Hopper - page 4. (Read 43136 times)

I'm using them all for hopping. The only pools I have set as backup are PPS pools, which thankfully isn't many afaik.

what do you use them for? hopping or backup?

Also, are the settings for the btcserv configs in the config pack correct? According to btcserv.net, the global network speed was 12.37TH/s, and CherryPicking reports the global speed as 13.7GH/s.. or am I missing something here?

Also, still having issues with mainframe, nofee, unitedminers, and bitp.it.

New How to hop out now!

'How to hop' - now with even more chart porn.

Would it be possible that you could implement support for cherry-picking which GPUs we'd like to use for mining?

Say for instance that I want GPU 0, 1, 3, 4 to be mining with CherryPicking, while GPU 2 is left alone. This can be done with POCLBM and Phoenix, picking which GPU's to dedicate to mining, so could CherryPicking implement this in some way?

EDIT: Anyone else having problems with mainframe, nofee, unitedminers, and bitp.it? CherryPicking has problems connecting to them.

Don't, it would be too much of a mess. What would be the reason for doing it anyways?

I just edit mine also.

I just edit mine. I haven't downloaded new ones since I started using CP. Plus, mine are customized to my liking (got rid of the numbers & changed some of the names). I guess I could do the same with the new system if you do change it so not a problem either way.

Yeah, that was the idea, though I also post any changes I make to the archive here, so I don't know if people download the entire archive again or just edit the changes.

I know BitcoinPool switched to PROP50, don't know about all other pools. I'll have a look.

Which pools should we switch to PROP50?

thanks,

what would the benefits be? more files more complicated. If it would work better than it does now then yes, it would be great, but why would it work better?

i use normal. the other options are lower variance but reduced efficiency. in the long term normal is more profitable but in the short term it's higher risk for higher reward

I was wanting to know what people are using for the hopping algorithm. 

Normal
Dynamic Fast Multiplicate
or one of the other choices

Thanks,

It has been suggested that I separate a pool's mining accounts from the rest of the settings, so each pool would have 2 config files, one for the credentials, one for the other settings. Before implementing this change I want to hear what everybody has to say about it, so would you want this implemented or should I just leave things the way they are?

Actually I was already planning to do that, I had noticed that the update spam didn't really allow you to see much info.

I'm really happy to hear you think CherryPicking is that good!

1) This is actually pretty much impossible in a Java "console" application. Java console apps only really have an input and an output stream, they are not actually aware of running in a console or not and they don't care. Basically, the JVM actually handles the console stuff and reads the application's output stream and writes to its input stream. This means you cannot intercept keypresses or anything like that since you only have access to what the virtual machine is giving you, even if I change to a simple read() that returns a single char, it still only gets written to the input stream itself after you press Enter.
I haven't done too much research into this topic, there may be some way to get around this. Native code could be used, but that would likely cause issues with cross-platform compatibility.

Not saying that I'm 100% sure it's impossible, but don't expect this.

2) Sure, this is no problem and will be there in the next update.

let me think of some other features...

OK OK I got one...

When updating the pools...the stuff flies by too fast for my 40 year old eyes...The reason it scrolls by so fast is because you have verry little information per line.

for example:

*19bitp
Pool update done
     type:PROP
     Hash rate: 6.456 GH/s
     Monitoring mode:shares
     Round shares: 857093
     1.1354738431769291

can be read easier if it was:

*19bitp prop @ 6.456 GH/s shares 857093 1.1354738431769291

If I see that line, I will know the pool update was done, and just like arguments in phoenix or the other miners, i know what those numbers mean. If there is a pool error, replace all info with *19bitp UPDATE FAILED.


Max History:

Long time ago, before the internet I used to teach people how to fly planes...part of becoming a pilot, you had to learn meteorology, or...the weather...

Before flights a pilot would look at the weather report that looked something like this:


Decoded is:
 Routine Upper Air, Aircraft report from Thunder Bay, Ontario issued at 2128 UTC on the 19th
 YZ is Toronto and WG is Winnipeg. This is the Flight Information Region where the PIREP was issued
 Aircraft observation was 25 nmi (46 km) east (090 degrees magnetic) of the Marathon, Ontario VOR/DME at 2120 UTC. The aircraft was at 5,000 ft (1,524 m)and is a Beech 99. The clouds were broken at 2,000 ft (610 m) AMSL with tops at 4,000 ft (1,219 m) and an overcast layer at 11,000 ft (3,353 m) AMSL. The temperature is -14 Celsius and the winds are from the NE (030 degrees true) at 45 knots (83 km/h). There is moderate clear air turbulence between 6,000 ft (1,829 m) and 8,000 ft (2,438 m). There is light rime icing between 2,000 ft (610 m) and 4,000 ft (1,219 m). Note this would indicate that the icing is picked up in the cloud. The remarks section says that light freezing rain was encountered in the cloud.

The hopping info given is not as complicated, but just like miner arguments we will learn what it means if we need to use it.

That is the only thing about the hopper that I think "can be improved", meaning I think everything else is perfect!

But if this is not changed, thats cool too...

Part of the credit goes to max, this feature was his idea.

now we can tweak, its awesome!

Forgetful as I am, I neglected to mention another feature that has been added in 0.6.7, namely that you can see the individual hash rate of each GPU, as has been requested. It can display 8 GPUs at most (no more room on a single default-length terminal line). To switch to/from individual hash rate display press/type g and then Enter. Screenshot below of what it looks like, running on my 2-GPU machine: