[A51] test Kraken

[Max Parker]

Hi, all. I want to test Kraken tool for finding Kc and I have a few
questions: 1 - what version of Ubuntu you recommend to install? (as i
understand, manage a GPU with Kraken is a hell of a story, because it needs
to install some old (2010) software and drivers) 2 - what version of
catalyst and ATI SDK need to install? 3 - with which last AMD Radeon GPU
Kraken works?

Thanks,
Best Regards,
Max

[Jan Hrach]

Post by Max Parker
1 - what version of Ubuntu you recommend to install?

We used it on Debian Wheezy. Therefore, it should work on Ubuntu 12.04.

Post by Max Parker
what version of catalyst and ATI SDK need to install?

We had several then-current versions, so 10-12.something, IIRC all of them worked.

Post by Max Parker
3 - with which last AMD Radeon GPU Kraken works?

The pre-GCN cards, so HD4/5/6xxx. Reportedly, some low-end HD7xxx are actually pre-gcn cores too, but I have no info in this.

Have you considered using Deka <https://brmlab.cz/project/gsm/deka/start>, an OpenCL cracker? :) (disclaimer: I'm Deka author)

Post by Max Parker
Hi, all. I want to test Kraken tool for finding Kc and I have a few questions: 1 - what version of Ubuntu you recommend to install? (as i understand, manage a GPU with Kraken is a hell of a story, because it needs to install some old (2010) software and drivers) 2 - what version of catalyst and ATI SDK need to install? 3 - with which last AMD Radeon GPU Kraken works?
Thanks,
Best Regards,
Max
_______________________________________________
A51 mailing list
https://lists.srlabs.de/cgi-bin/mailman/listinfo/a51

[Milinko Isakovic]

Hi to all,

I tired deka, but seems to be a lot of problems. First of all, I had
problem to install drivers (Debian Jessie) amd64, at the end, finaly I did
it somehow.

Configuration is:

32 Gb ram
2x 7970
8x SAS disk
i7 cpu

Main problem for me is that it seems to me that GPU cracking is not working
or I do not know how to make an setup.

Screenshots I am sending to you describing:

1-5.png - GUP cracking ---> 100+ sec
cpu1-5.ping CPU cracking ---> 18-19 sec

Does anybody know where I am making mistake ?


Also I can give ssh to somebody if somebody would like to do tests / checkl
where problem is>

Regadrs
Milinko

[Jan Hrach]

(ssh'ed there, installed htop and iotop)

This is because you try to crack only one burst at once. The kernel is designed in a way that it loads num_kernels * vector_size fragments at once, i.e., 4096*32 = 131072 fragments (one burst is 16320 fragments) and then time for one round is almost constant. So you need to crack as many bursts in parallel as to keep it fully saturated. If you are cracking only one burst, the CPU *is* faster. But if you submit for example 20 bursts at once (I would recommend even more, say up to 100), you will make the advantage of 2048 cores of your GPU.

PS: your /dev/sdg died, so currently it does not crack at all :-(

Post by Milinko Isakovic
Hi to all,
I tired deka, but seems to be a lot of problems. First of all, I had problem to install drivers (Debian Jessie) amd64, at the end, finaly I did it somehow.
32 Gb ram
2x 7970
8x SAS disk
i7 cpu
Main problem for me is that it seems to me that GPU cracking is not working or I do not know how to make an setup.
1-5.png - GUP cracking ---> 100+ sec
cpu1-5.ping CPU cracking ---> 18-19 sec
Does anybody know where I am making mistake ?
Also I can give ssh to somebody if somebody would like to do tests / checkl where problem is>
Regadrs
Milinko

[Jan Hrach]

I think it looks OK now. I have raised QSIZE to 100. Looks like the queue management in Deka sucks :-/

If you are still there /dev/sdg sould be now ok. I think it was cable issue...
(ssh'ed there, installed htop and iotop)
This is because you try to crack only one burst at once. The kernel is designed in a way that it loads num_kernels * vector_size fragments at once, i.e., 4096*32 = 131072 fragments (one burst is 16320 fragments) and then time for one round is almost constant. So you need to crack as many bursts in parallel as to keep it fully saturated. If you are cracking only one burst, the CPU *is* faster. But if you submit for example 20 bursts at once (I would recommend even more, say up to 100), you will make the advantage of 2048 cores of your GPU.
PS: your /dev/sdg died, so currently it does not crack at all :-(

Post by Milinko Isakovic
Hi to all,
I tired deka, but seems to be a lot of problems. First of all, I had problem to install drivers (Debian Jessie) amd64, at the end, finaly I did it somehow.
32 Gb ram
2x 7970
8x SAS disk
i7 cpu
Main problem for me is that it seems to me that GPU cracking is not working or I do not know how to make an setup.
1-5.png - GUP cracking ---> 100+ sec
cpu1-5.ping CPU cracking ---> 18-19 sec
Does anybody know where I am making mistake ?
Also I can give ssh to somebody if somebody would like to do tests / checkl where problem is>
Regadrs
Milinko

--
Jan Hrach | http://jenda.hrach.eu/
GPG CD98 5440 4372 0C6D 164D A24D F019 2F8E 6527 282E
--
Milinko Isakovic, CEO
CS Network Solutions Limited
72 Blythe Road, West Kensington, London W14 0HB
London Switchboard: [phone]
Belgrade Operations: [phone]
Personal mobille: [phone]
Web: www.cs-networks.net <http://www.cs-networks.net/>
<http://www.facebook.com/smsanywhere> <https://twitter.com/cs_networks> <http://www.linkedin.com/company/cs-networks> <http://www.youtube.com/csnetworks>
--------------------------
This message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. CS Networks shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system. CS Networks does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference.

[Milinko Isakovic]

Jan thank you for assistance, in setup and,


Currently we are facing issue with deka setup. so far we ware able to crack
keys with HD7900 series GPU. but issue is time required to crack one burst
or 100 bursts is approx 3 min
how can we reduce this time.

just for example if 1 gpu is used per burst then cant we use 4 GPU per
burst to decrease lookup time. also currently I have 2 GPU with me but
time taken to crack is same.
here is my procedure
start paplon.py
start oclvankus.py
choose one gpu per instance and run 2 instance.
start one instance of delta_client.py
start cracking

now here are some example result of my crack

crack #0 took 110463 msec
crack #5 took 111005 msec
crack #2 took 113481 msec
crack #6 took 114020 msec
crack #18 took 115290 msec
crack #7 took 116799 msec
crack #9 took 117100 msec
crack #3 took 118306 msec
crack #4 took 118606 msec
crack #15 took 118906 msec
crack #13 took 119809 msec
crack #8 took 120348 msec
crack #16 took 120649 msec
crack #10 took 123359 msec
crack #19 took 124863 msec
crack #11 took 126129 msec
crack #14 took 127872 msec
crack #17 took 130940 msec
crack #12 took 137195 msec

if you can see the time is increasing as it moves with next burst.


i also checked in bursts.samplesession.tar.gz it start with 45000ms and
ends with 65000 ms

now i will result of one gpu instance

crack #5 took 135398 msec
crack #0 took 135700 msec
crack #2 took 138767 msec
crack #15 took 140602 msec
crack #9 took 140905 msec
crack #6 took 141208 msec
crack #3 took 144273 msec
crack #4 took 144574 msec
crack #7 took 144874 msec
crack #16 took 146093 msec
crack #13 took 146395 msec
crack #8 took 147616 msec
crack #21 took 150978 msec
crack #14 took 152812 msec
crack #10 took 153114 msec
crack #19 took 153413 msec

there is very less difference in it


it will be good if one please share actual steps to take while using multi
gpu.

In case of adding for example 14 GPU, and speed will have point only in
rising burst in parallel: for example from 200 to 1000, or we cracking
speed for 200 burst in parallel will be decreasing, and how much it will
decrease?

Also I am wondering, with CPU rising what will happed? In case I use
multiprocessor MB (4cpu or 8cpu), will speed for one burst will go down,
from current 20 second to 5-8 second ? Or only will be able to fish 8
bursts in 20 seconds ?

We are trying to to get speed of 1 second for each burst... Is this
possible anyhow with DEKA ? On what part we need to focus ?

Later we will have questions regarding cluster, but firstly we would like
to get maximum from one computer...

Post by Jan Hrach
I think it looks OK now. I have raised QSIZE to 100. Looks like the queue
management in Deka sucks :-/
https://brmlab.cz/project/gsm/deka/deka-test (crack.txt in the linked
tarball), the others are OK.

If you are still there /dev/sdg sould be now ok. I think it was cable

issue...

(ssh'ed there, installed htop and iotop)
This is because you try to crack only one burst at once. The kernel

is designed in a way that it loads num_kernels * vector_size fragments at
once, i.e., 4096*32 = 131072 fragments (one burst is 16320 fragments) and
then time for one round is almost constant. So you need to crack as many
bursts in parallel as to keep it fully saturated. If you are cracking only
one burst, the CPU *is* faster. But if you submit for example 20 bursts at
once (I would recommend even more, say up to 100), you will make the
advantage of 2048 cores of your GPU.

PS: your /dev/sdg died, so currently it does not crack at all :-(

Post by Milinko Isakovic
Hi to all,
I tired deka, but seems to be a lot of problems. First of all, I

had problem to install drivers (Debian Jessie) amd64, at the end, finaly I
did it somehow.

Post by Milinko Isakovic
32 Gb ram
2x 7970
8x SAS disk
i7 cpu
Main problem for me is that it seems to me that GPU cracking is

not working or I do not know how to make an setup.

Post by Milinko Isakovic
1-5.png - GUP cracking ---> 100+ sec
cpu1-5.ping CPU cracking ---> 18-19 sec
Does anybody know where I am making mistake ?
Also I can give ssh to somebody if somebody would like to do tests

/ checkl where problem is>

Post by Milinko Isakovic
Regadrs
Milinko

--
Jan Hrach | http://jenda.hrach.eu/
GPG CD98 5440 4372 0C6D 164D A24D F019 2F8E 6527 282E
--
Milinko Isakovic, CEO
CS Network Solutions Limited
72 Blythe Road, West Kensington, London W14 0HB
London Switchboard: [phone]
Belgrade Operations: [phone]
Personal mobille: [phone]
Web: www.cs-networks.net <http://www.cs-networks.net/>
<http://www.facebook.com/smsanywhere> <https://twitter.com/cs_networks>

<http://www.linkedin.com/company/cs-networks> <
http://www.youtube.com/csnetworks>

--------------------------
This message (including any attachments) is confidential and may be

privileged. If you have received it by mistake please notify the sender by
return e-mail and delete this message from your system. Any unauthorized
use or dissemination of this message in whole or in part is strictly
prohibited. Please note that e-mails are susceptible to change. CS Networks
shall not be liable for the improper or incomplete transmission of the
information contained in this communication nor for any delay in its
receipt or damage to your system. CS Networks does not guarantee that the
integrity of this communication has been maintained nor that this
communication is free of viruses, interceptions or interference.
--
Jan Hrach | http://jenda.hrach.eu/
GPG CD98 5440 4372 0C6D 164D A24D F019 2F8E 6527 282E

--
Milinko Isakovic, CEO
CS Network Solutions Limited

72 Blythe Road, West Kensington, London W14 0HB

London Switchboard: [phone]
Belgrade Operations: [phone]
Personal mobille: [phone]

Web: www.cs-networks.net
<http://www.facebook.com/smsanywhere> <https://twitter.com/cs_networks>
<http://www.linkedin.com/company/cs-networks>
<http://www.youtube.com/csnetworks>
--------------------------

This message (including any attachments) is confidential and may be
privileged. If you have received it by mistake please notify the sender by
return e-mail and delete this message from your system. Any unauthorized
use or dissemination of this message in whole or in part is strictly
prohibited. Please note that e-mails are susceptible to change. CS Networks
shall not be liable for the improper or incomplete transmission of the
information contained in this communication nor for any delay in its
receipt or damage to your system. CS Networks does not guarantee that the
integrity of this communication has been maintained nor that this
communication is free of viruses, interceptions or interference.

[Jan Hrach]

I have measured it with my client (napalmex from gsmtk) and it was really only 10 kfrag/s.

Regenerated kernel to use only 4x32bit vectors (genkernel32).

Now it computes 2 bursts per second with 60s lag (could be probably fine-tuned), which is ~expected (we have 3 per second on 3x7970). (and now the connection died)

Post by Milinko Isakovic
Jan thank you for assistance, in setup and,
Currently we are facing issue with deka setup. so far we ware able to crack keys with HD7900 series GPU. but issue is time required to crack one burst or 100 bursts is approx 3 min
how can we reduce this time.
just for example if 1 gpu is used per burst then cant we use 4 GPU per burst to decrease lookup time. also currently I have 2 GPU with me but time taken to crack is same.
here is my procedure
start paplon.py
start oclvankus.py
choose one gpu per instance and run 2 instance.
start one instance of delta_client.py
start cracking
now here are some example result of my crack
crack #0 took 110463 msec
crack #5 took 111005 msec
crack #2 took 113481 msec
crack #6 took 114020 msec
crack #18 took 115290 msec
crack #7 took 116799 msec
crack #9 took 117100 msec
crack #3 took 118306 msec
crack #4 took 118606 msec
crack #15 took 118906 msec
crack #13 took 119809 msec
crack #8 took 120348 msec
crack #16 took 120649 msec
crack #10 took 123359 msec
crack #19 took 124863 msec
crack #11 took 126129 msec
crack #14 took 127872 msec
crack #17 took 130940 msec
crack #12 took 137195 msec
if you can see the time is increasing as it moves with next burst.
i also checked in bursts.samplesession.tar.gz it start with 45000ms and ends with 65000 ms
now i will result of one gpu instance
crack #5 took 135398 msec
crack #0 took 135700 msec
crack #2 took 138767 msec
crack #15 took 140602 msec
crack #9 took 140905 msec
crack #6 took 141208 msec
crack #3 took 144273 msec
crack #4 took 144574 msec
crack #7 took 144874 msec
crack #16 took 146093 msec
crack #13 took 146395 msec
crack #8 took 147616 msec
crack #21 took 150978 msec
crack #14 took 152812 msec
crack #10 took 153114 msec
crack #19 took 153413 msec
there is very less difference in it
it will be good if one please share actual steps to take while using multi gpu.
In case of adding for example 14 GPU, and speed will have point only in rising burst in parallel: for example from 200 to 1000, or we cracking speed for 200 burst in parallel will be decreasing, and how much it will decrease?
Also I am wondering, with CPU rising what will happed? In case I use multiprocessor MB (4cpu or 8cpu), will speed for one burst will go down, from current 20 second to 5-8 second ? Or only will be able to fish 8 bursts in 20 seconds ?
We are trying to to get speed of 1 second for each burst... Is this possible anyhow with DEKA ? On what part we need to focus ?
Later we will have questions regarding cluster, but firstly we would like to get maximum from one computer...
I think it looks OK now. I have raised QSIZE to 100. Looks like the queue management in Deka sucks :-/

If you are still there /dev/sdg sould be now ok. I think it was cable issue...
(ssh'ed there, installed htop and iotop)
This is because you try to crack only one burst at once. The kernel is designed in a way that it loads num_kernels * vector_size fragments at once, i.e., 4096*32 = 131072 fragments (one burst is 16320 fragments) and then time for one round is almost constant. So you need to crack as many bursts in parallel as to keep it fully saturated. If you are cracking only one burst, the CPU *is* faster. But if you submit for example 20 bursts at once (I would recommend even more, say up to 100), you will make the advantage of 2048 cores of your GPU.
PS: your /dev/sdg died, so currently it does not crack at all :-(

Post by Milinko Isakovic
Hi to all,
I tired deka, but seems to be a lot of problems. First of all, I had problem to install drivers (Debian Jessie) amd64, at the end, finaly I did it somehow.
32 Gb ram
2x 7970
8x SAS disk
i7 cpu
Main problem for me is that it seems to me that GPU cracking is not working or I do not know how to make an setup.
1-5.png - GUP cracking ---> 100+ sec
cpu1-5.ping CPU cracking ---> 18-19 sec
Does anybody know where I am making mistake ?
Also I can give ssh to somebody if somebody would like to do tests / checkl where problem is>
Regadrs
Milinko

--
Jan Hrach | http://jenda.hrach.eu/
GPG CD98 5440 4372 0C6D 164D A24D F019 2F8E 6527 282E
--
Milinko Isakovic, CEO
CS Network Solutions Limited
72 Blythe Road, West Kensington, London W14 0HB
London Switchboard: [phone]
Belgrade Operations: [phone]
Personal mobille: [phone]
Web: www.cs-networks.net <http://www.cs-networks.net> <http://www.cs-networks.net/>
<http://www.facebook.com/smsanywhere> <https://twitter.com/cs_networks> <http://www.linkedin.com/company/cs-networks> <http://www.youtube.com/csnetworks>
--------------------------
This message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. CS Networks shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system. CS Networks does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference.

--
Jan Hrach | http://jenda.hrach.eu/
GPG CD98 5440 4372 0C6D 164D A24D F019 2F8E 6527 282E
--
Milinko Isakovic, CEO
CS Network Solutions Limited
72 Blythe Road, West Kensington, London W14 0HB
London Switchboard: [phone]
Belgrade Operations: [phone]
Personal mobille: [phone]
Web: www.cs-networks.net <http://www.cs-networks.net/>
<http://www.facebook.com/smsanywhere> <https://twitter.com/cs_networks> <http://www.linkedin.com/company/cs-networks> <http://www.youtube.com/csnetworks>
--------------------------
This message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. CS Networks shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system. CS Networks does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference.

[Milinko Isakovic]

Hi,

It was some issue with provider. You can re-log. One more question is
regarding re-crakc time increase.

I am starting process with:

here is my procedure
start paplon.py
start oclvankus.py - choose one gpu per instance and run 2 instance.
start one instance of delta_client.py
start cracking

first crack will be approx 35 sec, and 100th burst will be approx 100sec, now
after all bursts are cracked we try to crack net set
again it will start around 35 sec and will keep increasing by 1000-5000
msec for each burst... I am not sure why this is increasing ?


crack #1 took 37747 msec
crack #0 took 38727 msec
Found 5A6439C53D7656DB @ 49 #30 (table:292)
Found 99CF3C3A9CB91E59 @ 6 #31 (table:396)
Found 146988FF33EAC243 @ 26 #28 (table:492)
Found 890A6F295CF9D961 @ 39 #45 (table:100)
crack #2 took 40453 msec
crack #5 took 40778 msec
crack #182 took 105511 msec
crack #188 took 105814 msec
crack #194 took 106114 msec
crack #193 took 106342 msec
crack #191 took 107249 msec
ending point
first 37sec
last 107 sec

Is this increasing time, from first to last ok in case of parallel it
sould be near same time ? Or I am missing something in start procedure ?

You are able to log, and check in case I am logged you can kill my process
connection :)

Post by Jan Hrach
I have measured it with my client (napalmex from gsmtk) and it was really only 10 kfrag/s.
Regenerated kernel to use only 4x32bit vectors (genkernel32).
Now it computes 2 bursts per second with 60s lag (could be probably
fine-tuned), which is ~expected (we have 3 per second on 3x7970). (and now
the connection died)

Post by Milinko Isakovic
Jan thank you for assistance, in setup and,
Currently we are facing issue with deka setup. so far we ware able to

crack keys with HD7900 series GPU. but issue is time required to crack one
burst or 100 bursts is approx 3 min

Post by Milinko Isakovic
how can we reduce this time.
just for example if 1 gpu is used per burst then cant we use 4 GPU per

burst to decrease lookup time. also currently I have 2 GPU with me but
time taken to crack is same.

Post by Milinko Isakovic
here is my procedure
start paplon.py
start oclvankus.py
choose one gpu per instance and run 2 instance.
start one instance of delta_client.py
start cracking
now here are some example result of my crack
crack #0 took 110463 msec
crack #5 took 111005 msec
crack #2 took 113481 msec
crack #6 took 114020 msec
crack #18 took 115290 msec
crack #7 took 116799 msec
crack #9 took 117100 msec
crack #3 took 118306 msec
crack #4 took 118606 msec
crack #15 took 118906 msec
crack #13 took 119809 msec
crack #8 took 120348 msec
crack #16 took 120649 msec
crack #10 took 123359 msec
crack #19 took 124863 msec
crack #11 took 126129 msec
crack #14 took 127872 msec
crack #17 took 130940 msec
crack #12 took 137195 msec
if you can see the time is increasing as it moves with next burst.
i also checked in bursts.samplesession.tar.gz it start with 45000ms and

ends with 65000 ms

Post by Milinko Isakovic
now i will result of one gpu instance
crack #5 took 135398 msec
crack #0 took 135700 msec
crack #2 took 138767 msec
crack #15 took 140602 msec
crack #9 took 140905 msec
crack #6 took 141208 msec
crack #3 took 144273 msec
crack #4 took 144574 msec
crack #7 took 144874 msec
crack #16 took 146093 msec
crack #13 took 146395 msec
crack #8 took 147616 msec
crack #21 took 150978 msec
crack #14 took 152812 msec
crack #10 took 153114 msec
crack #19 took 153413 msec
there is very less difference in it
it will be good if one please share actual steps to take while using

multi gpu.

Post by Milinko Isakovic
In case of adding for example 14 GPU, and speed will have point only in

rising burst in parallel: for example from 200 to 1000, or we cracking
speed for 200 burst in parallel will be decreasing, and how much it will
decrease?

Post by Milinko Isakovic
Also I am wondering, with CPU rising what will happed? In case I use

multiprocessor MB (4cpu or 8cpu), will speed for one burst will go down,
from current 20 second to 5-8 second ? Or only will be able to fish 8
bursts in 20 seconds ?

Post by Milinko Isakovic
We are trying to to get speed of 1 second for each burst... Is this

possible anyhow with DEKA ? On what part we need to focus ?

Post by Milinko Isakovic
Later we will have questions regarding cluster, but firstly we would

like to get maximum from one computer...

Post by Milinko Isakovic
I think it looks OK now. I have raised QSIZE to 100. Looks like the

queue management in Deka sucks :-/
from https://brmlab.cz/project/gsm/deka/deka-test (crack.txt in the
linked tarball), the others are OK.

Post by Milinko Isakovic

If you are still there /dev/sdg sould be now ok. I think it was

cable issue...

Post by Milinko Isakovic

(ssh'ed there, installed htop and iotop)
This is because you try to crack only one burst at once. The

kernel is designed in a way that it loads num_kernels * vector_size
fragments at once, i.e., 4096*32 = 131072 fragments (one burst is 16320
fragments) and then time for one round is almost constant. So you need to
crack as many bursts in parallel as to keep it fully saturated. If you are
cracking only one burst, the CPU *is* faster. But if you submit for example
20 bursts at once (I would recommend even more, say up to 100), you will
make the advantage of 2048 cores of your GPU.

Post by Milinko Isakovic

PS: your /dev/sdg died, so currently it does not crack at all

:-(

Post by Milinko Isakovic

Post by Milinko Isakovic
Hi to all,
I tired deka, but seems to be a lot of problems. First of

all, I had problem to install drivers (Debian Jessie) amd64, at the end,
finaly I did it somehow.

Post by Milinko Isakovic

Post by Milinko Isakovic
32 Gb ram
2x 7970
8x SAS disk
i7 cpu
Main problem for me is that it seems to me that GPU cracking

is not working or I do not know how to make an setup.

Post by Milinko Isakovic

Post by Milinko Isakovic
1-5.png - GUP cracking ---> 100+ sec
cpu1-5.ping CPU cracking ---> 18-19 sec
Does anybody know where I am making mistake ?
Also I can give ssh to somebody if somebody would like to do

tests / checkl where problem is>

Post by Milinko Isakovic

Post by Milinko Isakovic
Regadrs
Milinko

--
Jan Hrach | http://jenda.hrach.eu/
GPG CD98 5440 4372 0C6D 164D A24D F019 2F8E 6527 282E
--
Milinko Isakovic, CEO
CS Network Solutions Limited
72 Blythe Road, West Kensington, London W14 0HB
London Switchboard: [phone]
Belgrade Operations: [phone]
Personal mobille: [phone]
Web: www.cs-networks.net <http://www.cs-networks.net> <

http://www.cs-networks.net/>

Post by Milinko Isakovic

<http://www.facebook.com/smsanywhere> <

https://twitter.com/cs_networks> <
http://www.linkedin.com/company/cs-networks> <
http://www.youtube.com/csnetworks>

Post by Milinko Isakovic

--------------------------
This message (including any attachments) is confidential and may

be privileged. If you have received it by mistake please notify the sender
by return e-mail and delete this message from your system. Any unauthorized
use or dissemination of this message in whole or in part is strictly
prohibited. Please note that e-mails are susceptible to change. CS Networks
shall not be liable for the improper or incomplete transmission of the
information contained in this communication nor for any delay in its
receipt or damage to your system. CS Networks does not guarantee that the
integrity of this communication has been maintained nor that this
communication is free of viruses, interceptions or interference.

Post by Milinko Isakovic
--
Jan Hrach | http://jenda.hrach.eu/
GPG CD98 5440 4372 0C6D 164D A24D F019 2F8E 6527 282E
--
Milinko Isakovic, CEO
CS Network Solutions Limited
72 Blythe Road, West Kensington, London W14 0HB
London Switchboard: [phone]
Belgrade Operations: [phone]
Personal mobille: [phone]
Web: www.cs-networks.net <http://www.cs-networks.net/>
<http://www.facebook.com/smsanywhere> <https://twitter.com/cs_networks>

<http://www.linkedin.com/company/cs-networks> <
http://www.youtube.com/csnetworks>

Post by Milinko Isakovic
--------------------------
This message (including any attachments) is confidential and may be

privileged. If you have received it by mistake please notify the sender by
return e-mail and delete this message from your system. Any unauthorized
use or dissemination of this message in whole or in part is strictly
prohibited. Please note that e-mails are susceptible to change. CS Networks
shall not be liable for the improper or incomplete transmission of the
information contained in this communication nor for any delay in its
receipt or damage to your system. CS Networks does not guarantee that the
integrity of this communication has been maintained nor that this
communication is free of viruses, interceptions or interference.
--
Jan Hrach | http://jenda.hrach.eu/
GPG CD98 5440 4372 0C6D 164D A24D F019 2F8E 6527 282E

--
Milinko Isakovic, CEO
CS Network Solutions Limited

72 Blythe Road, West Kensington, London W14 0HB

London Switchboard: [phone]
Belgrade Operations: [phone]
Personal mobille: [phone]

Web: www.cs-networks.net
<http://www.facebook.com/smsanywhere> <https://twitter.com/cs_networks>
<http://www.linkedin.com/company/cs-networks>
<http://www.youtube.com/csnetworks>
--------------------------

This message (including any attachments) is confidential and may be
privileged. If you have received it by mistake please notify the sender by
return e-mail and delete this message from your system. Any unauthorized
use or dissemination of this message in whole or in part is strictly
prohibited. Please note that e-mails are susceptible to change. CS Networks
shall not be liable for the improper or incomplete transmission of the
information contained in this communication nor for any delay in its
receipt or damage to your system. CS Networks does not guarantee that the
integrity of this communication has been maintained nor that this
communication is free of viruses, interceptions or interference.

[Snehasish Kar]

Hi

Is it some how possible to decrypt at one burst per second using deka or kraken?

BR
Snehasish

On 24-Feb-2016, at 3:32 PM, Milinko Isakovic <***@gmail.com<mailto:***@gmail.com>> wrote:

Hi,

It was some issue with provider. You can re-log. One more question is regarding re-crakc time increase.

I am starting process with:

here is my procedure
start paplon.py
start oclvankus.py - choose one gpu per instance and run 2 instance.
start one instance of delta_client.py
start cracking

first crack will be approx 35 sec, and 100th burst will be approx 100sec, now after all bursts are cracked we try to crack net set
again it will start around 35 sec and will keep increasing by 1000-5000 msec for each burst... I am not sure why this is increasing ?


crack #1 took 37747 msec
crack #0 took 38727 msec
Found 5A6439C53D7656DB @ 49 #30 (table:292)
Found 99CF3C3A9CB91E59 @ 6 #31 (table:396)
Found 146988FF33EAC243 @ 26 #28 (table:492)
Found 890A6F295CF9D961 @ 39 #45 (table:100)
crack #2 took 40453 msec
crack #5 took 40778 msec
crack #182 took 105511 msec
crack #188 took 105814 msec
crack #194 took 106114 msec
crack #193 took 106342 msec
crack #191 took 107249 msec
ending point
first 37sec
last 107 sec

Is this increasing time, from first to last ok in case of parallel it sould be near same time ? Or I am missing something in start procedure ?

You are able to log, and check in case I am logged you can kill my process connection :)

On Tue, Feb 23, 2016 at 12:52 PM, Jan Hrach <***@yakumo.hrach.eu<mailto:***@yakumo.hrach.eu>> wrote:
I have measured it with my client (napalmex from gsmtk) and it was really only 10 kfrag/s.

Regenerated kernel to use only 4x32bit vectors (genkernel32).

Now it computes 2 bursts per second with 60s lag (could be probably fine-tuned), which is ~expected (we have 3 per second on 3x7970). (and now the connection died)

Post by Milinko Isakovic
Jan thank you for assistance, in setup and,
Currently we are facing issue with deka setup. so far we ware able to crack keys with HD7900 series GPU. but issue is time required to crack one burst or 100 bursts is approx 3 min
how can we reduce this time.
just for example if 1 gpu is used per burst then cant we use 4 GPU per burst to decrease lookup time. also currently I have 2 GPU with me but time taken to crack is same.
here is my procedure
start paplon.py
start oclvankus.py
choose one gpu per instance and run 2 instance.
start one instance of delta_client.py
start cracking
now here are some example result of my crack
crack #0 took 110463 msec
crack #5 took 111005 msec
crack #2 took 113481 msec
crack #6 took 114020 msec
crack #18 took 115290 msec
crack #7 took 116799 msec
crack #9 took 117100 msec
crack #3 took 118306 msec
crack #4 took 118606 msec
crack #15 took 118906 msec
crack #13 took 119809 msec
crack #8 took 120348 msec
crack #16 took 120649 msec
crack #10 took 123359 msec
crack #19 took 124863 msec
crack #11 took 126129 msec
crack #14 took 127872 msec
crack #17 took 130940 msec
crack #12 took 137195 msec
if you can see the time is increasing as it moves with next burst.
i also checked in bursts.samplesession.tar.gz it start with 45000ms and ends with 65000 ms
now i will result of one gpu instance
crack #5 took 135398 msec
crack #0 took 135700 msec
crack #2 took 138767 msec
crack #15 took 140602 msec
crack #9 took 140905 msec
crack #6 took 141208 msec
crack #3 took 144273 msec
crack #4 took 144574 msec
crack #7 took 144874 msec
crack #16 took 146093 msec
crack #13 took 146395 msec
crack #8 took 147616 msec
crack #21 took 150978 msec
crack #14 took 152812 msec
crack #10 took 153114 msec
crack #19 took 153413 msec
there is very less difference in it
it will be good if one please share actual steps to take while using multi gpu.
In case of adding for example 14 GPU, and speed will have point only in rising burst in parallel: for example from 200 to 1000, or we cracking speed for 200 burst in parallel will be decreasing, and how much it will decrease?
Also I am wondering, with CPU rising what will happed? In case I use multiprocessor MB (4cpu or 8cpu), will speed for one burst will go down, from current 20 second to 5-8 second ? Or only will be able to fish 8 bursts in 20 seconds ?
We are trying to to get speed of 1 second for each burst... Is this possible anyhow with DEKA ? On what part we need to focus ?
Later we will have questions regarding cluster, but firstly we would like to get maximum from one computer...
I think it looks OK now. I have raised QSIZE to 100. Looks like the queue management in Deka sucks :-/

If you are still there /dev/sdg sould be now ok. I think it was cable issue...
(ssh'ed there, installed htop and iotop)
This is because you try to crack only one burst at once. The kernel is designed in a way that it loads num_kernels * vector_size fragments at once, i.e., 4096*32 = 131072 fragments (one burst is 16320 fragments) and then time for one round is almost constant. So you need to crack as many bursts in parallel as to keep it fully saturated. If you are cracking only one burst, the CPU *is* faster. But if you submit for example 20 bursts at once (I would recommend even more, say up to 100), you will make the advantage of 2048 cores of your GPU.
PS: your /dev/sdg died, so currently it does not crack at all :-(

Post by Milinko Isakovic
Hi to all,
I tired deka, but seems to be a lot of problems. First of all, I had problem to install drivers (Debian Jessie) amd64, at the end, finaly I did it somehow.
32 Gb ram
2x 7970
8x SAS disk
i7 cpu
Main problem for me is that it seems to me that GPU cracking is not working or I do not know how to make an setup.
1-5.png - GUP cracking ---> 100+ sec
cpu1-5.ping CPU cracking ---> 18-19 sec
Does anybody know where I am making mistake ?
Also I can give ssh to somebody if somebody would like to do tests / checkl where problem is>
Regadrs
Milinko

--
Jan Hrach | http://jenda.hrach.eu/
GPG CD98 5440 4372 0C6D 164D A24D F019 2F8E 6527 282E
--
Milinko Isakovic, CEO
CS Network Solutions Limited
72 Blythe Road, West Kensington, London W14 0HB
London Switchboard: [phone]
Belgrade Operations: [phone]
Personal mobille: [phone]
Web: www.cs-networks.net<http://www.cs-networks.net> <http://www.cs-networks.net> <http://www.cs-networks.net/>
<http://www.facebook.com/smsanywhere> <https://twitter.com/cs_networks> <http://www.linkedin.com/company/cs-networks> <http://www.youtube.com/csnetworks>
--------------------------
This message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. CS Networks shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system. CS Networks does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference.

--
Jan Hrach | http://jenda.hrach.eu/
GPG CD98 5440 4372 0C6D 164D A24D F019 2F8E 6527 282E
--
Milinko Isakovic, CEO
CS Network Solutions Limited
72 Blythe Road, West Kensington, London W14 0HB
London Switchboard: [phone]
Belgrade Operations: [phone]
Personal mobille: [phone]
Web: www.cs-networks.net<http://www.cs-networks.net> <http://www.cs-networks.net/>
<http://www.facebook.com/smsanywhere> <https://twitter.com/cs_networks> <http://www.linkedin.com/company/cs-networks> <http://www.youtube.com/csnetworks>
--------------------------
This message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. CS Networks shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system. CS Networks does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference.

--
Jan Hrach | http://jenda.hrach.eu/
GPG CD98 5440 4372 0C6D 164D A24D F019 2F8E 6527 282E
--
Milinko Isakovic, CEO
CS Network Solutions Limited

72 Blythe Road, West Kensington, London W14 0HB

London Switchboard: [phone]
Belgrade Operations: [phone]
Personal mobille: [phone]

Web: www.cs-networks.net<http://www.cs-networks.net/>
[cid:]<http://www.facebook.com/smsanywhere> [cid:] <https://twitter.com/cs_networks> [cid:] <http://www.linkedin.com/company/cs-networks> [cid:] <http://www.youtube.com/csnetworks>
--------------------------

This message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. CS Networks shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system. CS Networks does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference.
_______________________________________________
A51 mailing list
***@lists.srlabs.de<mailto:***@lists.srlabs.de>
https://lists.srlabs.de/cgi-bin/mailman/listinfo/a51

[Jan Hrach]

You can enable DEBUGDUMP in vankusconf.py, sumbit some burst from http://jenda.hrach.eu/brm/kraken_magic/bursts.samplesession.tgz and then compare the resulting files. With this you can see if the bug is in chain computation or in table lookup.

hello all
Jan, thank u for your help and for the great tool, DEKA.
i trying to run it but still can't get the Kc. everything looks fine and seems working as expected.
I did everything as you described in your blog. Only one difference I set up my tablet using Behemoth.py
can u please take a look at the screenshots and config file. may be you know where I am making mistake.
Ubuntu 15.10
2xGPU Radeon HD7970
16Gb RAM
40 tables (.dlt) at /dev/sdb2 (2T)
40 (.ins) ad /dev/sdc (2T)
thanks
BR,
Max Parker

Post by Max Parker
1 - what version of Ubuntu you recommend to install?

We used it on Debian Wheezy. Therefore, it should work on Ubuntu 12.04.

Post by Max Parker
what version of catalyst and ATI SDK need to install?

We had several then-current versions, so 10-12.something, IIRC all of them worked.

Post by Max Parker
3 - with which last AMD Radeon GPU Kraken works?

The pre-GCN cards, so HD4/5/6xxx. Reportedly, some low-end HD7xxx are actually pre-gcn cores too, but I have no info in this.
Have you considered using Deka <https://brmlab.cz/project/gsm/deka/start>, an OpenCL cracker? :) (disclaimer: I'm Deka author)

Post by Max Parker
Hi, all. I want to test Kraken tool for finding Kc and I have a few questions: 1 - what version of Ubuntu you recommend to install? (as i understand, manage a GPU with Kraken is a hell of a story, because it needs to install some old (2010) software and drivers) 2 - what version of catalyst and ATI SDK need to install? 3 - with which last AMD Radeon GPU Kraken works?
Thanks,
Best Regards,
Max
_______________________________________________
A51 mailing list
https://lists.srlabs.de/cgi-bin/mailman/listinfo/a51

--
Jan Hrach | http://jenda.hrach.eu/
GPG CD98 5440 4372 0C6D 164D A24D F019 2F8E 6527 282E