Hi again, The crystal clock embedded in the reader also has an influence on transfer speed (and on card processing speed if the card is old).
Regards Sebastien Le 08/09/2011 13:56, Ludovic Rousseau a écrit : > 2011/9/8 Umberto Rustichelli aka Ubi <[email protected]>: >> Humm... the next question is required by my boss, and I'd like to know, >> too... :) >> >> The scenario is this one: the smart cards in use belong to the same family >> (InCard InCrypto v2) of others that we commonly use without this glitch, >> just they are more recent. >> The reader is totally different from the one we commonly use, that is >> no issue: Omnykey 3121 + old InCrypto (serial 100...) >> with issue: ACR38 + new InCrytpo (serial 700...) > The Omnykey 3121 [1] is an APDU reader and the T=1 protocol is > implemented by the reader. > The ACR38U [2] is a TPDU reader and the T=1 is implemeted by the > driver (with the logs you see). > >> We're going to perform some tests, but regarding the negotiated time out, >> which part is responsible for that? What does it depend on? >> Reader? SW? Smart card? Is the smart card aware if the time required to >> perform operations? >> Can I change the timeout via some configuration file (our logs are filled up >> of this message)? >> As a rule of thumb, is it possible that the reader is responsible for the >> slowdown, or is it never the culprit? > I don't want to go into details. If you want more information you > should read ISO 7816-3. > > Have you _measured_ a slowdown? What are the numbers? > > Note that readers are _not_ equivalent. Some readers are faster than > others. Have a look at [3] with readers sorted by dwMaxDataRate. > > Bye > > [1] http://pcsclite.alioth.debian.org/ccid/readers/CardMan3121.txt > [2] http://pcsclite.alioth.debian.org/ccid/readers/ACR38U-CCID.txt > [3] http://pcsclite.alioth.debian.org/ccid/dwMaxDataRate.html > _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
