[Pcsclite-muscle] CCID: Reduce status change latency by using the status from RDR_to_PC_NotifySlotChange?

[Ran Benita]

On Wed, Jan 1, 2025, at 18:14, Ludovic Rousseau wrote:
> Hello Ran,
>
> Sorry for the delay. Your email was in my spam folder.

Thank you for taking the time to look at this.

> Le mer. 11 déc. 2024 à 21:41, Ran Benita <ran at unusedvar.com> a écrit :
>>
>> For readers which support it, the CCID driver listens for
>> RDR_to_PC_NotifySlotChange notifications on the interrupt endpoint. This
>> replaces the need for polling. When a RDR_to_PC_NotifySlotChange notification
>> is received, the CCID driver then issues a PC_to_RDR_GetSlotStatus to get the
>> new status and notify the application.
>>
>> However, the RDR_to_PC_NotifySlotChange already contains the new status of the
>> slot(s). If the CCID driver were to use it, it could skip the
>> PC_to_RDR_GetSlotStatus roundtrip, thereby removing the 10-20ms latency it
>> adds (by my measurement with a couple of readers) before the application gets
>> the status change. IMO, 10-20ms latency for SCardGetStatusChange, while not a
>> lot, is not insignificant.
>
> I tried with a Gemalto PC Twin reader and I do not get the same numbers.
>
> 03806987 [140463466800832] ../src/ccid_usb.c:1618:InterruptRead() after (0) (0)
> 00000029 [140463466800832] NotifySlotChange: 50 03
> 00000009 [140463466800832] ../src/ifdhandler.c:1983:IFDHICCPresence()
> usb:08e6/3437:libudev:0:/dev/bus/usb/001/006 (lun: 0)
> 00000005 [140463466800832] -> 000000 65 00 00 00 00 00 0A 00 00 00
> 00000400 [140463466800832] <- 000000 81 00 00 00 00 00 0A 01 00 00
> 00000005 [140463466800832] ../src/ifdhandler.c:2109:IFDHICCPresence()
> Card present
>
> The PC_to_RDR_GetSlotStatus command takes 400 µs to be treated by the reader.
>
> I also tried with a Alcor Micro AU9540 and this time the first
> PC_to_RDR_GetSlotStatus command needs 9925 µs (~10 ms).
> The next PC_to_RDR_GetSlotStatus command requires only 796 µs.

I have just tested some readers I have and can confirm your findings:

Contact readers:
04e6:5810 SCM Microsystems, Inc. uTrust 2700 R Smart Card Reader: ~500us
0bda:0165 Realtek Semiconductor Corp. Smart Card Reader Interface: ~400us
04e6:5410 SCM Microsystems, Inc. SCR35xx Smart Card Reader: ~400us
08e6:3437 Gemalto (was Gemplus) GemPC Twin SmartCard Reader: ~400us
2ce3:9563 Generic EMV Smartcard Reader: ~900us

Multi-slot contactless reader (timings from Wireshark, ccid doesn't log for it):
072f:221a Advanced Card Systems, Ltd ACR1251U-A1: ~250us

> If your readers need 20 ms then maybe you have a problem with your readers.
> What readers have you used?
> Are they contactless readers?
> Can you provide traces as described in https://pcsclite.apdu.fr/#support ?

Indeed, it's the particular reader which is slow.
It is a contactless reader which is part of an industrial card dispensing machine.
I should have checked other readers...

>> What are your opinion on this idea? As a proof of concept, I modified
>> `InterruptRead` to return the new status to `IFDHPolling`, which stashes it in
>> the `CcidSlots`; then `IFDHICCPresence` uses this status, if it is set,
>> instead of calling `CmdGetSlotStatus`. This seems to work from rudimentary
>> testing, although there is some business with `bPowerFlags` that I haven't
>> gotten to the bottom of. Hopefully someone more familiar with the code can do
>> it properly, if the idea is sound.
>
> It should work.
> It would add complexity to the driver for a (very) limited gain.

Given that GetSlotStatus is fast on reasonable readers, I agree.

Thanks,
Ran

> Bye
>
> -- 
>  Dr. Ludovic Rousseau