Vertcoin - First Scrypt N | First Stealth Address - Privacy without mixer

[djm34]

if you are using catalyst 14.6 or below (lol... ) please replace in lyra2RE.cl

#define SPH_ROTL32(x, n)   (((x) << (n)) | ((x) >> (32 - (n))))
#define SPH_ROTR32(x, n)   (((x) >> (n)) | ((x) << (32 - (n))))

#define SPH_ROTL64(x, n)   (((x) << (n)) | ((x) >> (64 - (n))))
#define SPH_ROTR64(x, n)   (((x) >> (n)) | ((x) << (64 - (n))))

by

#define SPH_ROTL32(x,n) rotate(x,(uint)n)
#define SPH_ROTR32(x,n) rotate(x,(uint)(32-n))
#define SPH_ROTL64(x,n) rotate(x,(ulong)n)
#define SPH_ROTR64(x,n) rotate(x,(ulong)(64-n))

That should increase the hashrate (actually it is the inverse on 14.9... no idea what they are doing with their compiler between each version)

report if you see some increase or decrease and with which driver version...

[bigradeon]

@djm34
with your tweak my hash rate is increasing in a few kh/s per gpu, approximately 3-5kh/s but unfortunately more RJ
w7 64bit 14.6

[jk_14]

Oh, right.

Hi, Wolf

under linux, in some algos there are quite huge amount of context switches per second
(what cause high cpu utilisation):

for example:

Celeron + 3x 750Ti:

root@kopiemtu:~# vmstat -n 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 5  0      0 2269904  64944 1106396    0    0     0     4   11    7 45 20 35  0  0
 3  0      0 2269896  64944 1106396    0    0     0    26  590 257053 57 43  0  0  0
 3  0      0 2269896  64944 1106396    0    0     0     0  594 256664 57 43  0  0  0
 3  0      0 2269864  64944 1106396    0    0     0     0  588 257120 57 43  0  0  0

root@kopiemtu:~# uptime
 21:41:52 up 22 days,  7:03,  2 users,  load average: 3,13, 3,09, 3,06


and:
Xeon + 5x 750Ti

root@kopiemtu:~# vmstat -n 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 6  0      0 2148372  59916 589464    0    0     0     1    9    5 24 15 61  0  0
 5  0      0 2148364  59916 589464    0    0     0     0 1177 367276 61 39  0  0  0
 5  0      0 2148364  59916 589464    0    0     0     0 1158 366147 61 39  0  0  0
 5  1      0 2148364  59916 589464    0    0     0    23 1171 365873 61 39  0  0  0

root@kopiemtu:~# uptime
 21:41:35 up 13 days,  4:21,  2 users,  load average: 5,17, 5,16, 5,14



but there are algos, even in the same ccminer fork, where this problem doesn't exist,
could you suppose, what is the reason of it?

[djm34]

@djm34
with your tweak my hash rate is increasing in a few kh/s per gpu, approximately 3-5kh/s but unfortunately more RJ
w7 64bit 14.6

that's strange, I get about 100kh/s more (no change in reject)

[djm34]

Oh, right.

Hi, Wolf

under linux, in some algos there are quite huge amount of context switches per second
(what cause high cpu utilisation):

for example:

Celeron + 3x 750Ti:

root@kopiemtu:~# vmstat -n 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 5  0      0 2269904  64944 1106396    0    0     0     4   11    7 45 20 35  0  0
 3  0      0 2269896  64944 1106396    0    0     0    26  590 257053 57 43  0  0  0
 3  0      0 2269896  64944 1106396    0    0     0     0  594 256664 57 43  0  0  0
 3  0      0 2269864  64944 1106396    0    0     0     0  588 257120 57 43  0  0  0

root@kopiemtu:~# uptime
 21:41:52 up 22 days,  7:03,  2 users,  load average: 3,13, 3,09, 3,06


and:
Xeon + 5x 750Ti

root@kopiemtu:~# vmstat -n 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 6  0      0 2148372  59916 589464    0    0     0     1    9    5 24 15 61  0  0
 5  0      0 2148364  59916 589464    0    0     0     0 1177 367276 61 39  0  0  0
 5  0      0 2148364  59916 589464    0    0     0     0 1158 366147 61 39  0  0  0
 5  1      0 2148364  59916 589464    0    0     0    23 1171 365873 61 39  0  0  0

root@kopiemtu:~# uptime
 21:41:35 up 13 days,  4:21,  2 users,  load average: 5,17, 5,16, 5,14



but there are algos, even in the same ccminer fork, where this problem doesn't exist,
could you suppose, what is the reason of it?

Probably something to do with how the CPU waits for the CPU. You could make it busy wait for greatest reaction time, but that would spin a core at 100% per GPU.

had to check what was the context switch...
I think, it is normal, in bbr or lyra2, the gpu compute a smaller number of threads than in x11 so to process the entire range of nonce it will require more gpu calls, meaning the program will go back more often on the cpu.
However this shouldn't really increase cpu usage.
Would be interesting to get some feedback on cpu usage on linux

[bigradeon]

@djm i 'll try again later  maybe it depend on system configuration.

[scam-buster]

why the power network has grown so dramatically?

[randywald]

I now test settings for Sapphire R9 290 TRI-X . It looks like 1.15 MH/s.

Code:

"xintensity" : "128",
"worksize" : "256",
"kernel" : "Lyra2RE",
"algorithm" : "Lyra2RE",
"lookup-gap" : "2",
"thread-concurrency" : "15360",
"shaders" : "2560,2560",
"gpu-threads" : "2",
"gpu-engine" : "1020,1020",
"gpu-memclock" : "1500,1500",
"gpu-fan" : "40",
"gpu-memdiff" : "0",
"gpu-powertune" : "20",
"gpu-vddc" : "0.000",
"temp-cutoff" : "95",
"temp-overheat" : "85",
"temp-target" : "80",
"api-mcast-port" : "4028",
"api-port" : "4028",
"expiry" : "28",
"failover-switch-delay" : "60",
"gpu-dyninterval" : "7",
"gpu-platform" : "0",
"log" : "20",
"no-pool-disable" : true,
"queue" : "1",
"scan-time" : "7",
"tcp-keepalive" : "30",
"temp-hysteresis" : "3",
"shares" : "0",
"kernel-path" : "/usr/local/bin",
"verbose" : "true"

Edit: Please correct me if you have better settings.

[randywald]

why the power network has grown so dramatically?

I think this is KNC Titan mining Scrypt-N. After switching to Lyra2RE ASICs cannot mine it anymore.

[jk_14]

Oh, right.

Hi, Wolf

under linux, in some algos there are quite huge amount of context switches per second
(what cause high cpu utilisation):

for example:

Celeron + 3x 750Ti:

root@kopiemtu:~# vmstat -n 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 5  0      0 2269904  64944 1106396    0    0     0     4   11    7 45 20 35  0  0
 3  0      0 2269896  64944 1106396    0    0     0    26  590 257053 57 43  0  0  0
 3  0      0 2269896  64944 1106396    0    0     0     0  594 256664 57 43  0  0  0
 3  0      0 2269864  64944 1106396    0    0     0     0  588 257120 57 43  0  0  0

root@kopiemtu:~# uptime
 21:41:52 up 22 days,  7:03,  2 users,  load average: 3,13, 3,09, 3,06


and:
Xeon + 5x 750Ti

root@kopiemtu:~# vmstat -n 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 6  0      0 2148372  59916 589464    0    0     0     1    9    5 24 15 61  0  0
 5  0      0 2148364  59916 589464    0    0     0     0 1177 367276 61 39  0  0  0
 5  0      0 2148364  59916 589464    0    0     0     0 1158 366147 61 39  0  0  0
 5  1      0 2148364  59916 589464    0    0     0    23 1171 365873 61 39  0  0  0

root@kopiemtu:~# uptime
 21:41:35 up 13 days,  4:21,  2 users,  load average: 5,17, 5,16, 5,14



but there are algos, even in the same ccminer fork, where this problem doesn't exist,
could you suppose, what is the reason of it?

Probably something to do with how the CPU waits for the GPU. You could make it busy wait for greatest reaction time, but that would spin a core at 100% per GPU.

yeah, right, i.e. "active wait"

this printout above is from your cudaminer for BBR fork, but it's present in some other algos, too

[jk_14]

had to check what was the context switch...
I think, it is normal, in bbr or lyra2, the gpu compute a smaller number of threads than in x11 so to process the entire range of nonce it will require more gpu calls, meaning the program will go back more often on the cpu.
However this shouldn't really increase cpu usage.
Would be interesting to get some feedback on cpu usage on linux

OK, that would explain it more-less
that is cpu usage on linux during BBR mining on Celeron above:

Code:

top - 18:10:54 up 23 days,  3:32,  1 user,  load average: 3,01, 2,87, 2,94
Tasks: 101 total,   2 running,  99 sleeping,   0 stopped,   0 zombie
%Cpu0  : 58,0 us, 41,7 sy,  0,0 ni,  0,0 id,  0,0 wa,  0,3 hi,  0,0 si,  0,0 st
%Cpu1  : 58,3 us, 41,6 sy,  0,0 ni,  0,0 id,  0,0 wa,  0,2 hi,  0,0 si,  0,0 st
KiB Mem:   4020192 total,  1743208 used,  2276984 free,    65124 buffers
KiB Swap:        0 total,        0 used,        0 free.  1107168 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
27849 root      20   0 32,980g 264564 176740 S 199,2  6,6   1926:13 cpuminer
18522 root      20   0       0      0      0 S   0,7  0,0   0:02.47 kworker/0:1
  329 root      39  19       0      0      0 S   0,2  0,0 106:54.09 kipmi0
    1 root      20   0   33792   3164   1472 S   0,0  0,1   0:02.21 init

that is BBR mining on Xeon from example above

Code:

top - 18:12:43 up 14 days, 54 min,  1 user,  load average: 5,00, 4,96, 5,00
Tasks: 125 total,   3 running, 122 sleeping,   0 stopped,   0 zombie
%Cpu0  : 62,8 us, 37,2 sy,  0,0 ni,  0,0 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
%Cpu1  : 61,4 us, 38,6 sy,  0,0 ni,  0,0 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
%Cpu2  : 58,1 us, 41,9 sy,  0,0 ni,  0,0 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
%Cpu3  : 61,9 us, 38,1 sy,  0,0 ni,  0,0 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
KiB Mem:   4015084 total,  1281640 used,  2733444 free,    57232 buffers
KiB Swap:        0 total,        0 used,        0 free.   548544 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
15654 root      20   0 41,375g 388208 290616 S 399,4  9,7 992:05.78 cpuminer
 3304 root      20   0       0      0      0 S   2,3  0,0   0:13.35 kworker/0:3
    1 root      20   0   33648   2984   1456 S   0,0  0,1   0:01.75 init
    2 root      20   0       0      0      0 S   0,0  0,0   0:00.55 kthreadd

and the same set for Lyra2RE:

Code:

top - 20:07:53 up 20 days,  5:29,  2 users,  load average: 2,92, 2,54, 2,71
Tasks: 116 total,   3 running, 113 sleeping,   0 stopped,   0 zombie
%Cpu0  :  0,0 us, 42,7 sy, 54,9 ni,  2,0 id,  0,0 wa,  0,3 hi,  0,0 si,  0,0 st
%Cpu1  :  0,0 us, 43,5 sy, 55,8 ni,  0,7 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
KiB Mem:   4020192 total,  1308852 used,  2711340 free,    63156 buffers
KiB Swap:        0 total,        0 used,        0 free.   713548 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 1817 root      20   0 32,864g 238604 181900 S 196,1  5,9   8:14.27 ccminer
29671 root      20   0       0      0      0 S   0,7  0,0   0:00.91 kworker/0:1
 4708 root      20   0   31408   1592   1112 R   0,3  0,0   0:00.07 top
    1 root      20   0   33792   3164   1472 S   0,0  0,1   0:02.13 init

Code:

top - 23:11:17 up 2 days, 14:14,  2 users,  load average: 4,71, 4,91, 5,00
Tasks: 175 total,   1 running, 174 sleeping,   0 stopped,   0 zombie
%Cpu0  :  2,2 us, 46,1 sy, 48,5 ni,  3,2 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
%Cpu1  :  3,0 us, 48,1 sy, 47,9 ni,  1,0 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
%Cpu2  :  0,2 us, 47,4 sy, 52,0 ni,  0,4 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
%Cpu3  :  1,8 us, 47,0 sy, 48,0 ni,  3,2 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
KiB Mem:   4012956 total,  1730088 used,  2282868 free,   111084 buffers
KiB Swap:        0 total,        0 used,        0 free.   785488 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
11682 root      20   0 41,250g 383464 297076 S 381,7  9,6   4:02.48 ccminer
 1150 root      20   0  298808  38068   3080 S   2,2  0,9   7:06.31 polkitd
  703 message+  20   0   39936   2080   1040 S   0,8  0,1   2:33.04 dbus-daemon
11675 root      20   0       0      0      0 S   0,6  0,0   0:00.15 kworker/0:7
 1123 root      20   0  347312   6424   4784 S   0,4  0,2   1:22.94 NetworkManage

[voephilis]

great to see how this forum changed from a investors/speculators forum to a miners forum 

waiting for lyra2RE !

[silencesilence]

I think everything is going according to plan  

104 hour or 4.3 days to Lyre2RE Update from now  

Friends tell all your friends to update wallets  

share the news in your city, country or planet  

80 hour or 3.3 days to Lyre2RE Update from now 

[poiuty]

Somebody already tested Catalyst Omega  14.12?
http://support.amd.com/ru-ru/download/desktop?os=Linux+x86

[centrafuge]

Can I just copy the new wallet files to my existing install directory? I'm using win 64 bit.

Thanks

[poiuty]

14.12 and linux -> no HW. But hash rate slow.
270X 14.12 => 550 Kh/s
270X 14.6 => 630 Kh/s

[jamesl22]

Can I just copy the new wallet files to my existing install directory? I'm using win 64 bit.

Thanks

Yes, but make sure to back up your wallet.dat just in case!

[centrafuge]

Will do...

Many Thanks

[poiuty]

Test Lyra2RE P2Pool. Settings.

"url" : "stratum+tcp://eu.p2pool.pl:9175",
"user" : "VjkHXUAQo1ifpPdrHafbr7yokWBCAUudyW",
"pass" : "x"

[Pansyfaust]

I'm waiting for Windows QT (GUI) 64-bit 

Thanks Vert Team

Yes, THANK YOU Vert team! Keep it up. 

Dude, hey Pansy from carbonite