stuttering
 

[QUOTE=Ethan (EO);269290]
Because it eliminates one devicetohost memory copy in the inner loop, you may want to give my build from [URL]http://www.mersenneforum.org/showpost.php?p=268927&postcount=524[/URL] a try[/QUOTE]
Ehmm, does anybody also experience stuttering while concurrent video playblack and CUDULucas since the inner loop elimination? It really annoys me. Any ideas? Win7 64, GTX 560 Ti, 280.XX driver.

Btw, the " real time" output hasn't become faster for me switching from CUDA 3.2 to 4.0 (driver and dlls) but I can confirm an GPU usage increase from 97% to 99% (1.2 --> 1.3 eoc).

Nevertheless, nice work apsen and ethan.

[QUOTE=Brain;269483]Ehmm, does anybody also experience stuttering while concurrent video playblack and CUDULucas since the inner loop elimination? It really annoys me. Any ideas? Win7 64, GTX 560 Ti, 280.XX driver.

Btw, the " real time" output hasn't become faster for me switching from CUDA 3.2 to 4.0 (driver and dlls) but I can confirm an GPU usage increase from 97% to 99% (1.2 --> 1.3 eoc).

Nevertheless, nice work apsen and ethan.[/QUOTE]
Indeed...I'll be trying this build soon...but Brain's issue again comes down to the tasking model on the card and questions of priority. He wants to run video playback at high enough priority not to be interfered with by CUDALucas....

[QUOTE=Bdot;269451]Hmm, but isn't that the same as running multiple mfaktc instances in order to fully utilize the GPU?[/QUOTE]

They aren't running concurrently (technically).
There can be multiple kernel calls from one instance running on one GPU but not from different instances. All kernel calls from instance X need to be finished before a kernel call from instance Y can start.

Oliver

[QUOTE=Ethan (EO);268927]Also -- in no way am I trying to centralize or control CUDALucas source development, but I have setup a bzr repository for my work on CUDALucas, and anyone else who wants to coordinate can send me their public key and I'll add them for write access. Read-only access is available at

[CODE]bzr+ssh://bzruser@utila.eocys.com/CUDALucas/trunk[/CODE], using the following private key:

[CODE]-----BEGIN RSA PRIVATE KEY-----
...
-----END RSA PRIVATE KEY-----
[/CODE]

[/QUOTE]

Ethan,

I'm unable to connect to that. First of all the client is trying to create /.ssh directory and has no permissions to that. Also when trying to establish ssh connection I'm being prompted for password (i.e. the key authentication does not work). Could you help with that?

Thanks,
Andriy

[QUOTE=apsen;269812]Ethan,

I'm unable to connect to that. First of all the client is trying to create /.ssh directory and has no permissions to that. Also when trying to establish ssh connection I'm being prompted for password (i.e. the key authentication does not work). Could you help with that?

Thanks,
Andriy[/QUOTE]

Sure -- I think what you need to do is manually create the .ssh directory, and then inside that create a file named `id_rsa' and paste the whole private key block above into it. Then try reconnecting with the bzr client, which should be able to use the key to connect. Let me know if that works!

[QUOTE=Ethan (EO);269958]Sure -- I think what you need to do is manually create the .ssh directory, and then inside that create a file named `id_rsa' and paste the whole private key block above into it. Then try reconnecting with the bzr client, which should be able to use the key to connect. Let me know if that works![/QUOTE]You must also ensure that file ownerships and permissions are correct. The ~/.ssh directory should be owned by the user and be 700 mode (i.e. inaccessible by anyone but the owner). The files in the ~/.ssh directory should (but strictly speaking need not) be owned by the user and 600 mode.

I've been bitten by that one many times, as some of the forum's members can testify.

Paul

[QUOTE=xilman;270002]You must also ensure that file ownerships and permissions are correct. The ~/.ssh directory should be owned by the user and be 700 mode (i.e. inaccessible by anyone but the owner). The files in the ~/.ssh directory should (but strictly speaking need not) be owned by the user and 600 mode.

I've been bitten by that one many times, as some of the forum's members can testify.

Paul[/QUOTE]

I'm aware of that and I can connect via regular ssh to other machines.

[QUOTE=Ethan (EO);269958]Sure -- I think what you need to do is manually create the .ssh directory, and then inside that create a file named `id_rsa' and paste the whole private key block above into it. Then try reconnecting with the bzr client, which should be able to use the key to connect. Let me know if that works![/QUOTE]

Let's do it step by step:

First of all I should be able to:

[CODE]ssh bzruser@utila.eocys.com[/CODE]

Correct?

I cannot - I'm being prompted for password (private key is being offered but falls back to password).

[QUOTE=apsen;270045]Let's do it step by step:

First of all I should be able to:

[CODE]ssh bzruser@utila.eocys.com[/CODE]Correct?

I cannot - I'm being prompted for password (private key is being offered but falls back to password).[/QUOTE]
This may or may not help you solve your problem, but I recommend using the -v (verbose) flag to ssh, and it may provide some insight into your problem.

I personally prefer Git and GitHub to BZR, but to each their own. :smile:

[QUOTE=KingKurly;270048]This may or may not help you solve your problem, but I recommend using the -v (verbose) flag to ssh, and it may provide some insight into your problem.
[/QUOTE]

I did. That's how I see that the key is being offered.

[QUOTE=apsen;270055]I did. That's how I see that the key is being offered.[/QUOTE]
Sorry for the overly basic advice then. I just grabbed the key and tried it myself. It worked.

First, the key info. I stored it in a separate file because I didn't want to mess up my own ssh keys. If you don't have any keys of your own, use id_rsa for the filename and skip the -i flag to ssh below.
[CODE]
kurly@kurlytop:~/.ssh$ ls -ld .
drwx------ 2 kurly kurly 4096 2011-08-25 00:26 .
kurly@kurlytop:~/.ssh$ ls -l bzr
-rw------- 1 kurly kurly 1679 2011-08-25 00:26 bzr
kurly@kurlytop:~/.ssh$ md5sum bzr
58e8aa27f6f8b2aad21e5ec3d36e8ecb bzr
kurly@kurlytop:~/.ssh$ cat bzr
-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEAuf0oTjwsArSJRbbUQ+mFYpDZrt+f3d0wulSb9i+XojMTnmZC
WApmcW8dkKdQVmXo7bcmRatJkHPuzTkYXMoTbASg4rjXDmKaGRrBz68InzCa76Qt
FVC7xExHm4KrdXErWGSDQ5Nn+AMjw7nt8khKeA8FBPhI2hZDTYYG75FFisaWn0bb
BPyK8OqyPO0bH4C8NpeYWxORRhdZoFY8vm8OZCkCtqFXHUuSI6sYfp4vwiswb1XB
coaRjmqWKahpP8+MFCRhOlwkPtMT/UXC47xPEu9mXBPD6I/blWtSHvSSbtZHzK33
l81VmmRyACp5II9l10AFpcw4l0Pb7qm5iTC60QIDAQABAoIBAQCtSsKuOoRrNNme
Wh5m9IMydnJM7NGgwAIx6rmyZV+sYljKQs9YBsCyumxapnpFNgkUzIxdZ55QeKSt
FKCtfB8iiyF4fe7q2VZpQ7QHlTe8U2ZZGKhk7uc0nDowHE0zTPGtF2Hyqbq6q/o7
2NZq4453VM9BdTEz+oBVECcQOlQIWy0f6t7ZC6qkAA8zBVug6ZC3P4POyXrK5J8e
0gAJfy5D8W2pe2W/p5BU0GRr/z4W1X4/P7lQ4mBEZVONg/rXS/6apMmwlUZ5GH17
V7LR+yMhNZszH9vHQ3fljLOXUrLB413fUDRQE2ER1Nk6gYPGIaJuwI3R1UEDosNS
9Q3lyFkRAoGBAPSXQbTwVpEpszA9UXG5SbY121AVV56booLc9rVOlge/7GdRh1Mi
/l/ueS9r7bWimJQkbXC70rMRCcZFJ4b4c5On55nhXwdEFctCRQWhu1a/kDGKkwUX
4kVIl4YofRZMaxYPVL3vuN1VcskLVc29oRt+nvgykGaOmRyVT4r8Qkh9AoGBAMKq
HWCoN+bOCPAZRYOEBJC8/3+qSqrE2qnmBucJwgcI/VU5GitwxNJm1HCpZQjbb32S
ZF62tlieiIbdsVnD0tvQwKc2HMP5Ml3mCGgPt1r4n99Lcl6803kbwLzOojR8+3Sa
/ddOWw51+oF0RJezUXaYZCjr1w+nckSJzVoEld/lAoGBAJm/asI+QWxGdijgoo2G
F1u+Rvn0MHu3AVSZaUtW9uAwOH5JtXMBED1lPjAc+/OtHZQhwdmXdz6weyBy4AHr
s1shtGf6Ty3WEo0OPyznGUfSauV5YilVdhpvIzBlyxt1NetL/8zVH7OhvuG5ilol
1VvfIDaMMlEFWiGpibKoF1JRAoGAGwnkALv838s4hJkOBcF9nNkTqBjwPB4RvU2d
IdRCJhYCkibXUrdcL1lnIqr0xLEuIEQIOvuoAlEq54i9jJldnXi2ecNTZYkkjNRZ
0JJ2RmWIV0y0eyJBQW4wbElLUH0XtE+e+JwCm9SZUgfjSyr2IsHyD5kKizsX7Rsy
8dD3PF0CgYB0ft0q6+S4YWuja9r2aSYFdhBJYp2rmV3ZZC2wQXkatcU968y7DqUf
0OU0NITw5RoDXKHqCIUBmGEtxkolc8nNEXo4TKkV6+aY0DEK9gKLgvpJDOVavm1O
m4HGdh0J7AWwleRgCll69WG8xxX4aIADHjGHAmVPdW9olkHev+NHjQ==
-----END RSA PRIVATE KEY-----
[/CODE]Next, the SSH connection. The final line of output indicates that I can't get a PTY, but that's to be expected: I'm sure shell access is denied for this account... BZR access only. (At least that's how the 'git' account is set up on GitHub, as well as my home machine.) You will see that the key was offered and accepted. The -i tag tells it to use that specific file as the ID. Apparently it tries my key first, but you can see that I was able to connect successfully.

[CODE]
kurly@kurlytop:~/.ssh$ ssh -v -i ./bzr bzruser@utila.eocys.com
OpenSSH_5.8p1 Debian-1ubuntu3, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to utila.eocys.com [74.94.66.61] port 22.
debug1: Connection established.
debug1: identity file ./bzr type -1
debug1: identity file ./bzr-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p1 Debian-1ubuntu3
debug1: match: OpenSSH_5.8p1 Debian-1ubuntu3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.8p1 Debian-1ubuntu3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: RSA e2:d2:33:3c:0f:e8:d9:42:8d:48:6c:a6:55:bd:ae:1e
debug1: Host 'utila.eocys.com' is known and matches the RSA host key.
debug1: Found key in /home/kurly/.ssh/known_hosts:49
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: [CENSORED]
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: ./bzr
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to utila.eocys.com ([74.94.66.61]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Remote: Forced command.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Port forwarding disabled.
debug1: Remote: Pty allocation disabled.
debug1: Remote: User rc file execution disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
PTY allocation request failed on channel 0
[/CODE]Let me know if I can provide further help; I'm a big fan of open source projects. :smile: