Hello, I have the the same results as you Frank, the process time always increase for each reader, and is a JRE problem, because I made some tests using the "scriptor" of pcsc-tools with two and three readers in different threads , and the execution time was identical of just one reader.
In my case, I just need to stablish a connection to smart cards in one or more readers and send commands to them, this is very practical, easy and fast with javax.smartcardio, but this non-parallelism become a real problem for me, I really need it. What would you suggest? Do you think rewrite the provider is a good option? It will be very low-level for me, I'm not so used to it hehe My system is all Java based, then will become a little hard to rebuild it to another language, but is a possibility... Just a curiosity, this happen on Apple OS too? Thanks for all the help. Regards Murilo ________________________________________ De: Muscle [muscle-boun...@lists.musclecard.com] em nome de Frank Marien [fr...@apsu.be] Enviado: quinta-feira, 4 de julho de 2013 11:48 Para: muscle@lists.musclecard.com Assunto: Re: [Muscle] RES: Parallel Process with readers - pcsc-lite Right, Parallellization test, Java SE 1.6, Arch Linux, pcsc-lite version 1.8.8. Enabled features: Linux x86_64-unknown-linux-gnu serial usb libudev usbdropdir=/usr/lib/pcsc/drivers ipcdir=/run/pcscd configdir=/etc/reader.conf.d one reader: 689 0 0 1043 0 255 1167 0 510 1291 0 765 1414 0 1020 1538 0 1275 1662 0 1530 1786 0 1785 2160 0 2040 2284 0 2295 2407 0 2550 2529 0 2629 Total for 0=2786ms two readers: 540 0 0 984 1 0 1088 0 255 1213 1 255 1338 1 510 1462 0 510 1586 0 765 1710 1 765 1835 1 1020 1959 0 1020 2334 1 1275 2458 0 1275 2582 0 1530 2707 1 1530 2832 1 1785 2956 0 1785 3079 0 2040 3204 1 2040 3578 0 2295 3703 1 2295 3828 1 2550 3952 0 2550 4131 1 2629 4200 0 2629 Total for 0=4208ms Total for 1=3676ms three readers: 564 0 0 651 2 0 753 1 0 857 2 255 982 0 255 1097 1 255 1221 2 510 1346 0 510 1461 1 510 1585 2 765 1710 0 765 1825 1 765 1949 2 1020 2074 0 1020 2189 1 1020 2313 2 1275 2437 0 1275 2561 2 1530 2686 0 1530 2802 1 1275 3176 2 1785 3301 0 1785 3416 1 1530 3541 0 2040 3664 2 2040 3780 1 1785 3904 2 2295 4019 1 2040 4144 0 2295 4267 2 2550 4383 1 2295 4508 0 2550 4630 2 2629 4745 1 2550 4871 0 2629 Total for 0=4873ms 4984 1 2629 Total for 2=4792ms Total for 1=5047ms So, the time required to read that 2629-byte file from these cards does increase with the number of readers you're doing this on in parallel. Consistent: Java uses one context and pcsc-lite has a Mutex per context. On windows, this appears not to be the case, indeed. time to read that file is avg 2.8 seconds and stays 2.8 seconds with two or three readers. For my "pick a card" dialog, the slowdown is acceptable and I had never noticed it. (It still takes only 5 seconds to read 3 photos, not the 9 seconds it takes if I read them one after the other), so it's not really serial in practice: the cards aren't spending all their time sending data, in any case. It's not a full pipe, each block is an APDU and APDU Response cycle, and that may account for the mitigation of the fenomenon here. Still, Murilo, if you want to read all those cards at once efficiently, I'm afraid you won't be able to count on the JRE's default PCSC wrapper and javax.smartcardio.. So the next question is obvious: do you require the Provider features of javax.smartcardio, or do you just need to access smart cards and do private stuff with them directly?) (since the former would be much more work to implement). WKR, -f On 07/04/13 10:54, Frank Marien wrote: > Sure, Ludovic, > > I understand, the windows implementation may not have that mutex at that > same granularity, so the naive Java single-shared-context strategy may > have less > of an impact on that platform. > > What I'm curious about is why I'm *not* noticing any such difference, > this while > I'm developing on GNU/Linux (pcsc-lite), but we're routinely testing on > both OSX (fork of pcsc-lite) > *and* Windows (closed-source proprietary implementation), and Murilo > *does* notice such an impact. > > We're both testing on both Linux and Windows.. > I'm looking for the cause of the difference between these experiences. > > But I suggest both Murilo and I do a timing diagram (see if there is > overlap in the timing of the transfers) of our experiments, and then get > back here with the results, because otherwise we're just discussing > perception and that may be deceiving, not to mention getting more > off-topic than strictly necessary. > > I think it's interesting because of my impression that I *am* getting > parallellism with pcsc-lite, from java, > while, after reading the previous explanations, that shouldn't really be > possible. > > -f > > On 07/04/13 09:33, Ludovic Rousseau wrote: >> 2013/7/4 Frank Marien <fr...@apsu.be>: >>> Still.. I think we're missing something, here. If it's inherent in >>> libj2pcsc (java wrapper) or javax.smartcardio (and it looks like it from >>> the sources above), then why I can I read 5 photos from 5 eID's in the >>> same required to read one, and also, why would Murilo *not* have the >>> issue on Windows? Different implementation there? >> The Microsoft WinSCard API implementation is different from pcsc-lite >> and so has different "limitations". >> So yes, the Windows and Unix implementations are different. >> >> Bye >> >> -- >> Dr. Ludovic Rousseau >> >> _______________________________________________ >> Muscle mailing list >> Muscle@lists.musclecard.com >> http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com >> > > _______________________________________________ > Muscle mailing list > Muscle@lists.musclecard.com > http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com > _______________________________________________ Muscle mailing list Muscle@lists.musclecard.com http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com _______________________________________________ Muscle mailing list Muscle@lists.musclecard.com http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
