Hello, List,

I used the pcsc-lite version of Damien Sauveron to test
two Athena ASEDrive IIIe USB readers working in parallel.
The smart cards were Starcos SPK 2.3 with Protocol T=1.
The reader driver was the last version from the Athena site,
ASEDriveIIIeUSB1.1, with the addition of the new tag
TAG_IFD_THREAD_SAFE.
The test program produced 1024 bit RSA signatures in an
endless cycle.
The system was a SuSe Linux 8.1 with kernel 2.4.19-4GB.

With this test bed I was able to get a performance of ca.
2 signatures per second per reader, i.e. a total throughput
of 4 signatures per second (real multithreading).

This is quite impressive, since the readers I tested before
needed 1 to 2 seconds to do a signature. Moreover, it's the
first time I got real multithreading using protocol T=1 cards,
USB readers and pcsc-lite.

I think this was the first test of Damien's multithreading
version of pcsc-lite besides of his own, so it may be an
interesting feedback for him and for the list.

I would appreciate it very much, if Damiens modifications to
pcsc-lite could find their way into the head of the cvs!

Regards Bettina Martelli


Damien Sauveron wrote:
Hi,

I am happy to announce that a new implementation of clients management for PC/SC Lite is available on [1].
Before to commit it on the CVS, we need your feedbacks. I have tested it and it seems work fine. The tarball includes all the modifications realized on the CVS since the last release (1.2.0)


New features:
- differents processes (i.e. applications) can access to differents readers in parallel
- differents threads can access to differents readers in parallel if each have created its own context (SCardEstablishContext)
- if differents threads sharing a same context there is a mutex on the context an the operation are serialized.


To do:
Authorized to release a context by only the thread that has created it.
Cleanups in the code.
Verify the support with SCF. Actually I think that there is no problem with SCF and that only the first feature is supported. The other new features should be not supported. Volunteers for implement them ?


In the previous version we have only one thread in all the process that can access in one reader. Moreover now the clients are scheduled by the kernel avoid to implements our round-robin scheduling.
One or two month ago I have added the support in parallel of readers but it was useless because we did not have this new clients management design. Now we will get better performance.
I will try to do a complete benchmark tomorrow.


This version also contains many cleanups/corrections and simplifies the code of the previous version.

I hope this version will be usefull for you and I await impatiently your feedbacks if you have some problems or not.

[1] http://damien.sauveron.free.fr/

Regards,


-- Dr. Bettina Martelli, Development, TC TrustCenter AG Sonninstra�e 24-28, D-20097 Hamburg, Germany Tel: +49 (0)40 / 80 80 26-0 Fax: +49 (0)40 / 80 80 26-126

_______________________________________________
Muscle mailing list
[EMAIL PROTECTED]
http://lists.musclecard.com/mailman/listinfo/muscle

Reply via email to