Nicolas, if you ever visit Göttingen in Germany, I owe you a drink of your choice.
* Nicolas George <[email protected]> | Ralf Fassel (HE12026-07-03): | > an IPC (fanless Industrial PC > | Stop right there. Nobody cares that your PC is industrial or fanless. > | On the other hand, we care that IPC means “interprocess communication”. | Especially in the context of performance issue with concurrent | processes. > | Using IPC all over the place will only confuses the people who have the | knowledge to help you. Point taken. | > local_time[ms] what | > 17817764 68904 MAIN "START" sub-1 started > | The number of digits in your milliseconds is quite strange. For better readability I separated the non-changing part of the timestamps (milliseconds from epoch) with a space from the changing part. | Run your whole system under strace -tttT and see exactly what system | call is taking time in the process that arrives late. Spot on, thanks for suggesting this. I would not have dared to run strace on the subprocess due to the huge amount of output. But the -T actually helps to see where the process stops and wastes its time. In my case it is a hardware license dongle which obviously has problems when many processes simultaneously try to obtain a license from it (needless to say: same dongle no problem on Windows). It guess this also explains the 1sec-clustering which I see in the timings: seems like there is some internal 1-sec timeout in the library code for the dongle. If it was due to the PC-Hardware, I would have expected to see even distribution of answering times, but not that clustering. If I change to a file-based license, I get stable answer times of 0.3secs (yes, it's that fast, and I would have expected exactly this from this CPU). Thanks to all who took their time to look into this and their suggestions. R'
