Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!helios.ee.lbl.gov!beva.bev.lbl.gov!wbrown From: wbrown@beva.bev.lbl.gov (Bill Brown) Newsgroups: comp.realtime Subject: Re: VxWorks Performance Data Message-ID: <4295@helios.ee.lbl.gov> Date: 27 Nov 89 15:23:07 GMT References: <1081@savax.UUCP> Sender: usenet@helios.ee.lbl.gov Reply-To: wbrown@beva.bev.lbl.gov (Bill Brown) Organization: Lawrence Berkeley Laboratory, Berkeley Lines: 66 In article <1081@savax.UUCP> cioli@savax.UUCP (Jeff J. Cioli) writes: >Does anyone have any performance data (e.g. benchmarks results, papers) con- >cerning context switch, interrupt latency, message delivery latency, etc for >VxWorks and the various underlying kernels ? > >Thanks ____ | |____| | | | | Time Between Writes Square wave Frequency MVME-147 Square-wave Direct write* 2 uS. 250 KHz. Function Call* 5 uS 100 KHz MVME-133 {CMC E-net, MVME-025 VME Controller} Square-wave Direct Write* 3 uS. 167 KHz. Function Call* 8.5 uS. 118 Khz. RPC xx Ms. xx Hz. * Output device is ACROMAG 9210 D.A.C. board I also made a couple of interrupt-latency checks - as best I can recall it's about 15 microseconds between the interrupt on the VME bus and the first instruction in the interrupt function. This was probably using a '147 board (naw - I don't gotta write it down - I can remember it when I need it). We are using the Wind kernel. I believe that a task switch takes on the order of couple of hundred microseconds but don't have any hard figures. It would be possible to cut down the interrupt latency a little bit by doing some assembly language stuff, rather than using vxWorks' intConnect() but the gain is not much, a say less than a factor of 2. I hope this helps - it's not everything you asked for, but at least it's something. -bill wlbrown@lbl.gov Disclaimer: These opinions are my own and have nothing to do with the official policy or management of L.B.L, who probably couldn't care less about employees who play with trains. Brought to you by Super Global Mega Corp .com