From thor@thor.atd.ucar.edu Fri Nov 1 11:15:30 1991 From: thor@thor.atd.ucar.edu (Richard Neitzel) Date: Fri Nov 1 11:15:40 PST 1991 Subject: New Archive items. Recent changes to the Archive: Ntp for VxWorks is now correctly repackaged into ntpvx01 - ntpvx08 & is suitable for email retrieval. The old version of pipe_class.shar & ring_class.shar have been replaced by newer versions called pipe.shar & ring.shar. The old version of flags_class has been replaced by a newer version. A C++ class for task control has been added as task_class.shar. Richard Neitzel thor@thor.atd.ucar.edu Torren med sitt skjegg National Center For Atmospheric Research lokkar borni under sole-vegg Box 3000 Boulder, CO 80307-3000 Gjo'i med sitt shinn 303-497-2057 jagar borni inn. From smb@afterlife.ncsc.mil Sun Nov 3 22:26:37 1991 From: smb@afterlife.ncsc.mil (Steve M. Burinsky) Date: Sun Nov 3 22:26:47 PST 1991 Subject: vwman > Submitted-by bclark@vlbacc.aoc.nrao.edu Thu Oct 31 07:19:11 1991 > Submitted-by: bclark@vlbacc.aoc.nrao.edu (Barry Clark) > > Another minor matter. Why does Wind River ship vwman? I find it much more > satisfactory to rearrange the directory names (souces in .../man/man?, > troffed stuff in .../man/cat?) and use > alias vwman man -M .../man > I am fond of whatis, and Wind River's vwman -l just doesn't hack it. I agree. Also, vwman doesn't pay attention to the PAGER environment variable as man does. I've asked WRS to make this simple fix, but to no avail. Could it be that the target specific man pages wouldn't work well with man, as in "vwman mv147/sysClkEnable"? From ojr%itk.unit.no@Csa2.LBL.Gov Sun Nov 3 23:55:55 1991 From: ojr%itk.unit.no@Csa2.LBL.Gov Date: Sun Nov 3 23:56:04 PST 1991 Subject: RE: yacc and lex GNU has a version of both lex (flex) and yacc (bison). I would believe that a reverse engineering of the libraries would infringe on SUN (or whoevers) copyright. The GNU utilities may be more suitable since source is distributed. Regards, Ornulf Jan Rodseth M.Sc. ojr@itk.unit.no SINTEF Automatic Control +(47 7) 594351 (direct) / 594375 (switchboard) N-7034 TRONDHEIM, NORWAY +(47 7) 594399 (fax) From crispen%foxy.boeing.com@ada3.ca.boeing.com Mon Nov 4 05:36:24 1991 From: crispen%foxy.boeing.com%ada3.ca.boeing.com@Csa2.LBL.Gov (crispen) Date: Mon Nov 4 05:36:36 PST 1991 Subject: Re: The silence is deafening... Dear Exploder: please don't flood the net with this, unless you think it's necessary. The reason I didn't respond is that I thought everyone else would -- so now everyone else....... You can't win. Henning, I think it's a great idea; I didn't know about this exploder group until a couple of weeks ago, and I've been using VxWorks since 198(7?). If nothing else, it will draw people into the mailing list, let us put up some FAQ for new kids, etc. Since I have read-only access to Usenet, this will be the only way you'll find out about my "yes" vote. Bob Crispen Boeing Huntsville From bgeer@beorn.sim.es.com Mon Nov 4 06:15:33 1991 From: bgeer@beorn.sim.es.com (bob geer) Date: Mon Nov 4 06:15:50 PST 1991 Subject: select(), & RE: vwman select(): vwman's info on select() & man's info on Unix select() (on a Sun Sparc) both say the select() call should return zero on timeout. However, vw5.0.1 select() returns a "1" on timeout (I am checking for activity on only 1 fd). Is this a known problem? vwman: I have noticed some directory entries into /man/man2 showing up with zero length. When an entry with zero length is in this directory, vwman will not print any info on that particular subject. I haven't figured out yet what mechanism allows zero length entries to happen (I'm running under SunOS 4.1.1 on an IPC Sparcstation). Is this a known problem? Thanks in advance. <> Bob `Bear' Geer <> bgeer@beorn.sim.es.com (this *should* work) <> <> cola-zombie <> speaking only for myself, one of my many tricks <> <> Salt Lake City, <> "We must strive to be more than we are, Lal." <> <> Ootah <> -- Cmdr. Data, learning schmaltz <> From rayssd!swlrao.msd.ray.com!rfs@uunet.uu.net Mon Nov 4 07:24:31 1991 From: rfs@swlrao.msd.ray.com (RICHARD SNASHALL) Date: Mon Nov 4 07:24:47 PST 1991 Subject: RE: yacc and lex I could suggest that you might consider FLEX from the University of California for the scanner portion. Historically, it has generated smaller and faster code than lex. In addition, the skeleton file may be overridden with a command line option. This allows the distributed software to be utilized as is, but allows the user to implement another skeleton for VxWorks without disturbing system configuration. The address I have(several years old) is: vern@lbl-{csam,rtsg}.arpa or ucbvax!lbl-csam.arpa!vern Vern Paxson Real Time Systems Group Bldg. 46A Lawrence Berkeley Laboratory 1 Cyclotron Rd. Berkeley, CA 94720 (415) 486-6411 -------------------------------------------------------- | The opinions expressed here do not necessarily | | reflect those of Raytheon company. | | | | Richard Snashall, Raytheon Missile Systems Division | | 50 Apple Hill Road, Mail Stop T3ML19 | | Tewksbury, MA 01876-0901 (508) 858-9207 | | | | {uiucdcs,uunet}!rayssd!swlra1.msd.ray.com!rfs | | rfs@swlra1.msd.ray.com | |--------------------------------------------------------| From owen@cod.nosc.mil Mon Nov 4 09:39:57 1991 From: owen@cod.nosc.mil (Wallace E. Owen) Date: Mon Nov 4 09:40:06 PST 1991 Subject: Re: lex & yacc ------- > I think I heard somewhere that yacc was not reentrant, and was thus a problem > for VxWorks. The same person also told me that Bison was reentrant. bison++ allows the creation of multiple simultaneous parsers in one program by turning the parser and it's tables into a class definition. Multiple objects of this class may be instantiated, allowing recognition of multiple grammars. Of course, this means switching to C++. G++ is C++, gnu style. +-------------------------------------------------------+---------------------+ | I can see nothing, sire. | Wally Owen | | "I only wish I had such eyes," the king remarked in a | ETA Technologies | | fretful tone. "To be able to see nobody? And at that | (619) 546-7800 | | distance, too! Why, it's as much as I can do to see | 546-0971 Fax | | real people by this light!" -- Lewis Carrol | owen@nosc.mil | +-------------------------------------------------------+---------------------+ ------- From jones@cs.buffalo.edu Mon Nov 4 11:52:02 1991 From: jones@cs.buffalo.edu (Terry A. Jones) Date: Mon Nov 4 11:52:17 PST 1991 Subject: Problems with VxWorks for SPARC I have what I hope is a simple question for someone who has been through this before. We are running VxWorks on some Force SPARC CPU1-E cards. The version command under VxWorks reports the following: VxWorks (for Sun SPARCengine 1E) version 4.0.2 SPARC. Kernel: WIND SPARC version 1.0. Made on Tue Aug 13 12:08:33 EDT 1991. If we run the cards with the stock 4Meg of memory, we have no problems. Attempting to configure VxWorks to use 16Meg gives us ethernet initialization failures. The systems seem to run fine, but the ethernet is dead. I am trying to find out if this is a know problem, or if there is something that I am missing in the configuration process? Here is what I have seen... a) In module ...sun1e/config.h: Increasing the value of this #define , #define LOCAL_MEM_SIZE 0x00400000 /* 4 megabytes */ results in ethernet failures when the boot ROM executes the newly loaded system. The errors that are reported are: Attaching network interface ln0...done 0xbffeb4 (rootTask):ln0:ERROR:Lance chip initialization failure, CSR0=0x8881 0xbe8c20 (netTask):ln0:ERROR:Lance chip initialization failure, CSR0=0x8881 0xbe8c20 (netTask):ln0:ERROR:Lance chip initialization failure, CSR0=0x8881 0xbe8c20 (netTask):ln0:ERROR:Lance chip initialization failure, CSR0=0x8881 0xbe8c20 (netTask):ln0:ERROR:Lance chip initialization failure, CSR0=0x8881 0xbe8c20 (netTask):ln0:ERROR:Lance chip initialization failure, CSR0=0x8881 0xbe8c20 (netTask):ln0:ERROR:Lance chip initialization failure, CSR0=0x8881 0xbe8c20 (netTask):ln0:ERROR:Lance chip initialization failure, CSR0=0x8881 At this point the ethernet interface is unusable. The following #defines (also in sun1e/config.h) concern me: #define LN_POOL_ADRS NONE /*0x00200000*/ /* hard-coded, not malloc-ed */ #define LN_POOL_SIZE NONE /*0x00020000*/ /* hard-coded buffer size */ If these are left as shown, defined as NONE, does the network startup allocate this region? If they are defined with the given values, 0x00200000 for the address, and 0x00020000 as the length, is the region statically referenced? And if so, does the dynamic pool initialization know enough to allocate around this region? Is it possible that there are other values that need to be changed along with the memory size parameter? Another good question to ask would be how does the ethernet system depend on the configured memory size? I welcome any suggestions or comments, and thank you for listening. Terry Jones From rayssd!iss-ipc1.ssd.ray.com!fjr@uunet.uu.net Mon Nov 4 13:20:31 1991 From: fjr@iss-ipc1.ssd.ray.com Date: Mon Nov 4 13:20:41 PST 1991 Subject: Re: select(), & RE: vwman bob geer writes: vwman: I have noticed some directory entries into /man/man2 showing up with zero length. When an entry with zero length is in this directory, vwman will not print any info on that particular subject. I haven't figured out yet what mechanism allows zero length entries to happen (I'm running under SunOS 4.1.1 on an IPC Sparcstation). Is this a known problem? If you look at the script for vwman, you will see that it explicitely formats the VxWorks manual pages. The raw files are stored in the mansrc directory area while the formatted ones are stored in the man area. If someone aborts vwman in the middle of a run it can leave a zero length manual page in the formatted area. This will be used when vwman is invoked at a later time. The zero length files can be removed to fix the problem. We changed vwman to do this automatically. Maybe Wind River should too (or better yet trap errors to prevent writing partial files). Fred ______________________________________________________________ | Fred J Roeber, Raytheon Submarine Signal Division | | 1847 West Main Road, Mail Stop 188 | | Portsmouth, RI 02871-1087 (401) 847-8000 (X4205) | | | | {uiucdcs,uunet}!rayssd!sgfb.ssd.ray.com!fjr | |______________________________________________________________| From erik!dan@uunet.uu.net Mon Nov 4 14:31:34 1991 From: erik!dan@uunet.uu.net (Dan Downing) Date: Mon Nov 4 14:31:44 PST 1991 Subject: socket disconnect, inability to detect The following two socket errors have been discovered, reported to WRS and verified by them: I KEEP_ALIVE option does'nt work (usefull for detecting disconnect of other half of connection) II recv() returns 0 bytes received, and errno/SO_ERROR = 0 (i.e. no error) when the other half of connection disconnects. To demonstrate problem, write simple server/client (host/vxworks target) program using TCP socket, server: gets socket, binds, listens, then accepts client: gets socket, connects kill client process on host On server: check errno & bytes received they will be 0, also if you do a getsockopt for SO_ERROR it too will be 0 (note: SO_ERROR should just be a copy of errno). Error #II appears to be the only work around at the present for detecting disconnect of other half. This should work since I don't think you can normally do a recv() and get 0 bytes???? Seems rather strange that WRS has been peddling this product for many years and this hasn'nt shown up before. I can envision many applications where the server whould want to know if the client has disconnected! Any comments or suggestions??? Dan Downing | HELP, HELP, the company I slave for (work for) is moving to Valencia | @ddowning@kevex.com | California, I prefer to stay in the San Francisco region, any job | 415-591-3600 ext 442 | leads would be appreciated....thanks dan | From erik!dan@uunet.uu.net Mon Nov 4 14:47:38 1991 From: erik!dan@uunet.uu.net (Dan Downing) Date: Mon Nov 4 14:47:49 PST 1991 Subject: socket disconnect, inability to detect (correction) ORIGINAL Poster: To demonstrate problem, write simple server/client (host/vxworks target) program using TCP socket, server: gets socket, binds, listens, then accepts client: gets socket, connects kill client process on host CORRECTION: To demonstrate problem, write simple CLIENT/SERVER (host/vxworks target)...... The orginal way it was writtem may have implied that the problem was on the UNIX side, who knows maybe the UNIX side has a problem too!! Dan Downing | HELP, HELP, the company I slave for (work for) is moving to Valencia | @ddowning@kevex.com | California, I prefer to stay in the San Francisco region, any job | 415-591-3600 ext 442 | leads would be appreciated....thanks dan | From omni!hwajin@apple.com Mon Nov 4 15:26:14 1991 From: hwajin@omni.com (Hwa-Jin Bae) Date: Mon Nov 4 15:26:24 PST 1991 Subject: Re: Problems with VxWorks for SPARC >0xbe8c20 (netTask):ln0:ERROR:Lance chip initialization failure, CSR0=0x8881 looks like memory error. according to 7990 manual, memory error is set when the lance is the bus master and has not received \ready within 25.6 us after asserting the address on the dal lines. > The following #defines (also in sun1e/config.h) concern me: >#define LN_POOL_ADRS NONE /*0x00200000*/ /* hard-coded, not malloc-ed * >/ >#define LN_POOL_SIZE NONE /*0x00020000*/ /* hard-coded buffer size * >/ when LN_POOL_ADRS is -1 (NONE), lance driver calls malloc() to allocate space for rmd's, tmd's and ring buffer for rx and tx. this is done for most boards where lance and cpu have equal access to memory (both can be a master for local mem via onboard arbitration logic). some of the boards have separate piece of memory accessable by lance, which can be specified as LN_POOL_ADRS. lance is pretty demanding on memory access timing, and it may not be wise to use off-board memory for lance buffers. you may want to partition out some portion of onboard memory as a separate partition and give it to lance. From rjn@snowbird.labs.tek.com Mon Nov 4 15:47:45 1991 From: rjn@snowbird.labs.tek.com (Jim Nusbaum) Date: Mon Nov 4 15:47:55 PST 1991 Dan Downing writes: > II > recv() returns 0 bytes received, and errno/SO_ERROR = 0 (i.e. no error) when the other half > of connection disconnects. I don't think this is really an error in the socket code. I'm not sure about recv(), but read() returns 0 bytes on EOF. When using read() to read from a socket, if the other end disconnects a conceptual EOF occurrs and read() will return 0 bytes. This is how read from a socket is defined to work and is how I have always determined that the other end has disconnected. I assume that recv() works the same way. errno should not be set in this case as EOF is not an error. Did you really mean to say that this is an error in the socket code? Jim Nusbaum, Computer Research Lab, Tektronix, Inc. [ucbvax,decvax,allegra,uw-beaver,hplabs]!tektronix!crl!rjn rjn@crl.labs.tek.com (503) 627-4612 From hill@luke.atdiv.lanl.gov Mon Nov 4 15:52:54 1991 From: hill@luke.atdiv.lanl.gov (Jeff Hill) Date: Mon Nov 4 15:53:03 PST 1991 Subject: socket disconnect, inability to detect In case you needed confirmation of this problem ... I had to add a check for zero length message disconnect to my code also. This must have shown up in V4 since my stuff was working fine on prior releases. I also have the KEEP_ALIVE option set, but it doesnt seem to check very frequently if ever. However, SUNOS and MULTINET dont seem to work any differently. Jeff From jjohnson@hns.com Mon Nov 4 15:53:49 1991 From: jjohnson@hns.com (Jayne Johnson) Date: Mon Nov 4 15:54:05 PST 1991 IN reference to the recv() gets 0 length messages when a remote card issues a close() We have seen the same problem but in the Intel960 environment and were told by Intel that this is a normal situation when tcp gets into the close_wait state. In our configuration, we have our own TCP/IP network (not connected to Internet) and users are always connected unless a remote card fails due to a reset or software/hardware crash. So we were testing the error conditions of connections and noticed that we were receiving 0 length messages whenever a remote card issued a close(). I am trully interested in this and would like to know what WRS is planning to do. We have put some code to detect 0 len messages and issue indications to our socket interface application(s) so they can disconnect the connection . We have not tried KEEP_ALIVE since we have implemented our own monitor which does ICMP echoes more often then the KEEP_ALIVE poll feature. From mea@sparta.com Mon Nov 4 16:04:55 1991 From: mea@sparta.com (Mike Anderson) Date: Mon Nov 4 16:05:10 PST 1991 Subject: VME Crate reset circuit Greetings! I have had many requests from folks wanting to know how to build a black box that will reset a VME crate when an RS-232 signal changes state (such as the DCD (Data Carrier Detect) or Ring Indicate (RI) line on a modem or or the DTR (Data Terminal Ready) on a nearby workstation. Such a device would permit a remote VxWorks user in his/her office to reset a VME crate in a remote computer room provided there was a handy RS-232 port that could be toggled somewhere in the vicinity. Here is a description of one that I built for $15 worth of parts and an hour or so worth of time. This media (E-mail) is not very conducive to circuit schematics (and I'm not too good at drawing them either), so I hope that a description will be good enough to help you build one of these beasties if you need one. The circuit is actually quite simple. Essentially, you are using a reed relay to act as a reset button and an RS-232 signal level to trigger the relay. You will need to add a diode into the circuit in the line where the RS-232 voltage level comes in to pass the voltage when it goes high (such as DCD or RI on a modem) but not pass it when the signal is low. Just for yucks, I also wired in a 220 ohm resistor across an LED hanging on the signal line so the LED lights when the line is in the reset (high) state. RS-232 voltage levels are typically in the 3-12 volt range (nominally about 6-volts) with currents in the 10-20 mA range, so size your components accordingly. Now, the reset line on the VMEBus can typically be found on the back of the motherboard with a mask on the board that indicates "RESET" or "RST". The requirement is to put +5 Volts (I'm pretty sure, but somebody should check the spec to be certain) on that pin and that will cause the box to reset. Alternatively, if you can easily find the wires from the reset button on your VME card cage (this is what I do), you can simply tap into them with those "vampire" type wire connectors from your local Radio Shack (BTW, all of the parts mentioned above are available from your local "Shack") that are typically used to tap into the power leads for car radio installations. Put it all together, and toggle your selected RS-232 signal (you typically want to hold the line in the reset state for 3-5 seconds) and voila your crate will reset! Alternatively, I have just finished the design and construction of a RS-232 controlled power distribution system (I built 4 of them for one of my customers, in fact) that allows a PC or Sun to write bytes out an RS-232 port and selectively turn-on, turn-off or reset devices in a rack. We're using it to set up a notebook PC-based watchdog circuit that receives a heartbeat from my VxWorks boxes and my embedded SPARCStation clone (the PC/AT form factor Opus PM-500) via the Ethernet and allows the PC to either reset or cycle power on any device in the equipment rack. The Opus card also monitors the PC and can cycle power on it if necessary. I built it so equipment in remote locations can be relatively self monitoring and can reinitialize themselves if necessary without the requirement for human intervention. This device handles both 110V and 220V circuits and is considerably more complex and more expensive (about $700 in parts and 4 hours in assembly/checkout time). If you need to control lots of devices from a single RS-232 port (independent control of up to 14 devices plus two independent reset lines is the default configuration for this box but I can expand to controlling or resetting up to 128 devices from a single port) then I can build more of these and sell them to you ;-). I use HVAC control relays for these circuits so they'll handle up to 270V, 2 phase @ 10 Amps per device. I can handle greater currents with different relays as well. I hope that this will be of some help to those of you who hate to have the noise of a VME crate in your office, but (like most of us) have to reset your VxWorks boards with relative frequency and (like me) are too lazy to get up and stroll the halls just to press a reset button. Drop me an E-mail or call if you have any questions. ============================================================================== AAAA D D D D EEEEE M M TM // AAAA RRRR TTTTTT SSSSS EEEEE TM A A D D D D E M M M M // A A R R TT S E AAAAAA D D D D EEEEE M M M // AAAAAA RRRR TT SSS EEEEE A A D D D D E M M // A A R R TT S E A A D D D D EEEEE M M // A A R R TT SSSSS EEEEE Process Distribution/Control and Communications for Distributed Systems Mike Anderson Voice: (703) 448-0210 ext. 235 Director, ADDEM(TM) Project Office FAX: (703) 734-3323 SPARTA, Inc. EMAIL: mea@sparta.com Suite 900 7926 Jones Branch Drive "The optimist proclaims that we live in the McLean, VA 22102 best of all possible worlds, and the pessimist fears that this is true." J.B. Cabell ============================================================================== ----- End Included Message ----- From hill@luke.atdiv.lanl.gov Mon Nov 4 16:05:36 1991 From: hill@luke.atdiv.lanl.gov (Jeff Hill) Date: Mon Nov 4 16:05:47 PST 1991 Subject: crash after telnet disconnect We have been experiencing a stone dead crash shortly after we disconnect with telnet. Our setup is the hkv2f, cmc ethernet, and V4.0.2 vxWorks. At times we make heavy and continuous use of the cmc ethernet. We have also seen the shell not connect to the serial port after disconnecting with telnet even though logMsg() output still shows up there. We would greatly appreciate any input from persons experiencing similar problems. Jeff From jones@cs.buffalo.edu Mon Nov 4 17:40:49 1991 From: jones@cs.buffalo.edu (Terry A. Jones) Date: Mon Nov 4 17:40:59 PST 1991 Subject: Problems with VxWorks for SPARC >>0xbe8c20 (netTask):ln0:ERROR:Lance chip initialization failure, CSR0=0x8881 > >looks like memory error. according to 7990 manual, memory error is set >when the lance is the bus master and has not received \ready within >25.6 us after asserting the address on the dal lines. > This is what I had suspected, I do not have docs on the LANCE chip as yet. >> The following #defines (also in sun1e/config.h) concern me: > >>#define LN_POOL_ADRS NONE /*0x00200000*/ /* hard-coded, not malloc-ed * >>/ >>#define LN_POOL_SIZE NONE /*0x00020000*/ /* hard-coded buffer size * >>/ > >when LN_POOL_ADRS is -1 (NONE), lance driver calls malloc() to allocate >space for rmd's, tmd's and ring buffer for rx and tx. this is done for >most boards where lance and cpu have equal access to memory (both can >be a master for local mem via onboard arbitration logic). some of the boards >have separate piece of memory accessable by lance, which can be specified >as LN_POOL_ADRS. > In both cases, LANCE should be using the on board memory. The only difference between the two configurations is the value of the memory size parameter. If I use a CPU-1E card with 16Meg of RAM, and tell VxWorks that I only have 4 Meg, everything is fine. As soon as I configure above 4Meg, LANCE dies as mentioned above. terry From ehipp@wrs.com Mon Nov 4 19:38:58 1991 From: ehipp@wrs.com (Emily Hipp) Date: Mon Nov 4 19:39:08 PST 1991 Subject: sockets > The following two socket errors have been discovered, reported to WRS and verified by them: > I'm sorry but it seems you have been mis-informed by someone here. Neither of the two "socket errors" you descibed below are errors. > I > KEEP_ALIVE option does'nt work (usefull for detecting disconnect of other half of connection) > The keep alive option works. It just has a rather long timeout (the bsd default timeout). > II > recv() returns 0 bytes received, and errno/SO_ERROR = 0 (i.e. no error) when the other half > of connection disconnects. > By "disconnect" I assume you mean the peer closed the TCP socket. This is not an error, it is normal socket semantics or even normal read semantics. Receiving 0 bytes means EOF (in TCP sockets it means the peer isn't going to send any more on the socket). Try this on any other OS and you'll get the same results. > Error #II appears to be the only work around at the present for detecting disconnect of other Its not a work around, that's what its for. I hope this clears things up. Emily Hipp ehipp@wrs.com From matthieu@vega.laas.fr Tue Nov 5 01:47:47 1991 From: matthieu@vega.laas.fr (Matthieu Herrb) Date: Tue Nov 5 01:48:20 PST 1991 Subject: problems booting a Motorola mv135A Hello, I have a problem with a motorola mv135A (with 4 Megabytes of memory) that cannot boot. All our mv135 (1M) boot perfectly, but I cannot make a bootable PROM for the 4M version. Normaly, the only change to do is to modify LOCAL_MEM_SIZE in config.h. I have done that but the rom won't boot. (the prom are OK, the card seems to be OK also - it boot with the standard prom delivered by wrs (version 5.0)). We have VxWorks release 5.0.1. We tried compiling the bootrom with both cc68k (gcc) and sun cc on a sun3 without sucess. Has anybody experienced this kind of problems with the 135A, or do I have a local problem ? Thank you in advance. Matthieu Herrb From erik!dan@uunet.uu.net Tue Nov 5 09:32:49 1991 From: erik!dan@uunet.uu.net (Dan Downing) Date: Tue Nov 5 09:32:57 PST 1991 Subject: socket disconnect, possible errors , KEEP_ALIVE option still does'nt seem to function, code is: int optVal = 1 ; if ( setsockopt(snew,SOL_SOCKET,SO_KEEPALIVE, &optVal, sizeof(optVal) ) < 0 ) {printError("unable to set socket option SO_KEEPALIVE\n"); } else {printInfo("socket option SO_KEEPALIVE set ok\n"); } setsockopt() does'nt return an error. I set up my lan anaylzer to monitor for all IP traffic to and from target system, and still did'nt see any transmissions(waited 5 minutes too): therefore, either A-> KEEP_ALIVE don't work B-> I coded it wrong C-> lan anayzer is set up wrong AND I don't thing C is likely since the lan analyzer seems to capture traffic ok when commands/data are sent via sockets. Any suggestions?? ALSO, the only reference of any help with sockets (that I have encountered ) is UNIX NETWORK PROGRAMMING by W. Richard Stevens, the SUN manuals are gobbly gook, and of marginal use to us 'new to UNIX' people, any suggestions for a good/through reference? Dan Downing | HELP, HELP, the company I slave for (work for) is moving to Valencia | ddowning@kevex.com | California, I prefer to stay in the San Francisco region, any job | 415-591-3600 ext 442 | leads would be appreciated....thanks dan | From palumbo@cs.buffalo.edu Tue Nov 5 11:04:05 1991 From: palumbo@cs.buffalo.edu (Paul Palumbo) Date: Tue Nov 5 11:04:14 PST 1991 Subject: Memory pool I have a SPARCengine 1e and I want to have some custom hardware place some data into the SPARCengine memory starting at a specific address under DMA control. The simple question is, how do I tell VxWorks that I don't want it to use a chunk of memory starting at a particular address. I currently select a memory location starting at 0x80000 and assume that it wouldn't get used by the OS but this could be dangerous. Paul Palumbo internet:palumbo@cs.buffalo.edu Research Associate bitnet: palumbo@sunybcs.BITNET 226 Bell Hall csnet: palumbo@buffalo.csnet SUNY at Buffalo CS Dept. Buffalo, New York 14260 (716) 636-3407 uucp: ..!{boulder,decvax,rutgers}!sunybcs!palumbo From rjn@snowbird.labs.tek.com Tue Nov 5 12:01:59 1991 From: rjn@snowbird.labs.tek.com (Jim Nusbaum) Date: Tue Nov 5 12:02:06 PST 1991 Subject: socket disconnect, possible errors , Dan Downing writes: >I set up my lan anaylzer to monitor for all IP traffic to and from target system, and >still did'nt see any transmissions(waited 5 minutes too): The keep alive interval is 2 hours. A keep alive message will not be sent until the connection has been idle for 2 hours. Keep alives will then be sent every 75 seconds. After 8 probes the connection will be dropped. So you are going to need to monitor for at least 2 hours to see anything. Look at net/tcp_timer.h in the VxWorks header file directory for these values. Jim Nusbaum, Computer Research Lab, Tektronix, Inc. [ucbvax,decvax,allegra,uw-beaver,hplabs]!tektronix!crl!rjn rjn@crl.labs.tek.com (503) 627-4612 From omni!hwajin@apple.com Tue Nov 5 12:28:40 1991 From: hwajin@omni.com (Hwa-Jin Bae) Date: Tue Nov 5 12:28:46 PST 1991 Subject: Re: sockets >> I >> KEEP_ALIVE option does'nt work (usefull for detecting disconnect of other h >alf of connection) >> >The keep alive option works. It just has a rather long timeout (the bsd defau >lt >timeout). in vxworks 5.0 or later this code is based on bsd 4.3 tahoe tcp. 4.3 fixes the semantics of keep-alive that had been broken in 4.2. in 4.2 bsd tcp used to send out keep-alives with ack == rcv_nxt - 1 to force the other side to send a segment back (4.2 systems had to have non zero length keep-alive probes to respond). this was wrong. in 4.3 keep-alives are send with ack == rcv_next. if your peer implementation of tcp is 4.2 based or have special hacks for this feature (e.g. sunos has a special global called tcp_keeplen which should be set to either 1 or 0. keep-alive ack is set to rcv_next - tcp_keeplen, making it compatible with 4.2 systems if tcp_keeplen is set to 1. use adb to examine /vmunix for this value), you'll need to make sure that the two systems are compatible. earlier versions of vxworks used 4.2 style keep-alives. 5.0 or later uses 4.3 style. From omni!hwajin@apple.com Tue Nov 5 12:54:54 1991 From: hwajin@omni.com (Hwa-Jin Bae) Date: Tue Nov 5 12:54:59 PST 1991 Subject: Re: Problems with VxWorks for SPARC > In both cases, LANCE should be using the on board memory. The only >difference between the two configurations is the value of the memory size >parameter. If I use a CPU-1E card with 16Meg of RAM, and tell VxWorks >that I only have 4 Meg, everything is fine. As soon as I configure above >4Meg, LANCE dies as mentioned above. i'm speculating here again, but since the lance has 24 address pins one would assume that it would have access to all 16 meg of address space. this may not be true if the designer decided to decode only subset of the address lines to select memory chips (quite common). i would look at the schematics or any pal equations you may have (and perhaps doc) and find out if lance has access to all 16 meg of space. if you add all 16 meg to system memory pool, malloc() will start allocating blocks from the high address, which lance doesn't know how to access apparently. one way to get around this problem may be to make a separate memory partition from memory under 4 meg and give it to lance and give the rest to the system -- this is easy to do in vxworks, see memLib doc. From erik!dan@uunet.uu.net Tue Nov 5 13:23:17 1991 From: erik!dan@uunet.uu.net (Dan Downing) Date: Tue Nov 5 13:23:25 PST 1991 Subject: GAG ME WITH A REAL-TIME SPOON WRS called me to talk about the KEEP_ALIVE problem with sockets, and was informed that there exists a SBR about the problem, the result of which is that the KEEP_ALIVE option works but it isn't SPONTANEOUS..... SO, HOW SPONTANEOUS IS IT, little ole me asks, "bout 3 HOURS" they say.........no further comment necessary cept, maybe "gag me with a real-time spoon" Dan Downing | HELP, HELP, the company I slave for (work for) is moving to Valencia | ddowning@kevex.com | California, I prefer to stay in the San Francisco region, any job | 415-591-3600 ext 442 | leads would be appreciated....thanks dan | From iapsd!hopi!glenn@uunet.uu.net Tue Nov 5 13:26:47 1991 From: iapsd!hopi!glenn@uunet.uu.net (Glenn Herteg) Date: Tue Nov 5 13:26:54 PST 1991 Subject: Re: Memory pool > I have a SPARCengine 1e and I want to have some custom hardware place some > data into the SPARCengine memory starting at a specific address under DMA > control. The simple question is, how do I tell VxWorks that I don't want it > to use a chunk of memory starting at a particular address. I currently select > a memory location starting at 0x80000 and assume that it wouldn't get used > by the OS but this could be dangerous. Build your hardware so the address at which it drops the data is software programmable. malloc() a buffer of the size and alignment you need at run time, then program the board to point to that buffer. Voila! This solves almost any software memory-contention problem you might worry about. Glenn Herteg glenn%iapsd@uunet.uu.net From omni!hwajin@apple.com Tue Nov 5 16:28:44 1991 From: hwajin@omni.com (Hwa-Jin Bae) Date: Tue Nov 5 16:28:50 PST 1991 Subject: Re: socket disconnect, possible errors , >The keep alive interval is 2 hours. A keep alive message will not be >sent until the connection has been idle for 2 hours. Keep alives will >then be sent every 75 seconds. After 8 probes the connection will be >dropped. So you are going to need to monitor for at least 2 hours to >see anything. >Look at net/tcp_timer.h in the VxWorks header file directory for these >values. Jim is quite correct. in addtion, the following global variables can be changed to alter this default behavior. tcp_keepidle: this is set to 120*60*slowhz (2 hours, slowhz == 2). if you change this to 40 and you'll start probing for idle connections after 20 seconds. tcp_keepintvl: this is set to 75*slowhz. change this to 40 and you'll send the keep-alive every 20 seconds tcp_maxidle: this is always recomputed by the slowhz timer to be TCPTV_KEEPCNT * tcp_keepintvl; (TCPTV_KEEPCNT == 8 as in tcp_timer.h) and thus varies according to tcp_keepintvl; note this only applies to vxworks 5.0 or later. be careful tuning these numbers because it's not really a good idea to alter the behavior of any protocol in a heavily networked environment. From omni!hwajin@apple.com Tue Nov 5 16:45:42 1991 From: hwajin@omni.com (Hwa-Jin Bae) Date: Tue Nov 5 16:45:49 PST 1991 Subject: Re: Memory pool >> I have a SPARCengine 1e and I want to have some custom hardware place some >> data into the SPARCengine memory starting at a specific address under DMA >> control. The simple question is, how do I tell VxWorks that I don't want it >> to use a chunk of memory starting at a particular address. I currently sele >ct >> a memory location starting at 0x80000 and assume that it wouldn't get used >> by the OS but this could be dangerous. >Build your hardware so the address at which it drops the data is >software programmable. malloc() a buffer of the size and alignment you >need at run time, then program the board to point to that buffer. >Voila! This solves almost any software memory-contention problem you >might worry about. hmmm... is this really necessary? why not just you memPart... routines in memLib? create a separate memory partition. don't give it to the system partition. keep it as a separate partition. you can malloc from this partion using memPartAlloc() or something like that. perhaps i'm missing something. From ehipp@wrs.com Tue Nov 5 18:08:23 1991 From: ehipp@wrs.com (Emily Hipp) Date: Tue Nov 5 18:08:28 PST 1991 Subject: Re: socket disconnect, possible errors , >be careful tuning these numbers because it's not really a good idea >to alter the behavior of any protocol in a heavily networked environment. No kidding. Especially since tcp_maxidle (tcp_keepintvl), is used for more than just the keep alive timer. Emily From hmp@frc2.frc.ri.cmu.edu Tue Nov 5 18:14:32 1991 From: hmp@frc2.frc.ri.cmu.edu (Henning M. Pangels) Date: Tue Nov 5 18:14:39 PST 1991 Subject: Re: Memory Pool Here is what I've done to deal with this issue: In usrConfig.c, change the kernel initialization code to #ifdef RESERVE_MEM kernelInit (usrRoot, ROOT_STACK_SIZE, FREE_RAM_ADRS, sysMemTop() - RESERVE_MEM, ISR_STACK_SIZE, INT_LOCK_LEVEL); } #else kernelInit (usrRoot, ROOT_STACK_SIZE, FREE_RAM_ADRS, sysMemTop (), ISR_STACK_SIZE, INT_LOCK_LEVEL); } #endif Now, I can define the macro RESERVE_MEM in the applicable Makefile to indicate how much memory the system should leave alone. In addition, I know the location of this chunk because it is at the top of physical available memory, relative to sysMemTop(). If you need to reserve a specific block that would normally fall in the middle of the system pool, I imagine you could initialize the system pool to include everything below your private block, and later add additional system memory above your block using memPartAddToPool. The system memory partition ID is accessible via sysMemPartId or some similar name. -Henning Henning Pangels |hmp@frc2.frc.ri.cmu.edu | Field Robotics Center Research Programmer|(412) 268-7088 |Carnegie-Mellon University ------------------------------------------------------------------------------ Just because I don't care doesn't mean I don't understand! -- Homer Simpson From crispen%foxy.boeing.com@ada3.ca.boeing.com Wed Nov 6 09:37:44 1991 From: crispen%foxy.boeing.com%ada3.ca.boeing.com@Csa2.LBL.Gov (crispen) Date: Wed Nov 6 09:37:51 PST 1991 Subject: Re: Memory pool There's always the good old sysMemTop mod. Coming to VxWorks from micros (always a bad sign) I routinely modify sysMemTop so that it leaves me 64K or so at the very top of memory. I have my various processes update counters and post statuses there so that I have a fighting chance to see what the thing was doing when it crashed (great for CPU 1 and above, not so great for CPU 0 unless I'm willing to get up off my posterior and hook up a terminal to the working CPU). This is also a natural area for inter-processor communications, particularly for older CPUs that don't have mailboxes (or that talk to the MVME133XT which only has a vector of 0xff). I started to post my mods to sysMemTop, but I didn't know what the etiquette(sp) is for that, since VxWorks is protected by copyright. Well, it doesn't take a rocket scientist to figure out what to do. Bob Crispen Boeing Huntsville (205)461-3296 From omni!hwajin@apple.com Wed Nov 6 12:45:46 1991 From: hwajin@omni.com (Hwa-Jin Bae) Date: Wed Nov 6 12:45:52 PST 1991 Subject: Re: socket disconnect, possible errors , >>be careful tuning these numbers because it's not really a good idea >>to alter the behavior of any protocol in a heavily networked environment. > >No kidding. Especially since tcp_maxidle (tcp_keepintvl), is used >for more than just the keep alive timer. emily is of course right about this. tcp_maxidle is also used as the timeout value in time-wait state. tcp waits 2 * MSL (maximum segment lifetime) in time-wait state before going to closed state for some good and bad reasons. MSL is a rather arbitrary value though (to be determined by experiment) and arbitrarily defined to be 2 minutes in the rfc, and need not be more than 4 hours 55 minutes. all this has to do with "quiet time" to avoid segment sequence number space collision. the default tcp_keepintvl is 75 seconds, which means that tcp_maxidle has the default value of 10 minutes, which means bsd uses a longer timer in time-wait state than rfc, which is probably good in a general internetwork, but perhaps too long for a closed realtime network when connections are known to exist between compatible hosts. keep-alive timer borrows tcp_keepintvl/tcp_maxidle since it's also another rather arbitrary timer (keep-alive is not even part of tcp, but a feature of this particular tcp). once it starts rolling, all it needs is a periodic timer for probe period and an upper limit, so it borrows a convenient arbitrary values. in any case, keep-alive timer is dominated by tcp_keepidle (2 hours). when i wrote my STREAMS tcp/ip for a UNIX vendor without using any bsd code, i experimented with these numbers and couldn't really tell what the big deal was. oh well... it's just a protocol... all this rather verbose discussion leads me to believe that it may be necessary to provide tcp level socket options to control these things from the applications. ack... i didn't say that. From omni!hwajin@apple.com Wed Nov 6 13:05:19 1991 From: hwajin@omni.com (Hwa-Jin Bae) Date: Wed Nov 6 13:05:27 PST 1991 Subject: Re: socket disconnect, possible errors , i said, >tcp_maxidle is also used as the timeout >value in time-wait state. blah blah... i went and looked at the code carefully (for a change!) and it's actually being used in fin-wait-1 state in bsd code! this violates the tcp statemachine so it's more arbitrary than i thought. in any case, look at the tahoe source if interested. i better shut up before i hear from vxwexplo bandwidth police. ;-) From sb%itk.unit.no@Csa2.LBL.Gov Thu Nov 7 06:51:43 1991 From: sb%itk.unit.no@Csa2.LBL.Gov Date: Thu Nov 7 06:51:50 PST 1991 Subject: HELP: Bootflags on MVME-147 We have just got VxWorks and are trying to set up a backplane network between a MVME-147 and a MVME-165. After booting VxWorks on the 147 (the bus master), the 165 disappears! The mv147/config.h says: /* This file contains the configuration parameters for the Motorola MVME-147. NOTE If the MVME-147 board uses an old PAL version, and another board on the VME bus will be accessing the MVME-147's memory, the SYSFLG_VENDOR_0 bit (0x1000) in the boot flags field must be set. Eg. in the default boot line change "f=0" to "f=0x1000". See sysLib.c for more information. */ The question is: How do we set the boot-flag? Do anyone know about other potential pitfalls in our configuration? I'm sorry if this is a FAQ, but we sure do not know the answer ... Best regards Stefano Bertelli, Lab engineer, Institute of Engineering Cybernetics, The Norwegian institute of Technology, Trondheim, Norway Phone: 477 594440; Fax: 477 594399 sb@itk.unit.no From kla!mruth@sun.com Thu Nov 7 09:40:26 1991 From: kla!mruth@sun.com (Michael Ruth) Date: Thu Nov 7 09:40:31 PST 1991 Please remove my name from the exploder mailing list. <=========================================================================> <== Mike Ruth <== KLA Instruments Corporation Voice: (408)434-6890 <== 160 Rio Robles Fax: (408)434-4284 <== P.O. Box 49055 Email: sun.com!kla!mruth <== San Jose, CA 95161 <=========================================================================> From hmp@frc2.frc.ri.cmu.edu Thu Nov 7 12:27:35 1991 From: hmp@frc2.frc.ri.cmu.edu (Henning M. Pangels) Date: Thu Nov 7 12:27:42 PST 1991 Subject: Exception at interrupt level Yesterday, on the afternoon before our annual demo to our project sponsors, I started getting "exceptions at interrupt level", which result in the target rebooting itself (i.e. a trap to the ROM monitor). Here's an example: Exception at interrupt level: Bus Error Program Counter: 0x003b9f9a Status Register: 0x2100 Access Address : 0xffffffff Instruction : 0x7fff Special Status : 0x0755 Regs at 0x59a2c Other times, the excpetion might be an unimplemented opcode or illegal instructions; the value of the PC is not always the same. However, it always happens when a CPU-intensive task is crunching some numbers for a few seconds. It is unpredictable, and happens maybe 5% of the time or less. Clearly, something is getting trashed somewhere, and the exception is probably a secondary effect. Does anyone have general suggestions on how to debug this? Would excHookAdd() work at this point? According to the man page on excLib, a trap to the ROM monitor only happens if exceptions or interrupts occur after excVecInit() but before excInit() has been called; both of these happen at boot time, and my problem usually doesn't show up until quite some period of normal operation. -Henning Henning Pangels |hmp@frc2.frc.ri.cmu.edu | Field Robotics Center Research Programmer|(412) 268-7088 |Carnegie-Mellon University ------------------------------------------------------------------------------ Fast, Cheap, Good: Choose Any Two From omni!hwajin@apple.com Thu Nov 7 13:06:32 1991 From: hwajin@omni.com (Hwa-Jin Bae) Date: Thu Nov 7 13:06:38 PST 1991 Subject: Re: HELP: Bootflags on MVME-147 >We have just got VxWorks and are trying to set up a backplane network >between a MVME-147 and a MVME-165. After booting VxWorks on the 147 >(the bus master), the 165 disappears! The mv147/config.h says: >The question is: How do we set the boot-flag? Do anyone know about >other potential pitfalls in our configuration? see the man page for bootParamsPrompt(). you probably know this already but... a couple of quick checks that can be done: 1. make sure there is only one bus master by checking the jumpers. if bus mastership is configurable from the software, check the sysLib routine that does it. 2. make sure that there is no collision in memory mapping. boards shouldn't try to map their memory to the same vme bus address space. From biocca@bevsun.bev.lbl.gov Thu Nov 7 14:00:52 1991 From: biocca@bevsun.bev.lbl.gov (Alan K Biocca) Date: Thu Nov 7 14:00:58 PST 1991 Subject: Re: Exception at interrupt level This sounds rather like the bug that occurs occasionally when you compile exception handlers using the Sun C Compiler without optimization, and it generates some floating point store instructions. The optimizer takes them out, but if they remain they are a time-bomb that waits to collide with some computation-intensive task. Alan K Biocca BEVALAC Controls Group From bernard@aar.alcatel-alsthom.fr Fri Nov 8 04:42:40 1991 From: bernard@aar.alcatel-alsthom.fr ( Olivier Bernard ) Date: Fri Nov 8 04:42:48 PST 1991 Subject: transmit error detecting This is my problem: we are using, in a mobile robot project, a radio modem to communicate beetween a MVME147 and our Unix network. SLIP is used as a communication layer. I want to detect communication loss (when the robot is far from the host). I thought I could do that by looking a the tcps_rexmttimeo field in tcpstat global variable but unfortunetly the modem is quite slow and sometimes SLIP has to retransmit packets which implies time-out if the buffer modem is full. So I can't know when communication is really lossed. 1- Has anybody got an idea ? 2- Does anybody use a better modem ? (ours: 4800 bds half-duplex with a protocol which is of no-use) Thanks -- Olivier ----------------------------------------------------------- ! ! ! Olivier BERNARD ! ! Alcatel Alsthom Recherche ! ! Route de Nozay ! ! 91460 Marcoussis ! ! France ! ! ! ! mail: bernard@aar.alcatel-alsthom.fr ! ! ! ! programmer's tragedy: ! ! "He's a really nowhere man, sitting in a nowhere land, ! ! making all his nowhere plans for nobody ..." ! ! - J. Lennon ! ! ! ----------------------------------------------------------- From prb@aplexus.jhuapl.edu Fri Nov 8 05:38:19 1991 From: prb@aplexus.jhuapl.edu (Paul R. Bade) Date: Fri Nov 8 05:38:26 PST 1991 Subject: MVME-167 backplane network I've been working with vxWorks 5.0.2beta for the MVME-167 boards for a couple of weeks now and have just try to configure two boards on a backplane network. A single MVME-167 boots just fine until I specify a backplane network address. Then the board does the following: 1) boots vxWorks across the network 2) initializes the backplane network and lo0 3) trys to load the symbols across the network Eventually (~10 min), it gives up and prints the vxWorks banner, but no symbols are present. Has anyone else experienced this?????? Thanks in advance, Paul Bade Johns Hopkins University Applied Physics Lab phone: (301)-953-5000 x8681 prb@aplexus.jhuapl.edu From hmp@frc2.frc.ri.cmu.edu Fri Nov 8 05:44:11 1991 From: hmp@frc2.frc.ri.cmu.edu (Henning M. Pangels) Date: Fri Nov 8 05:44:19 PST 1991 Subject: Re: transmit error detecting [...] >2- Does anybody use a better modem ? > (ours: 4800 bds half-duplex with a protocol which is of no-use) There certainly are higher-performance radio modems available in the U.S., but the situation in France might be different - I know that in in Germany where I grew up the regulations are quite restrictive. We have used a 9600 baud full-duplex (I believe) radio modem made by Vectran, but that was quite some time ago, and the setup was fairly bulky. More recently, others around here have been using a much smaller device, but its range might be limited to indoor operation. In a similar vein, does anyone know of a wireless ethernet package other than Motorolas Altair system? -Henning P.S. Re: comp.os.vxworks -- The responses so far have been 100% positive, but no real discussion has evolved. That's just fine; we just have to wait out the prescribed period before an official vote can be taken. Henning Pangels |hmp@frc2.frc.ri.cmu.edu | Field Robotics Center Research Programmer|(412) 268-7088 |Carnegie-Mellon University ------------------------------------------------------------------------------ If you aren't part of the solution, you're part of the precipitate. From omni!hwajin@apple.com Fri Nov 8 14:48:46 1991 From: hwajin@omni.com (Hwa-Jin Bae) Date: Fri Nov 8 14:48:53 PST 1991 Subject: Re: transmit error detecting >we are using, in a mobile robot project, a radio modem to communicate >beetween a MVME147 and our Unix network. SLIP is used as a communication >layer. I want to detect communication loss (when the robot is far from >the host). I thought I could do that by looking a the tcps_rexmttimeo field in > tcpstat >global variable but unfortunetly the modem is quite slow and sometimes SLIP >has to retransmit packets which implies time-out if the buffer modem >is full. So I can't know when communication is really lossed. detecting communication loss over tcp from the user level is not easy. tcp itself doesn't really know when about actual communication lost in transit. it simply retransmits the segment after a timeout if it doesn't receive an ack for a segment. the number of retransmitted packets are kept in tcps_sndrexmitpack field and the number of bytes retransmitted are in tcps_sndrexmitbyte field of the tcpstat global variable. in vxWorks 5.0 or later, there is a user callable routine tcpstatShow() that prints out the content of tcpstat to the console, much like UNIX "netstat -a" command. if your ty driver reports an error when write() fails, slip driver should increment the error count for the output (in ifnet structure there is if_if_oerrors -- see if.h), which can help you find out more precisely when the slip/ty-driver fails to send a byte or a packet. unfortunately, i made a mistake in the slip driver for vxWorks and it doesn't really bump the output error count each time write() error happens. i thought initially to increment only per packet output error, but not for the byte error (since the failed byte may be slip framing escape char). i never decided which was the right way to do it. WRS might have fixed this bug already. you should be able to hack on the ty driver to report error if you fail to send bytes. since slip takes over a particular ty device this should be sufficient (and more accurate) for reporting transmission error or loss due to lack of buffers in the modem or something. but i don't really know the full details of what the issues are in your case so i might be totally off base again. From visicom!VisiCom.COM!trest@nosc.mil Fri Nov 8 18:11:34 1991 From: trest@visicom.com (Mike Trest) Date: Fri Nov 8 18:11:41 PST 1991 Subject: Exception at interrupt level I encountered this problem "when crunching some numbers" on a SPARC board (pre ver 5.0). I traced it to the sqrt() floating point routine and simultaneous occurance of i/o interrupt servicing. Our immediate workaround was to call intLock()/intUnlock() arround each sqrt(). It was adequate because the increased interrupt latency (which rarely occured) was more palatible than the reboot. APLabs and WindRiver are aware of the problem. It is my understanding that the next release 5.0.x will fix it. ..mike.. Mike Trest | trest@visicom.com | VisiCom Laboratories Senior Engineer | (619) 592-0353 | San Diego, CA From rypma@waterloo.hp.com Fri Nov 8 18:14:25 1991 From: rypma@waterloo.hp.com (Ted Rypma) Date: Fri Nov 8 18:14:40 PST 1991 Subject: Re: comp.os.vxworks Submitted-by: hmp@frc2.frc.ri.cmu.edu (Henning M. Pangels) > [...] > P.S. Re: comp.os.vxworks -- The responses so far have been 100% > positive, but no real discussion has evolved. That's just fine; we > just have to wait out the prescribed period before an official vote can be > taken. > Henning Pangels |hmp@frc2.frc.ri.cmu.edu | Field Robotics Center > Research Programmer|(412) 268-7088 |Carnegie-Mellon University ---------- Having a "real" notes/news group gets my 110% endorsement. I find it difficult to follow a thread using the exploder, and the topics often aren't very useful. "Real" notes/news fits in much better in our environment. Ted Rypma Hewlett-Packard From rypma@waterloo.hp.com Fri Nov 8 18:20:45 1991 From: rypma@waterloo.hp.com (Ted Rypma) Date: Fri Nov 8 18:20:52 PST 1991 Subject: Re: transmit error detecting > Submitted-by: bernard@aar.alcatel-alsthom.fr ( Olivier Bernard ) > > we are using, in a mobile robot project, a radio modem to communicate > beetween a MVME147 and our Unix network. SLIP is used as a communication > layer. ---------- Since SLIP sits on a tty, ensure that the tty driver reports carrier or communication loss to some code that can then do a slip close or de-attach. If the interface is marked as down, any attempted communication on it via tcp/ip should report an error. Ted Rypma Hewlett-Packard From mea@sparta.com Mon Nov 11 10:29:38 1991 From: mea@sparta.com (Mike Anderson) Date: Mon Nov 11 10:29:53 PST 1991 Subject: FORTRAN for VxWorks Greetings! Is there anyone out there that can recommend a source for a FORTRAN compiler that runs on the Sun SPARCStation and cross-targets to 68Ks running VxWorks? I know that NKR has a FORTRAN for VxWorks, but that one only runs on Sun 3s. On a separate matter, how are folks cross-targeting the 68040 from SPARCStations? Will a 68040 run 68020 code, or do I need a separate compiler? Thanks, ============================================================================== AAAA D D D D EEEEE M M TM // AAAA RRRR TTTTTT SSSSS EEEEE TM A A D D D D E M M M M // A A R R TT S E AAAAAA D D D D EEEEE M M M // AAAAAA RRRR TT SSS EEEEE A A D D D D E M M // A A R R TT S E A A D D D D EEEEE M M // A A R R TT SSSSS EEEEE Process Distribution/Control and Communications for Distributed Systems Mike Anderson Voice: (703) 448-0210 ext. 235 Director, ADDEM(TM) Project Office FAX: (703) 734-3323 SPARTA, Inc. EMAIL: mea@sparta.com Suite 900 7926 Jones Branch Drive "The optimist proclaims that we live in the McLean, VA 22102 best of all possible worlds, and the pessimist fears that this is true." J.B. Cabell ============================================================================== From sharpster@hns.com Mon Nov 11 15:34:26 1991 From: sharpster@hns.com (Steve Harpster) Date: Mon Nov 11 15:37:32 PST 1991 Subject: 5.0.3 (beta) bug list request Is anyone keeping a list (or got one from Wind Rivers) of known bugs in 5.0.3 (beta)? If so, can you e-mail it to me or post it? We get our VxWorks from Intel who claims to not have a list. Many thanks.... -- Stephen Harpster Hughes Network System, Inc. sharpster@hns.com From muts@fysap.fys.ruu.nl Tue Nov 12 00:39:01 1991 From: muts@fysap.fys.ruu.nl (Peter Mutsaers) Date: Tue Nov 12 00:39:09 PST 1991 Subject: tcp hangs in certain conditions It seems unbelievable, but it looks very much as if vxworks 5.0 TCP occasionally blocks, when sending data quite fast to a process on a UNIX host which is quite busy. I am experiencing the problem with writers on VXworks, SUN and ULTRIX, all constantly putting data to a reader on an ULTRIX machine. When the reader is often stopped by other things, so that all tcp/ip buffers are full, the socket to vxworks is blocked, although xvworks is writing into it. This only happens with the socket connected to vxworks, (an eurocom-6 board). I am sending 4k blocks, and hanging always occurs when a part of the block has already been (successfully) received. Is this a known problem? _________________________________________________________________________ Peter Mutsaers. RUU physics dept. Heidelberglaan 5, Utrecht, Nederland muts@fysap.fys.ruu.nl |================================================ tel: (+31)-(0)30-533880 | " Trust me; I know what I'm doing. " From leonid@amil.co.il Tue Nov 12 01:42:09 1991 From: leonid@amil.co.il (Leonid Rosenboim) Date: Tue Nov 12 01:42:15 PST 1991 Subject: Re: tcp hangs in certain conditions What kind of CPU is that ? If it's a 68000 or 68010 I may have an answer for you (drop me aline). Otherwise I do not understand how did you conclude that the VxWorks side is guilty of the crime. What happends if that busy reader runs on a SUN instead of Ultrix ? --------------------------------------------------------------------- | Leonid Rosenboim Internet: leonid@amil.co.il | | System Administrator Fax: +972-3498-078 | | Applied Materials (Israel) LTD. Phone: +972-3498-201 | --------------------------------------------------------------------- From muts@fysap.fys.ruu.nl Tue Nov 12 02:45:06 1991 From: muts@fysap.fys.ruu.nl (Peter Mutsaers) Date: Tue Nov 12 02:45:17 PST 1991 Subject: tcp hangs in certain conditions >>Op Tue, 12 Nov 91 11:21:45 IST schreef u: > What kind of CPU is that ? If it's a 68000 or 68010 I may have an answer > for you (drop me aline). It is a 68020. > Otherwise I do not understand how did you conclude that the VxWorks side > is guilty of the crime. What happends if that busy reader runs on a SUN > instead of Ultrix ? Well, I found out it is the combination of ULTRIX and VxWorks: it only happens when the reader is on ultrix, but it only happens with sockets connected to vxworks, not to other machines (sun, hp, etc.). Maybe the cause has something to do with the little-endianess of DEC machines? Peter Mutsaers From mea@sparta.com Tue Nov 12 04:09:38 1991 From: mea@sparta.com (Mike Anderson) Date: Tue Nov 12 04:09:45 PST 1991 Subject: Re: tcp hangs in certain conditions Greetings! Peter Mutsaers writes that he sees TCP block under VxWorks when he really loads the network down. We, too, are seeing this phenomena on our Heurikon V30XE boards, but only under 5.0.1. 4.0.2 works like a champ (albeit quite a bit slower). We are performing the transfers to a SPARCStation IPC. We don't have 5.0.2 as of yet (it's in the mail ;-) so we hope that that release will fix some of the other bugs we've uncovered in 5.0.1. BTW, I have forwarded the gcc text segment misalignment bug through to the tech support folks and I will post any answer I get as soon as I get it. In the mean time, if you try to use the entrypoint _text and you didn't compile your code with the -traditional flag set, your programs will die a horrible death. ============================================================================== AAAA D D D D EEEEE M M TM // AAAA RRRR TTTTTT SSSSS EEEEE TM A A D D D D E M M M M // A A R R TT S E AAAAAA D D D D EEEEE M M M // AAAAAA RRRR TT SSS EEEEE A A D D D D E M M // A A R R TT S E A A D D D D EEEEE M M // A A R R TT SSSSS EEEEE Process Distribution/Control and Communications for Distributed Systems Mike Anderson Voice: (703) 448-0210 ext. 235 Director, ADDEM(TM) Project Office FAX: (703) 734-3323 SPARTA, Inc. EMAIL: mea@sparta.com Suite 900 7926 Jones Branch Drive "The optimist proclaims that we live in the McLean, VA 22102 best of all possible worlds, and the pessimist fears that this is true." J.B. Cabell ============================================================================== From mea@sparta.com Tue Nov 12 04:48:17 1991 From: mea@sparta.com (Mike Anderson) Date: Tue Nov 12 04:48:31 PST 1991 Subject: SBE VPU-25 experience Greetings! Is there anyone out in net land that has had any experience (good or bad) with the SBE VPU-25 and/or the SBE VLAN-E2 under VxWorks? I've been asked to try and integrate some of these boards and the information that I've gotten from SBE is sketchy at best. Thanks ============================================================================== AAAA D D D D EEEEE M M TM // AAAA RRRR TTTTTT SSSSS EEEEE TM A A D D D D E M M M M // A A R R TT S E AAAAAA D D D D EEEEE M M M // AAAAAA RRRR TT SSS EEEEE A A D D D D E M M // A A R R TT S E A A D D D D EEEEE M M // A A R R TT SSSSS EEEEE Process Distribution/Control and Communications for Distributed Systems Mike Anderson Voice: (703) 448-0210 ext. 235 Director, ADDEM(TM) Project Office FAX: (703) 734-3323 SPARTA, Inc. EMAIL: mea@sparta.com Suite 900 7926 Jones Branch Drive "The optimist proclaims that we live in the McLean, VA 22102 best of all possible worlds, and the pessimist fears that this is true." J.B. Cabell ============================================================================== From hebo@mbari.org Tue Nov 12 08:40:14 1991 From: hebo@mbari.org (Bob Herlien) Date: Tue Nov 12 08:40:20 PST 1991 Subject: Re: SBE VPU-25 experience Mike, We haven't used the VPU-25, but we do use the VPU-30 as our main VxWorks target platform. The VPU-30 is a 25 MHz 68030 with 4 MB RAM. It's a reliable general purpose CPU. I'm surprised that the information you got from SBE was "sketchy". We got quite a bit of information from them before purchase. The documentation that comes with the VPU-30 is the most complete hardware doc I've ever seen, and is a primary reason we're quite pleased with the purchase. More than 300 pages, including full schematics and reprints of the LSI chips used. I've only had one encounter with their technical support staff, but their response was good. Before I knew that it was a generic VME bus problem, I reported as a bug the fact that it couldn't do TAS from both the backplane and the local CPU. (In case you're not familiar with this, on VME bus, simultaneous TAS instructions from both a local CPU and the VME bus don't interlock properly. That's why VxWorks has the grungy software TAS). The tech support guy took it as a bug report, researched it, and gave me a good description of the problem on VME bus within a couple of days. ----------------------------------------------- Bob Herlien MBARI (Monterey Bay Aquarium Research Institute) hebo@hp850.mbari.org From tadusa!tadtec!ma@uunet.uu.net Tue Nov 12 11:46:09 1991 From: tadusa!tadtec!ma@uunet.uu.net Date: Tue Nov 12 11:46:16 PST 1991 Subject: Re: SBE VPU-25 experience Bob, >I've only had one encounter with their technical support staff, but their >response was good. Before I knew that it was a generic VME bus problem, >I reported as a bug the fact that it couldn't do TAS from both the backplane >and the local CPU. (In case you're not familiar with this, on VME bus, >simultaneous TAS instructions from both a local CPU and the VME bus don't >interlock properly. That's why VxWorks has the grungy software TAS). >The tech support guy took it as a bug report, researched it, and gave me >a good description of the problem on VME bus within a couple of days. This isn't a VME problem. It is perfectly reasonable to perform simultaneous locked accesses to a VME boards' DRAM from both another VME master, and the local CPU. It's up to the DRAM arbitration hardware to ensure that locked cycles addressed to it work correctly. There is a problem implementing locking for the cas2 68k instruction over VME however, as these instructions expect the lock to be maintained while the address being accessed changes. The VME spec does not allow this. Mark Armitage email: ma@tadtec.uucp Technical Projects Manager phone: +44 223 423030 Tadpole Technology plc fax: +44 223 420772 From ricks@wrs.com Tue Nov 12 12:36:40 1991 From: ricks@wrs.com (Rick Sustek) Date: Tue Nov 12 12:36:46 PST 1991 Subject: Re: tcp hangs in certain conditions To Mike at Sparta and other hkv30xe users: There is a driver patch available for the enet device on this board. It fixes several problems, most due to known hardware problems. It also runs a *lot* faster. Pls call tech support. Rick ricks@wrs.com From omni!hwajin@apple.com Wed Nov 13 01:55:17 1991 From: hwajin@omni.com (Hwa-Jin Bae) Date: Wed Nov 13 01:55:31 PST 1991 Subject: Re: tcp hangs in certain conditions peter mutsaers writes, >It seems unbelievable, but it looks very much as if vxworks 5.0 TCP >occasionally blocks, when sending data quite fast to a process on a >UNIX host which is quite busy. I am experiencing the problem with >writers on VXworks, SUN and ULTRIX, all constantly putting data to a >reader on an ULTRIX machine. "once the tcp occasionally blocks", does it come back and continue to deliver the data afterwards? or does it just hang indefinitely? as you probably know already, when the receiver's tcp window goes to zero, the sender will start a zero window probe sequence or go to persist state, waiting for the peer to open up its receive window. if the ultrix says its window is closed, vxworks can't send tcp data to it. using a protocol analyzer you should be able to see what the value of that window is. if you want, you may expand the receive socket level buffer for the ultrix socket where you receive data, which will provide larger tcp window when receiving data. if the user doesn't read the data from the socket, tcp won't open up the window, which is the way it should be -- flow controlled. >When the reader is often stopped >by other things, so that all tcp/ip buffers are full, the socket to >vxworks is blocked, although xvworks is writing into it. by "the socket to vxworks is blocked", i guess you mean that the task that writes to the socket is pending on a semaphore. this is probably because you exhausted the send socket level buffer. for tcp, the default value is 4K for each socket level buffer (send and receive side). i'm not sure what you mean by "although xvworks is writing into it". >This only happens with the socket connected to vxworks, (an eurocom-6 >board). I am sending 4k blocks, and hanging always occurs when a part >of the block has already been (successfully) received. how did you find out that "a part of the block has been successfully received"? do you do "netstat" to see the size of socket buffer used? do you actually do a read on the socket and print out the number of bytes read? is it correct to assume that: a) sender tries its best to send as much of the 4 k block data as possible as fast as possible, b) receiver receives data when it can at 4 k blocks, c) receiver sometimes doesn't read socket and lets tcp window to shrink, and does something else, d) the sender blocks until the receiver reads data again. and mike anderson writes, > Peter Mutsaers writes that he sees TCP block under VxWorks when he really > loads the network down. We, too, are seeing this phenomena on our > Heurikon V30XE boards, but only under 5.0.1. 4.0.2 works like a champ > (albeit quite a bit slower). i'd like know more details about this phenomena. more specifically, the details of how the tcp behaves differently in 5.0.1 and 4.0.2. what kind of applications make this behavior come out? what do you exactly do in your applications? any further information is appreciated. From haas@brl.mil Wed Nov 13 06:21:11 1991 From: haas@brl.mil (IBD) Date: Wed Nov 13 06:21:18 PST 1991 Subject: Re: transmit error detecting (subtopic RF modems) Olivier Bernard was interested in a radio-frequency modem for application to a mobile robot. I am involved in a project involving vxWorks-based remote control of a vehicle over a radio link. We are using ARLAN modems from TeleSystems SLW, Inc., a Canadian firm. These spread-spectrum modems are designed for stationary installation (e.g. inter-building LAN), but are performing adequately at distances of over a kilometer, from a moving platform, through modest obstructions, with simple antenna. We are using a model which multiplexes several serial lines over the radio link, but I understand there is another model which has an Ethernet port. Our modems cost about $2000 each. I am not involved in the commo group and can't answer detailed questions concerning our implementation, but M. Bernard may be interested in contacting the vendor for more information. TeleSystems SLW, Inc. 85 Scarsdale Road, Suite 201 Don Mills Ontario, Canada M3B 2R2 phone (416) 441-9966 ===================================================================== Gary Haas U.S. Army Ballistics Research Lab Aberdeen Proving Ground, MD (410) 278-8867 From muts@fysap.fys.ruu.nl Wed Nov 13 12:25:29 1991 From: muts@fysap.fys.ruu.nl (Peter Mutsaers) Date: Wed Nov 13 12:25:37 PST 1991 Subject: Re: tcp hangs in certain conditions Hello, sorry for the 'large volume' and maybe excessive amount of data. Leonid Rosenboim suggested that I try with etherfind to trace TCP during the problem I described before. Here is a part of the trace, note that about at : t=4 I pressed ^S to stop the receiver after that a few packets still came in (slowly) t=40 I pressed ^Q to continue the receiver now the receiver did not continue, but block on a read from the socket connected to vxworks t=168 I killed the receiver. fyscg is the (vxworks) sender, ruunb4 is the receiver. Here is a part of the trace; maybe someone could explain what is going on here, I would be grateful: (widen your window to view this easily) 3.89 TCP from fyscg.1025 to ruunb4.fys.ruu.nl.4000 seq 8BAE601, ack 5BE65E01, window 4096, 1024 bytes data 3.89 TCP from fyscg.1025 to ruunb4.fys.ruu.nl.4000 seq 8BAEA01, ack 5BE65E01, window 4096, 1024 bytes data 3.89 TCP from fyscg.1025 to ruunb4.fys.ruu.nl.4000 seq 8BAEE01, ack 5BE65E01, window 4096, 1024 bytes data 3.89 TCP from fyscg.1025 to ruunb4.fys.ruu.nl.4000 seq 8BAF201, ack 5BE65E01, window 4096, 1024 bytes data 4.08 TCP from ruunb4.fys.ruu.nl.4000 to fyscg.1025 seq 5BE65E01, ack 8BAF601, window 8192, 4.12 TCP from fyscg.1025 to ruunb4.fys.ruu.nl.4000 seq 8BAF601, ack 5BE65E01, window 4096, 1024 bytes data 4.12 TCP from fyscg.1025 to ruunb4.fys.ruu.nl.4000 seq 8BAFA01, ack 5BE65E01, window 4096, 1024 bytes data 4.12 TCP from fyscg.1025 to ruunb4.fys.ruu.nl.4000 seq 8BAFE01, ack 5BE65E01, window 4096, 1024 bytes data 4.13 TCP from fyscg.1025 to ruunb4.fys.ruu.nl.4000 seq 8BB0201, ack 5BE65E01, window 4096, 1024 bytes data 4.28 TCP from ruunb4.fys.ruu.nl.4000 to fyscg.1025 seq 5BE65E01, ack 8BB0601, window 4096, 4.29 TCP from fyscg.1025 to ruunb4.fys.ruu.nl.4000 seq 8BB0601, ack 5BE65E01, window 4096, 1024 bytes data 4.29 TCP from fyscg.1025 to ruunb4.fys.ruu.nl.4000 seq 8BB0A01, ack 5BE65E01, window 4096, 1024 bytes data 4.29 TCP from fyscg.1025 to ruunb4.fys.ruu.nl.4000 seq 8BB0E01, ack 5BE65E01, window 4096, 1024 bytes data 4.29 TCP from fyscg.1025 to ruunb4.fys.ruu.nl.4000 seq 8BB1201, ack 5BE65E01, window 4096, 1024 bytes data 4.48 TCP from ruunb4.fys.ruu.nl.4000 to fyscg.1025 seq 5BE65E01, ack 8BB1601, window 0, 9.14 TCP from fyscg.1025 to ruunb4.fys.ruu.nl.4000 seq 8BB1601, ack 5BE65E01, window 4096, 1 bytes data 9.26 TCP from ruunb4.fys.ruu.nl.4000 to fyscg.1025 seq 5BE65E01, ack 8BB1602, window 4095, 9.27 TCP from fyscg.1025 to ruunb4.fys.ruu.nl.4000 seq 8BB1602, ack 5BE65E01, window 4096, 1024 bytes data 9.27 TCP from fyscg.1025 to ruunb4.fys.ruu.nl.4000 seq 8BB1A02, ack 5BE65E01, window 4096, 1024 bytes data 9.27 TCP from fyscg.1025 to ruunb4.fys.ruu.nl.4000 seq 8BB1E02, ack 5BE65E01, window 4096, 1024 bytes data 9.27 TCP from fyscg.1025 to ruunb4.fys.ruu.nl.4000 seq 8BB2202, ack 5BE65E01, window 4096, 1023 bytes data 9.46 TCP from ruunb4.fys.ruu.nl.4000 to fyscg.1025 seq 5BE65E01, ack 8BB1602, window 4095, 10.14 TCP from fyscg.1025 to ruunb4.fys.ruu.nl.4000 seq 8BB1602, ack 5BE65E01, window 4096, 1024 bytes data 12.14 TCP from fyscg.1025 to ruunb4.fys.ruu.nl.4000 seq 8BB1602, ack 5BE65E01, window 4096, 1024 bytes data 15.73 TCP from ruunb4.fys.ruu.nl.4000 to fyscg.1025 seq 5BE65E01, ack 8BB1602, window 12287, 16.15 TCP from fyscg.1025 to ruunb4.fys.ruu.nl.4000 seq 8BB1602, ack 5BE65E01, window 4096, 1024 bytes data 24.15 TCP from fyscg.1025 to ruunb4.fys.ruu.nl.4000 seq 8BB1602, ack 5BE65E01, window 4096, 1024 bytes data 27.75 TCP from ruunb4.fys.ruu.nl.4000 to fyscg.1025 seq 5BE65E01, ack 8BB1602, window 16384, 40.15 TCP from fyscg.1025 to ruunb4.fys.ruu.nl.4000 seq 8BB1602, ack 5BE65E01, window 4096, 1024 bytes data 72.17 TCP from fyscg.1025 to ruunb4.fys.ruu.nl.4000 seq 8BB1602, ack 5BE65E01, window 4096, 1024 bytes data 136.20 TCP from fyscg.1025 to ruunb4.fys.ruu.nl.4000 seq 8BB1602, ack 5BE65E01, window 4096, 1024 bytes data 168.56 TCP from ruunb4.fys.ruu.nl.4000 to fyscg.1025 seq 5BE65E01, ack 8BB1602, FIN, window 16384, 168.56 TCP from fyscg.1025 to ruunb4.fys.ruu.nl.4000 seq 8BB1A02, ack 5BE65E02, window 4096, 200.22 TCP from fyscg.1025 to ruunb4.fys.ruu.nl.4000 seq 8BB1602, ack 5BE65E02, window 4096, 1024 bytes data 264.25 TCP from fyscg.1025 to ruunb4.fys.ruu.nl.4000 seq 8BB1602, ack 5BE65E02, window 4096, 1024 bytes data 328.28 TCP from fyscg.1025 to ruunb4.fys.ruu.nl.4000 seq 8BB1602, ack 5BE65E02, window 4096, 1024 bytes data Regards, Peter Mutsaers From Enterprise!arete!reder@uu.psi.com Wed Nov 13 16:02:49 1991 From: reder@arete.lbl.gov (Leonard J. Reder) Date: Wed Nov 13 16:02:57 PST 1991 Subject: Passive monitoring of network sockets We currently have a Sun SPARC 2 sending data to a Motorola MVME-147S board over a network using Sockets to communicate from the Sun to the Motorola. The Motorola is running VxWorks (actually VADSWorks with the WRS GNU tools). On the same network I would like to run my Sun SLP running a program that receives the same data the Motorola gets. I know I could do this with an additional socket connection but what I want in this case is to have the SPARC 2 broadcast the data a single time so that both the Motorola and Sun will receive the data simaltaneously and network traffic will not increase. Can this even be done with sockets? Thanks for any reply; Len Reder Arete Assoc. 818-501-2880 (voice) reder@arete.com (email) ----- End Included Message ----- From bard@cutter.ssd.loral.com Wed Nov 13 16:22:14 1991 From: bard@cutter.ssd.loral.com (James Woodyatt) Date: Wed Nov 13 16:22:20 PST 1991 Subject: Re: Passive monitoring of network sockets #> I want in this case is to have the SPARC 2 #> broadcast the data a single time so that both the #> Motorola and Sun will receive the data #> simaltaneously and network traffic will not #> increase. #> #> Can this even be done with sockets? Not with TCP sockets. UDP sockets can use the broadcast address for your network/subnet. We use this feature here at SS/L distributing spacecraft telemetry. __________________________________________________________________ | | James Woodyatt VOICE: (415) 852-5429 | Space Systems/Loral (M/S G87) FAX: (415) 852-6286 | 3825 Fabian Way E-MAIL: bard@cutter.ssd.loral.com | Palo Alto, CA 9430 | From ehipp@wrs.com Wed Nov 13 19:54:31 1991 From: ehipp@wrs.com (Emily Hipp) Date: Wed Nov 13 19:54:37 PST 1991 Subject: Re: tcp hangs in certain conditions Hello, >It seems unbelievable, but it looks very much as if vxworks 5.0 TCP >occasionally blocks, when sending data quite fast to a process on a Based on the etherfind trace, your problem appears it be caused by a checksum bug that was in versions 5.0 and 5.0.1 (and was corrected in 5.0.2). You can verify that this bug is causing the behavior you refer to by doing a 'netstat -s' on the UNIX side and checking to see if the checksum error counter(s) increase. Please contact WRS tech support for futher assistance, or if this does not appear to be the source of your difficulty. Emily Hipp ehipp@wrs.com From omni!hwajin@apple.com Wed Nov 13 23:05:25 1991 From: hwajin@omni.com (Hwa-Jin Bae) Date: Wed Nov 13 23:05:31 PST 1991 Subject: Re: Passive monitoring of network sockets you could also use sunos nit (network interface tap) interface to get to the ethernet directly. it's similar to etherHook stuff in vxworks. do "man nit" for more info. fyi, etherfind uses nit. From D.S.Riches@bnr.co.uk Wed Nov 13 23:55:04 1991 From: D.S.Riches@bnr.co.uk Date: Wed Nov 13 23:55:10 PST 1991 Subject: Re: Passive monitoring of network sockets Remove mem from the list please. From sb%itk.unit.no@Csa2.LBL.Gov Thu Nov 14 10:01:36 1991 From: sb%itk.unit.no@Csa2.LBL.Gov Date: Thu Nov 14 10:01:43 PST 1991 Subject: MV147 and backplane internet We have been trying to set up a backplane internet on the MV147. We are not able to initialize it! When we start booting it it says: --------------------------- Attaching network interface ln0... done. Loading... 213248 + 56628 + 21380 Starting at 0x1000... Attaching network interface ln0... done. Initializing backplane net with anchor at 0x800000... Bus Error Program Counter: 0x0002c4fe Status Register: 0x3700 Access Address : 0xffff8fec Instruction : 0xbab9 Special Status : 0x074d Task: 0x3ffea8 "tRootTask" ------------------------------- The stack-trace is as follows: 336c2 : kernelRoot (485a0, 1c0c, 3fd8f0, 2710, 485a0, 481b8, 3e8, ee, 0, 0) 2a8a6 : usrRoot ([485a0, 3b5350, 0, 0, 336c4]) 1d7e : usrNetInit ([700, 0, 3fd8f0, 0, 0]) 1efa : usrNetIfConfig (355d3, 3ffcba, 0) 22be : bpInit ([800000, 800000, fff0, 1, 35771]) 1c5c8 : wdStart ([ffff8fec, 3c, 1d1bc, 800000, 355d3]) It looks as if wdCreate returns a completely wild address (ffff8fec) for the watchdog id. Salient features from config.h: #define BP_OFF_BOARD TRUE #if BP_OFF_BOARD #undef BP_ANCHOR_ADRS #define BP_ANCHOR_ADRS ((char *)0x00800000) #define BP_MEM_ADRS BP_ANCHOR_ADRS #define BP_MEM_SIZE 0x80000 #else ... #define LOCAL_MEM_LOCAL_ADRS 0 #define LOCAL_MEM_SIZE 0x400000 #define LOCAL_MEM_BUS_MULT 0 HELP! The Norwegian Institute of Technology Div. of Engineering Cybernetics +(47 7) 594440 (direct) / 594375 (switchboard) N-7034 TRONDHEIM, NORWAY +(47 7) 594399 (fax) From mea@sparta.com Thu Nov 14 11:26:28 1991 From: mea@sparta.com (Mike Anderson) Date: Thu Nov 14 11:26:35 PST 1991 Subject: Xwindows VME Clients Greetings! Has anyone in netland come across any of those hardware VME-based X clients (e.g., TI 34010 or 34020 based) that have a driver or interface to VxWorks that I can plug into my existing chassis? I have a customer that's interested in direct VME graphics support to a monitor without going across an Ethernet to display the graphics. Thanks, ============================================================================== AAAA D D D D EEEEE M M TM // AAAA RRRR TTTTTT SSSSS EEEEE TM A A D D D D E M M M M // A A R R TT S E AAAAAA D D D D EEEEE M M M // AAAAAA RRRR TT SSS EEEEE A A D D D D E M M // A A R R TT S E A A D D D D EEEEE M M // A A R R TT SSSSS EEEEE Process Distribution/Control and Communications for Distributed Systems Mike Anderson Voice: (703) 448-0210 ext. 235 Director, ADDEM(TM) Project Office FAX: (703) 734-3323 SPARTA, Inc. EMAIL: mea@sparta.com Suite 900 7926 Jones Branch Drive "The optimist proclaims that we live in the McLean, VA 22102 best of all possible worlds, and the pessimist fears that this is true." J.B. Cabell ============================================================================== From omni!hwajin@apple.com Fri Nov 15 03:20:16 1991 From: hwajin@omni.com (Hwa-Jin Bae) Date: Fri Nov 15 03:20:24 PST 1991 Subject: Re: tcp hangs in certain conditions looking at the etherfind trace, @ 4.48 the receiver sends a window of zero, indicating its saturation of buffer space, which prompts the sender to start probing for the window to open. the receiver immediately responds with an open window of 4 K so the sender resumes sending data. @ 9.27 the sender sends a segment with sequence number 8BB1602 and length of 1K, and continues to send as many segment as possible to fill the window, which doesn't seem to get closed on receiver's side even though it's not acknowledging any data. this goes on forever because the receiver does not ack any more than the seq 8BB1602. so the sender keeping sending the segment starting with 8BB1602 which is yet to be acknowledged. i don't know why ultrix is doing this. From tadusa!tadtec!ma@uunet.uu.net Fri Nov 15 04:16:51 1991 From: tadusa!tadtec!ma@uunet.uu.net Date: Fri Nov 15 04:16:58 PST 1991 Subject: Re: Xwindows VME Clients Mike, > Has anyone in netland come across any of those hardware VME-based >X clients (e.g., TI 34010 or 34020 based) that have a driver or >interface to VxWorks that I can plug into my existing chassis? I >have a customer that's interested in direct VME graphics support to >a monitor without going across an Ethernet to display the graphics. I think that you're actually looking for an X server - that's the part that actually controls the display hardware. If that is the case, then the Tadpole TP-IGCV may be what you're looking for. VERY briefly, its a 1280 * 1024 * 8 bit display VME board with 34020 & 68020 CPUs. It runs an X server, and can communicate with other machines using both normal ethernet and the VME backplane. If you want more details, then please call me (in the UK) at the number below. Mark Armitage email: ma@tadtec.uucp Technical Projects Manager phone: +44 223 423030 Tadpole Technology plc fax: +44 223 420772 From muts@fysap.fys.ruu.nl Fri Nov 15 04:32:15 1991 From: muts@fysap.fys.ruu.nl (Peter Mutsaers) Date: Fri Nov 15 04:32:22 PST 1991 Subject: tcp hangs in certain conditions >>On Fri, 15 Nov 91 03:20:29 PST hwajin@omni.com (Hwa-Jin Bae) wrote: > looking at the etherfind trace, > this goes on forever because the receiver does not ack any more than > the seq 8BB1602. so the sender keeping sending the segment starting > with 8BB1602 which is yet to be acknowledged. > i don't know why ultrix is doing this. According to ehipp@wrs.com this is caused by a bug in the checksum of TCP in version 5.0 and 5.0.1 of VxWorks. It has been fixed in version 5.0.2. So we will get that now. Thanks to all who helped. Peter Mutsaers From interf!atlas!argus!brackett@uunet.uu.net Fri Nov 15 10:01:41 1991 From: interf!atlas!argus!brackett@uunet.uu.net (Todd Brackett) Date: Fri Nov 15 10:01:48 PST 1991 Subject: Re: Xwindows VME Clients Mike Anderson writes, >> Has anyone in netland come across any of those hardware VME-based >> X clients (e.g., TI 34010 or 34020 based) that have a driver or >> interface to VxWorks that I can plug into my existing chassis? I >> have a customer that's interested in direct VME graphics support to >> a monitor without going across an Ethernet to display the graphics. Graphic Strategies, Inc make an animal called the VGME-34010, as of my last information (Sept 90), it was running an X11R3 server. It was a 6U form factor with 1280 X 1024 resolution using 8 bit planes for 256 colors out of 16.7 million. It had a hardware cursor, scroll and pan. I have no idea what it costs.... Regards, ------------------------------------------------------- |Todd S. Brackett |Voice:703 790 8500 | |Interferometrics, Inc. |FAX: 703 848 2492 | |8150 Leesburg Pike | | |Vienna, VA 22182 | | |-----------------------------------------------------| |U. S. Naval Observatory |Voice:202 653 0945 | |34th and Massachusetts Ave. NW |FAX: 202 653 0941 | |Building 52 | | |Washington, DC 20392-5100 | | |-----------------------------------------------------| |Internet:brackett@interf.com | |Uunet: uunet!interf!brackett | ------------------------------------------------------- From tadusa!tadca!tadca!bm@uunet.uu.net Fri Nov 15 10:17:16 1991 From: tadusa!tadca.tadca!bm@uunet.uu.net (B. M. MISTRY) Date: Fri Nov 15 10:17:25 PST 1991 Subject: Re: Xwindows VME Clients > >Date: Thu, 14 Nov 91 11:26:39 PST > >Errors-To: uunet!lbl.gov!vxwexplo-errs > >To: vxworks_users@vxw.ee.lbl.gov > >From: uunet!lbl.gov!vxwexplo (the vxWorks Users Group Exploder) > >Subject: Xwindows VME Clients > > > >Submitted-by mea@sparta.com Thu Nov 14 11:26:28 1991 > >Submitted-by: mea@sparta.com (Mike Anderson) > > > >Greetings! > > > > Has anyone in netland come across any of those hardware VME-based > >X clients (e.g., TI 34010 or 34020 based) that have a driver or > >interface to VxWorks that I can plug into my existing chassis? I > >have a customer that's interested in direct VME graphics support to > >a monitor without going across an Ethernet to display the graphics. > > > >Thanks, > > > >Process Distribution/Control and Communications for Distributed Systems > > > >Mike Anderson Voice: (703) 448-0210 ext. 235 > >Director, ADDEM(TM) Project Office FAX: (703) 734-3323 > >SPARTA, Inc. EMAIL: mea@sparta.com > >Suite 900 > >7926 Jones Branch Drive "The optimist proclaims that we live in the > >McLean, VA 22102 best of all possible worlds, and the pessimist > > fears that this is true." > > > > J.B. Cabell > > > >============================================================================== Hello, In answer to your quest for a VME bus TMS34020 X-Windows Graphics requirement. ------------------------------------------------------------------------------------------------------- The TP-IGC from Tadpole Technology Inc., is a dedicated X server for implementing X-Windows solutions on VME. The board is designed with the TMS34020 Graphics systems processor and a MC68020 control processor providing I/O and protocol handling. The display resolution is 1280 x 1024 with Hardware Vertical Screen Scroll and Horizontal Panning. The X-Server code is embedded on the board for high performance, therefore there is no 'booting procedure' which would involve locating and loading of the X-server over the Ethernet. The board is an intelligent controller designed to relieve the host of the X-server and graphics processing load. VME master devices can directly transfer data into screen or off-screen storage, and a high performance 32-bit VME master/slave interface with BLT support allows efficient and fast client-server communication over the backplane. The TP-IGC also has a RS232 Mouse port, a TTL keyboard port and 2 additional RS232 ports. The Ethernet interface is provided for direct network connection, switch selectable for either Ethernet or Cheapernet. TP-IGC Features ============ TMS34020 40MHz Graphics Systems Processor VRAM 2 MB Video RAM DRAM 4 MB Dynamic RAM VIDEO 256 colours from 16 million 8-bit pixel 64 x 64 programmable hardware cursor MC68020 20 MHz control processor for i/o and protocol handling SRAM 128KB (client-server protocol use by Host and the MC68020) EPROM 256K-4MB NET i82596 LAN controller SERIAL TTL for Keyboard RS232 Mouse port 2 x RS232 Asynchronous MISC Six 16-bit Counter/Timers VME (IEE 1014) DTB Master (RMW) A32/24 D32/16/8 BLT Requester R(0-3) ROR/RWD(FAIR) DTB Slave (RMW,UAT) A32 D32/16/8(EO) BLT Interrupter I(1-7) DYN Interrupt Handler I(1-7) DYN **** For more information on the above product contact **** TADPOLE TECHNOLOGY INC., Tel: (800) 232 6656 e-mail: uunet!tadusa!ll (SALES) e-mail: uunet!tadusa!support (Technical Support) ************************************************** Regards _Baz +++++++++++++++++++++++++++++++++++++++++++++++++++++ + B. M. MISTRY Tel: (408) 441 7920 + + Technical Support Fax: (408) 441 8018 + + Tadpole Technology Inc. e-mail: uunet!tadusa!tadca!bm + + 2001 Gateway Place, Suite 550W bm@tadca.tadusa.uunet + + San Jose, CA. 95110 + +++++++++++++++++++++++++++++++++++++++++++++++++++++ From prb@aplexus.jhuapl.edu Fri Nov 15 14:18:38 1991 From: prb@aplexus.jhuapl.edu (Paul R. Bade) Date: Fri Nov 15 14:18:49 PST 1991 Subject: Cache Coherency on the MVME-167 Hello, I have been trying to run some backplane socket benchmarks on two MVME-167 boards with the cache enabled and bus snooping on. I seem to be experiencing a cache coherency problem and wanted to find out if anyone else has tried to use the bus snooping. First, A little about bus snooping........ The beta version of VxWorks for the MVME-167 board does not include support for the MMU and bus snooping In fact, the data cache is disabled on processor 0. This represents a tremendous hit in effective processing power so I have written some code to utilize both the MMU and bus snooping. My configuration..... I have made several changes to the normal vxWorks memory map. These changes include reserving the area between 0x1000 and 0xfffff for some custom stuff and the mmu translation tables. This lower 1 Mbyte is mapped to the VMEbus at 0x10000000 and it is Noncacheable with no bus snooping. The next 2 Mbytes are mapped as copyback and would not be accessed by the VMEbus. The top 1 Mbyte is used as a memory pool for the network and is thus mapped to the VMEbus at 0x10300000 to 0x103fffff. The pool is created with the variable EI_POOL_ADRS and EI_POOL_SIZE. Before I get into the cache and snooping issues for this pool, Let me describe the rest of the MMU mapping on both processor. ADDRESS RANGE PERMISSIONS CACHE MODE ----------------------------------------------------------------- 00000000->000fbfff Read-Write Off/Serial User/Supv 000fc000->000fffff Read-Only Off/Serial User/Supv 00100000->003fffff Read-Write CopyBack User/Supv 00400000->007fffff Not Resident 00800000->00bfffff Read-Write Off/Serial User/Supv 00c00000->0fffffff Not Resident 10000000->1fffffff Read-Write Off/Serial User/Supv 20000000->3fffffff Read-Write Off/Serial User/Supv 40000000->ff7fffff Not Resident ff800000->ffbfffff Read-Only CopyBack User/Supv ffc00000->ffdfffff Not Resident ffe00000->ffe1ffff Read-Write CopyBack User/Supv ffe20000->ffefffff Not Resident fff00000->ffffffff Read-Write Off/Serial User/Supv Snooping is enabled for the PCC Chip2 Lanc to LANC_BEICR_SINK_DATA. The MEMC_RCR_SWAIT bit is set if MEMC_REVISION == 0 The VME DMA has the snooping turned on even though I don't think it is used. Now for the backplane network memory pool options............. 1) When the pool is Cacheable copyback, with the sink data snooping option on the VMEbus chip, the backplane network fails when running max data rate benchmarks. It usually takes 5-10 minutes and fails with the server which is writing from proc(1) with his write queue full and the receiver client proc(1) with nothing in his queue to read. See displays from inetstatShow(). 2) When the pool is Cacheable writethrough, with the sink data snooping option on the VMEbus chip, it also has also been seen to fail but much less frequently. I need run more tests on this mode. 3) When the pool is NonCacheable, I have not yet seen a failure. I would be very interested if anyone else has any similar experiences. Paul R. Bade Johns Hopkins University / Applied Physics Lab Laurel, MD prb@aplexus.jhuapl.edu Another Day, Another $$$$$$$$ From ericm@iceman.gvg.tek.com Wed Nov 20 11:41:04 1991 From: ericm@iceman.gvg.tek.com (Eric McLaughlin) Date: Wed Nov 20 11:41:15 PST 1991 Subject: XDR I'm currently designing communications software for a new product. This product may be controlled by our custom panel, a PC, a Mac, or a workstation over an ethernet link. External boxes control us via a language built on top of UDP. Internally, our product also communicates via this UDP based language. There are 20+ miscroprocessors in our product, which communicate over two backplanes. We are designing our own backplane and driver for greater throughput. Anyway, I would like to provide the architecture independent data representation found with XDR, without the overhead of XDR. What I'd like to know is what are other people doing out there to alleviate the byte ordering and structure padding problems when communicating with different types of processors via a network? Eric M. From leonid@amil.co.il Thu Nov 21 01:36:48 1991 From: leonid@amil.co.il (Leonid Rosenboim) Date: Thu Nov 21 01:36:55 PST 1991 Subject: Re: XDR Basically there are two methods of encoding data in a machine independent manner. The first method uses precompiled type and structure information, while the second encodes all this information into the data stream. A good example of the first method is XDR, and the overhead of XDR is as little overhead as one can get (when using RPCGEN to produce xdr_* functions). A good example of the second method is ISO's ASN.1. This technology is widely used, in the TCP/IP world, the SNMP (Simple Network Management Protocol) uses ASN.1 for data encoding. I have never used it, therefore I am not in a position to compare the overhead involved and compare it with XDR. You also must take into account the fact that embedded type and structure information consumes much more bandwidth and CPU. I think that if bandwidth and performance are significant factors for your project (versus openness and heterogenity), you should stick with XDR or maybe just an application specific protocol that control representation when necesary. --------------------------------------------------------------------- | Leonid Rosenboim Internet: leonid@amil.co.il | | System Administrator Fax: +972-3498-078 | | Applied Materials (Israel) LTD. Phone: +972-3498-201 | --------------------------------------------------------------------- From benny%dimona.vlss.amdahl.com%juts.ccc.amdahl.com@amdahl.uts.amdahl.com Thu Nov 21 11:07:27 1991 From: benny@dimona.vlss.amdahl.com (Benny Schnaider) Date: Thu Nov 21 11:07:38 PST 1991 Subject: Re: XDR Eric, Our application consists of 64 (MVME135) targets talking (TCP/IP) over the bakeplane. All of the 64 are connected in a star configuration to a center node which (among other tasks) serves as the gateway to the rest of the "external network." Although we have many node on the "external network" (e.g., SPARC, MC680XX, IBM/370), they are all based on the same byte-order architecture. Thus, the basic problem that we face in transferring data across these architectures is machine dependent alignment problems (not byte order). Our solution to the alignment problem is to use a base alignment which is common to all the architectures/compilers. This implies padding data-structures with dummy fields to compensate for the alignment mismatches: EXAMPLE: struct pack1 { struct pack2 { short field1; short field1; long field2; ==> short dummy; } long field2; } In this example struct pack2 will have identical offsets for both field1 and field2 for all the compilers that we use (we use at least 4 different compiles in our application). I think this should be common to other compilers as well. The biggest advantage of this approach is the fact that you do not waste any CPU time during "run-time" for conversions. Basically, everything is done at compile time. We have automated the conversion process by: 1. All the structures sent across the network are concentrated in special header files. 2. As part of the build process (make), we (automatically) parse the special files and pad the dummy fields for the most common alignment. 3. We synthesize a "C" file which is later compiled and executed. The results of the execution is a single signature (4 bytes) which reflects the alignment of the structure. The idea here is to write a code for each structure which computes fields distance and sizes. 4. The signature produced in the previous stage is verified at run time during the connection initialization process of the application. (This is more for sanity checking and verification that the software versions of all nodes match). Benny From omni!hwajin@apple.com Thu Nov 21 12:59:20 1991 From: hwajin@omni.com (Hwa-Jin Bae) Date: Thu Nov 21 12:59:26 PST 1991 Subject: Re: XDR in general xdr is much less expensive that asn.1. asn.1 has a basic encoding scheme consisting of type-length-value triples. when used this scheme produces consistently bigger encoded packets than xdr. a variation of xdr is used in ncs rpc systems, which uses "the receiver makes it right" scheme as opposed to the xdr's common format scheme. xdr's common encoding format requires both sides to encode/decode, whereas ncs rpc scheme makes it possible to skip the overhead of encoding data into intermediate forms if the sender and the receiver use the same data representation. From BATTISTELLA%LEGNARO.INFN.IT@Csa3.LBL.Gov Fri Nov 22 00:53:41 1991 From: BATTISTELLA%LEGNARO.INFN.IT@Csa3.LBL.Gov Date: Fri Nov 22 00:53:49 PST 1991 Subject: looking for drivers We would like to know if there are software drivers for MVME-332XT board for Wx-Works 5.0 and where we can find them. Thank you very much Stefania Canella Andrea Battistella e-mail address: BATTISTELLA@LEGNARO.INFN.IT From BELLATO%LEGNARO.INFN.IT@Csa3.LBL.Gov Fri Nov 22 10:47:48 1991 From: BELLATO%LEGNARO.INFN.IT@Csa3.LBL.Gov Date: Fri Nov 22 10:47:56 PST 1991 Subject: mvme332xt driver info Legnaro 20-11-1991 To VxWorks User's Group members :: I currently face the problem of using the Motorola MVME332XT octal serial port board within VxWorks 5.0 . To your Knowledge, is there any driver available ? Any pointers to code (PD or not), vendors or users that solved the problem would be very ,very appreciated. Thanks in advance. M. A. Bellato email :: bellato@legnaro.infn.it From psm%helios.nosc.mil@nosc.mil Fri Nov 22 15:07:59 1991 From: psm%helios.nosc.mil@nosc.mil Date: Fri Nov 22 15:08:05 PST 1991 Subject: Anyone know thruput of backplane TCP/IP net? We are designing a system that will run vxWorks on a multiprocessor VME chassis, and use the vxWorks backplane TCP/IP network for interprocessor communications. Has anyone got an idea of what thruput (bytes/second) is achievable between a couple of reasonably fast (25 Mhz 68030) boards using TCP or UDP across a backplane net? ---- Scot McIntosh Internet: psm@helios.nosc.mil UUCP: {ihnp4,akgua,decvax,decwest,ucbvax}!sdscvax!nosc!psm "It's not a bug, it's a limitation" - Microsoft Tech Assistant From sass@ast.saic.com Fri Nov 22 17:26:47 1991 From: sass@ast.saic.com (Dennis Sass) Date: Fri Nov 22 17:26:54 PST 1991 Subject: benchmarks I need benchmark data for VADSWorks (Verdix Ada & VxWorks) on an MVME147 @ 33Mhz. If anyone has data to share I'd be delighted. -- Dennis Sass Science Applications International Corporation 10260 Campus Point Drive MS/12 San Diego, CA 92121 telephone: 619.458.4905 fax: 619.546.6833 e-mail: sass@ast.saic.com From hooper@key.amdahl.com Sat Nov 23 11:20:22 1991 From: hooper@key.amdahl.com (Phil Hooper) Date: Sat Nov 23 11:20:32 PST 1991 Subject: core analysis anybody written or have some comments on a core analysis program for sparc vxworks. Let's go with the assumption that there is a method of pulling the entire memory image out of a board when necessary. thanks, hooper@key.com From ojr%itk.unit.no@Csa2.LBL.Gov Mon Nov 25 04:33:30 1991 From: ojr%itk.unit.no@Csa2.LBL.Gov Date: Mon Nov 25 04:33:37 PST 1991 Subject: Net-interface for Tadpole TP-INC We have a couple of Tadpole TP-INC ethernet interface boards that we would like to use in an VxWork environment. Has anyone written an interface between VxWorks and these boards? It is a relatively simple board. An 68000 takes care of LANCE handling. The interface to the host processor is via shared memory. Interrupt is given from TP-INC each time an ethernet-packet is ready in the buffer. A similar concept is used for outgoing packets. Regards, Ornulf Jan Rodseth M.Sc. ojr@itk.unit.no SINTEF Automatic Control +(47 7) 594351 (direct) / 594375 (switchboard) N-7034 TRONDHEIM, NORWAY +(47 7) 594399 (fax) From jjohnson@hns.com Mon Nov 25 06:31:21 1991 From: jjohnson@hns.com (Jayne Johnson) Date: Mon Nov 25 06:31:32 PST 1991 Subject: Re: Anyone know thruput of backplane TCP/IP net? We are using TCP and UDP for interprocess communications and are using Intel 960CA chip running at 33MHZ ( but due to compiler limitations are only achieving about 12-15MIPS). We have been able to achieve 300-450Kbytes/second rate using TCP. Using FTP to download we have seen rates up to 900Kbytes/second. We have found that TCP can not sustain any better than 60 packets/second rate where our packet size is averaged at 256bytes. We are limited by the select() on the receiving destination not being able to signal our receive tasks fast enough. Our select() timeout is set to every 100 msecs. If you decrease the timeout and increase the TCP window sizes I would guess we would be better throughput. Our windows are the default 4K size. We have NOT modified them to date. We are considering this as a good option to set. Please let me know if you know of other options to tweek to get better throughput out of TCP. We are really interested. From hmp@frc2.frc.ri.cmu.edu Mon Nov 25 08:59:24 1991 From: hmp@frc2.frc.ri.cmu.edu (Henning M. Pangels) Date: Mon Nov 25 08:59:31 PST 1991 Subject: Message Queues, Interrupts & Task Priorities I'm running into a strange deadlock situation involving a message queue. Here's the basic scenario: 1. A high priority task (i.e. the shell, during testing) runs some code that causes an expected hardware interrupt from an I/O board. It pends on a semaphore to synchronize with that interrupt. 2. The interrupt handler does a little work, and then sends a message to a queue. 3. A lower priority task receives the message, does some more work and gives the binary semaphore to indicate its completion. 4. The high priority task is unblocked and can continue, possibly repeating this cycle What happens when several (~10-20) of these cycles occur in quick succession, sometimes things get stuck in a situation where the high prority task never gets the semaphore, because the interrupt handling task never gets the corresponding message from the interrupt handler. However, I can ascertain that the interrupt handler has fired, and in fact, a msgQShow indicates that 1 message is queued at this point. At the same time, I can get a task trace (tt) of the interrupt handling task, which shows it *pending* on the queue. Here's a log of the tt and msgQShow output: -> tt "intHandlerTask" 44188 _vxTaskEntry +10 : _intHandlerTask (3e09fc, 40, 6, 0, 3e3570, 216ea, 0, 0 , 0, 0) 3db2d0 _intHandlerTask+18 : _msgQReceive (3e09fc, 3d68da, 6, ffffffff) caa4 _msgQReceive +42 : _qJobGet (3e0a00, ffffffff) value = 0 = 0x0 -> msgQShow 0x3e09fc Message queue id 0x3e09fc: FIFO Task queuing 6 Message length max (bytes) 64 Messages max 1 Messages queued 0 Receivers blocked 0 Send timeouts 0 Receive timeouts value = 0 = 0x0 What's puzzling me is how things can get into this state - a message queued (according to msgQShow), AND a receiver task pending on the same queue (according to tt). If my application code is spawned at a priority lower than the interupt handling task, the problem goes away, but I'm still curious how this can happen. I've checked the return value from msgQSend to verify that the queue is not full. Any clues or debugging hints would be much appreciated. -Henning Henning Pangels |hmp@frc2.frc.ri.cmu.edu | Field Robotics Center Research Programmer|(412) 268-7088 |Carnegie-Mellon University ------------------------------------------------------------------------------ Just because I don't care doesn't mean I don't understand! -- Homer Simpson From votava@fndaue.fnal.gov Mon Nov 25 09:07:55 1991 From: votava@fndaue.fnal.gov (Margaret Votava) Date: Mon Nov 25 09:08:01 PST 1991 Subject: Reclaiming space from downloads Hi, Is it possible to reclaim space from loaded objects? During debugging the same objects are repeatedly loaded and memory is quickly exhausted. Windriver themselves do not yet provide an unloader. They believe that the user community has one available. Does anybody know where it is and how I can access it? I am sure this has been mentioned many times before, but we are new to vxworks and the exploder, so please bear with some of our novice questions/problems. ---- Margaret Votava votava@fnal.fnal.gov From rayssd!iss-ipc1.ssd.ray.com!fjr@uunet.uu.net Mon Nov 25 09:19:35 1991 From: fjr@iss-ipc1.ssd.ray.com Date: Mon Nov 25 09:19:43 PST 1991 Subject: Re: Anyone know thruput of backplane TCP/IP net? Scot, We have benchmarked backplane communication for two 25MHz Force cards. What we found is that backplane communication is about the same speed as ethernet communication except that ethernet communication is a little faster for small messages. Since this puts the throughput in the 100 Kbyte per second range it is clear that the backplane driver is no speed demon. It seems that everyone who needs high speed backplane communication writes their own communication routines. This came up at the last East Coast user's group meeting when almost everyone there indicated they had come up with their own mechanisms. The VxWorks stuff is meant to support non time critical communication (esp. things like debugging and development communication). BTW, the big reason backplane stuff is so slow is all the protocol processing required to conform to the different IP protocols. Hope that helps. Fred ______________________________________________________________ | Fred J Roeber, Raytheon Submarine Signal Division | | 1847 West Main Road, Mail Stop 188 | | Portsmouth, RI 02871-1087 (401) 847-8000 (X4205) | | | | {uiucdcs,uunet}!rayssd!sgfb.ssd.ray.com!fjr | |______________________________________________________________| From prb@aplexus.jhuapl.edu Mon Nov 25 10:42:49 1991 From: prb@aplexus.jhuapl.edu (Paul R. Bade) Date: Mon Nov 25 10:42:55 PST 1991 Subject: Re: Message Queues, Interrupts & Task Priorities Another Victim, Yes, you have encountered a little known bug in 5.0.2. Wind River has acknowledged that message Queues have a bug which appears when posting to them from an interrrupt service routine. They are currently working on a fix. It should be here soon. For now I have put a printf statement before pending on a message Queue. This changes the timing on my system such that the problem does not show its ugly head. Good Luck, Paul Bade Johns Hopkins University (301)-953-5000 x 8681 From omni!hwajin@apple.com Mon Nov 25 11:31:17 1991 From: hwajin@omni.com (Hwa-Jin Bae) Date: Mon Nov 25 11:31:25 PST 1991 Subject: Re: Anyone know thruput of backplane TCP/IP net? >We have benchmarked backplane communication for two 25MHz Force cards. >What we found is that backplane communication is about the same speed as >ethernet communication except that ethernet communication is a little >faster for small messages. Since this puts the throughput in the 100 Kbyte >per second range it is clear that the backplane driver is no speed demon. in vxworks 5.0 or later a significant optimization has been put into the backplane driver. backplane throughput is consistently better than ethernet throughput unless you're using an onboard lance with the optimized driver, in which case the throughput will be about the same -- limiting factor being the protocol implementation. backplane throughput also depends largely on the type of mutex you're using. there are three: mailbox, vme interrupt, and using TAS instruction. if both boards using the backplane can do mailbox or vme interrupts you should be able to see better throughput than using TAS to poll on shared memory. "your mileage may vary" seems to be proper here. *hwajin From jones@cs.buffalo.edu Mon Nov 25 12:49:35 1991 From: jones@cs.buffalo.edu (Terry A. Jones) Date: Mon Nov 25 12:49:42 PST 1991 Subject: Problems loading large object modules. We are having problems loading large object modules under VxWorks version 4.0.2 SPARC and were wondering if anyone else has experienced this same problem, or has a solution. We are able to load modules of say 512K bytes of initialized data without a hitch. The problem arises when we attempt to load a particular module that contains approximately 4.2Meg of initialized data. Attempting to load this module over the ethernet causes `netTask' to trash his stack, and I do not see an easy way to increase his stack size. Suggestions?? Terry Jones From srm%matrx@mcnc.org Mon Nov 25 13:23:57 1991 From: srm@matrx.matrix.com (Steve Morris) Date: Mon Nov 25 13:24:04 PST 1991 Subject: memory board, VSB part. slave I/F TO: memory board users and manufacturers I'm looking for a 6U VMEbus memory board with a VSB interface which can be either a responding or participating slave. Please email info to... Steve Morris || MATRIX Corp. || srm@matrix.com Thanks. From kent@wrs.com Mon Nov 25 14:18:37 1991 From: kent@wrs.com (Kent Long) Date: Mon Nov 25 14:18:44 PST 1991 Subject: 5.0 Message Queue Bug Hi, Folks - Sometimes I marvel at the way a problem can smolder silently for months (or in this case a full year) and then suddenly erupt in multiple places.... Henning Pangels (hmp@frc2.frc.ri.cmu.edu) writes: > I'm running into a strange deadlock situation involving a message queue. > > sometimes things get stuck in a situation where the high priority task never > gets the semaphore, because the interrupt handling task never gets the > corresponding message from the interrupt handler. However, I can ascertain > that the interrupt handler has fired, and in fact, a msgQShow indicates that > 1 message is queued at this point. At the same time, I can get a task trace > (tt) of the interrupt handling task, which shows it *pending* on the queue. > > What's puzzling me is how things can get into this state - a message queued > (according to msgQShow), AND a receiver task pending on the same queue > (according to tt). Henning has indeed uncovered a problem in VxWorks 5.0, 5.0.1, and 5.0.2 message queues. This bug was verified here at WRS just last week! We are currently in the process of preparing a patch for existing customers; that should be done in the next two weeks. I was quite struck to see Henning's report come in during the midst of all this, after the problem was lurking in the shadows for so long. Here is a somewhat more generic scenario of how the bug occurs: 1. A task does a msgQReceive() on a message queue. 2. There are no messages in the queue, so the task begins to pend (block). 3. At JUST THE WRONG MOMENT, an interrupt happens. The ISR which services that interrupt does a msgQSend() to put a message in the queue, because it didn't find any tasks pended on the queue (yet). 4. So, now the message is in the queue, but the task just goes ahead and blocks. We are now stuck, with a task waiting but with a message in the queue. 5. At this point, if another message is sent to the queue, or if another task does a msgQRecieve(), then things will get kicked loose, and all will appear normal. This is why we didn't catch this during the message queue testing we did for 5.0. (For example, we used the network to exercise message queues, but due to TCP/IP retries, etc. another interrupt would send another message and get things going again.) The fix for this problem involves strengthening the interlocking between steps 2 and 3, so that the message isn't added to the queue until the receiving task is fully blocked. (It will then unblock and receive the message normally.) This is obviously a serious bug, in that it involves a basic synchronization mechanism. Let me assure you, we in WRS Engineering are treating this as our highest priority. We have a fix for the problem which we have tested, and we are now working out the logistics of getting everybody updated. Existing customers (i.e. most Exploder readers) will get a patch tape which will include a script to automatically modify the involved library objects. Unless you use the bootroms in some non-standard manner (e.g. link your application with the roms directly), you may safely continue to use 5.0 or 5.0.2 or bootroms. (New bootroms will be sent upon request.) New customers (beginning in December) will get a revised version of 5.0.2, called "5.0.2b". This is simply 5.0.2 with the patch pre-applied. (I mention this only to re-assure 5.0.2 customers who will ultimately start hearing of the existence of 5.0.2b.) Versions of 5.0.2 which have been in Beta (e.g. for various non-Sun hosts or non-68k targets) will be version 5.0.2b (i.e. they will have the message queue bug fixed) in their final versions. Patches will not be distributed for the existing Beta versions. All 5.0[.X] customers will be getting a letter describing this bug and a set of alternatives to receive the fix. (It should be possible to email uuencoded versions of the objects and installation script, or WRS will send a tape containing the patch.) This is an important fix, so I strongly encourage all of you to install it as soon as it is available! To what extent it matters, we all feel very bad about a problem like this making it out to the field, and I promise we will do whatever is required to set things straight. Thanks for your understanding, - kent Kent Long Wind River Systems From muts@fysap.fys.ruu.nl Mon Nov 25 23:42:37 1991 From: muts@fysap.fys.ruu.nl (Peter Mutsaers) Date: Mon Nov 25 23:42:44 PST 1991 Subject: Anyone know thruput of backplane TCP/IP net? >>Op Mon, 25 Nov 91 09:19:48 PST Fred J Roeber wrote: > We have benchmarked backplane communication for two 25MHz Force cards. > What we found is that backplane communication is about the same speed as > ethernet communication except that ethernet communication is a little > faster for small messages. Since this puts the throughput in the 100 Kbyte > per second range it is clear that the backplane driver is no speed demon. > It seems that everyone who needs high speed backplane communication writes > their own communication routines. This came up at the last East Coast > user's group meeting when almost everyone there indicated they had come up > with their own mechanisms. The VxWorks stuff is meant to support non > time critical communication (esp. things like debugging and development > communication). BTW, the big reason backplane stuff is so slow is all the > protocol processing required to conform to the different IP protocols. > Hope that helps. Fred This surprises me; last week, Wind River systems presented a talk in the Netherlands to present VxWorks and to push into the Benelux market. Here some questions were asked about backplane speed. The reply of the person of Wind River Systems (I forgot his name) was that the TCP/IP protocol has some overhead, but that this is small as compared to the overhead and other things that are intrinsic to VME. Therefore, it was there filosophy to use the normal TCP/IP as this is more beautiful to have one way of communication everywhere, and the overhead of the protocol would be neglegible. Apparently this claim is not true. Peter Mutsaers From muts@fysap.fys.ruu.nl Mon Nov 25 23:47:48 1991 From: muts@fysap.fys.ruu.nl (Peter Mutsaers) Date: Mon Nov 25 23:47:55 PST 1991 Subject: Anyone know thruput of backplane TCP/IP net? Probably I reacted to soon concerning backplane speed, as later Hwa-Jin Bae supported the claim of wrs that backplane throuput is quite efficient when used with TCP/IP now. Peter Mutsaers From interf!atlas!tdirenzo@uunet.uu.net Tue Nov 26 05:12:37 1991 From: interf!atlas!tdirenzo@uunet.uu.net (Tony Di Renzo) Date: Tue Nov 26 05:12:43 PST 1991 Subject: Re: core analysis Please remove my name from the exploder mailing list, I will not be able to read my mail after the first of the year. From rayssd!iss-ipc1.ssd.ray.com!fjr@uunet.uu.net Tue Nov 26 07:22:37 1991 From: fjr@iss-ipc1.ssd.ray.com Date: Tue Nov 26 07:22:43 PST 1991 Subject: Re: Anyone know thruput of backplane TCP/IP net? Yesterday I wrote about our benchmarking of backplane throughput and compared it to the ethernet throughput. Hwajin Bae responded that in 5.0 and later the throughput is much better and that the backplane should be faster than ethernet unless one is using an on chip LANCE. A couple points from our measurement: - We are using version 5.0 with the throughput speedups. The overall throughput of either Ethernet or backplane is much higher than with the old releases. - We are comparing the backplane to ethernet using an on card ethernet chip so, as Hwajin mentions, are getting pretty high ethernet speeds. - We are using mailboxes, not polling, on the backplane (this is really the only way to go since the TAS polling hurts backplane performance a lot). I don't mean to take anything away from the WRS backplane driver or concept. It really is nice to be able to use a single consistent communication scheme to communicate between two tasks regardless of whether they are in the same processor, separated by a backplane, or separated by a network. The scheme works well and is fine if you can live with moderate throughput and somewhat higher CPU loading. The key here is that, as Hwajin also mentions, the limiting factor is the protocol processing. Lets not try to fool anyone; the TCP/IP or UDP/IP protocol processing associated with either the backplane or ethernet is not trivial. Each message to be sent is passed through dozens of subroutines, copied several times, partially checksummed at multiple levels and generally fiddled with quite a bit. All this work does take time. We are using a stripped down UDP version that skips a lot of the intermediate processing by making assumptions on how the message is to be handled and can get twice the throughput due to the elimination of much of the protocol processing. Our stripped down version is NOT a general solution and isn't meant to indicate that the WRS implementation is inefficient; their implementation is quite good. The issue is that backplane communication could be made a lot faster using a dedicated communication scheme. WRS had indicated that they are looking at/working on the concept of multiprocessor message queues and semaphores. These, when in place, will be noticeably faster than the backplane driver (we are still implemententing our version of these so don't know how much speedup is possible). This solution will lack one advantage of the TCP/IP based solution; the code will have to use a different mechanism to communicate over the backplane than over the network. Like most real time programming, there are tradeoffs. To get extra speed you have to sacrifice a little flexibility. From maf@verdix.com Tue Nov 26 07:36:07 1991 From: maf@verdix.com Date: Tue Nov 26 07:36:14 PST 1991 Subject: Re: Problems loading large object modules. > We are having problems loading large object modules under > VxWorks version 4.0.2 SPARC and were wondering if anyone else has > experienced this same problem, or has a solution. We are able to load > modules of say 512K bytes of initialized data without a hitch. The > problem arises when we attempt to load a particular module that contains > approximately 4.2Meg of initialized data. Attempting to load this module > over the ethernet causes `netTask' to trash his stack, and I do not see > an easy way to increase his stack size. Suggestions?? Try avoiding the net driver by using the NFS driver instead. You will need to define INCLUDE_NFS when you build your VxWorks image, and you will need to nfsMount the file system containing the load module if it is not the same as the one containing the VxWorks image: -> nfsMount "myhost", "/home/" Once the file system is mounted by your target, you can cd to the directory containing the load module. If you do a pwd, you should not see the host name at the beginning of the path (if you do, you will still be accessing the net driver). You can then load the file normally. For example: -> cd "/home/mylib" -> ld < big.o or alternatively: -> ld < /home/mylib/big.o Marc Friedman From owen@cod.nosc.mil Tue Nov 26 09:36:51 1991 From: owen@cod.nosc.mil (Wallace E. Owen) Date: Tue Nov 26 09:36:58 PST 1991 Subject: Re: Message Queues, Interrupts & Task Priorities ------- Please un-susscribe me. Wallace Owen owen@nosc.navy.mil or any reasonable facsimile thereof ------- From ricks@wrs.com Tue Nov 26 19:02:37 1991 From: ricks@wrs.com (Rick Sustek) Date: Tue Nov 26 19:02:44 PST 1991 Subject: Re: backplane driver Just some more spewage on the subject... The poor backplane driver and interprocessor comm situation is as it is for a number of reasons. The capability of having stock TCP/IP capabilties between CPUs in a cage as well as to an "outside" network is a wonderfull feature. It is vital to the simplicity of booting each board in the cage. It is also an integral part of what makes VxWorks VxWorks, i.e., a runtime AND development environment. Remote debugging, remote login, all that... It was necessary to focus on an "IP style" backplane driver just to deliver a useable product! Once all the boards are booted however, many applications require a simple, high speed means of sending data between them. The socket level interface is just plain overkill and cannot provide the throughput required by many applications. So we have basically left you to "roll your own" mechanism. This is not necessarily an evil thing to do, since many of these mechanisms are fairly simple to design and implement. It is also difficult for us to provide a "one size fits all" mechanism. Even if we provided an alternative to the existing bp driver, a certain percentage of you would still "roll your own", due to some specific needs. (From working in the pSOS world, I know of at least two companies that could not get what they wanted from the SCG multiprocessor comm module). Ah but these are only lame excuses... One obvious answer to the problem is to use the bp driver directly from your code. Unfortunately, this has faults as well. First, the bp driver is written in the style of BSD UNIX network interface code. This style was not designed to be accessable to the user, and hence provides only a complex method of tapping into the driver. The triad of etherOutputHook(), etherInputHook(), and etherOutput() provide a little more leverage, but these are a kludge at best. Secondly, and very important, is the fact that the bp driver will throw away data it is asked to send if there are no shared memory buffers available. This shoots the idea of reliabilty right in the foot! So, to answer your question about backplane driver throughput: "Less than glorious!" We are aware of the issues, and are working towards a better solution for you. So keep those cards and letters coming! (on second thought...) Rick From psm%helios.nosc.mil@nosc.mil Wed Nov 27 09:18:06 1991 From: psm%helios.nosc.mil@nosc.mil Date: Wed Nov 27 09:18:13 PST 1991 Subject: Re:: backplane driver > Submitted-by ricks@wrs.com Tue Nov 26 19:02:37 1991 > Submitted-by: ricks@wrs.com (Rick Sustek) > > Just some more spewage on the subject... > > [useful stuff omitted] > > So, to answer your question about backplane driver throughput: > "Less than glorious!" > > We are aware of the issues, and are working towards a better solution for > you. So keep those cards and letters coming! (on second thought...) Too late! Is there a databank maintained by WRS or anyone else containing drivers or techniques that others have employed in the past to speed up data transfers across the backplane? Even those that bypassed TCP/IP would be of interest. From sjk@emerald.labs.tek.com Wed Nov 27 11:28:17 1991 From: sjk@emerald.labs.tek.com (503) Date: Wed Nov 27 11:28:24 PST 1991 Subject: Re: : backplane driver Regarding your message: > Too late! Is there a databank maintained by WRS or anyone else > containing drivers or techniques that others have employed in the > past to speed up data transfers across the backplane? Even those that > bypassed TCP/IP would be of interest. A company called Aptec Computer Systems has a library of routines they call mpLib. What they did was the semLib, partLib, nameLib, msgQLib functionality across the backplane of their system. They did a presentation at the VxWorks Users Group last spring, and it looks real good. It is MUCH faster than the backplane drivers + TCP/IP (semaphore give/ take between processors @ 150 uSec using two 25Mhz 68020 w/5 wait- state memory processors on a 200 Mb/sec backplane bus). Simple low-level command port send/receive is under 100 uSec at this point. Running with a faster processor and faster memory would significantly improve these timings, since very little shared memory access takes place. The only catch is they are still trying to figure out how to sell it to outside interests (they bundle it with their hardware/software at this time). If you are interested in exploring the possibilities with them, contact Gerry Feldkamp at (503) 626-9000. They don't have easy access to e-mail. Steven ---------------------------------------------------------------------- e-mail: sjk@crl.labs.tek.com Steven King phone: 503-627-2736 Computer Research Lab, Tektronix, Inc. voice mail: 503-727-6651 P.O. Box 500 MS 50-662 fax: 503-627-5502 Beaverton, OR 97077 ---------------------------------------------------------------------- From omni!hwajin@apple.com Wed Nov 27 14:28:19 1991 From: hwajin@omni.com (Hwa-Jin Bae) Date: Wed Nov 27 14:28:26 PST 1991 Subject: Re:: backplane driver hi, >> We are aware of the issues, and are working towards a better solution for >> you. So keep those cards and letters coming! (on second thought...) > >Too late! Is there a databank maintained by WRS or anyone else >containing drivers or techniques that others have employed in the >past to speed up data transfers across the backplane? Even those that >bypassed TCP/IP would be of interest. rick made some helpful comments about the etherHook facilities. i think a lot of people use it to get direct access to the network interface drivers. but i don't think there is a comprehensive databank for various techniques (i may be wrong; i am frequently). in the spirit of being helpful, here are some of the techniques: 1. etherLib stuff: the man page for etherLib is better in 5.0. i know that etherLib stuff has been used by a lot of users because i used to answer a lot of questions while i worked for wrs. i ended up putting in more information about how to use the etherLib routines (which was not explained quite well in the old manual pages), and added a routine that will perform ARP (since etherOutput takes ethernet address, not internet address). it is a "kludge" as rick mentions, but considering the amount of work that went into the whole thing, it has proven to be extremely useful. i wasn't involved in etherLib design initially and i considered it rather "hacky" at the time -- but again useful! some of the problems: 1) non-symmetric overhead: because the network interface drivers are BSD based, etherOutput() has to copy data into mbufs before passing to the drivers. with a bit of additional work to the drivers this overhead can be eliminated. note that the ether input hook routines get called before data is copied into mbufs, thus avoiding this overhead. 2) inconsistency: not all ethernet devices support etherLib facilities while a non-ethernet device (such as backplane) supports it. etherLib is a bit of misnomer in this sense. 3) side effects: a hook routine, once added, affects all network interfaces that are capable of etherLib support. this is unfortunate because one doesn't necessarily need the overhead of packets from all network interfaces being delivered to a hook routine. the global function pointers etherInputHookRtn and etherOutputHookRtn should not be global -- they should instead be specific to a given instantiation of a particular network interface driver. 3) lacks filtering: to do the data link I/O efficiently the constant overhead of calling hook routines should be avoided. unix based solutions such as sunos "nit" or berkeley "packet filter" provide ways to minimize the overhead for "uninteresting" traffic by filtering and selectively forwarding packets of certain types to the users. 4) lacks buffering: in some cases, buffering lots of small, fragmented pieces of data on either side of the user interface is helpful. this should be optional as it can be undesirable in other cases. 5) no error checking: etherLib trusts ethernet crc; for backplane, it hopes that memory copy happens without error. this is perhaps a reasonable assumption, but doesn't work for something like slip (no checksum of any kind). this is perhaps where people disagree the most. there isn't much work done at the link-level driver level if the packet can't be delivered to the device due to lack of buffers, etc. (as rick mentions). but the higher level users (or protocols) should handle that. doing the management of errors such as this bloats code/overhead for each of the drivers, the job that should be done outside the realm of the drivers in more general and widely applicable way. error checking (mainly for statistical purpose and rejecting incorrect data) that is necessary and specific to a particular type of link device should be done in the driver; other types of error checking/handling/recovery should be done in some other shared code space. 2. low level rpc: at wrs an architect designed and i subsequently implemented a quick prototype rpc style interface to the network drivers. it worked for what it was worth but we concluded that it needed much work. many people have done this sort of thing before: sprite rpc, stanford v rpc, amoeba rpc -- these all can work directly on network drivers, bypassing tcp/ip overhead. if you're really serious about "doing it right", you should be reading papers and code for these systems. 3. vendor specific solutions: some vme vendors have put in hardware support for sending and/or multi-casting messages over vme. when used with mailboxes, they are fast, but perhaps not as flexible or portable as one would like. common problem with this approach has to do with limited/fixed data format/space allowed. but with some careful device specific coding and tuning, you can get your hardware to perform well. 4. raw sockets: sockets have a significant overhead (especially in original unix implementations), but with some extra careful coding, you can bypass a lot of overhead. if you want to maintain code portability at the socket level and still want to get some sort of efficiency, you can use raw sockets to the IP level, and as deemed necessary, disable routing, disable fragmentation, and doing arp. i know some have done this -- pretty desperate, true, but it works. in realtime world, where each application has distinct and varied need in terms of hardware support, performance, portability, code size, and complexity, it's hard for one vendor to keep everyone happy. the best perhaps one can do is to try to be helpful, which i think wrs does. i'm no longer with wind river, but still think they do a decent job ;-) hwa-jin bae interphase 4699 old ironsides dr., suite 400, santa clara, california 95054 e-mail: hwajin@omni.com phone: (408)982-9090 fax: (408)982-9904 From thor@thor.atd.ucar.edu Sat Nov 30 22:59:55 1991 From: thor@thor.atd.ucar.edu (Richard Neitzel) Date: Sat Nov 30 23:00:06 PST 1991 Subject: Monthly VxWorks archive posting This is the monthly posting showing the current holdings in the VxWorks Software Archive. To get more detailed infomation send email to: vxworks_archive@ncar.ucar.edu The message body must read: send index send index from vx send index from unix ------------------------------------------------ VxWorks sources: total 1561 -rw-r--r-- 1 thor 2070 Sep 23 10:48 README -rw-r--r-- 1 thor 22132 Jun 18 1990 ansi.p1 -rw-r--r-- 1 thor 22717 Jun 18 1990 ansi.p2 -rw-r--r-- 1 thor 24174 Jun 18 1990 ansi.p3 -rw-r--r-- 1 thor 8108 Jun 18 1990 ansi.patch1 -rw-r--r-- 1 thor 2671 Jan 2 1990 benchmarks -rw-r--r-- 1 thor 7168 Jul 13 1989 bitcnt -rw-r--r-- 1 thor 11437 Feb 15 1991 c++builtin.shar -rw-r--r-- 1 thor 22330 Apr 4 1990 c++headers.p1 -rw-r--r-- 1 thor 22775 Apr 4 1990 c++headers.p2 -rw-r--r-- 1 thor 29052 Dec 6 1989 camaclib1 -rw-r--r-- 1 thor 25095 Dec 6 1989 camaclib2 -rw-r--r-- 1 thor 31005 Dec 6 1989 camaclib3 -rw-r--r-- 1 thor 37770 Dec 21 1989 cbench.shar -rw-r--r-- 1 thor 7371 Jun 15 1990 cntsem_class.shar -rw-r--r-- 1 thor 5853 May 31 1989 crc.shar -rw-r--r-- 1 thor 8917 Oct 9 1990 deadman.shar -rw-r--r-- 1 thor 25681 Aug 29 1989 dt1451 -rw-r--r-- 1 thor 5944 Apr 26 1989 fcompress.shar -rw-r--r-- 1 thor 11561 Nov 1 12:12 flags_class.shar -rw-r--r-- 1 thor 44762 Jul 18 1990 force.p1 -rw-r--r-- 1 thor 40154 Jul 18 1990 force.p2 -rw-r--r-- 1 thor 80491 May 8 1989 force.shar -rw-r--r-- 1 thor 6106 Oct 10 1989 getdate -rw-r--r-- 1 thor 9774 Nov 2 1990 hkv30extintutil.shar -rw-r--r-- 1 thor 8612 Nov 22 14:08 index -rw-r--r-- 1 thor 2694 Oct 9 1990 ivecalloc.shar -rw-r--r-- 1 thor 27824 May 30 1989 jobCondLib -rw-r--r-- 1 thor 25014 May 30 1989 jobLib lrwxrwxrwx 1 root 10 Aug 14 07:11 jobcondlib -> jobCondLib lrwxrwxrwx 1 root 6 Aug 14 07:11 joblib -> jobLib -rw-r--r-- 1 thor 35245 Oct 9 1990 joblib2.p1 -rw-r--r-- 1 thor 18110 Oct 9 1990 joblib2.p2 -rw-r--r-- 1 thor 9079 Apr 2 1990 lclflag.shar drwxr-xr-x 2 thor 512 Oct 31 1990 libX11 lrwxrwxrwx 1 root 6 Aug 14 07:11 libx11 -> libX11 -rw-r--r-- 1 thor 25077 Oct 9 1990 loadmeter.shar -rw-r--r-- 1 thor 10399 May 4 1989 math.shar -rw-r--r-- 1 thor 11950 May 30 1989 math2 -rw-r--r-- 1 ftp 26655 Nov 15 1990 monitor.shar -rw-r--r-- 1 thor 18733 Jun 14 1990 msgque_class.shar -rw-r--r-- 1 thor 55175 Oct 21 09:11 ntpvx01 -rw-r--r-- 1 thor 55174 Oct 21 09:11 ntpvx02 -rw-r--r-- 1 thor 50076 Oct 21 09:11 ntpvx03 -rw-r--r-- 1 thor 39603 Oct 21 09:11 ntpvx04 -rw-r--r-- 1 thor 28719 Oct 21 09:11 ntpvx05 -rw-r--r-- 1 thor 32494 Oct 21 09:11 ntpvx06 -rw-r--r-- 1 thor 37097 Oct 21 09:11 ntpvx07 -rw-r--r-- 1 thor 41621 Oct 21 09:11 ntpvx08 -rw-r--r-- 1 thor 20494 Oct 31 12:06 pipe.shar -rw-r--r-- 1 thor 15418 May 30 1989 poolLib lrwxrwxrwx 1 root 7 Aug 14 07:11 poollib -> poolLib -rw-r--r-- 1 thor 13204 Oct 31 08:19 ring.shar -rw-r--r-- 1 thor 6614 May 31 1989 semCnt lrwxrwxrwx 1 root 6 Aug 14 07:11 semcnt -> semCnt -rw-r--r-- 1 thor 2308 Jan 2 1990 ss1.bnch -rw-r--r-- 1 thor 16225 Oct 10 1989 string.shar -rw-r--r-- 1 thor 15096 Oct 2 08:55 task_class.shar -rw-r--r-- 1 thor 16171 Oct 9 1990 taskmon.shar -rw-r--r-- 1 thor 10523 May 31 1989 tod.shar -rw-r--r-- 1 thor 25790 Nov 8 1990 ty335.shar -rw-r--r-- 1 thor 25814 Apr 26 1989 vtape.shar -rw-r--r-- 1 thor 43671 Nov 22 14:05 vwcurses01 -rw-r--r-- 1 thor 40180 Nov 22 14:05 vwcurses02 -rw-r--r-- 1 thor 38308 Nov 22 14:05 vwcurses03 -rw-r--r-- 1 thor 31181 Nov 22 14:05 vwcurses04 -rw-r--r-- 1 thor 31798 Nov 22 14:05 vwcurses05 -rw-r--r-- 1 thor 31459 Nov 22 14:05 vwcurses06 -rw-r--r-- 1 thor 24279 Nov 22 14:05 vwcurses07 -rw-r--r-- 1 thor 29720 Aug 28 14:10 vxrsh.p1 -rw-r--r-- 1 thor 26002 Aug 28 14:10 vxrsh.p2 -rw-r--r-- 1 thor 13713 Aug 28 14:10 vxrsh.p3 -rw-r--r-- 1 thor 4106 Nov 22 14:08 xxx Unix sources: total 82 -rw-r--r-- 1 thor 1192 Mar 13 1990 index drwxr-xr-x 2 thor 512 Oct 26 1989 patch -r--r--r-- 1 thor 11744 Apr 11 1989 shar.shar -rw-r--r-- 1 thor 19698 Nov 15 1989 vxtool -rw-r--r-- 1 thor 21934 Jan 31 1990 vxview -rw-r--r-- 1 thor 14151 Feb 9 1990 vxview.patch -r--r--r-- 1 thor 9869 Feb 1 1989 xc.shar drwxr-xr-x 2 thor 512 Feb 11 1990 xdbx Richard Neitzel thor@thor.atd.ucar.edu Torren med sitt skjegg National Center For Atmospheric Research lokkar borni under sole-vegg Box 3000 Boulder, CO 80307-3000 Gjo'i med sitt shinn 303-497-2057 jagar borni inn.