Introducing CherryPicking - new Windows & Linux Pool Hopper

[Bloodred]

@max, so that's only when trying to stop CP on Linux? Does it happen on pool switches? And just to be sure, it's Phoenix having high CPU usage, not CP itself, right?

As for the slow updating, can you post a sample of Phoenix output without CherryPicking, a screenshot or copy-pasted text will do, including the Phoenix live info display? Which version are you using exactly?
The slow live stats updating may be happening because your version of Phoenix may be outputting different text compared to what I used while developing, that's why I need to see what its output is. As always, as long as pool switching works for you and you have normal load on your GPUs, the slow stats update may be just a 'cosmetic' problem.

@blacbe, that's a nice increase. While testing I can't say I've noticed any hash rate difference on my GPUs, but it's good to hear you're getting significantly better results.
Any problems with Phoenix so far, serious or no? Are you on Linux or Windows?

LE: As for developing, I've used Phoenix 1.6.2 on Windows and to get it on Linux I did a git clone and used that for testing (this was when I posted the screenshots).

[blacbe]

im using windows no problems

[pitabread]

Running great on both Windows 7 64bit and Ubuntu 11.04 64.

[max in montreal]

Running, all is fine, and top gives me this:

Code:

root@linuxcoin:/home/user# top

top - 04:53:57 up 23 min,  4 users,  load average: 1.80, 1.63, 1.06
Tasks: 191 total,   1 running, 187 sleeping,   0 stopped,   3 zombie
Cpu(s): 48.4%us, 25.9%sy,  0.0%ni,  8.2%id, 17.4%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   6121188k total,  2143000k used,  3978188k free,   125400k buffers
Swap:        0k total,        0k used,        0k free,   705644k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
 3998 root       1   0  441m  77m  44m S 41.2  1.3   2:28.59 Xorg               
17079 user       1   0  628m  85m  29m S  6.0  1.4   0:03.42 firefox-bin        
 9473 user       1   0  342m  82m  28m S  4.7  1.4   0:40.70 phoenix.py         
 9482 user       1   0  342m  82m  28m S  4.3  1.4   0:40.54 phoenix.py         
 9485 user       1   0  342m  82m  28m S  4.0  1.4   0:37.06 phoenix.py         
 9488 user       1   0  342m  81m  28m S  4.0  1.4   0:40.36 phoenix.py         
 9491 user       1   0  342m  78m  25m S  4.0  1.3   0:40.16 phoenix.py         
 9476 user       1   0  342m  81m  28m S  3.7  1.4   0:40.35 phoenix.py         
 9479 user       1   0  342m  81m  28m S  3.0  1.4   0:36.19 phoenix.py         
15869 root       1   0  212m  10m 7908 S  1.0  0.2   0:00.19 x-terminal-emul    
 9103 root       1   0  252m  21m  14m S  0.7  0.4   0:06.33 AMDOverdriveCtr    
 9107 root       1   0  252m  21m  14m S  0.7  0.4   0:06.52 AMDOverdriveCtr    
 9109 root       1   0  252m  21m  14m S  0.7  0.4   0:06.50 AMDOverdriveCtr    
 9111 root       1   0  252m  21m  14m S  0.7  0.4   0:07.38 AMDOverdriveCtr    
  828 root       1   0     0    0    0 D  0.3  0.0   0:00.01 jbd2/loop1-8       
 2380 root       1  15 16344 1160  816 S  0.3  0.0   0:01.56 preload            
 3036 mysql      1   0  165m  23m 6528 S  0.3  0.4   0:00.43 mysqld    

 

let me try to get thew cpu to spike again...

[Milkshanks]

i have a 17% increase in hashrate with phoenix

Wow, 17%?!

My hashrate has always been higher while using poclbm instead of phoenix.

[max in montreal]

I think my problem was because I was too agressive...

I restarted the system and started cherry a few times and e nded it a few times, all works as it should.

[Bloodred]

I think my problem was because I was too agressive...

I restarted the system and started cherry a few times and e nded it a few times, all works as it should.

There haven't been any changes made to Phoenix on Linux (just checked) since I got it and it's still behaving properly on my install. If you ever get that again I'll have a thorough look through the code, though I can't imagine what could cause high CPU usage in Phoenix.

im using windows no problems

Running great on both Windows 7 64bit and Ubuntu 11.04 64.

Good news!

[blacbe]

this is what i used with poclbm
-v -w256 -f 0 bfi_int

and this with phoenix
-k phatk2 vectors bfi_int aggression=13 worksize=256

[Bloodred]

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:

[max in montreal]

now we can tweak, its awesome!

[Bloodred]

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

[max in montreal]

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:

Code:

UACN10 CYQT 192128
 YZ WG
 UA /OV YSP 090025 /TM 2120 /FL050 /TP BE99 /SK 020BKN040 110OVC /TA -14 /WV 030045 /TB MDT CAT 060-080 /IC LGT RIME 020-040 /RM LGT FZRA INC

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...

[Bloodred]

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.

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

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

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

Bloodred a pair of suggestions.

First the latest version is solid.

Two minor UI tweaks.

1) eliminate need for pressing enter.  i.e. e to exit not e+enter.  i for info not i+enter.
I believe it would be as simple as replacing readline() w/ getchar().  Java isn't my language but most languages support both single char reads and line reads from console.

2) Include the "i" info screen when you exit.  i.e. hitting e displays final info (simply a call to the function which handles i and then exits.  Often I do this manually (i + enter, e + enter) but would be nice to have it all wrapped up.

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.

[Bloodred]

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?

[kdf]

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

Normal
Dynamic Fast Multiplicate
or one of the other choices

Thanks,

[blacbe]

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

Normal
Dynamic Fast Multiplicate
or one of the other choices

Thanks,

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

[max in montreal]

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?

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?

[kdf]

Which pools should we switch to PROP50?

thanks,

[Bloodred]

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

[Bloodred]

but why would it work better?

when there are new config files for some pool u just replace the files sp u dont need to edit them

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.