On 22/02/2011, at 2:54, Jerome Flesch wrote: > While investigating a timing issue with one of our program, we found out > something weird: We've written a small test program that just calls > clock_gettime() a lot of times and checks that the time difference between > calls makes sense. In the end, it seems it doesn't always do. > > Calling twice in a row clock_gettime() takes usually less than 1ms. But with > an average load, about 1 time in 200000, more than 10ms are spent between > both calls for no apparent reason. According to our tests, when it happens, > the time between both calls can go from few milliseconds to many seconds (our > best score so far is 10 seconds :). Same goes for gettimeofday(). > > To reproduce this issue, we use the small test program joined to this mail > and openssl speed test commands (usually 'openssl speed -elapsed dsa2048'). > It only appears if one of these openssl speed test run on the same core than > our test progam, so we have to start as many openssl instances as there are > cores on the test computer.
This sounds like a problem I have trying to read from a FIFO in hardware over USB. Most of the time the libusb poll thread doesn't take very long, but every now and then it takes too long and my FIFO fills up (~75msec). If you do find a solution I would be very interested :) In the end I wrote a kernel driver which read & buffered the data, but I suppose that is not possible for you. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
