jgraham@CRC.SKL.DND.CA (Jay Graham) (08/24/90)
To any XtAddTimeOut()/Unix experts:
We are developing an application on 386/ix and will need time
interrupts in the 10s of milleseconds range, however when using
XtAddTimeOut() with a 10ms interval we seem to be actually getting
around a 20ms interval. We assume that maybe there are communication
delays that cause the discrepancy. Obviously since the resolution
is better than one second, XtAddTimeOut does not use the Unix alarm
system call. We would like to know how XtAddTimeOut (or the X server)
is implemented so that it can get millsecond resolution so that we
can develop something similar ourselves.
Our H/W S/W platform is:
ATT 6386/25
ISC 386/ix Version 2.0.2 (System V)
ISC X Window System, Version 1.1 (X11R3)
If anyone can help please email or post.
Thanks in advance
Jay Graham (jgraham@crc.skl.dnd.ca)
Software Kinetics, Ltd,
Ottawa, Ontario, Canadaargv@turnpike.Eng.Sun.COM (Dan Heller) (08/24/90)
In article <9008231943.AA01202@crc.skl.dnd.ca> jgraham@CRC.SKL.DND.CA (Jay Graham) writes: > We are developing an application on 386/ix and will need time > interrupts in the 10s of milleseconds range, however when using > XtAddTimeOut() with a 10ms interval we seem to be actually getting > around a 20ms interval. We assume that maybe there are communication > delays that cause the discrepancy. Obviously since the resolution > is better than one second, XtAddTimeOut does not use the Unix alarm > system call. We would like to know how XtAddTimeOut (or the X server) > is implemented so that it can get millsecond resolution so that we > can develop something similar ourselves. Don't try to develop something similar -- this is the best resolution you're going to get, all things considered. XtAddTimeOut() is closely tied to the select() system call. this is the ultimate system call that returns when either 1) there is data on the X connection to read 2) select() times out first. The timeout for select() is based on the interval value in XtAddTimeOut(). Please refer to select() for more details on how this works. The possible reason for it taking longer than expected is that it takes some time for the state of the machine to go from the place where you _set_ XtAddTimeOut() and the place where the select() call actually gets called. You aren't going to get any better resolution than this -- you don't want to use unix signals because they are going likely going to interrupt a system call (e.g., the read() call that is reading the next data packet from the X connection) and you are going to end up with corrupted data. -- dan ---------------------------------------------------- O'Reilly && Associates argv@sun.com / argv@ora.com Opinions expressed reflect those of the author only.
rick@pcrat.uucp (Rick Richardson) (08/26/90)
In article <141292@sun.Eng.Sun.COM> argv@turnpike.Eng.Sun.COM (Dan Heller) writes: >In article <9008231943.AA01202@crc.skl.dnd.ca> jgraham@CRC.SKL.DND.CA (Jay Graham) writes: >> We are developing an application on 386/ix and will need time >> interrupts in the 10s of milleseconds range, however when using >> XtAddTimeOut() with a 10ms interval we seem to be actually getting >> around a 20ms interval. We assume that maybe there are communication >Don't try to develop something similar -- this is the best resolution >you're going to get, all things considered. XtAddTimeOut() is closely >tied to the select() system call. On 386/ix, the STREAMS function poll() takes an argument in milliseconds, but the actual resolution is 10 msecs. I don't know what the select() function uses, since I can't find any documentation for it. I haven't any knowledge of which one 386/ix uses for X, but my guess is that it isn't poll, since you should be able to get down to 10 msecs. Here is a little test program you can use to check the resolution of poll(). Usage: polltest msecs. The test should take 10 seconds unless you specify an msecs value smaller than the resolution allowed. -Rick #include <sys/types.h> #include <sys/times.h> #include <sys/param.h> #include <stropts.h> #include <poll.h> #define SECS 10 /* * Test program to verify timeout resolution of poll(2) * Usage: polltest [ timeout_in_msecs ] */ main(argc, argv) char *argv[]; { struct tms tms_dummy; struct pollfd poll_dummy; int i, msecs, ticks; long start, end; msecs = (argc > 1) ? atoi(argv[1]) : 10; ticks = (SECS*1000)/msecs; start = times(&tms_dummy); for (i = 0; i < ticks; ++i) poll(&poll_dummy, 0, msecs); end = times(&tms_dummy); printf("%d sec. test took %f secs.\n", SECS, ((float) end-start)/HZ); } -- Rick Richardson | Looking for FAX software for UNIX/386 ??? Ask About: |Mention PC Research,Inc.| FaxiX - UNIX Facsimile System (tm) |FAX# for uunet!pcrat!rick| FaxJet - HP LJ PCL to FAX (Send WP,Word,Pagemaker...)|Sample (201) 389-8963 | JetRoff - troff postprocessor for HP LaserJet and FAX|Output
mouse@SHAMASH.MCRCIM.MCGILL.EDU (der Mouse) (08/27/90)
> On 386/ix, the STREAMS function poll() takes an argument in > milliseconds, but the actual resolution is 10 msecs. I don't know > what the select() function uses, since I can't find any documentation > for it. For those without BSD documentation who are nonetheless curious: select()'s timeout argument is given as seconds-plus-microseconds (a structure with two long ints). Of course, very few if any machines/systems actually give microsecond resolution; typical actual resolution might be 1/100 or 1/60 second. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu