From rem-conf-request@es.net Mon Jan 03 12:58:53 1994 Received: from Sun.COM by osi-east.es.net via ESnet SMTP service id <13108-0@osi-east.es.net>; Mon, 3 Jan 1994 09:50:22 +0000 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA09852; Mon, 3 Jan 94 09:50:16 PST Received: from rebma.noname by Eng.Sun.COM (4.1/SMI-4.1) id AA12686; Mon, 3 Jan 94 09:48:33 PST Received: by rebma.noname (4.1/SMI-4.1) id AA00400; Mon, 3 Jan 94 09:50:17 PST Date: Mon, 3 Jan 94 09:50:17 PST From: hoffman@rebma.Eng.Sun.COM (Don Hoffman) Message-Id: <9401031750.AA00400@rebma.noname> To: rem-conf@es.net Subject: Advance notice of MBONE multicast : Sunergy Broadcast - Global Information Infrastructures Reply-To: Don.Hoffman@Eng.Sun.COM We will be relaying the broacast described below on to MBONE on 1/11, 8:30am-10:00am PST. Please let me know if this will conflict with other uses of MBONE at that time. Also, we are evaluating the feasibility and mechanisms for allowing questions to the interviewees from MBONE, in addition to the usual phoned-in and email questions. More details will be sent closer to air-time. This program will also be available on satellite transponder. Please let me know if you are intereted in accessing the broadcast via satellite. To anticipate the question, the content of this program is vendor-neutral, and Sun products will not be discussed. Thanks, Don Hoffman email - hoffman@sun.com, phone - +415-336-4339, fax - +415-336-6035 ----- Begin Included Message ----- SUNERGY - LIVE INTERACTIVE SATELLITE BROADCAST #8 January 11, 1994 8:30 - 10:00 am (PST) "Global Information Infrastructures" In the last Sunergy broadcast the topic of the Internet was discussed. During that program we took a look at some of the ways that the Internet acts as both supplier and retriever of information, internationally. We also discussed US government policy and security issues. Sunergy #8 will take an even *closer* look into the building of a global information highway. Topics/issues covered will include: - Interoperability and standards - What critical factors stand in the way (or are yet to be resolved)? - How will the building of an NII (National Information Infrastructure) in the United States affect the rest of the world? - What are the "real world" uses of an information highway? - What will be the "look" of this highway? Guests: John Gage (HOST) - Director of the Science Office, Sun Microsystems Vinton Cerf - Vice President, Corporation for National Research Initiatives President, Internet Society Dr. Eric Schmidt - President, Sun Technology Enterprises Geoffrey Baehr - Chief Technical Officer, SunConnect If you have satellite receive capabilities and would like the satellite coordinates email the Sunergy Office at sunergy@sun.com. Also, include any specific topics or issues you would like to see covered in this broadcast. ########################## GUEST BIOGRAPHIES ######################## Dr. Eric E. Schmidt - President, Sun Technology Enterprises, Inc. Corporate Executive Officer, Sun Microsystems, Inc. Dr. Schmidt heads a subsidiary of Sun Microsystems, Inc. that includes several independent business units. Sun Technology Enterprises Inc. is made up of SunConnect, which handles network connectivity and network management products; SunPics, for printing and imaging products; SunPro, for software developer tools; SunSelect, for products that integrate UNIX with personal computers; and SunSolutions, for distributed workgroup applications. Dr. Schmidt joined Sun in June 1983 as manager of software and moved to director of software engineering before his appointment as vice president and general manager of the Software Products Division in May 1985. He was promoted to vice president of the General Systems Group in May 1988 and assumed his current position in February 1991. Prior to joining Sun, Dr. Schmidt was a member of the research staff at the Computer Science Lab at Xerox Palo Alto Research Center (PARC), where he developed release tools for the Cedar programming environment project. He also held positions at Bell Laboratories and Zilog. Dr. Schmidt has a B.S. in electrical engineering from Princeton University, and an M.S. in electrical engineering and a Ph.D. in computer science from the University of California at Berkeley. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ VINTON G. CERF is currently Vice President of the Corporation for National Research Initiatives, where he has managed the Digital Library, Electronic Mail, and Internet research programs since 1986. From 1982 to 1986, Dr. Cerf worked at MCI Communications, where he developed MCI Mail. He worked at the Defense Advanced Research Projects Agency from 1976 to 1982, where he led the packet communications, internetting and security efforts and served as principal scientist in the Information Processing Techniques Office. At Stanford University, from 1972 to 1976, he taught electrical engineering and computer science, and coinvented the TCP/IP protocol suite. At UCLA, from 1967 to 1972, he managed the Network Measurement Center and helped develop the host protocols for the ARPANET. At IBM he performed systems engineering on the QUIKTRAN time-sharing system. Dr. Cerf is a member of the Association for Computing Machinery (ACM), and has served as chairman of LA-SIGART (1968), chairman of SIGCOMM (1987-1991), and a member of the ACM Council (1991-1992). He was elected a Fellow of the IEEE in 1988, and received the Koji Kobayashi Award in 1992. Dr. Cerf served as a member of the Internet Architecture Board from 1986 to 1989, and as its chairman from 1989 to 1992. He is a coorganizer of the Internet Society, and was elected its president in 1992. Dr. Cerf has served on numerous national and international committees and commissions, technical advisory boards and boards of charitable organizations. With his wife, Sigrid, he works on a Shakespeare video-captioning project, and in his copious spare time enjoys science fiction, gourmet cooking, and the collection and consumption of fine wines. Dr. Cerf received a BS in Mathematics in 1965 from Stanford University, and his MS (1970) and PhD (1972) in Computer Science from UCLA. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ John Gage Director, Science Office Sun Microsystems Computer Corporation John Gage works for Bill Joy, the Chief Technical Officer of Sun, and is responsible for Sun's relationships with the world scientific and public policy communities, international scientific institutions and groups developing new forms of scientific research involving computing. He is on scientific and advisory panels of the United States National Science Foundation, the US Congress Office of Technology Assessment, the European Institute of Technology and the United States National Academy of Sciences. He has recently been appointed to the US National Research Council Mathematical Sciences Education Board. He is a member of ACM, IEEE, SIAM, AMS, AAAS, and SMPTE. He attended the Harvard Business School and the Harvard Graduate School of Public Policy. He did doctoral work in economics and mathematics at the University of Berkeley at the same time as Bill Joy. Gage subsequently left Berkeley with Joy to start Sun in 1982. Gage is on the Board of Directors of Unicode, an industry consortium of IBM, Microsoft, Apple, Novell, Sun, GO Corporation, and others to provide multilingual capability in all world scripts for all documents and applications. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Geoffrey Baehr - Chief Technical Officer, SunConnect (Biography to be added in next announcement) ----- End Included Message ----- From rem-conf-request@es.net Mon Jan 03 15:27:57 1994 Received: from taurus.cs.nps.navy.mil by osi-east.es.net via ESnet SMTP service id <15461-0@osi-east.es.net>; Mon, 3 Jan 1994 12:22:12 +0000 Received: by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA12076; Mon, 3 Jan 94 12:23:25 PST Date: Mon, 3 Jan 94 12:23:25 PST From: brutzman@cs.nps.navy.mil (Don Brutzman) Message-Id: <9401032023.AA12076@taurus.cs.nps.navy.mil> To: rem-conf@es.net, sigkids.s94@siggraph.org Subject: MBONE use at SIGGRAPH 24-29 July I am interested in broadcasting from SIGGRAPH 94 in Orlando next July. If anyone else is planning to broadcast during this time, please contact me so that we can discuss network access and bandwidth considerations. regards, Don Donald P. Brutzman LCDR USN work (408) 656-2149 Code OR/Br Naval Postgraduate School [Glasgow 204] fax (408) 656-2595 Monterey California 93943-5000 USA home (408) 372-0190 From rem-conf-request@es.net Tue Jan 04 16:28:18 1994 Received: from zephyr.isi.edu by osi-east.es.net via ESnet SMTP service id <00895-0@osi-east.es.net>; Tue, 4 Jan 1994 13:22:12 +0000 Received: by zephyr.isi.edu (5.65c/5.61+local-16) id ; Tue, 4 Jan 1994 13:22:10 -0800 Date: Tue, 4 Jan 1994 13:22:10 -0800 From: postel@ISI.EDU (Jon Postel) Message-Id: <199401042122.AA14323@zephyr.isi.edu> To: rem-conf@es.net Subject: A once in a 1000 lifetime event ----- Begin Included Message ----- >From vcerf@cnri.reston.va.us Tue Jan 4 13:12:04 1994 X-Sender: farber@linc.cis.upenn.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 4 Jan 1994 16:07:01 -0500 To: isoc-trustees@CNRI.Reston.VA.US Sender: vint cerf From: David Farber Subject: A once in a 1000 lifetime event Cc: Manny Farber On or about July 21 1994, comet Shoemaker-Levy 9 is doomed to collide with Jupiter. The Planetary Society is planning to set up a world wide "network" of observers so that some telescope is always pointed at Jupiter. Also they hope to provide TV links to classrooms, auditoriums and TV stations so that those without telescopes can watch the collisions as they happen. (the comet is a set of rocks the largest thoughtb to be 1 and 1/2 miles. How about the Internet also provide images to schools, people etc at a rate and quality depending on their connection. It could be a major both PR event for the Net as well as a real chance to motivate high quality video and still in real time with expert commentary. Any interest, Maybe we could get Gore to watch on his workstation Dave ----- End Included Message ----- From rem-conf-request@es.net Tue Jan 04 18:05:43 1994 Received: from darpa.mil by osi-east.es.net via ESnet SMTP service id <01739-0@osi-east.es.net>; Tue, 4 Jan 1994 14:59:07 +0000 Received: from [192.48.218.153] (next153.darpa.mil) by vax.darpa.mil (5.65c/5.61+local-5) id ; Tue, 4 Jan 1994 17:57:19 -0500 Date: Tue, 4 Jan 1994 17:57:19 -0500 Message-Id: <199401042257.AA26489@vax.darpa.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: postel@ISI.EDU (Jon Postel), rem-conf@es.net From: tkalil@ARPA.MIL (Thomas A. Kalil) Subject: Re: A once in a 1000 lifetime event At 1:22 PM 1/4/94 -0800, Jon Postel wrote: >----- Begin Included Message ----- > >>From vcerf@cnri.reston.va.us Tue Jan 4 13:12:04 1994 >X-Sender: farber@linc.cis.upenn.edu >Mime-Version: 1.0 >Content-Type: text/plain; charset="us-ascii" >Date: Tue, 4 Jan 1994 16:07:01 -0500 >To: isoc-trustees@CNRI.Reston.VA.US >Sender: vint cerf >From: David Farber >Subject: A once in a 1000 lifetime event >Cc: Manny Farber > >On or about July 21 1994, comet Shoemaker-Levy 9 is doomed to collide with >Jupiter. The Planetary Society is planning to set up a world wide "network" >of observers so that some telescope is always pointed at Jupiter. Also they >hope to provide TV links to classrooms, auditoriums and TV stations so that >those without telescopes can watch the collisions as they happen. (the >comet is a set of rocks the largest thoughtb to be 1 and 1/2 miles. > >How about the Internet also provide images to schools, people etc at a rate >and quality depending on their connection. It could be a major both PR >event for the Net as well as a real chance to motivate high quality video >and still in real time with expert commentary. > >Any interest, > >Maybe we could get Gore to watch on his workstation > >Dave > > > > >----- End Included Message ----- Why not -- all we need to do is get him a T1 line. :-) **************************************************************************** Thomas Kalil "The NII - just do it!" tkalil@arpa.mil National Economic Council The White House Washington DC 20500 (p) 202-456-2801 (f) 202-456-2223 "Your taxpayer dollars at work." **************************************************************************** From rem-conf-request@es.net Fri Jan 07 11:03:49 1994 Received: from chile.concert.net by osi-east.es.net via ESnet SMTP service id <16906-0@osi-east.es.net>; Fri, 7 Jan 1994 08:03:07 +0000 Received: by chile.concert.net (5.65/tas-concert/aug93) id AA12321; Fri, 7 Jan 94 11:03:05 -0500 Date: Fri, 7 Jan 94 11:03:05 -0500 From: Tim Seaver Message-Id: <9401071603.AA12321@chile.concert.net> To: rem-conf@es.net Subject: Telecon XIII feedback I'd like to get feedback from anyone who watched the Telecon XIII Video Update multicast Wed. If you saw part of the program and have any comments on the quality of the multicast or the program content, I'd appreciate hearing from you via email. Also, the producers of the program, Applied Business TeleCommunications (ABC), would like to put out a press release about the multicast. If you have comments you'd not mind being published, you can contact Dave Boomstein of ABC directly at 205 880 3790. He'd like to have any responses ASAP. Thanks, Tim Seaver MCNC - CONCERT Network From rem-conf-request@es.net Mon Jan 10 04:39:03 1994 Received: from sally.Informatik.RWTH-Aachen.DE by osi-east.es.net via ESnet SMTP service id <11228-0@osi-east.es.net>; Mon, 10 Jan 1994 01:37:58 +0000 Received: from urmel.informatik.rwth-aachen.de by sally.informatik.rwth-aachen.de (4.1/sally-2) id AA24794; Mon, 10 Jan 94 10:36:26 +0100 Received: from tom.informatik.rwth-aachen.de by urmel.informatik.rwth-aachen.de (4.1/urmel-13) id AA06921; Mon, 10 Jan 94 10:36:25 +0100 Received: From IKARUS/WORKQUEUE by tom.informatik.rwth-aachen.de via Charon-4.0A-VROOM with IPX id 100.940110103611.448; 10 Jan 94 10:35:24 -0100 Message-Id: To: rem-conf@es.net From: Oliver Hermanns Organization: Informatik IV * RWTH Aachen Date: 10 Jan 1994 10:36:58 MEZ-1 Subject: IP-Multicast and XTP compatibility? Reply-To: oli@i4.informatik.rwth-aachen.de Priority: normal X-Mailer: Pegasus Mail/Mac v2.02 Hi folks. Sorry, this might be a faq (bud I didn't find any hint on this topic in the MBONE faq document). I would like to install Steve Deerings IP multicast package on our SUN Sparc 2 machines. These are running under SUNOS 4.1.2. and have the XTP (Xpress Transfer Protocol) Kernel extensions Vers. 1.7.2 installed. The XTP kernel extensions do not impose changes to TCP or IP systems object files. But there are some changes in the socket interface (so that user applications are able to select the desired transport protocol). The IP extensions also change the socket interface, so I am not so sure, if these extensions collide. My request: Who has made any experiences with the joint installation of both extensions? Do they run in parallel? Are there some side effects? What has to be changed? ....? Any help appreciated, Oliver = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - Oliver Hermanns, Technical University of Aachen, Dpt. of Computer Science IV Ahornstrasse 55, D-52074 Aachen, Germany Tel.: +49-241-80-4571, Fax: +49-241-80-21429 E-mail: oli@informatik.rwth-aachen.de = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - From rem-conf-request@es.net Mon Jan 10 07:18:39 1994 Received: from bells.cs.ucl.ac.uk by osi-east.es.net via ESnet SMTP service id <12110-0@osi-east.es.net>; Mon, 10 Jan 1994 04:06:57 +0000 Received: from rover.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 10 Jan 1994 12:06:48 +0000 To: rem-conf@es.net Subject: NV for tcl7.3 (tk 3.6) Date: Mon, 10 Jan 94 12:06:48 +0000 From: Gordon Joly Are there any sources? At ftp.parc.xerox.com Ta Gordon Joly Phone +44 71 380 7777 3703 FAX +44 71 387 1397 Email: G.Joly@cs.ucl.ac.uk UUCP: ...!{uunet,uknet}!ucl-cs!G.Joly Comp Sci, University College London, Gower Street, LONDON WC1E 6BT WWW:- http://www.cs.ucl.ac.uk/mice/gjoly.html -:WWW From rem-conf-request@es.net Mon Jan 10 12:50:57 1994 Received: from Sun.COM by osi-east.es.net via ESnet SMTP service id <14810-0@osi-east.es.net>; Mon, 10 Jan 1994 09:24:32 +0000 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA08634; Mon, 10 Jan 94 09:24:30 PST Received: from amber.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA08646; Mon, 10 Jan 94 09:22:44 PST Received: by amber.Eng.Sun.COM (5.0/SMI-SVR4) id AA00462; Mon, 10 Jan 1994 09:23:07 +0800 Date: Mon, 10 Jan 1994 09:23:07 +0800 From: Don.Hoffman@Eng.Sun.COM (Don Hoffman) Message-Id: <9401101723.AA00462@amber.Eng.Sun.COM> To: rem-conf@es.net Subject: Reminder: SUNERGY - LIVE INTERACTIVE SATELLITE BROADCAST #8 X-Sun-Charset: US-ASCII Content-Length: 7973 The following will be broadcast on the MBONE 1/11/94 from 8:30 - 10:00 am (PST). The sd conference name will be "Sunergy Broadcast #8" This program will also be available world-wide on satellite transponder. Please let me know if you are intereted in accessing the broadcast via satellite. Thanks, Don Hoffman email - hoffman@sun.com, phone - +415-336-4339, fax - +415-336-6035 ----- Begin Included Message ----- ///////////////////////// FINAL ANNOUNCEMENT \\\\\\\\\\\\\\\\\\\\\\\ SUNERGY - LIVE INTERACTIVE SATELLITE BROADCAST #8 January 11, 1994 8:30 - 10:00 am (PST) "Global Information Infrastructures" In the last Sunergy broadcast the topic of the Internet was discussed. During that program we took a look at some of the ways that the Internet acts as both supplier and retriever of information, internationally. We also discussed US government policy and security issues. Sunergy #8 will take an even *closer* look into the building of a global information highway. Topics/issues covered will include: - Interoperability and standards issues - What critical factors stand in the way (or are yet to be resolved)? - How will the building of an NII (National Information Infrastructure) in the United States affect the rest of the world? - What will this highway look like? Demonstrations: - Mosaic on the Internet - Vertical blanking interval. During the broadcast we will be send closed captioning (of the whole show), postscript files and teletext out via the vertical blanking interval. We will show how a "vertical interval decoder" can be used to receive this data on a workstation.* - Broadcast to the MBONE. This program will be broadcast over the Multicast Backbone. We will show the "non-MBONE" audience how this appears on the workstation * ANYONE WITH CAPTIONING DECODER EQUIPMENT CAN ALSO RECEIVE THIS SIGNAL AS A REGULAR CAPTIONED TELEVISION BROADCAST Guests: John Gage (HOST) - john.gage@sun.com - Director of the Science Office, Sun Microsystems Vinton Cerf - vcerf@CNRI.Reston.VA.US - Vice President, Corporation for National Research Initiatives President, Internet Society Dr. Eric Schmidt - eric.schmidt@sun.com - President, Sun Technology Enterprises Geoffrey Baehr - geoffrey.baehr@sun.com - Chief Technical Officer, SunConnect If you have satellite receive capabilities and would like the satellite coordinates email the Sunergy Office at sunergy@sun.com. Also, include any specific topics or issues you would like to see covered in this broadcast. ########################## GUEST BIOGRAPHIES ######################## Dr. Eric E. Schmidt - President, Sun Technology Enterprises, Inc. Corporate Executive Officer, Sun Microsystems, Inc. Dr. Schmidt heads a subsidiary of Sun Microsystems, Inc. that includes several independent business units. Sun Technology Enterprises Inc. is made up of SunConnect, which handles network connectivity and network management products; SunPics, for printing and imaging products; SunPro, for software developer tools; SunSelect, for products that integrate UNIX with personal computers; and SunSolutions, for distributed workgroup applications. Dr. Schmidt joined Sun in June 1983 as manager of software and moved to director of software engineering before his appointment as vice president and general manager of the Software Products Division in May 1985. He was promoted to vice president of the General Systems Group in May 1988 and assumed his current position in February 1991. Prior to joining Sun, Dr. Schmidt was a member of the research staff at the Computer Science Lab at Xerox Palo Alto Research Center (PARC), where he developed release tools for the Cedar programming environment project. He also held positions at Bell Laboratories and Zilog. Dr. Schmidt has a B.S. in electrical engineering from Princeton University, and an M.S. in electrical engineering and a Ph.D. in computer science from the University of California at Berkeley. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ VINTON G. CERF is currently Vice President of the Corporation for National Research Initiatives, where he has managed the Digital Library, Electronic Mail, and Internet research programs since 1986. >From 1982 to 1986, Dr. Cerf worked at MCI Communications, where he developed MCI Mail. He worked at the Defense Advanced Research Projects Agency from 1976 to 1982, where he led the packet communications, internetting and security efforts and served as principal scientist in the Information Processing Techniques Office. At Stanford University, from 1972 to 1976, he taught electrical engineering and computer science, and coinvented the TCP/IP protocol suite. At UCLA, from 1967 to 1972, he managed the Network Measurement Center and helped develop the host protocols for the ARPANET. At IBM he performed systems engineering on the QUIKTRAN time-sharing system. Dr. Cerf is a member of the Association for Computing Machinery (ACM), and has served as chairman of LA-SIGART (1968), chairman of SIGCOMM (1987-1991), and a member of the ACM Council (1991-1992). He was elected a Fellow of the IEEE in 1988, and received the Koji Kobayashi Award in 1992. Dr. Cerf served as a member of the Internet Architecture Board from 1986 to 1989, and as its chairman from 1989 to 1992. He is a coorganizer of the Internet Society, and was elected its president in 1992. Dr. Cerf has served on numerous national and international committees and commissions, technical advisory boards and boards of charitable organizations. With his wife, Sigrid, he works on a Shakespeare video-captioning project, and in his copious spare time enjoys science fiction, gourmet cooking, and the collection and consumption of fine wines. Dr. Cerf received a BS in Mathematics in 1965 from Stanford University, and his MS (1970) and PhD (1972) in Computer Science from UCLA. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ John Gage Director, Science Office Sun Microsystems Computer Corporation John Gage works for Bill Joy, the Chief Technical Officer of Sun, and is responsible for Sun's relationships with the world scientific and public policy communities, international scientific institutions and groups developing new forms of scientific research involving computing. He is on scientific and advisory panels of the United States National Science Foundation, the US Congress Office of Technology Assessment, the European Institute of Technology and the United States National Academy of Sciences. He has recently been appointed to the US National Research Council Mathematical Sciences Education Board. He is a member of ACM, IEEE, SIAM, AMS, AAAS, and SMPTE. He attended the Harvard Business School and the Harvard Graduate School of Public Policy. He did doctoral work in economics and mathematics at the University of Berkeley at the same time as Bill Joy. Gage subsequently left Berkeley with Joy to start Sun in 1982. Gage is on the Board of Directors of Unicode, an industry consortium of IBM, Microsoft, Apple, Novell, Sun, GO Corporation, and others to provide multilingual capability in all world scripts for all documents and applications. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Geoffrey Baehr - Chief Technical Officer- Networking, SunConnect Previously Director of Advanced Development at Sun Microsystems Computer Corporation. He initiated ATM projects at Sun along with wireless, spread spectrum radio, mobile IP and authentication. Before Sun, he was the Manager of Network System Engineers at TRW Baehr was the first president and founder of the ATM Forum and the editor for IEEE Communications Gigabit Network magazine. ----- End Included Message ----- From rem-conf-request@es.net Mon Jan 10 16:13:31 1994 Received: from hplms26.hpl.hp.com by osi-east.es.net via ESnet SMTP service id <02157-0@osi-east.es.net>; Mon, 10 Jan 1994 13:12:39 +0000 Received: from hplms2.hpl.hp.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA08046; Mon, 10 Jan 94 13:11:20 -0800 Received: from opera.hpl.hp.com by hplms2.hpl.hp.com with SMTP (1.37.109.8/15.5+ECS 3.3+HPL1.1I) id AA16036; Mon, 10 Jan 1994 13:11:08 -0800 Received: by opera.hpl.hp.com (1.37.109.8/HPL42.42) id AA19238; Mon, 10 Jan 1994 13:11:03 -0800 From: Yee-Hsiang Chang Message-Id: <9401102111.AA19238@opera.hpl.hp.com> Subject: Re: IP-Multicast and XTP compatibility? To: oli@i4.informatik.rwth-aachen.de Date: Mon, 10 Jan 94 13:11:03 PST Cc: rem-conf@es.net In-Reply-To: ; from "Oliver Hermanns" at Jan 10, 94 10:36 am X-Hpvue$Revision: 1.8 $ Mime-Version: 1.0 Content-Type: Message/rfc822 X-Vue-Mime-Level: 4 Mailer: Elm [revision: 70.85] > > Hi folks. > > Sorry, this might be a faq (bud I didn't find any hint on this topic in the > MBONE faq document). > > I would like to install Steve Deerings IP multicast package on our SUN Sparc > 2 machines. These are running under SUNOS 4.1.2. and have the XTP (Xpress > Transfer Protocol) Kernel extensions Vers. 1.7.2 installed. > > The XTP kernel extensions do not impose changes to TCP or IP systems object > files. But there are some changes in the socket interface (so that user > applications are able to select the desired transport protocol). The IP > extensions also change the socket interface, so I am not so sure, if these > extensions collide. > > My request: > > Who has made any experiences with the joint installation of both extensions? > Do they run in parallel? Are there some side effects? What has to be > changed? ....? > > Any help appreciated, > Oliver > = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - > Oliver Hermanns, > Technical University of Aachen, Dpt. of Computer Science IV > Ahornstrasse 55, D-52074 Aachen, Germany > Tel.: +49-241-80-4571, Fax: +49-241-80-21429 > E-mail: oli@informatik.rwth-aachen.de > = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - Oliver, I did the porting of XTP and IP multicast on a Sun workstation when I worked for my previous employer. Although the versions of XTP (KRM 1.7) and SunOS (4.1) are older in my case, they should not have any conflict with each other in your case. XTP and IPmulticast run in parallel and has no side effect that I am aware of. Regards, Yee-Hsiang -- Yee-Hsiang Chang HP Labs 1501 Page Mill Road Palo Alto, CA 94304-1126 email: yhc@hpl.hp.com phone: 415-857-7398 From rem-conf-request@es.net Mon Jan 10 19:50:10 1994 Received: from viipuri.nersc.gov by osi-west.es.net via ESnet SMTP service id <03433-0@osi-west.es.net>; Mon, 10 Jan 1994 16:49:15 +0000 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA25506; Mon, 10 Jan 94 16:49:14 PST Date: Mon, 10 Jan 94 16:49:14 PST From: ari@es.net (Ari Ollikainen) Message-Id: <9401110049.AA25506@viipuri.nersc.gov> To: rem-conf@es.net Subject: Intel's "personal conferencing standard" Anybody from Intel or any of the other participants able to comment on this? How does this fit into the fabric of the ITU-T H.200 series video telephony/conferencing standards? ------ Intel developing personal conferencing standard SANTA CLARA, Calif. (UPI) -- Intel Corp. said Monday it was joining several computer and communications industry players to develop standards for conferencing over personal computers. The chip giant said the specification will consist of work done by several companies and is targeted for release mid-1994. Intel said the companies working on the standard include Compaq Computer Corp., Compression Labs Inc., Ericsson Business Networks AB, Lotus Development Corp., Northern Telecom, Novell, PictureTel Corp., Software Publishing Corp., WordPerfect Corp., VTEL, and VideoServer. Additionally, American Telephone & Telegraph Co. will support the specification. ``We're delighted to be joined by this very powerful group of industry leaders,'' said Patrick Gelsinger, vice president and general manager of Intel's personal conferencing division. ``We expect the convergence of the communications and computer industries to produce a gigantic new industry.'' Gelsinger said the need has emerged for a cross-industry open standard allowing users to work simultaneously on the same documents as well as sharing audio and video information over telephone lines and on computer networks. ``Current standards don't allow for this type of integrated PC work in the personal conferencing environment,'' Gelsinger said. --------- ari@es.net _/_/ _/_/_/_/ _/ Ari Ollikainen {VOX: 510 423-5962} _/ _/ _/ _/ _/ Energy Sciences Network {FAX: 510 423-8744} _/_/_/_/ _/_/_/_/ _/ National Energy Research Supercomputer Center _/ _/ _/ _/ _/ Lawrence Livermore National Laboratory _/ _/ _/ _/ _/ MailStop L-561, PO BOX 5509, Livermore, CA. 94551 From rem-conf-request@es.net Mon Jan 10 20:41:24 1994 Received: from elxr-fddi.jpl.nasa.gov by osi-east.es.net via ESnet SMTP service id <05939-0@osi-east.es.net>; Mon, 10 Jan 1994 17:30:38 +0000 Received: from localhost by elxr.Jpl.Nasa.Gov (8.6.4/SMI-4.1+DXRm2.5) id RAA04519; Mon, 10 Jan 1994 17:30:32 -0800 Message-Id: <199401110130.RAA04519@elxr.Jpl.Nasa.Gov> To: rem-conf@es.net, mbone@isi.edu Subject: Multicast patches and SunOS 4.1.3_U1 Date: Mon, 10 Jan 1994 17:30:24 -0800 From: Dave Hayes Has anyone brought up the multicast patches on a SunOS 4.1.3_U1 machine? ------ Dave Hayes - Institutional Network & Communications - JPL/NASA - Pasadena CA dave@elxr.jpl.nasa.gov dave@jato.jpl.nasa.gov ...usc!elroy!dxh Ours is a world where people don't know what they want but are willing to go through hell to get it. From rem-conf-request@es.net Tue Jan 11 05:02:25 1994 Received: from ncc.ripe.net by osi-east.es.net via ESnet SMTP service id <07797-0@osi-east.es.net>; Tue, 11 Jan 1994 01:53:58 +0000 Received: from mellow.ripe.net by ncc.ripe.net with SMTP id AA02713 (5.65a/NCC-1.12); Tue, 11 Jan 1994 10:19:10 +0100 Message-Id: <9401110919.AA02713@ncc.ripe.net> To: Dave Hayes Cc: rem-conf@es.net, mbone@isi.edu From: Geert Jan de Groot X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Subject: Re: Multicast patches and SunOS 4.1.3_U1 In-Reply-To: Your message of "Mon, 10 Jan 1994 17:30:24 PST." <199401110130.RAA04519@elxr.Jpl.Nasa.Gov> Date: Tue, 11 Jan 1994 10:17:49 +0100 Sender: geertj@ripe.net On Mon, 10 Jan 1994 17:30:24 -0800 Dave Hayes wrote: > Has anyone brought up the multicast patches on a SunOS 4.1.3_U1 machine? I did yesterday, and so far, things seem to work (check reif.ripe.net). I used the 4.1.3 patches on a SUN ELC. The only problem I found is that these patches are incompatible with the SunLink X.25 LLC code, but that has always been the case. While at it, would it be possible for the mulcast-patches to include bpf-support as well? These patches are in source form ony, which is a problem if you don't have a source license.. Geert Jan From rem-conf-request@es.net Tue Jan 11 11:14:54 1994 Received: from uucp5.netcom.com by osi-east.es.net via ESnet SMTP service id <09249-0@osi-east.es.net>; Tue, 11 Jan 1994 08:02:41 +0000 Received: from localhost by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1) id IAA26783; Tue, 11 Jan 1994 08:00:44 -0800 Received: from diablo.insoft.com by insoft1.insoft.com (4.1/RHP-1.0) id AA18207; Tue, 11 Jan 94 10:27:15 EST Received: by diablo.insoft.com (4.1/SMI-4.1) id AA00323; Tue, 11 Jan 94 10:54:50 EST Date: Tue, 11 Jan 94 10:54:50 EST From: cemarley@diablo.insoft.com (Conall E. Marley) Message-Id: <9401111554.AA00323@diablo.insoft.com> Reply-To: "Conall E. Marley" To: rem-conf@es.net Subject: IP Multicast extions for HP 700 Could someone please tell me where I can find the Multicast extensions for an HP 715/50. Sorry if this is covered in a FAQ...I couldn't find what I need on the sites I know about. Thanks in advance, Conall ========================================================================= Conall Marley Phone: (717) 730-9501 Product Manager FAX : (717) 730-9504 InSoft, Inc. email: cemarley@insoft.com From rem-conf-request@es.net Tue Jan 11 11:56:26 1994 Received: from picard.cmf.nrl.navy.mil by osi-east.es.net via ESnet SMTP service id <09567-0@osi-east.es.net>; Tue, 11 Jan 1994 08:45:57 +0000 Received: from herman.cmf.nrl.navy.mil (herman-atm.cmf.nrl.navy.mil [134.207.10.3]) by picard (8.6.4/8.6.4) with SMTP id LAA15687 for ; Tue, 11 Jan 1994 11:44:49 -0500 From: William C Fenner Received: by herman.cmf.nrl.navy.mil (4.1/client-1.3) id AA07499; Tue, 11 Jan 94 11:43:24 EST Date: Tue, 11 Jan 94 11:43:24 EST Message-Id: <9401111643.AA07499@herman.cmf.nrl.navy.mil> To: rem-conf@es.net Subject: Signal quality of Sunergy rtpqual is showing approximately 66% loss on the nv feed. vat is reporting much lower losses, under 10%, and approximately a half second playout time. Anyone else seeing better or worse conditions? Bill From rem-conf-request@es.net Tue Jan 11 13:27:58 1994 Received: from orion.arc.nasa.gov by osi-east.es.net via ESnet SMTP service id <10546-0@osi-east.es.net>; Tue, 11 Jan 1994 10:14:24 +0000 Original-Received: Tue, 11 Jan 94 10:12:52 PST by orion.arc.nasa.gov (4.1/1.2) PP-warning: Illegal Received field on preceding line From: Nora Lavelle Message-Id: <9401111812.AA28022@orion.arc.nasa.gov> Subject: Shuttle Mission Coverage To: rem-conf@es.net Date: Tue, 11 Jan 1994 10:12:51 -0800 (PST) X-Mailer: ELM [version 2.4 PL3] Content-Type: text Content-Length: 1203 I am planning to multicast the NASA Select coverage of STS-60 on a 24 hour basis starting on Jan 20 1994 and lasting until Jan 28 1994. This coverage will consist of nv and vat sessions. If this coverage interferes with other multicast conferences, I will be standing by to reduce bandwidth or suspend coverage in order to share the MBONE. I will be multicasting with a ttl of 127. If there are any problems with this schedule or practice, please contact me. E-mail any questions or comments to anaops@atlas.arc.nasa.gov -------------------------------------------------------------------------------- __ __ ________ __ ___ Nora Lavelle /\_\ /\_\ /_______/\ /\_\ /\__\ System Adminstrator / / / / / / \ _____\/ / / / / / _ \ Sterling Software / / /__/ / / \ \ \______ / / /___ / / /_\ \ / / /___\/ / \ \/_____/\ / / /_____\ / / ___ \ \/_______ / \_______\/ \/________/ \/__/ \__\ NASA Ames Research Center nlavelle@orion.arc.nasa.gov -------------------------------------------------------------------------------- From rem-conf-request@es.net Tue Jan 11 13:38:37 1994 Received: from Sun.COM by osi-east.es.net via ESnet SMTP service id <10681-0@osi-east.es.net>; Tue, 11 Jan 1994 10:26:41 +0000 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA29180; Tue, 11 Jan 94 10:26:37 PST Received: from amber.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA19705; Tue, 11 Jan 94 10:24:49 PST Received: by amber.Eng.Sun.COM (5.0/SMI-SVR4) id AA00726; Tue, 11 Jan 1994 10:25:11 +0800 Date: Tue, 11 Jan 1994 10:25:11 +0800 From: Don.Hoffman@Eng.Sun.COM (Don Hoffman) Message-Id: <9401111825.AA00726@amber.Eng.Sun.COM> To: rem-conf@es.net, fenner@cmf.nrl.navy.mil Subject: Re: Signal quality of Sunergy X-Sun-Charset: US-ASCII Content-Length: 830 Sorry about the quality early in the program. One problem was something I think I was discussed on rem-conf a few months ago. I thought I would bring it up again to save anyone else the same problem. There is a bug in Solaris 2.3 where the "don't-fragment" bit is set on multicast packets. This is correct behavior for unicast packets as it triggers the ICMP packets used for MTU discovery on a route. Since MTU discovery does not apply to multicast, the router (in this case, on one of our internal T1 links) correctly discards the packets, leading to the very large loss rate seen on MBONE. One workaround is to set the MTU size on the sender to be the smallest MTU in the net. Another workaround is to disable MTU discovery. Problem will be fixed in 2.4 by not setting "don't-fragment" bit on multicast packets. Don From rem-conf-request@es.net Tue Jan 11 13:49:17 1994 Received: from venera.isi.edu by osi-east.es.net via ESnet SMTP service id <10795-0@osi-east.es.net>; Tue, 11 Jan 1994 10:38:29 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Tue, 11 Jan 1994 10:38:19 -0800 Posted-Date: Tue 11 Jan 94 10:37:30 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Tue, 11 Jan 94 10:37:31 PST Date: Tue 11 Jan 94 10:37:30 PST From: Stephen Casner Subject: Re: Multicast patches and SunOS 4.1.3_U1 To: GeertJan.deGroot@ripe.net Cc: rem-conf@es.net, MBONE@ISI.EDU Message-Id: <758313450.0.CASNER@XFR.ISI.EDU> In-Reply-To: <9401110919.AA02713@ncc.ripe.net> Mail-System-Version: There is a 4.1.3 version of if_le.o which includes the bpf patches in addition to the multicast patches on ftp.isi.edu:mbone/if_le.o-bpf. One can do the other steps required to add bpf without sources. -- Steve ------- From rem-conf-request@es.net Tue Jan 11 14:18:44 1994 Received: from runix.runit.sintef.no by osi-east.es.net via ESnet SMTP service id <11148-0@osi-east.es.net>; Tue, 11 Jan 1994 11:09:21 +0000 Received: from runit.sintef.no by runix.runit.sintef.no with SMTP (PP) id <28550-0@runix.runit.sintef.no>; Tue, 11 Jan 1994 20:09:10 +0100 Received: by ravn (4.1/Runit-cl-1.0) id AA20675; Tue, 11 Jan 94 20:09:08 +0100 Date: Tue, 11 Jan 1994 20:09:07 +0100 (MET) From: Steinar Haug Subject: Re: Multicast patches and SunOS 4.1.3_U1 To: Stephen Casner Cc: rem-conf@es.net, MBONE@ISI.EDU In-Reply-To: <758313450.0.CASNER@XFR.ISI.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > There is a 4.1.3 version of if_le.o which includes the bpf patches in > addition to the multicast patches on ftp.isi.edu:mbone/if_le.o-bpf. > One can do the other steps required to add bpf without sources. Wonderful! Some of us have wanted this for a long time! One small point: Van Jacobson's BPF patches which are included in tcpdump also have patches for BPF to the loopback interface (if_loop.o). Is there a binary version of if_loop.o, with BPF patches, available? (This is not as important as if_le.o, of course - I can live without BPF mods for the loopback interface, but the BPF mods for the Ethernet interface are very nice to have!) Steinar Haug, system/networks administrator SINTEF RUNIT, University of Trondheim, NORWAY Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no From rem-conf-request@es.net Tue Jan 11 16:35:48 1994 Received: from venera.isi.edu by osi-east.es.net via ESnet SMTP service id <13227-0@osi-east.es.net>; Tue, 11 Jan 1994 13:31:43 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Tue, 11 Jan 1994 13:31:35 -0800 Posted-Date: Tue 11 Jan 94 13:30:45 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Tue, 11 Jan 94 13:30:46 PST Date: Tue 11 Jan 94 13:30:45 PST From: Stephen Casner Subject: Multicast + bpf patches To: Steinar.Haug@runit.sintef.no Cc: rem-conf@es.net, MBONE@ISI.EDU Message-Id: <758323845.0.CASNER@XFR.ISI.EDU> In-Reply-To: Mail-System-Version: > Is there a binary version of if_loop.o, with BPF patches, available? OK, I made one. Also, I forgot to mention that the if_le.o-bpf file was for the sun4c architecture. So, now in ftp.isi.edu:mbone you will find the following files: sunos-bpf/sys.sunos413/sun4c/if_le.o sunos-bpf/sys.sunos413/sun4c/if_loop.o sunos-bpf/sys.sunos413/sun4m/if_le.o sunos-bpf/sys.sunos413/sun4m/if_loop.o I could add 4.1.1 variants as needed. -- Steve ------- From rem-conf-request@es.net Tue Jan 11 16:47:44 1994 Received: from runix.runit.sintef.no by osi-east.es.net via ESnet SMTP service id <13302-0@osi-east.es.net>; Tue, 11 Jan 1994 13:38:46 +0000 Received: from runit.sintef.no by runix.runit.sintef.no with SMTP (PP) id <03549-0@runix.runit.sintef.no>; Tue, 11 Jan 1994 22:38:30 +0100 Received: by ravn (4.1/Runit-cl-1.0) id AA21930; Tue, 11 Jan 94 22:38:28 +0100 Date: Tue, 11 Jan 1994 22:38:28 +0100 (MET) From: Steinar Haug Sender: Steinar Haug Reply-To: Steinar Haug Subject: Re: Multicast + bpf patches To: Stephen Casner Cc: rem-conf@es.net, MBONE@ISI.EDU In-Reply-To: <758323845.0.CASNER@XFR.ISI.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > OK, I made one. Also, I forgot to mention that the if_le.o-bpf file > was for the sun4c architecture. So, now in ftp.isi.edu:mbone you > will find the following files: > > sunos-bpf/sys.sunos413/sun4c/if_le.o > sunos-bpf/sys.sunos413/sun4c/if_loop.o > sunos-bpf/sys.sunos413/sun4m/if_le.o > sunos-bpf/sys.sunos413/sun4m/if_loop.o Thanks a lot! This is extremely helpful - and 4.1.3 is really all I need. Now I can run multicasting *and* BPF on all the architectures I want. Steinar Haug From rem-conf-request@es.net Tue Jan 11 16:53:21 1994 Received: from mvs.oac.ucla.edu by osi-east.es.net via ESnet SMTP service id <13367-0@osi-east.es.net>; Tue, 11 Jan 1994 13:44:56 +0000 Received: from UCLAMVS.BITNET by MVS.OAC.UCLA.EDU (IBM MVS SMTP V2R2.1) with BSMTP id 3647; Tue, 11 Jan 94 13:44:24 PST Date: Tue, 11 Jan 94 13:43 PST To: rem-conf@ES.NET, mbone@ISI.EDU From: Denis DeLaRoca (310) 825-4580 Subject: Re: Re: Multicast patches and SunOS 4.1.3_U1 On Tue, 11 Jan 1994 10:17:49 +0100, Geert Jan de Groot said: > I did yesterday, and so far, things seem to work (check reif.ripe.net). > I used the 4.1.3 patches on a SUN ELC. The only problem I found No audio problems? On a Sparc-LX, I think I saw some problems reported with the patched versions of dbri_conf.o and dbri_mmcodec.o files. -- Denis From rem-conf-request@es.net Tue Jan 11 17:27:16 1994 Received: from viipuri.nersc.gov by osi-west.es.net via ESnet SMTP service id <11578-0@osi-west.es.net>; Tue, 11 Jan 1994 14:19:20 +0000 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA26439; Tue, 11 Jan 94 14:19:18 PST Date: Tue, 11 Jan 94 14:19:18 PST From: ari@es.net (Ari Ollikainen) Message-Id: <9401112219.AA26439@viipuri.nersc.gov> To: rem-conf@es.net Subject: Re: Intel's "personal conferencing standard" Cc: rcwg@gov.fnal.hepnet, dvtf@es.net More on this story from today's (1/11/94) SanFrancisco Chronicle, page B1, BUSINESS staff write Laura Evenson: Intel Spearheads Conferencing Project Intel Corp., the Santa Clara-based semiconductor maker. will bring leading computer and communications companies together to develop a standard for videoconferencing as part of an effort to be a player in the communications market. Intel's standard will use IBM-compatible computers to create simultaneous voice and data transmission over ordinary telephone lines. "We expect the convergence of the communications and computer industries to produce a gigantic new industry," said Patrick Gelsinger, vice president and general manager of Intel's Personal Conferencing Division. "Personal conferencing is the first example of this convergence and extends PC capability into real-time communications." Intel's partners in this venture include Compaq Computer Corporation, Compression Labs Inc., and American Telephone & Telegraph Company. Analysts say the standard developed by Intel could lower the cost of desktop-to-desktop videconferencing and datasharing systems to less than $1000 by 1996. The standard could also improve the quality of video and audio teleconferencing. If Intel's effort is successful, two business people could talk on the phone , alter a spreadsheet and see all the changes instantaneously. Under the partnership announced today, Lotus Development Corp., Software Publishing Corp., and WordPerfect Corp., will develop and support PC software applications to enable document and video conferencing; AT&T will provide the communications support; Ericsson Business Networks AB and Northern Telecom Ltd. will provide communications infrastructure support; Novell Inc. will provide netwoking expertise; Compaq will provide systems integra- tion and other support; and video conferencing expertese will come from Compression Labs, PictureTel Corp. and VTEL Corp. ----------- ari@es.net _/_/ _/_/_/_/ _/ Ari Ollikainen {VOX: 510 423-5962} _/ _/ _/ _/ _/ Energy Sciences Network {FAX: 510 423-8744} _/_/_/_/ _/_/_/_/ _/ National Energy Research Supercomputer Center _/ _/ _/ _/ _/ Lawrence Livermore National Laboratory _/ _/ _/ _/ _/ MailStop L-561, PO BOX 5509, Livermore, CA. 94551 From rem-conf-request@es.net Tue Jan 11 18:11:55 1994 Received: from ncc.ripe.net by osi-east.es.net via ESnet SMTP service id <14214-0@osi-east.es.net>; Tue, 11 Jan 1994 15:03:02 +0000 Received: from mellow.ripe.net by ncc.ripe.net with SMTP id AA05588 (5.65a/NCC-1.12); Wed, 12 Jan 1994 00:02:46 +0100 Message-Id: <9401112302.AA05588@ncc.ripe.net> To: Denis DeLaRoca 825-4580 (310) Cc: rem-conf@es.net, mbone@isi.edu From: Geert Jan de Groot X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Subject: Re: Multicast patches and SunOS 4.1.3_U1 In-Reply-To: Your message of "Tue, 11 Jan 1994 13:43:00 PST." <199401112144.AA02632@venera.isi.edu> Date: Wed, 12 Jan 1994 00:02:41 +0100 Sender: geertj@ripe.net On Tue, 11 Jan 94 13:43 PST Denis DeLaRoca 825-4580 wrote: > > I did yesterday, and so far, things seem to work (check reif.ripe.net). > > I used the 4.1.3 patches on a SUN ELC. The only problem I found > No audio problems? On a Sparc-LX, I think I saw some problems reported > with the patched versions of dbri_conf.o and dbri_mmcodec.o files. The SUN ELC uses the old AMD ISDN/audio chip and thus doesn't have these problems. The LX uses the same chip as an SS10; the programming interface may be different, but I don't see how. Geert Jan (who cannot test on a SS10. Anyone willing to donate theirs ? :-) From rem-conf-request@es.net Tue Jan 11 18:14:06 1994 Received: from anu.anu.edu.au by osi-east.es.net via ESnet SMTP service id <14198-0@osi-east.es.net>; Tue, 11 Jan 1994 15:00:25 +0000 Received: from octavia.anu.edu.au. by anu.anu.edu.au (4.1/SMI-4.1) id AA13414; Wed, 12 Jan 94 09:59:55 EST Received: by octavia.anu.edu.au. (4.1/SMI-4.1) id AA20375; Wed, 12 Jan 94 10:00:14 EST Date: Wed, 12 Jan 94 10:00:14 EST From: markus@octavia.anu.edu.au (Markus Buchhorn) Message-Id: <9401112300.AA20375@octavia.anu.edu.au.> To: mbone@isi.edu, rem-conf@es.net Subject: Duplication of EMAIL packets... Could people perhaps refrain from posting the same e-mail to both the rem-conf and mbone lists please ? I'm fairly sure that most people interested in this area would subscribe to both lists. There was some discussion of this before Christmas. If I recall correctly: Rem-conf: Conference announcements/discussions mbone: everything else :-) especially the technical stuff. Hmm - perhaps we need a different split ? How 'bout: mbone-announce: Announcements of conferences, new software, etc. mbone-tech: The nitty gritty of multicasting mbone-misc: Whatever get's missed out by the above. Or how about some newsgroups ? rec.multicasting.* ? :-) :-) (Puts on asbestos underwear and starts running..) Sorry to be a bit negative, but I get enough e-mail each day to keep me amused for a fair few hours... Cheers, Markus Markus Buchhorn, Parallel Computing Research Facility email = markus@octavia.anu.edu.au snail = CISR, I Block, OAA, ANU Australian National University, Canberra, 0200 , Australia. [International = +61 6, Australia = 06] [Phone = 2492930, Fax = 2490747] From rem-conf-request@es.net Tue Jan 11 23:40:23 1994 Received: from sole.cs.washington.edu by osi-west.es.net via ESnet SMTP service id <13954-0@osi-west.es.net>; Tue, 11 Jan 1994 18:26:08 +0000 Return-Path: Received: from localhost (cmaeda@localhost) by sole.cs.washington.edu (8.6.4/7.1ws+) id SAA27481; Tue, 11 Jan 1994 18:26:32 -0800 Date: Tue, 11 Jan 1994 18:26:32 -0800 From: cmaeda@cs.washington.edu Message-Id: <199401120226.SAA27481@sole.cs.washington.edu> To: rem-conf@es.net Subject: ip multicast s/w for NetBSD By the way, if anyone needs patches for NetBSD 0.9 (a free BSD for PC clones), I have them. They're based on the BSDI patches and the resulting kernels run the BSDI binaries from LBL. (I've already broadcast this to the NetBSD community but I don't know how much overlap there is with rem-conf.) From rem-conf-request@es.net Wed Jan 12 02:13:30 1994 Received: from venera.isi.edu by osi-east.es.net via ESnet SMTP service id <16357-0@osi-east.es.net>; Tue, 11 Jan 1994 23:12:52 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Tue, 11 Jan 1994 23:12:48 -0800 Posted-Date: Tue 11 Jan 94 23:11:59 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Tue, 11 Jan 94 23:12:00 PST Date: Tue 11 Jan 94 23:11:59 PST From: Stephen Casner Subject: Re: Duplication of EMAIL packets... To: casner@ISI.EDU Message-Id: <758358719.0.CASNER@XFR.ISI.EDU> In-Reply-To: <9401112300.AA20375@octavia.anu.edu.au.> Mail-System-Version: Let me try again to clarify the purpose of the rem-conf and mbone mailing lists. Sorry this is medium-long to be more detailed. I agree that the sending of messages to both the rem-conf and mbone lists should be minimized. This message is going to both, but to try to avoid a long discussion and to encourage private replies to me instead, the lists are addressed in the Bcc. I will summarize the responses to the list(s) if it seems warranted. Markus Buchhorn's characterization of the purpose of the two lists was not quite right. Ari Ollikainen and I have come up with the following: REM-CONF: - technical discussions that are related to all the pieces of the puzzle involved in accomplishing remote conferencing (one-one, one-to-many, many-to-many), including software, hardware, and protocols - participants are developers and end-users of remote conferencing, therefore it is the preferred list for: - release notes for new applications, such as audio/video tools - announcements of events on the MBONE that can be received by the people who run these tools, since rem-conf should reach most/many of the potential viewers MBONE: - purpose is to manage the engineering and operation of the MBONE itself - participants are those who run MBONE nodes (i.e., a narrower audience than rem-conf), therefore is is the preferred list for: - requests for MBONE tunnels to be set up or changed - questions about the multicast kernel software, since the person who builds multicast kernels for a site is likely to be the same one who runs the MBONE node for that site - release notes for new MBONE monitoring tools I assume that most people who are on the mbone list are also on the rem-conf list. Therefore, in the future when I respond to a message sent to both lists, I will try to remember to delete the mbone list address and reply only to rem-conf. If there are people on the mbone list who are not on the rem-conf list (and don't want to be) who would object to this policy, send me private email about it so I can guage the (in)accuracy of my assumption. Markus suggested that the lists be split further. That would cause a lot more work in list management, and in my opinion, would probably cause more confusion about which list to choose rather than less. He also suggested newsgroups, where the finer grain would be more feasible, but I think we want a more directed distribution for now. Taking note of the intended purposes of the two lists, if you wish to join (or leave) the rem-conf list, send a message to rem-conf-request@es.net and not to the list itself (following the usual -request convention). Please note that the rem-conf maintainer asks for regional and organizational volunteers to set up more local rem-conf "exploders". Similarly, to join (or leave) the appropriate regional sublist of the mbone list, send a message to the appropriate one of the following regional -request lists (the list is divided along regional topology so that maintenance of the MBONE within a region can be done without disturbing others): mbone-eu: mbone-eu-request@sics.se Europe mbone-jp: mbone-jp-request@wide.ad.jp Japan mbone-korea: mbone-korea-request@mani.kaist.ac.kr Korea mbone-na: mbone-na-request@isi.edu North America mbone-nz: mbone-nz-request@waikato.ac.nz New Zealand mbone-oz: mbone-oz-request@internode.com.au Australia mbone-sg: mbone-sg-request@lincoln.technet.sg Singapore mbone: mbone-request@isi.edu other Here's to happy and efficient emailing! -- Steve ------- From rem-conf-request@es.net Wed Jan 12 02:15:40 1994 Received: from piper.cs.colorado.edu by osi-east.es.net via ESnet SMTP service id <16349-0@osi-east.es.net>; Tue, 11 Jan 1994 23:07:53 +0000 Received: by piper.cs.colorado.edu id AA21076 (5.65c/IDA-1.4.4 for rem-conf@es.net); Wed, 12 Jan 1994 00:07:46 -0700 Date: Wed, 12 Jan 1994 00:07:46 -0700 From: Evi Nemeth Message-Id: <199401120707.AA21076@piper.cs.colorado.edu> To: mbone@isi.edu, rem-conf@es.net Subject: John Perry Barlow, MBONE, 9:00 AM - 10:30 AM PST, Jan 17, 1994 Cc: evi@piper.cs.colorado.edu =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= John Perry Barlow will deliver the keynote address opening the winter USENIX conference at the San Francisco Hilton, Jan 17-21, 1994. The keynote will be broadcast (audio and video) on the MBONE from a bit after 9:00 AM to 10:30 AM on Monday, January 17. Barlow will speak on recent developments in the national information infrastructure, telecommunications regulations, cryptography, globalization of the Net, intellectual property, and, generally, of the settlement of Cyberspace. In 1990, Mr. Barlow and Mitch Kapor co-founded the Electronic Frontier Foundation, and he currently serves as chair of its executive committee. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From rem-conf-request@es.net Wed Jan 12 04:34:28 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <16336-0@osi-west.es.net>; Wed, 12 Jan 1994 01:25:13 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 12 Jan 1994 09:24:27 +0000 To: Don.Hoffman@Eng.Sun.COM (Don Hoffman) cc: rem-conf@es.net, fenner@cmf.nrl.navy.mil, J.Crowcroft@cs.ucl.ac.uk Subject: Re: Signal quality of Sunergy In-reply-to: Your message of "Tue, 11 Jan 94 10:25:11 +0800." <9401111825.AA00726@amber.Eng.Sun.COM> Date: Wed, 12 Jan 94 09:24:25 +0000 From: Jon Crowcroft >Problem will be fixed in 2.4 by not setting "don't-fragment" bit on >multicast packets. couple of other things i notice different about solaris and bsd multicast the matching on UDP multicast PCB's seems different - there is a question of interpretation of the spec, but basically, if a multicast packet is sent to port p, it should be delivered to all multicast sockets (streams?) listening/recvfroming on port p, but not to unicast ones, nor should a unicast packet to port p be delivered to a multicast socket - where someone as a list/recvfrom on INADDR_ANY, if the port is unicast, then packets from anywhere to unicast should get there. if its multicast, they shouldn't, but multicast ones should - i.e. the port space is sperate for the seperate IP address spaces, uni&multi-cast, and the wild card match is interpreted independently too i think at least one of the ipmulticast source/relaseses around doesnt do all this right, but the solaris one seems to (congrats)! surely jon oh, and the talk was very good, but shame about the blatant advertising at the begining:-) From rem-conf-request@es.net Wed Jan 12 14:11:30 1994 Received: from ell.ee.lbl.gov by osi-west.es.net via ESnet SMTP service id <20467-0@osi-west.es.net>; Wed, 12 Jan 1994 11:03:01 +0000 Received: by ell.ee.lbl.gov for rem-conf@es.net (5.65/1.43r) id AA04419; Wed, 12 Jan 94 11:03:00 -0800 From: mccanne@ee.lbl.gov (Steven McCanne) Message-Id: <9401121903.AA04419@ell.ee.lbl.gov> To: rem-conf@es.net Subject: new vat (v3.1) available for anonymous ftp Date: Wed, 12 Jan 94 11:03:00 PST There's a new version of vat available for anonymous ftp from ftp.ee.lbl.gov in conferencing/vat/*-vat-3.1.tar.Z. We ported vat from InterViews to tcl/tk and made some improvements to the user interface (thanks to John Ousterhout for making this incredibly easy). Some of the changes aren't backward compatible so it would be a good idea to peruse the change history below. A very common problem people have with tk applications is defining resources like "*background" and "*foreground". If you use these (or other unqualified resources), vat's (and nv's) interface can look real ugly. The tk port required a bunch of new code and we reorganized the internal architecture a bit, so we probably haven't gotten all the bugs out. As usual, direct bug reports, questions, and comments to vat@ee.lbl.gov. Steve & Van ----------- v3.0-3.1, Tue Jan 11 16:02:50 PST 1994 - New look to user interface; ported to tcl/tk. The painful side effect is that the vat X resource names have all changed. Tk requires them to have the form Vat.resource, i.e., vat must be capitalized and the attribute name must start with a lower case letter. We changed all the old resource names from the form vat*FooBar to Vat.fooBar. - Made push-to-talk mode built-in. - Changed invocation of auxiliary control panel from clicking on bottom title bar, to clicking on a button labeled ``Menu''. Added an ``Okay'' button to the control panel to make it go away. - Added a help window. - Removed the "mute both" button since it's rarely used. - Added per-site statistics windows. Use left-mouse button on site name to get popup window with packet stats. Use shift-left-mouse to get permanent window with stats & stripchart. - Added Vat.iconPrefix resource. This string is prepended to the conference name and the result used as vat's icon name. For example, you might set Vat.iconPrefix to ``vat:''. - Give better error message when a multicast destination is used on a non-multicast capable system. - Added a type-in box for audio device priority. - Added AGC sliders to auxiliary controls window. - Added a quit button. - Make muteNewSites X resource match name in cbox (changed from "supressNewSites"). - Changed "-f idvi" option "-f dvi" to match name in cbox. - Remove support for Vat.Speaker resource (per warning in v2.17beta change log). - Anti-social practice of using pure whitespace for session name is no longer permitted. - Removed conference title bar. Moved audio access functionality to title bar at bottom of window. From rem-conf-request@es.net Wed Jan 12 22:35:33 1994 Received: from viipuri.nersc.gov by osi-west.es.net via ESnet SMTP service id <26005-0@osi-west.es.net>; Wed, 12 Jan 1994 19:28:33 +0000 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA27678; Wed, 12 Jan 94 19:28:31 PST Date: Wed, 12 Jan 94 19:28:31 PST From: ari@es.net (Ari Ollikainen) Message-Id: <9401130328.AA27678@viipuri.nersc.gov> To: rem-conf@es.net Subject: Re: Intel's "personal conferencing standard" Cc: rcwg@gov.fnal.hepnet, dvtf@es.net Is it REALLY Circle-the-Wagons-Time for ITU-T H.320 as applied to desktops? On the heels of the announcement of Intel's "personal conferencing standard" effort comes this, by FAX: January 10, 1994 Dear H.320 Stakeholder, The purpose of this letter is to solicit your company's participation in an initiative being led by AT&T, and other companies who would join us, aiming to facilitate better public awareness about current worldwide levels of commitment, momentum and trends in the creation, adoption and use of H.320 products and services. It is the view of AT&T that, in general, the worldwide commitment to, and momentum of, H.320 is currently underestimated and that, potentially, such underestimates could imped the further acceleration of H.320 adoption. This is of concern to us because we believe that the H.320 standard is important as the foundation for desktop videoconferencing and videocollabora- tion in order to assure : -global interoperability in a multivendor environment, -the security of having the foundational technologies available to the world at large through the auspices of an international standards body, rather than having the future of these technologies and resulting products under the ownership or control of any one or few companies, -the protection and extension of current worldwide investments in H.320 group and room videoconferencing systems. Therefore, we are seeking to present, to key industry analysts and members of the press, a collection of information which we are soliciting from you and other companies, worldwide, which we expect will be effective in portraying the substantial momentum of H.320. Our goal is to accomplish the first phase of this within the next four weeks, and therefore we need responses by January 14. And so we are soliciting information concerning your company's commitment to H.320 -- specifically information in areas of interest listed below -- which has already been made public, or which your company is prepared to make public. To this end our preferred format for receiving such information from you is in the form of a one or two page letter on your business letterhead. We will then collect, provide an overview for, ditribute, and in selected cases personnaly present to analysts and members of the press, copies of key H.320 stakeholders' own information, showing the stakeholders own letterheads. In addition, we are soliciting and compiling information on whether and where there is strong interest in forming an association of of H.320 products and services providers, and end users, dedicated to furthering the adoption and growth of H.320 products and services. Such an association would complement existing standards bodies, and localized and ad hoc groups furthering specific directionssuch as interoperability trials, by focusing on those factors which directly shape adoption momentum and market development. If there is strong enough interest on the part of a substantial enough group of H.320 stakeholders, AT&T would be willing to coordinate and facilitate the organization of such an association, so long as it is clear that this would be an association of which AT&T would be simply an equal among many members. Presently, we are especially interested in getting in touch with those who uregntly feel the need to agree in principle, in some public way, to join such a group. Finally, if by separate fax or telephone message to me, you would care to identify a fellow H.320 stakeholder in a company you believe may be deeply committed to H.320 -- someone you would personally encourage to participate -- I would greatly appreciate your help. Please address your letters to: Arnold C. Englander AT&T, Room 1C-408 101 Crawfords Corner Road Holmdel, New Jersey 07733 Voice: 908/949-0300, FAX: 908/949-3926 An alternate voice number, where I am most often available, is 908/953-6195, and I maintain voice mail at both voice numbers. Thank you in advance for your information, and for your continued contributions to the H.320 community. Sincerely, Arnold C.Englander Product Line Director Visual Communications Solutions AT&T ------------------------------------------------------------------------------- The FAX was actually sent from "AT&T Microelectronics, Visual Solutions Business Unit" From rem-conf-request@es.net Thu Jan 13 04:27:47 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <28069-0@osi-west.es.net>; Thu, 13 Jan 1994 01:13:42 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 13 Jan 1994 09:13:26 +0000 To: " (Ari Ollikainen)" cc: rem-conf@es.net, rcwg@net.es.FNAL.hepnet, dvtf@es.net Subject: Re: Intel's "personal conferencing standard" In-reply-to: Your message of "Thu, 13 Jan 94 03:39:35 GMT." <9401130328.AA27678@viipuri.nersc.gov> Date: Thu, 13 Jan 94 09:13:24 +0000 From: Jon Crowcroft >Is it REALLY Circle-the-Wagons-Time for ITU-T H.320 as applied to desktops? personally, most of the H. series video conferencing protocols are so badly broken that anyone trying to sell serious products based on them in a coule of years will find it hard going... they ar all fine if you ar on the end of a telephone, but they do not accomoadat multicast properly, and have order n**2 signaling approaches - bit-time-level delay-obsessed protocs like h.221 are close to braindead outside of a telephone exchange.... and i believe (but this is mor a guess) MPEG will outdistance h.261 very quickly once the entertainment people get going - MPEG on a sunvideo card is pretty impressive already... and so forth why doesnt someone fund a H.320 internet implementation and see what use it is? cheers jon From rem-conf-request@es.net Thu Jan 13 07:15:08 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <28945-0@osi-west.es.net>; Thu, 13 Jan 1994 04:05:02 +0000 Received: from danger.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 13 Jan 1994 12:04:31 +0000 From: Mark Handley Organisation: University College London, CS Dept. Phone: +44 71 380 7777 ext 3666 To: Jon Crowcroft cc: " (Ari Ollikainen)" , rem-conf@es.net, rcwg@net.es.FNAL.hepnet, dvtf@es.net Subject: Re: Intel's "personal conferencing standard" In-reply-to: Your message of "Thu, 13 Jan 94 09:27:20 GMT." <"28074 Thu Jan 13 01:14:19 1994"@es.net> Date: Thu, 13 Jan 94 12:04:20 +0000 Sender: M.Handley@cs.ucl.ac.uk >why doesnt someone fund a H.320 internet implementation and see what >use it is? H.261 is part of the H.320 family, and IVS is an internet implementation. Bitfield amongst other make a card, which UiO use very effectively over the internet. SunVideo will shortly support H.261. H.221 is serial line framing, so inappropriate. The rest of the H.320 family don't really apply unless you have H.221 framing. > and i believe (but this is mor a guess) MPEG will outdistance h.261 > very quickly once the entertainment people get going - MPEG on a > sunvideo card is pretty impressive already... The good thing about H.261 is that there are a number solutions alreday working for conferencing on the internet, and that it is the most widely used standard for video over serial links. It no-one else besides UCL working on gateways between the two worlds? I don't believe H.261's time has come yet, but we'll see what happens when MPEG chipsets are available cheaply. Mark From rem-conf-request@es.net Thu Jan 13 08:54:16 1994 Received: from nuplanet.MV.COM by osi-west.es.net via ESnet SMTP service id <29469-0@osi-west.es.net>; Thu, 13 Jan 1994 05:45:30 +0000 Received: from localhost by nuplanet.nuplanet.com (8.6/1.2remote (Problems to postmaster@prdcat.com)) id NAA15155; Thu, 13 Jan 1994 13:48:49 GMT From: jsteer@nuplanet.mv.com (jon steer) Message-Id: <199401131348.NAA15155@nuplanet.nuplanet.com> Subject: Re: Intel's "personal conferencing standard" To: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Thu, 13 Jan 94 8:48:49 EST Cc: J.Crowcroft@cs.ucl.ac.uk, ari@es.net, rem-conf@es.net, rcwg@net.es.FNAL.hepnet, dvtf@es.net In-Reply-To: <199401131311.IAA11351@prdcat.prdcat.com>; from "Mark Handley" at Jan 13, 94 12:04 pm Reply-To: jsteer@zydacron.com Organization: Zydacron, Inc X-Mailer: ELM [version 2.3 PL11] Mark Handley , > > > >why doesnt someone fund a H.320 internet implementation and see what > >use it is? > > H.261 is part of the H.320 family, and IVS is an internet implementation. > Bitfield amongst other make a card, which UiO use very effectively over the > internet. SunVideo will shortly support H.261. > > H.221 is serial line framing, so inappropriate. The rest of the H.320 > family don't really apply unless you have H.221 framing. > > > and i believe (but this is mor a guess) MPEG will outdistance h.261 > > very quickly once the entertainment people get going - MPEG on a > > sunvideo card is pretty impressive already... > > The good thing about H.261 is that there are a number solutions alreday > working for conferencing on the internet, and that it is the most widely > used standard for video over serial links. It no-one else besides UCL > working on gateways between the two worlds? Who is UCL ? > > I don't believe H.261's time has come yet, but we'll see what happens when > MPEG chipsets are available cheaply. > > Mark > ============================================================================= Jon Steer, Director of Unix Development Zydacron,Inc 670 Commerical St, Manchester, N.H. 03101 phone:(603)647-1000 fax: (603)647-9470 E-mail: jsteer@zydacron.com From rem-conf-request@es.net Thu Jan 13 09:00:10 1994 Received: from tel.vtt.fi by osi-west.es.net via ESnet SMTP service id <29523-0@osi-west.es.net>; Thu, 13 Jan 1994 05:50:00 +0000 Received: by tel.vtt.fi id AA14541 (5.65c/IDA-1.4.4 for rem-conf@es.net); Thu, 13 Jan 1994 15:50:57 +0200 Date: Thu, 13 Jan 1994 15:50:57 +0200 From: Jarmo Molsa Message-Id: <199401131350.AA14541@tel.vtt.fi> To: rem-conf@es.net Subject: Question about RTP timestamps We are beginning to implement RTP, and we encountered a problem, to which we'd like to hear opinions. According to the newest RTP draft (draft-ietf-avt-rtp-04) "the timestamp reflects the wall clock time when the RTP packet was generated". If the timestamp value is calculated as the rtp draft suggests, it seems that we run into a synchronization problem. ------------------------------------- |Audio n | Audio n+1 | ... ------------------------------------- --+--------+------------------------+---------------------------------> time t1 t2 t3 In the figure above we are reading isochronous audio data. Audio/video codec encodes samples of audio (e.g. PCM) continuously into its' buffer, and this encoded audio data can be read afterwards from the codec buffer. At t2 we read audio data (Audio n) from time interval t1 to t2. This audio data is packetized into RTP format and due to the definition of the timestamp, the RTP packet corresponding to (Audio n) is given timestamp t2 (if packetization delay is not considered). Next time audio is read at t3, and the audio data (Audio n+1) is from time interval t2 to t3. The corresponding RTP packet is given timestamp t3. These two RTP packets are transmitted through the network. The receiver depacketizes the RTP packets and extracts timestamps etc. The receiver tries to playout synchronize the received audio data by preserving the time difference between the two RTP packets, and writes the audio data to the codec in the following way: ---------- --------------------------- |Audio n | | Audio n+1 | ---------- --------------------------- --+--------+------------------------+---------------------------------> time t1' t2' t3' (t2' - t1' = t2 - t1) and (t3' - t2' = t3 - t2) If the received data is written to the codec according to the timestamps, a clear gap is created into the audio stream (a dropout in the voice). As a result, playout synchronism can not be achieved. Questions: Have we made a mistake when reading the rtp-draft? Are we using the timestamp in a way, that is not recommended? Should the RTP timestamp be used only for synchronizing RTP packet stream and not the actual data stream? The above mentioned scheme would work OK, if the timestamp would reflect the beginning of the time interval, for which the RTP packet contains data. In our example the first RTP packet would get timestamp t1, and the second RTP packet t2. This would be easily implementable in our case. All responses are appreciated. Jarmo Molsa E-mail: jarmo.molsa@vtt.fi From rem-conf-request@es.net Thu Jan 13 10:07:19 1994 Received: from duke.cs.duke.edu by osi-west.es.net via ESnet SMTP service id <00145-0@osi-west.es.net>; Thu, 13 Jan 1994 06:55:31 +0000 Received: from macbeth.cs.duke.edu by duke.cs.duke.edu (5.65/3.7G/4.1.3) id AA28710; Thu, 13 Jan 94 09:55:10 -0500 Received: from localhost by macbeth.cs.duke.edu (5.65/3.6L/4.1.3) id AA01019; Thu, 13 Jan 94 09:55:07 -0500 Message-Id: <9401131455.AA01019@macbeth.cs.duke.edu> To: Jon Crowcroft Cc: Don.Hoffman@Eng.Sun.COM (Don Hoffman), rem-conf@es.net, fenner@cmf.nrl.navy.mil Subject: in_pcb.c (was Re: Signal quality of Sunergy) In-Reply-To: Your message of "Wed, 12 Jan 1994 09:24:25 GMT." <9401120952.AA20975@duke.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 13 Jan 1994 09:55:06 -0500 From: Thomas Pusateri I'm not sure which bsd version of IP multicast is being discussed but I recently noticed some differences in in_pcb.c. There appears to be 3 versions of in_pcb.c: 1.) Original version distributed with the IP Multicast code. This is in Steve Deering's original code release on gregorio.stanford.edu and also what is in Steve McCanne's BSDI port available from ftp.ee.lbl.gov. This does not allow binding to a multicast address. 2.) Steve Deering's Sun only releases (ipmulti-sunos41x.tar.Z) includes changes to in_pcb.c that allows binding to multicast addresses. There is only a patch file to the sun source. I first noticed it in the jun24-1993 release. This is from the README_FULL_INSTALL >A new version of the kernel file in_pcb.c that allows incoming >multicast packets destined to the same UDP port to be delivered to >different processes, according to their destination IP multicast >addresses. Provided by Van Jacobson. 3.) The BSD4.4 release. This contains a third version of in_pcb.c. I do not have this running and am not sure of its operating characteristics. It appears from glancing at the code that you can bind to multicast addresses. Does someone more familiar with the code releases want to explain the difference between 2.) and 3.) ? Thanks, Tom Pusateri pusateri@cs.duke.edu In message <9401120952.AA20975@duke.cs.duke.edu> you write: > > >couple of other things i notice different about solaris and bsd >multicast > >the matching on UDP multicast PCB's seems different - there is a >question of interpretation of the spec, but basically, if a multicast >packet is sent to port p, it should be delivered to all multicast sockets >(streams?) listening/recvfroming on port p, but not to unicast ones, > >nor should a unicast packet to port p be delivered to a multicast >socket - > >where someone as a list/recvfrom on INADDR_ANY, if the port is >unicast, then packets from anywhere to unicast should get there. if >its multicast, they shouldn't, but multicast ones should - i.e. the >port space is sperate for the seperate IP address spaces, >uni&multi-cast, and the wild card match is interpreted independently > From rem-conf-request@es.net Thu Jan 13 10:09:50 1994 Received: from ninet.research.att.com by osi-west.es.net via ESnet SMTP service id <00211-0@osi-west.es.net>; Thu, 13 Jan 1994 07:01:11 +0000 Received: by research.att.com; Thu Jan 13 09:59 EST 1994 Date: Thu, 13 Jan 94 09:59:56 EST From: hgs@research.att.com (Henning G. Schulzrinne) To: Jarmo.Molsa@tel.vtt.fi Subject: Re: Question about RTP timestamps Cc: rem-conf@es.net Jarmo Molsa writes: > The above mentioned scheme would work OK, if the timestamp would > reflect the beginning of the time interval, for which the RTP packet > contains data. In our example the first RTP packet would get timestamp > t1, and the second RTP packet t2. This would be easily implementable > in our case. That is indeed the intention. Probably the spec should be more clear about this. Currently under discussion are also two changes you might want to be aware of: - timestamps can be expressed in units of the sampling frequency (e.g., if you are sampling at 8 kHz, the timestamp would increment at the same rate) - timestamps do not track wallclock time (that is, they run at the sampling clock rate, even if the sampling clock is slightly off, say, running at 8001 instead of 8000 Hz) Both of these are meant to simplify sender implementation and deal with obscure timestamp conversion problems when the sampling clock is extremely close to 65536 Hz. > > Jarmo Molsa > E-mail: jarmo.molsa@vtt.fi > --- Henning Schulzrinne (hgs@research.att.com) AT&T Bell Laboratories (MH 2A-244) 600 Mountain Ave; Murray Hill, NJ 07974 phone: +1 908 582-2262; fax: +1 908 582-5809 From rem-conf-request@es.net Thu Jan 13 15:38:14 1994 Received: from mvs.oac.ucla.edu by osi-west.es.net via ESnet SMTP service id <04190-0@osi-west.es.net>; Thu, 13 Jan 1994 12:31:03 +0000 Received: from UCLAMVS.BITNET by MVS.OAC.UCLA.EDU (IBM MVS SMTP V2R2.1) with BSMTP id 3758; Thu, 13 Jan 94 12:31:02 PST Date: Thu, 13 Jan 94 12:30 PST To: rem-conf@ES.NET From: Denis DeLaRoca (310) 825-4580 Subject: Film and Video Monthly: MBONE article! The February '94 issue of Film and Video Monthly (The Independent) focusing on New Frontiers in Interactive Media, features an article on the MBONE The MBONE's Connected to the Backbone by Patricia Thompson, pp 32 It introduces the MBONE, talks to Paul Jones at the University of North Carolina, covers the broadcast of David Blair's feature-length experimental video WAX, OR THE DISCOVERY OF TELEVISION AMONG THE BEES last may, and ends up with coverage of CU-SeeMe conferencing at Cornell. -- Denis From rem-conf-request@es.net Thu Jan 13 18:41:47 1994 Received: from picard.cmf.nrl.navy.mil by osi-west.es.net via ESnet SMTP service id <07106-0@osi-west.es.net>; Thu, 13 Jan 1994 15:35:11 +0000 Received: from riker.cmf.nrl.navy.mil (riker.cmf.nrl.navy.mil [134.207.10.69]) by picard (8.6.4/8.6.4) with SMTP id SAA05817 for ; Thu, 13 Jan 1994 18:33:47 -0500 Received: from localhost by riker.cmf.nrl.navy.mil (4.1/client-1.3) id AA28438; Thu, 13 Jan 94 18:34:21 EST Message-Id: <9401132334.AA28438@riker.cmf.nrl.navy.mil> To: rem-conf@es.net Subject: Hosts multicasting with the DF bit set Date: Thu, 13 Jan 1994 18:34:16 -0500 From: William C Fenner While I was snooping on our MBONE tunnel, I noticed several packets coming through with the DF bit set. As we all learned the other day during the Sunergy broadcast, setting DF on multicast packets can cause problems. I thought I would collect some data on who was doing this, and here is about 24 hours worth: alisa.pori.tut.fi blossom.cs.ucl.ac.uk bombur2.uio.no griffy.lbl.gov grimaldi.rutgers.edu intrepid.ecn.purdue.edu kssun11.rus.uni-stuttgart.de muumi.pori.tut.fi myy.pori.tut.fi niisku.pori.tut.fi nomad.uhcc.Hawaii.Edu nova.ballarat.EDU.AU shangchun.mathcs.emory.edu sixun.lbl.gov sun-classes.oit.gatech.edu sun.bldrdoc.gov sunoco.nswc.navy.mil topo.cs.ucl.ac.uk zombie.uoregon.edu So, if you own any of these machines, you might want to make sure that if you're sourcing large multicast packets you turn off the DF bit. Bill "Useless Statistics" Fenner From rem-conf-request@es.net Thu Jan 13 20:18:22 1994 Received: from orion.arc.nasa.gov by osi-west.es.net via ESnet SMTP service id <08385-0@osi-west.es.net>; Thu, 13 Jan 1994 17:10:11 +0000 Original-Received: Thu, 13 Jan 94 17:08:48 PST by orion.arc.nasa.gov (4.1/1.2) PP-warning: Illegal Received field on preceding line From: Nora Lavelle Message-Id: <9401140108.AA18295@orion.arc.nasa.gov> Subject: Shuttle Mission Multicast To: rem-conf@es.net Date: Thu, 13 Jan 1994 17:08:48 -0800 (PST) X-Mailer: ELM [version 2.4 PL3] Content-Type: text Content-Length: 1352 I posted this last week and I don't think it went through although I didn't receive a bounced message. If this is the first post that reached everyone I'm sorry for the short notice. I am planning to multicast the NASA Select coverage of STS-60 on a 24 hour basis starting on Jan 20, 1994 and lasting until Jan 28, 1994. This coverage will consist of nv and vat sessions. If this coverage interferes with other multicast conferences, I will be standing by to reduce bandwidth or suspend coverage in order to share the MBONE. I will be multicasting with a ttl of 127. If there are any problems or question regarding this multicast please mail them to: anaops@atlas.arc.nasa.gov -------------------------------------------------------------------------------- __ __ ________ __ ___ Nora Lavelle /\_\ /\_\ /_______/\ /\_\ /\__\ System Adminstrator / / / / / / \ _____\/ / / / / / _ \ Sterling Software / / /__/ / / \ \ \______ / / /___ / / /_\ \ / / /___\/ / \ \/_____/\ / / /_____\ / / ___ \ \/_______ / \_______\/ \/________/ \/__/ \__\ NASA Ames Research Center -------------------------------------------------------------------------------- From rem-conf-request@es.net Thu Jan 13 20:55:39 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <08781-0@osi-west.es.net>; Thu, 13 Jan 1994 17:47:00 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <15370(3)>; Thu, 13 Jan 1994 17:46:51 PST Received: from localhost by ecco.parc.xerox.com with SMTP id <16136>; Thu, 13 Jan 1994 17:46:49 -0800 To: William C Fenner cc: rem-conf@es.net Subject: Re: Hosts multicasting with the DF bit set In-reply-to: Your message of "Thu, 13 Jan 94 15:34:16 PST." <9401132334.AA28438@riker.cmf.nrl.navy.mil> X-Mailer: exmh version 1.2delta 1/6/94 Date: Thu, 13 Jan 1994 17:46:34 PST Sender: Ron Frederick From: Ron Frederick Message-Id: <94Jan13.174649pst.16136@ecco.parc.xerox.com> In message <9401132334.AA28438@riker.cmf.nrl.navy.mil> you write: > While I was snooping on our MBONE tunnel, I noticed several packets > coming through with the DF bit set. As we all learned the other day > during the Sunergy broadcast, setting DF on multicast packets can cause > problems. I thought I would collect some data on who was doing this, > and here is about 24 hours worth: > > [list deleted] > > So, if you own any of these machines, you might want to make sure that if > you're sourcing large multicast packets you turn off the DF bit. > I know this was a problem during the Sunergy broadcast, but that's mostly because they were using a version of 'nv' that still has the bug in it about generating oversize packets. It really should never have done that. I'm not sure it is really correct to say that setting DF on multicast is a bad idea in general. With properly written tools, not fragmenting packets is probably correct in most cases... -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Fri Jan 14 00:55:19 1994 Received: from ell.ee.lbl.gov by osi-west.es.net via ESnet SMTP service id <10446-0@osi-west.es.net>; Thu, 13 Jan 1994 21:49:31 +0000 Received: by ell.ee.lbl.gov for rem-conf@es.net (5.65/1.43r) id AA23156; Thu, 13 Jan 94 21:49:27 -0800 From: mccanne@ee.lbl.gov (Steven McCanne) Message-Id: <9401140549.AA23156@ell.ee.lbl.gov> To: Thomas Pusateri Cc: rem-conf@es.net Subject: Re: in_pcb.c (was Re: Signal quality of Sunergy) In-Reply-To: Your message of Thu, 13 Jan 94 09:55:06 -0500. <9401131455.AA01019@macbeth.cs.duke.edu> Date: Thu, 13 Jan 94 21:49:27 PST > There appears to be 3 versions of in_pcb.c: > > 1.) Original version distributed with the IP Multicast code. This is in > Steve Deering's original code release on gregorio.stanford.edu > and also what is in Steve McCanne's BSDI port available from > ftp.ee.lbl.gov. This does not allow binding to a multicast address. The missing in_pcb.c changes for the bsdi port was an oversight. I've updated ftp.ee.lbl.gov:bsd386-ipmcast.tar.Z to include an in_pcb.c with Van's latest pcb semantics (i.e., equivalent to the in_pcb.c in ipmulti-sunos41x.tar.Z at Stanford). I had sent the changes to bsdi and the NetBSD maintainers a while back. Unlike the old bsd code (and the current 4.4bsd code), this version meets the Host Requirements (according to Van). Steve From rem-conf-request@es.net Fri Jan 14 04:26:50 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <11920-0@osi-west.es.net>; Fri, 14 Jan 1994 01:19:09 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 14 Jan 1994 09:18:52 +0000 To: " (Steven McCanne)" cc: Thomas Pusateri , rem-conf@es.net Subject: Re: in_pcb.c (was Re: Signal quality of Sunergy) In-reply-to: Your message of "Fri, 14 Jan 94 05:55:25 GMT." <9401140549.AA23156@ell.ee.lbl.gov> Date: Fri, 14 Jan 94 09:18:51 +0000 From: Jon Crowcroft >> There appears to be 3 versions of in_pcb.c: >Unlike the old bsd code (and the current 4.4bsd code), this version >meets the Host Requirements (according to Van). right, but host requirements says: For most purposes, a datagram addressed to a broadcast or multicast destination is processed as if it had been addressed to one of the host's IP addresses; we use the term "specific-destination address" for the equivalent local IP Internet Engineering Task Force [Page 31] however, this doesn't make sense to me - after a long exchange with richard balck in cambridge, he convinced me that the pair ipaddr + port forms an address space that must be different for unicast and multicast, otherwise current unicast applications can get broken by new multicast ones that use the same port...surely? sorry to bring this up again - i'm sure it was discussed to pieces in 88 when steve D was devising all this stuff... jon From rem-conf-request@es.net Fri Jan 14 08:23:11 1994 Received: from faui45.informatik.uni-erlangen.de by osi-west.es.net via ESnet SMTP service id <13167-0@osi-west.es.net>; Fri, 14 Jan 1994 05:12:59 +0000 Received: from faui43.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA14614 (5.65c-6/7.3v-FAU); Fri, 14 Jan 1994 14:11:11 +0100 Received: from faui45r.informatik.uni-erlangen.de by immd4.informatik.uni-erlangen.de with SMTP; id AA15868 (5.65c-6/7.3m-FAU); Fri, 14 Jan 1994 14:11:09 +0100 From: Toerless Eckert Message-Id: <199401141311.AA15868@faui43.informatik.uni-erlangen.de> Subject: Re: in_pcb.c (was Re: Signal quality of Sunergy) To: Jon Crowcroft Date: Fri, 14 Jan 94 14:11:04 MET Cc: mccanne@ee.lbl.gov, pusateri@cs.duke.edu, rem-conf@es.net In-Reply-To: <199401141035.AA04957@faui45.informatik.uni-erlangen.de>; from "Jon Crowcroft" at Jan 14, 94 9:18 am Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.3 PL11] > From rem-conf-request@es.net Fri Jan 14 11:36 MET 1994 > Received: from faui45.informatik.uni-erlangen.de by immd4.informatik.uni-erlangen.de with SMTP; > id AA11123 (5.65c-6/7.3m-FAU); Fri, 14 Jan 1994 11:36:04 +0100 > Received: from osi-west.es.net by uni-erlangen.de with SMTP; > id AA04957 (5.65c-6/7.3v-FAU); Fri, 14 Jan 1994 11:35:55 +0100 > Message-Id: <199401141035.AA04957@faui45.informatik.uni-erlangen.de> > Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service > id <11920-0@osi-west.es.net>; Fri, 14 Jan 1994 01:19:09 +0000 > Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP > id ; Fri, 14 Jan 1994 09:18:52 +0000 > To: " (Steven McCanne)" > Cc: Thomas Pusateri , rem-conf@es.net > Subject: Re: in_pcb.c (was Re: Signal quality of Sunergy) > In-Reply-To: Your message of "Fri, 14 Jan 94 05:55:25 GMT." <9401140549.AA23156@ell.ee.lbl.gov> > Date: Fri, 14 Jan 94 09:18:51 +0000 > From: Jon Crowcroft > > > > >> There appears to be 3 versions of in_pcb.c: > > >Unlike the old bsd code (and the current 4.4bsd code), this version > >meets the Host Requirements (according to Van). > > right, but host requirements says: > For most purposes, a datagram addressed to a broadcast or > multicast destination is processed as if it had been > addressed to one of the host's IP addresses; we use the > term "specific-destination address" for the equivalent local IP > > Internet Engineering Task Force [Page 31] > > however, this doesn't make sense to me - after a long exchange with > richard balck in cambridge, he convinced me that the pair > ipaddr + port forms an address space that must be different for > unicast and multicast, otherwise current unicast applications can get > broken by new multicast ones that use the same port...surely? > > sorry to bring this up again - i'm sure it was discussed to pieces in > 88 when steve D was devising all this stuff... The problem with current unix implementation may be - as far as i understand it - that applications binding to a certain socket (i.e.: who want to receive traffic) will usually bind only to the port of the socket, so that they will work on multi homed machines. If an application only binds to one local ip address and port, it will not receive packets destined to other local ip addresses of the same multi homed machine. I am not sure if this behaviour still causes those kinds of applications to receive traffic destined to a multicast address (and the same port), i.e.: because there is some other application that listens on the multicast address. Surely it is no problem to have applications that only bind and listen to a single port only receive traffic for any of the local unicast ip addresses, and i even think that the multicast extensions already provide for this behaviour, i.e.: There should be no problem in this case, because application with no knowledge of multicast would not be involved in multicast traffic. Regards Toerless Eckert > > > jon > -- Toerless Eckert Universitaet Erlangen Nuernberg Lehrstuhl fuer Betriebsysteme Martensstrasse 1 D-91058 Erlangen, Germany Tel.: +49 9131 85 7278 FAX: +49 9131 85 8732 / +49 9131 39388 Toerless.Eckert@Informatik.Uni-Erlangen.DE /C=De/A=D400/P=Uni-Erlangen/OU=Informatik/S=Eckert/G=Toerless/ From rem-conf-request@es.net Fri Jan 14 08:56:38 1994 Received: from mbunix.mitre.org by osi-west.es.net via ESnet SMTP service id <13364-0@osi-west.es.net>; Fri, 14 Jan 1994 05:48:59 +0000 Received: by mbunix.mitre.org (931110.SGI.ANONFTP/4.7) id AA20209; Fri, 14 Jan 94 08:48:52 -0500 Date: Fri, 14 Jan 94 08:48:52 -0500 From: dpk@mbunix.mitre.org (Koester) Message-Id: <9401141348.AA20209@mbunix.mitre.org> Posted-From: The MITRE Corporation, Bedford, MA To: rem-conf@es.net Subject: sv access through a Mosaic server I recently encountered the MBONE FAQ on an AT&T Mosaic server. It was nice to have a hypertext index when discussing MBONE capabilities in a discussion on emerging technologies. Due to various corporate INFOSEC requirements, many of us cannot get MBONE on our desktop workstations. Has anyone tied sv to a Mosaic server so that people can remotely check on what is available? I can run Mosaic on the corporate firewall and view it as a remote X-windows application, however, I cannot get MBONE software products on my firewall. I would appreciate hearing whether or not anyone has implemented this. David Koester dpk@mbunix.mitre.org From rem-conf-request@es.net Fri Jan 14 10:18:12 1994 Received: from relay.hp.com by osi-west.es.net via ESnet SMTP service id <13961-0@osi-west.es.net>; Fri, 14 Jan 1994 07:08:25 +0000 Received: from it_750.ch.apollo.hp.com by relay.hp.com with SMTP (1.36.108.7/15.5+IOS 3.13) id AA06022; Fri, 14 Jan 1994 07:08:23 -0800 Message-Id: <9401141508.AA06022@relay.hp.com> Received: from york.ch.apollo.hp.com by it_750.ch.apollo.hp.com for rem-conf@es.net id AA04042; Fri, 14 Jan 1994 10:08:21 -0500 To: rem-conf@es.net Subject: Looking for imm app Date: Fri, 14 Jan 94 10:08:20 -0500 From: John Brezak Where can I find the "imm" application to view the JPEG satelite data ? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= John Brezak UUCP: uunet!apollo.hp!brezak Hewlett Packard/Apollo Internet: brezak@ch.hp.com 300 Apollo Drive Phone: (508) 436-4915 Chelmsford, Massachusetts Fax: (508) 436-5103 From rem-conf-request@es.net Fri Jan 14 11:41:36 1994 Received: from picard.cmf.nrl.navy.mil by osi-west.es.net via ESnet SMTP service id <15068-0@osi-west.es.net>; Fri, 14 Jan 1994 08:40:24 +0000 Received: from herman.cmf.nrl.navy.mil (herman-atm.cmf.nrl.navy.mil [134.207.10.3]) by picard (8.6.4/8.6.4) with SMTP id LAA10075; Fri, 14 Jan 1994 11:39:01 -0500 Received: from localhost by herman.cmf.nrl.navy.mil (4.1/client-1.3) id AA03385; Fri, 14 Jan 94 11:39:04 EST Message-Id: <9401141639.AA03385@herman.cmf.nrl.navy.mil> To: dpk@mbunix.mitre.org (Koester) Cc: rem-conf@es.net Subject: Re: sv access through a Mosaic server In-Reply-To: Your message of "Fri, 14 Jan 94 08:48:52 EST." <9401141348.AA20209@mbunix.mitre.org> X-Face: -*.ZYbFWa}{2c8NmF| > Has anyone tied sv to a Mosaic > server so that people can remotely check on > what is available? I assume you mean "sd", not "sv" . I've been idly tossing around the idea of creating an application that just listens for the session advertisements and updates an HTML page with them, but I couldn't really think any real uses for it. Do you just want to see what sessions are there? If you can't run the applications to recieve the sessions, then what good does that do you? Bill From rem-conf-request@es.net Fri Jan 14 13:57:59 1994 Received: from zephyr.isi.edu by osi-west.es.net via ESnet SMTP service id <17219-0@osi-west.es.net>; Fri, 14 Jan 1994 10:49:19 +0000 Received: by zephyr.isi.edu (5.65c/5.61+local-16) id ; Fri, 14 Jan 1994 10:49:10 -0800 Date: Fri, 14 Jan 1994 10:49:10 -0800 From: braden@ISI.EDU (Bob Braden) Message-Id: <199401141849.AA28816@zephyr.isi.edu> To: J.Crowcroft@cs.ucl.ac.uk Subject: multicast addressing Cc: rem-conf@es.net *> *> right, but host requirements says: *> For most purposes, a datagram addressed to a broadcast or *> multicast destination is processed as if it had been *> addressed to one of the host's IP addresses; we use the *> term "specific-destination address" for the equivalent local IP *> *> Internet Engineering Task Force [Page 31] *> *> however, this doesn't make sense to me - after a long exchange with *> richard balck in cambridge, he convinced me that the pair *> ipaddr + port forms an address space that must be different for *> unicast and multicast, otherwise current unicast applications can get *> broken by new multicast ones that use the same port...surely? *> Jon, I have not reviewed the email on this one, but I believe that is exactly the intent of the Host Requirements spec... the multicast address was not intended to be a separate address space. In other words, we believed that it SHOULD break an existing application if it used the same destination port (and source port and source host), but with a multicast address. Bob Braden From rem-conf-request@es.net Fri Jan 14 15:10:19 1994 Received: from duke.cs.duke.edu by osi-west.es.net via ESnet SMTP service id <18474-0@osi-west.es.net>; Fri, 14 Jan 1994 12:02:49 +0000 Received: from macbeth.cs.duke.edu by duke.cs.duke.edu (5.65/3.7G/4.1.3) id AA04556; Fri, 14 Jan 94 15:02:46 -0500 Received: from localhost by macbeth.cs.duke.edu (5.65/3.6L/4.1.3) id AA11803; Fri, 14 Jan 94 15:02:45 -0500 Message-Id: <9401142002.AA11803@macbeth.cs.duke.edu> To: William C Fenner Cc: rem-conf@es.net Subject: sd-listen (was Re: sv access through a Mosaic server) In-Reply-To: Your message of "Fri, 14 Jan 1994 11:39:02 EST." <9401141639.AA03385@herman.cmf.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 14 Jan 1994 15:02:44 -0500 From: Thomas Pusateri In message <9401141639.AA03385@herman.cmf.nrl.navy.mil> you write: > >I've been idly tossing around the idea of creating an application that just >listens for the session advertisements and updates an HTML page with them, but > >I couldn't really think any real uses for it. > I wrote a short hack to listen for SD announcements and print them out for use on the RS6000 since there is not yet SD support available for it. I didn't post it because I thought there might be a reason why source wasn't available for sd. I can sent it to you or if others want it and the SD people don't mind, I'll post it. Tom Pusateri From rem-conf-request@es.net Fri Jan 14 19:37:31 1994 Received: from hplms26.hpl.hp.com by osi-west.es.net via ESnet SMTP service id <22780-0@osi-west.es.net>; Fri, 14 Jan 1994 16:31:19 +0000 Received: from hplms2.hpl.hp.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA07132; Fri, 14 Jan 94 16:31:13 -0800 Received: from opera.hpl.hp.com by hplms2.hpl.hp.com with SMTP (1.37.109.8/15.5+ECS 3.3+HPL1.1I) id AA21500; Fri, 14 Jan 1994 16:30:57 -0800 Received: by opera.hpl.hp.com (1.37.109.8/HPL42.42) id AA06508; Fri, 14 Jan 1994 16:30:57 -0800 From: Yee-Hsiang Chang Message-Id: <9401150030.AA06508@opera.hpl.hp.com> Subject: Re: sv access through a Mosaic server To: fenner@cmf.nrl.navy.mil (William C Fenner) Date: Fri, 14 Jan 94 16:30:56 PST Cc: dpk@mbunix.mitre.org, rem-conf@es.net In-Reply-To: <9401141639.AA03385@herman.cmf.nrl.navy.mil>; from "William C Fenner" at Jan 14, 94 11:39 am X-Hpvue$Revision: 1.8 $ Mime-Version: 1.0 Content-Type: Message/rfc822 X-Vue-Mime-Level: 4 Mailer: Elm [revision: 70.85] > > I've been idly tossing around the idea of creating an application that just > listens for the session advertisements and updates an HTML page with them, but > I couldn't really think any real uses for it. > I think there is an issue of whether the current conference announcement and discovery paradigm using by "sd" and partially by mailing list announcement is the best one. If a wide-area directory service such as the Mosaic can be tailored for the conference announcement and discovery, we do not need to send event message periodically. -- Yee-Hsiang Chang HP Labs 1501 Page Mill Road Palo Alto, CA 94304-1126 email: yhc@hpl.hp.com phone: 415-857-7398 From rem-conf-request@es.net Sat Jan 15 01:57:43 1994 Received: from picard.cmf.nrl.navy.mil by osi-west.es.net via ESnet SMTP service id <25151-0@osi-west.es.net>; Fri, 14 Jan 1994 22:52:43 +0000 Received: from riker.cmf.nrl.navy.mil (riker.cmf.nrl.navy.mil [134.207.10.69]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id BAA15581; Sat, 15 Jan 1994 01:51:09 -0500 Received: from localhost by riker.cmf.nrl.navy.mil (4.1/client-1.3) id AA03481; Sat, 15 Jan 94 01:51:46 EST Message-Id: <9401150651.AA03481@riker.cmf.nrl.navy.mil> To: Yee-Hsiang Chang Cc: rem-conf@es.net, www-talk@www0.cern.ch Subject: Re: sd access through a WWW server In-Reply-To: Your message of "Fri, 14 Jan 94 16:30:56 PST." <9401150030.AA06508@opera.hpl.hp.com> X-Face: -*.ZYbFWa}{2c8NmF| [For those on the www-talk mailing list: the idea is to have the ability to use WWW for a session directory for multicast conferences. Many multicast conferences have a limited lifetime, so the use of a less dynamic system such as WWW may not be preferable.] On Fri, 14 Jan 94 16:30:56 PST Yee-Hsiang Chang wrote: > If a wide-area directory service such as > the Mosaic can be tailored for the conference announcement and discovery, > we do not need to send event message periodically. One of the other ideas that I've been tossing around is to create an application/x-sd type in HTTP, which simply passes the sd entry to a program that does whatever sd would do with that entry - then people running Mosaic with a proper ~/.mailcap could actually launch multicast applications by clicking on a hypertext link. I prefer application/x-sd to application/x-csh because it allows the client to decide what application to run for each session type, instead of forcing the server to make assumptions. If there is interest for this as well, I might crank it up a couple of notches on my priority list. Bill From rem-conf-request@es.net Sat Jan 15 06:41:23 1994 Received: from anusf.anu.edu.au by osi-west.es.net via ESnet SMTP service id <26502-0@osi-west.es.net>; Sat, 15 Jan 1994 03:36:08 +0000 Received: by anusf.anu.edu.au id AA05469 (5.65c/IDA-1.4.3 for rem-conf@es.net); Sat, 15 Jan 1994 22:37:58 +1100 From: Merik Karman Message-Id: <199401151137.AA05469@anusf.anu.edu.au> Subject: Multicast Kernel mods on Solbourne To: rem-conf@es.net Date: Sat, 15 Jan 94 22:37:57 EST Cc: merik@blackadder.dsh.oz.au X-Mailer: ELM [version 2.3 PL0] Hi, I am trying to get the multicast mods running on a Solbourne S4000 sparc box. It has 4.1B revision operating system which is 4.1.2 based. Has anyone got this configuration working or able to offer any tips. Thanks Merik Karman From rem-conf-request@es.net Sun Jan 16 09:16:32 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <01806-0@osi-west.es.net>; Sun, 16 Jan 1994 06:11:31 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 16 Jan 1994 14:11:15 +0000 To: braden@ISI.EDU (Bob Braden) cc: rem-conf@es.net Subject: Re: multicast addressing In-reply-to: Your message of "Fri, 14 Jan 94 10:49:10 PST." <199401141849.AA28816@zephyr.isi.edu> Date: Sun, 16 Jan 94 14:11:13 +0000 From: Jon Crowcroft >I have not reviewed the email on this one, but I believe that is exactly >the intent of the Host Requirements spec... the multicast address was not >intended to be a separate address space. In other words, we believed >that it SHOULD break an existing application if it used the same >destination port (and source port and source host), but with a multicast >address. Bob but the way things have evolved, its not clear to me this is right - jsut about the only hing that does switch from multicast to unicast is the way (i believe) vat does asides... and that could be done otherwise.... multicast addresses were always in some sense logical, while unicast IP was always 'an interface' and explicitly NOT and end system ID. surely it is dodgy to mix this up? jon From rem-conf-request@es.net Sun Jan 16 14:50:25 1994 Received: from zephyr.isi.edu by osi-west.es.net via ESnet SMTP service id <02757-0@osi-west.es.net>; Sun, 16 Jan 1994 11:49:39 +0000 Received: by zephyr.isi.edu (5.65c/5.61+local-16) id ; Sun, 16 Jan 1994 11:49:25 -0800 Date: Sun, 16 Jan 1994 11:49:25 -0800 From: braden@ISI.EDU (Bob Braden) Message-Id: <199401161949.AA26677@zephyr.isi.edu> To: braden@ISI.EDU, J.Crowcroft@cs.ucl.ac.uk Subject: Re: multicast addressing Cc: rem-conf@es.net *> *> but the way things have evolved, its not clear to me this is right - *> jsut about the only hing that does switch from multicast to unicast is *> the way (i believe) vat does asides... and that could be done *> otherwise.... *> Evolved? I suspect you refer the work-arounds we have had to make for implementation weaknesses; not a good argument in the standards world, normally. But maybe you mean something different. *> multicast addresses were always in some sense logical, while unicast *> IP was always 'an interface' and explicitly NOT and end system ID. *> surely it is dodgy to mix this up? *> *> *> jon *> *> But all the interface addresses of a given multihomed host point to the same [I hate saying this!] "transport service access point". The multicast address is a new logical address for the entity, but to introduce a whole new TSAP for multicast addressing seems to me to be the wrong idea. Bob From rem-conf-request@es.net Sun Jan 16 21:01:54 1994 Received: from anu.anu.edu.au by osi-west.es.net via ESnet SMTP service id <04071-0@osi-west.es.net>; Sun, 16 Jan 1994 17:56:49 +0000 Received: from acat.kimba (acat.anu.edu.au) by anu.anu.edu.au (4.1/SMI-4.1) id AA21297; Mon, 17 Jan 94 12:56:43 EST Received: by acat.kimba (4.1/SMI-4.1) id AA03285; Mon, 17 Jan 94 12:55:05 EST Date: Mon, 17 Jan 94 12:55:05 EST From: fractal@acat.anu.edu.au (Fractal) Message-Id: <9401170155.AA03285@acat.kimba> To: rem-conf@es.net Subject: please subscribe me Stuart Ramsden fractal@acat.anu.edu.au From rem-conf-request@es.net Sun Jan 16 22:49:27 1994 Received: from psych.psy.uq.oz.au by osi-west.es.net via ESnet SMTP service id <04689-0@osi-west.es.net>; Sun, 16 Jan 1994 19:44:09 +0000 Received: from localhost by psych.psy.uq.oz.au id ; Mon, 17 Jan 1994 13:43:56 +1000 Message-Id: <199401170343.NAA27766@psych.psy.uq.oz.au> To: Thomas Pusateri cc: rem-conf@es.net Subject: Re: sd-listen (was Re: sv access through a Mosaic server) In-reply-to: Your message of Fri, 14 Jan 1994 15:02:44 -0500. <9401142002.AA11803@macbeth.cs.duke.edu> Date: Mon, 17 Jan 1994 13:43:55 +1000 From: Robert Dal Santo >In message <9401141639.AA03385@herman.cmf.nrl.navy.mil> you write: >> >>I've been idly tossing around the idea of creating an application that just >>listens for the session advertisements and updates an HTML page with them, but >> >>I couldn't really think any real uses for it. >> > >I wrote a short hack to listen for SD announcements and print them >out for use on the RS6000 since there is not yet SD support available for >it. I didn't post it because I thought there might be a reason why source >wasn't available for sd. I can sent it to you or if others want it and >the SD people don't mind, I'll post it. > Could you send me this program ?? I am interesting in manipulating SD packets from outside sd as I can't always be here to run SD after system reboots. Thanks, =========================================================================== Robert Dal Santo Phone +61 7 365 6687 Fax +61 7 365 4466 Department of Psychology, University of Queensland 4072, AUSTRALIA. "I've reached the driveway to destruction and I'm taking the stationwagon." From rem-conf-request@es.net Sun Jan 16 23:00:44 1994 Received: from relay.hp.com by osi-west.es.net via ESnet SMTP service id <04794-0@osi-west.es.net>; Sun, 16 Jan 1994 19:56:05 +0000 Received: from it_750.ch.apollo.hp.com by relay.hp.com with SMTP (1.36.108.7/15.5+IOS 3.13) id AA24730; Sun, 16 Jan 1994 19:54:30 -0800 Message-Id: <9401170354.AA24730@relay.hp.com> Received: from york.ch.apollo.hp.com by it_750.ch.apollo.hp.com for rem-conf@es.net id AA18451; Sun, 16 Jan 1994 22:54:24 -0500 To: rem-conf@es.net Subject: NetBSD: IP Mcast + mrouted can cause a panic Date: Sun, 16 Jan 94 22:54:24 -0500 From: John Brezak [ Not sure if this is allowed on this list, but I'm sure someone will tell me if it isn't... ] This is in NetBSD from code derived from the bsd386 port. So far here is a stack traceback of the panic. panic("m_copym") // Helpful 'eh ? panic m_copym+0x4e ip_output+0x5a0 ip_mforward+0x21b (phyint_send) ip_mforward+0x1b0 ipintr+0x1f6 spl0+0x38 comintr+0x3b Xcom1+0x52 It appears to be happening when IP fragmentation is happening for the SLIP interface. I also have an ethernet locally. What I'm trying to do is setup a limited tunnel to home and feed a local network. Here is a snap of my /etc/mrouted.conf file: phyint 15.20.0.221 disable # sl0 tunnel 15.20.0.221 15.22.49.100 metric 2 threshold 128 [ The intent here is to not feed sl0 - this is where other end of the tunnel is. I want to feed the ed0 network. ] Any ideas/clues ? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= John Brezak UUCP: uunet!apollo.hp!brezak Hewlett Packard/Apollo Internet: brezak@ch.hp.com 300 Apollo Drive Phone: (508) 436-4915 Chelmsford, Massachusetts Fax: (508) 436-5103 From rem-conf-request@es.net Mon Jan 17 02:51:03 1994 Received: from ell.ee.lbl.gov by osi-west.es.net via ESnet SMTP service id <06544-0@osi-west.es.net>; Sun, 16 Jan 1994 23:45:44 +0000 Received: by ell.ee.lbl.gov for rem-conf@es.net (5.65/1.43r) id AA29275; Sun, 16 Jan 94 23:45:43 -0800 From: mccanne@ee.lbl.gov (Steven McCanne) Message-Id: <9401170745.AA29275@ell.ee.lbl.gov> To: rem-conf@es.net Subject: new vat (v3.2) available for anonymous ftp Date: Sun, 16 Jan 94 23:45:42 PST There's a new version of vat available for anonymous ftp from ftp.ee.lbl.gov in conferencing/vat/*-vat-3.2.tar.Z. Thanks to everyone for the great feedback we got on v3.1. This new release primarily fixes bugs and incorporates (most of) the suggestions on v3.1. The major changes are listed below. Bugs, questions, and comments to vat@ee.lbl.gov. Steve & Van ----------- v3.2 Sun Jan 16 23:18:49 PST 1994 - Removed maximum size limitation on vat window (suggested by Denton Gentry). - Added time-of-day of last activity to stat window. Update session name and audio format in stat window when it changes. - Tuned sitebox drawing code so exposure events don't cause entire window to flicker (problem reported by Ron Frederick). - Fixed wrapping XID bug (reported by Anders Klemets). - Documented `-u' command switch which allows you to override vat's built-in tcl program with your own script. We're releasing the source code to vat's tcl script so you experiment with the user interface (i.e., fix our bugs) and use it as a reference when our documentation is lacking. The preferred way to make customizations to the script is to override tcl procedures and variables with customized tcl code in $HOME/.vat.tcl. - Append uid to audio lock file name so that different users won't collide with eachother. The presumption is only one user at a time will try to use the audio hardware and since the lock files are never deleted, we make them unique. (suggestion from Tomi Leppikangas) - Added `-g' command option to specify window geometry. Replaces `-geometry' flag from vat-2 (which had been parsed by InterViews). (thanks to Atanu Ghosh) - Changed the user interface to the audio device aquisition. The ``Keep'' button prevents other vats from taking the audio, and the ``Release'' button explicitly releases the device. The title string is shown in an oblique font when the audio is not held. (These changes inspired by discussions with George Michaelson, Ron Frederick, and Steve Casner.) - Fix "entry" bindings so that C-d deletes selection if it exists (thanks to Mark Prior) Fix C-k to delete from cursor to end. Fix other miscellaneous entry problems (reported by Bill Fenner). - Lots of good fixes suggested by Steve Casner: made stat window reliefs raised instead of sunken; animate mute, menu, and help buttons; removed "help" title from help window since it's redundant with the window manager's title (the vat developer's don't use window manager title bars and we've repeatedly made the mistake of adding them to the application.); shutdown gracefully when window is destroyed by external agent; make peak indicator in VU meter change color above *VatVU.hotLevel percent of full scale. default is 90%. *VatVU.hot sets the color, which defaults to firebrick1; fixed lots of window title bugs. - Make sure windows are mapped entirely within the screen (suggestion by many). - Disable input/output port buttons when not selectable (suggestion from George Michaelson). - Replace "Okay" button labels with "Dismiss" (suggestion from Piete Brooks). - Recode sitebox drawing algorithm to work around bug in broken Parallax X servers that caused names to be imaged into the root window (reported by Steve Casner and Bill Fenner). - Fixed bug that caused occasional core dumps when bringing up stat window (thanks to Piete Brooks). - Fixed bug that caused bogus placement of popup windows with virtual desktops (thanks to Bruce Mah). From rem-conf-request@es.net Mon Jan 17 09:37:51 1994 Received: from mahler.belnet.be by osi-west.es.net via ESnet SMTP service id <10280-0@osi-west.es.net>; Mon, 17 Jan 1994 06:37:07 +0000 Received: from rc1.vub.ac.be by mahler.belnet.be with SMTP (PP); Mon, 17 Jan 1994 15:36:27 +0100 Received: from vnet3.vub.ac.be by rc1.vub.ac.be (4.1/RC1-931231) id AA21416; Mon, 17 Jan 94 15:39:33 +0100 Received: from [134.184.15.105] (rcmc5) by vnet3.vub.ac.be (4.1/VUB.920213) id AA13668; Mon, 17 Jan 94 15:39:28 +0100 Message-Id: <9401171439.AA13668@vnet3.vub.ac.be> Date: Mon, 17 Jan 1994 15:39:29 +0100 To: pusateri@cs.duke.edu From: rjansen@vnet3.vub.ac.be (Robert Jansen \(VUBnet\)) Subject: Re: sd-listen (was Re: sv access through a Mosaic server) Cc: rem-conf@es.net At 4:43 AM 1/17/94 +0100, Robert Dal Santo wrote: >>In message <9401141639.AA03385@herman.cmf.nrl.navy.mil> you write: >>> >>>I've been idly tossing around the idea of creating an application that just >>>listens for the session advertisements and updates an HTML page with them, >>>but >>> >>>I couldn't really think any real uses for it. >>> >> >>I wrote a short hack to listen for SD announcements and print them >>out for use on the RS6000 since there is not yet SD support available for >>it. I didn't post it because I thought there might be a reason why source >>wasn't available for sd. I can sent it to you or if others want it and >>the SD people don't mind, I'll post it. >> > > Could you send me this program ?? I am interesting in manipulating SD >packets from outside sd as I can't always be here to run SD after system >reboots. > >Thanks, > > >=========================================================================== >Robert Dal Santo Phone +61 7 365 6687 > Fax +61 7 365 4466 >Department of Psychology, >University of Queensland 4072, >AUSTRALIA. > >"I've reached the driveway to destruction and I'm taking the stationwagon." Mhhh.... handy for non-windowed users. Could you send it to root@vnet2.vub.ac.be (that's me :)) . Thanks in advance. Greetings from Belgium. -------------------------- Brussels University Pleinlaan 2 Computer Center VUB/ULB (VUBnet) Robert Jansen B-1050 Brussels Belgium (Europe) email: rjansen@vnet3.vub.ac.be Tel: +32-2-650.37.29 Secr: +32-2-650.37.38 Fax: +32-2-650.37.40 -------------------------- From rem-conf-request@es.net Mon Jan 17 10:56:33 1994 Received: from relay.hp.com by osi-west.es.net via ESnet SMTP service id <11341-0@osi-west.es.net>; Mon, 17 Jan 1994 07:44:13 +0000 Received: from it_750.ch.apollo.hp.com by relay.hp.com with SMTP (1.36.108.7/15.5+IOS 3.13) id AA00595; Mon, 17 Jan 1994 07:42:07 -0800 Message-Id: <9401171542.AA00595@relay.hp.com> Received: from york.ch.apollo.hp.com by it_750.ch.apollo.hp.com for rem-conf@es.net id AA28432; Mon, 17 Jan 1994 10:42:00 -0500 To: mccanne@ee.lbl.gov (Steven McCanne), cmaeda@cs.washington.edu Cc: rem-conf@es.net Subject: Re: NetBSD: IP Mcast + mrouted can cause a panic In-Reply-To: Your message of "Sun, 16 Jan 94 23:59:23 PST." <9401170759.AA29425@ell.ee.lbl.gov> Date: Mon, 17 Jan 94 10:41:59 -0500 From: John Brezak > > [ Not sure if this is allowed on this list, but I'm sure someone will > > tell me if it isn't... ] > > mbone@isi.edu is more appropriate. > > There are some bugs in bsd/386 patches on ftp.ee.lbl.gov. > I sent the patches below to cgd about a week ago. One of these > is probably causing your crash (the "tunnel_src" patch is just > a performance issue; the other three are real bugs). > > Steve I've now applied these patches and it still crashes. It appears to be in the fragmentation loop. It is trying to frag a packet of 0x5c8 bytes. I believe this to be the related panic in m_copym(). What other data can I try to get ? struct mbuf * m_copym(m, off0, len, wait) register struct mbuf *m; int off0, wait; register int len; { register struct mbuf *n, **np; register int off = off0; struct mbuf *top; int copyhdr = 0; if (off < 0 || len < 0) panic("m_copym"); if (off == 0 && m->m_flags & M_PKTHDR) copyhdr = 1; while (off > 0) { if (m == 0) panic("m_copym"); if (off < m->m_len) break; off -= m->m_len; m = m->m_next; } np = ⊤ top = 0; =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= John Brezak UUCP: uunet!apollo.hp!brezak Hewlett Packard/Apollo Internet: brezak@ch.hp.com 300 Apollo Drive Phone: (508) 436-4915 Chelmsford, Massachusetts Fax: (508) 436-5103 From rem-conf-request@es.net Mon Jan 17 11:00:37 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <11388-0@osi-west.es.net>; Mon, 17 Jan 1994 07:49:36 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 17 Jan 1994 15:46:26 +0000 To: braden@ISI.EDU (Bob Braden) cc: rem-conf@es.net Subject: Re: multicast addressing In-reply-to: Your message of "Sun, 16 Jan 94 11:49:25 PST." <199401161949.AA26677@zephyr.isi.edu> Date: Mon, 17 Jan 94 15:46:21 +0000 From: Jon Crowcroft >Evolved? I suspect you refer the work-arounds we have had to make for >implementation weaknesses; not a good argument in the standards world, >normally. But maybe you mean something different. oh - i thought workarounds for the way things work is how we do internet standards:-) > > *> multicast addresses were always in some sense logical, while unicast > *> IP was always 'an interface' and explicitly NOT and end system ID. > *> surely it is dodgy to mix this up? > *> > *> > *> jon > *> > *> > >But all the interface addresses of a given multihomed host point to the >same [I hate saying this!] "transport service access point". The >multicast address is a new logical address for the entity, but to >introduce a whole new TSAP for multicast addressing seems to me to be >the wrong idea. ok - i didn't want to make a federal case out of it:-) SIPP should clarify this though with its cleaner addressing model (while CLNP wil lno doubt give us 17 different new options, like prefix scoping!!! actually, does SIPP multicast do prefix scoping?) cheers jon From rem-conf-request@es.net Mon Jan 17 12:04:04 1994 Received: from mercury.unt.edu by osi-west.es.net via ESnet SMTP service id <12363-0@osi-west.es.net>; Mon, 17 Jan 1994 09:02:52 +0000 Received: from sol.acs.unt.edu by mercury.unt.edu with SMTP id AA27817 (5.65c/IDA-1.4.4 for ); Mon, 17 Jan 1994 11:02:38 -0600 Received: from localhost (mstgil@localhost) by sol.acs.unt.edu (8.6.4/8.6.4) id LAA10472; Mon, 17 Jan 1994 11:02:37 -0600 From: "Marc Ph. A. J. St.-Gil - UNIX/VAX Systems Manager" Message-Id: <199401171702.LAA10472@sol.acs.unt.edu> Subject: Re: Multicast Kernel mods on Solbourne To: merik@anusf.anu.edu.au (Merik Karman) Date: Mon, 17 Jan 1994 11:02:37 -0600 (CST) Cc: rem-conf@es.net, info-solbourne@acsu.buffalo.edu (Solbourne Mailing List) In-Reply-To: <199401151137.AA05469@anusf.anu.edu.au> from "Merik Karman" at Jan 15, 94 10:37:57 pm X-Organization: University of North Texas - Academic Computing Services X-Pmrqc: 1 X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 896 In reply to Merik Karman's message: > Hi, > > I am trying to get the multicast mods running on a > Solbourne S4000 sparc box. It has 4.1B revision > operating system which is 4.1.2 based. > Has anyone got this configuration working or able to > offer any tips. Hmmm, just started that thread on the info-solbourne mailing list for the exact same reason. You might want to watch there as well. The subscription address is info-solbourne-request@acsu.buffalo.edu and it's _very_ low volume. (Sometimes no messages for weeks on end.) I included the full text of your message because I cross posted it there. Marc -- Marc St.-Gil, UNIX/VAX Systems Manager AKA: The UNIXMeister(tm) Academic Computing Services Internet: mstgil@unt.edu University of North Texas Voice: 817/565-3408 PO Box 13495, Denton TX, 76203-6495 FAX: 817/565-4060 From rem-conf-request@es.net Mon Jan 17 12:55:29 1994 Received: from taurus.cs.nps.navy.mil by osi-west.es.net via ESnet SMTP service id <12929-0@osi-west.es.net>; Mon, 17 Jan 1994 09:45:27 +0000 Received: by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA20699; Mon, 17 Jan 94 09:46:49 PST Date: Mon, 17 Jan 94 09:46:49 PST From: brutzman@cs.nps.navy.mil (Don Brutzman) Message-Id: <9401171746.AA20699@taurus.cs.nps.navy.mil> To: rem-conf@es.net Subject: mbone paper available The MBONE paper we wrote is available. THANKS to everyone in this group who contributed comments. We don't know what issue of IEEE _COMPUTER_ it will be in - a few months now. You are welcome to use it for personal use & informing others. IEEE has not yet given permission for duplication in other newsletters. regards, Don Brutzman & Mike Macedonia Donald P. Brutzman LCDR USN work (408) 656-2149 Code OR/Br Naval Postgraduate School [Glasgow 204] fax (408) 656-2595 Monterey California 93943-5000 USA home (408) 372-0190 ftp taurus.cs.nps.navy.mil [login] anonymous [password] bob@whatever [ftp>] binary [ftp>] cd pub [ftp>] cd mbmg [ftp>] ls [ftp>] get mbone.hottopic.ps.Z [ftp>] quit uncompress mbone.hottopic.ps.Z lpr mbone.hottopic.ps If you cannot connect to taurus.cs.nps.navy.mil try 131.120.1.13 The printer you send the file to (with lpr or whatever) must be Postscript capable. From rem-conf-request@es.net Tue Jan 18 06:50:49 1994 Received: from ocfmail.ocf.llnl.gov by osi-west.es.net via ESnet SMTP service id <21969-0@osi-west.es.net>; Tue, 18 Jan 1994 03:09:51 +0000 Received: from [128.115.24.198] (jedsmac.llnl.gov) by ocfmail.ocf.llnl.gov (4.1/SMI-4.0) id AA07805; Tue, 18 Jan 94 03:09:47 PST Message-Id: <9401181109.AA07805@ocfmail.ocf.llnl.gov> X-Sender: jed@ocfmail.llnl.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Jan 1994 03:09:49 -0800 To: rem-conf@es.net From: jed@llnl.gov (James E. [Jed] Donnelley) Subject: mbone conference announcements Yee-Hsiang Chang writes: >I think there is an issue of whether the current conference announcement >and discovery paradigm using by "sd" and partially by mailing list >announcement is the best one. While it is certainly reasonable to look for better alternatives, regarding: >If a wide-area directory service such as >the Mosaic can be tailored for the conference announcement and discovery, >we do not need to send event message periodically. I think the way ttls are used in the current mbone complicates the announcement of conferences. With the current announcement mechanism employed by sd I see exactly the conferences that I am able to join (the ttl of the announcement is the same as that of the conference). I don't see how a global announcement mechanism on the Web could provide this facility. Only conferences with large ttls are announced on the mailing list. Is it suggested that we do this on the Web? I don't see how it can be done. How will new conferences be added? Perhaps someone that knows more about the Web than I can suggest something. I certainly like the idea of being able to see the available conferences and "view" them through a browser like Mosaic. I'm just not sure that it is the right tool for the job as things are currently set up. James E. (Jed) Donnelley - Staff Computer Scientist Advanced Telecommunications Program LAWRENCE LIVERMORE NATIONAL LABORATORY P.O. Box 808 L-60 Work Phone: +1 (510) 422-4309 Livermore, California, U.S.A. Fax: +1 (510) 423-8534 94551-9900 Internet: jed@llnl.gov From rem-conf-request@es.net Tue Jan 18 10:53:09 1994 Received: from crl.dec.com by osi-west.es.net via ESnet SMTP service id <23435-0@osi-west.es.net>; Tue, 18 Jan 1994 07:52:26 +0000 Received: by crl.dec.com; id AA04113; Tue, 18 Jan 94 10:46:50 -0500 Received: by easynet.crl.dec.com; id AA18100; Tue, 18 Jan 94 10:46:49 -0500 Message-Id: <9401181546.AA15339@caspian.crl.dec.com> To: rem-conf@es.net Subject: address change Date: Tue, 18 Jan 94 10:46:48 -0500 From: Ralph Swick X-Mts: smtp please change swick@crl.dec.com to swick@x.org on the rem-conf list. Thanks! From rem-conf-request@es.net Tue Jan 18 11:03:47 1994 Received: from george.lbl.gov by osi-west.es.net via ESnet SMTP service id <23456-0@osi-west.es.net>; Tue, 18 Jan 1994 07:53:50 +0000 Received: by george.lbl.gov (4.1/1.39) id AA14476; Tue, 18 Jan 94 07:53:47 PST From: jason@george.lbl.gov (Jason Lee [SFSU student]) Message-Id: <9401181553.AA14476@george.lbl.gov> Subject: imm Beta 2.6 session? To: rem-conf@es.net Date: Tue, 18 Jan 94 7:53:46 PST In-Reply-To: I was wondering if anyone knows what happened to the imm Beta 2.6 session in sd?? jason jason@george.lbl.gov From rem-conf-request@es.net Tue Jan 18 12:00:06 1994 Received: from duke.cs.duke.edu by osi-west.es.net via ESnet SMTP service id <22976-0@osi-west.es.net>; Tue, 18 Jan 1994 06:45:57 +0000 Received: from macbeth.cs.duke.edu by duke.cs.duke.edu (5.65/3.7G/4.1.3) id AA15830; Tue, 18 Jan 94 09:45:54 -0500 Received: from localhost by macbeth.cs.duke.edu (5.65/3.6L/4.1.3) id AA08205; Tue, 18 Jan 94 09:45:53 -0500 Message-Id: <9401181445.AA08205@macbeth.cs.duke.edu> To: rem-conf@es.net Subject: Availability: sd-listen Date: Tue, 18 Jan 1994 09:45:52 -0500 From: Thomas Pusateri Due to popular demand (and no objections), the sd-listen source code is available via anonymous ftp from gated.cornell.edu:/pub/public/sd-listen. The README now follows. -------------------------------------------------------------------- sd-listen 1.0 This is quick program I wrote to test a multicast port to several architectures that didn't have the session directory tool from LBL. It simply prints out the SD announcements as they are received. It does not originate any SD packets. The packet format was reverse engineered so it is not guaranteed to be correct although it does seem to work. There are no license restrictions on this code. Tom Pusateri 1/18/94 From rem-conf-request@es.net Tue Jan 18 12:25:52 1994 Received: from crl.dec.com by osi-west.es.net via ESnet SMTP service id <24581-0@osi-west.es.net>; Tue, 18 Jan 1994 09:12:45 +0000 Received: by crl.dec.com; id AA12570; Tue, 18 Jan 94 12:11:04 -0500 Received: by easynet.crl.dec.com; id AA19856; Tue, 18 Jan 94 12:11:03 -0500 Message-Id: <9401181711.AA16618@caspian.crl.dec.com> To: rem-conf@es.net Subject: oops! Date: Tue, 18 Jan 94 12:11:03 -0500 From: Ralph Swick X-Mts: smtp I guess I deserve whatever flood I get, but to maybe forestall more... Yes, I do know the proper administrative procedure. My cut-n-paste didn't DWIM and I didn't catch it. Sorry for the (doubly) wasted bandwith. Still reading from the sidelines... -Ralph From rem-conf-request@es.net Tue Jan 18 14:27:38 1994 Received: from picard.cmf.nrl.navy.mil by osi-west.es.net via ESnet SMTP service id <26587-0@osi-west.es.net>; Tue, 18 Jan 1994 11:16:41 +0000 Received: from herman.cmf.nrl.navy.mil (herman-atm.cmf.nrl.navy.mil [134.207.10.3]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id OAA04227; Tue, 18 Jan 1994 14:15:06 -0500 Received: from localhost by herman.cmf.nrl.navy.mil (4.1/client-1.3) id AA11239; Tue, 18 Jan 94 14:15:05 EST Message-Id: <9401181915.AA11239@herman.cmf.nrl.navy.mil> To: Thomas Pusateri Cc: rem-conf@es.net Subject: Re: Availability: sd-listen In-Reply-To: Your message of "Tue, 18 Jan 94 09:45:52 EST." <9401181445.AA08205@macbeth.cs.duke.edu> X-Face: -*.ZYbFWa}{2c8NmF| > Due to popular demand (and no objections), the sd-listen source code > is available via anonymous ftp from gated.cornell.edu:/pub/public/sd-listen. I have made a few modifications to sd-listen. I added the ability to dump the raw SD packets for use with my WWW server code, and fixed the core-dump problem on suns (or, rather, any architecture in which a struct with an int in it gets passed differently than an int). I will send my changes to Tom to include. Bill From rem-conf-request@es.net Tue Jan 18 14:46:50 1994 Received: from picard.cmf.nrl.navy.mil by osi-west.es.net via ESnet SMTP service id <26901-0@osi-west.es.net>; Tue, 18 Jan 1994 11:38:39 +0000 Received: from herman.cmf.nrl.navy.mil (herman-atm.cmf.nrl.navy.mil [134.207.10.3]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id OAA04311; Tue, 18 Jan 1994 14:37:03 -0500 From: William C Fenner Received: by herman.cmf.nrl.navy.mil (4.1/client-1.3) id AA11402; Tue, 18 Jan 94 14:37:03 EST Date: Tue, 18 Jan 94 14:37:03 EST Message-Id: <9401181937.AA11402@herman.cmf.nrl.navy.mil> To: rem-conf@es.net, www-talk@www0.cern.ch Subject: First shot at sd via WWW Well, I only have a directory, and only a rough one at that, but you can point your browser at http://herman.cmf.nrl.navy.mil:8001/sd/ and see what you think of my first shot. Thanks to Tom Pusateri for his sd-listen code. Bill From rem-conf-request@es.net Tue Jan 18 15:21:52 1994 Received: from csservera.scs.usna.navy.mil by osi-west.es.net via ESnet SMTP service id <27362-0@osi-west.es.net>; Tue, 18 Jan 1994 12:12:59 +0000 Received: from douglas.scs.usna.navy.mil by SCS.USNA.NAVY.MIL (4.1/SMI-4.1) id AA23945; Tue, 18 Jan 94 15:07:31 EST Date: Tue, 18 Jan 94 15:07:31 EST From: eun@SCS.USNA.NAVY.MIL (E.K. Park x3037) Message-Id: <9401182007.AA23945@SCS.USNA.NAVY.MIL> To: atm@sun.COM, members@farnet.ORG, nren-discuss@psi.COM, rem-conf@es.NET, wireless@tandem.COM Subject: ICCCN94 Call for Papers CALL FOR PAPERS Third International Conference on Computer Communications and Networks (ICCCN'94) September 11 - 14, 1994, San Francisco, California, USA Sponsored by USC Communication Sciences Institute In cooperation with IEEE Communication Society* The third ICCCN will cover all aspects of computer communications and networks. Of particular interest are recent advances in high-speed distributed multimedia applications, and the design and performance evaluation of system and network architectures that support these applications. Authors are invited to submit papers and tutorial proposals. Topics of interest include, but are not limited to: ATM Network Design Protocols for High Speed Networks ATM Traffic Control Distributed Multimedia applications ATM LAN's Multimedia Man/Machine Interface ATM Testbeds Video-on-Demand Systems Quality of Service Issues Video Coding Wireless Networks Network Management Multicast Protocols Performance Modeling/Analysis Optical Networks LAN/WAN Internetworking INSTRUCTIONS TO AUTHORS: All submissions must be accompanied by a cover letter containing a list of all authors, their affiliations, phone/fax numbers, and email addresses. Papers should be at most 20 double-spaced pages and must include an abstract of 100-150 words with up to ten keywords. Tutorial proposals should contain a one-page description and a detailed outline. All submissions will be refereed and judged with respect to quality and relevance. Submit six copies of each paper to the Program Chair (J. W. Wong), and tutorial proposal to the Program Vice Chair (E. K. Park). Proceedings will be available at the conference. CONFERENCE CHAIR: Professor T. Suda Department of Information and Computer Science University of California at Irvine Irvine, CA 92717 USA Phone (714) 856-5474; Fax (714) 856-4056; Email suda@ics.uci.edu PROGRAM CHAIR: Professor J. W. Wong Department of Computer Science University of Waterloo Waterloo, Ontario, Canada N2L 3G1 Phone (519) 888-4431; Fax (519) 885-1208; Email jwwong@math.uwaterloo.ca PROGRAM VICE CHAIR: Professor E. K. Park Computer Science Department United States Naval Academy Annapolis, MD 21042 USA Phone (410) 267-3037; Fax (410) 267-2686; Email eun@usna.navy.mil LOCAL ARRANGEMENT CHAIR: Dr. I. Khan, SRI International Phone (415) 859-6335; Fax (415) 859-4812; Email khan@erg.sri.com IMPORTANT DATES: Deadline for paper and/or tutorial submissions: March 4, 1994 Notification of acceptance: May 10, 1994 Camera ready papers due: June 10, 1994 ICCCN'94 STEERING COMMITTEE: Prof. V. O. K. Li (Chair, 213-740-4665, vli@irving.usc.edu), Prof. B. G. Lee (Korea), Prof. J.-F. Chang (Taiwan), Dr. Y. C. Lee (USA), Prof. H. Okada (Japan), Prof. R. Pickholtz (USA), Prof. G.-S. Poo (Singapore), and Prof. I. Rubin (USA) *Pending approval From rem-conf-request@es.net Tue Jan 18 16:52:20 1994 Received: from viipuri.nersc.gov by osi-west.es.net via ESnet SMTP service id <28428-0@osi-west.es.net>; Tue, 18 Jan 1994 13:45:02 +0000 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA01926; Tue, 18 Jan 94 13:44:51 PST Date: Tue, 18 Jan 94 13:44:51 PST From: ari@es.net (Ari Ollikainen) Message-Id: <9401182144.AA01926@viipuri.nersc.gov> To: pusateri@cs.duke.edu, rjansen@vnet3.vub.ac.be Subject: Re: sd-listen (was Re: sv access through a Mosaic server) Cc: rem-conf@es.net The following message was bounced by about half of the mail receivers that touched it... Please note that the most common complaint was: 554 Unbalanced '(' Apologies to all who are seeing this again. Suggestion to Robert: Find out how to get rid of the backslashes in your From: line > From rem-conf-request@es.net Mon Jan 17 06:38:19 1994 > Date: Mon, 17 Jan 1994 15:39:29 +0100 > To: pusateri@cs.duke.edu > From: rjansen@vnet3.vub.ac.be.\(\) (Robert Jansen \(VUBnet\)) > Subject: Re: sd-listen (was Re: sv access through a Mosaic server) > Cc: rem-conf@es.net > Content-Length: 1644 > > At 4:43 AM 1/17/94 +0100, Robert Dal Santo wrote: > >>In message <9401141639.AA03385@herman.cmf.nrl.navy.mil> you write: > >>> > >>>I've been idly tossing around the idea of creating an application that just > >>>listens for the session advertisements and updates an HTML page with them, > >>>but > >>> > >>>I couldn't really think any real uses for it. > >>> > >> > >>I wrote a short hack to listen for SD announcements and print them > >>out for use on the RS6000 since there is not yet SD support available for > >>it. I didn't post it because I thought there might be a reason why source > >>wasn't available for sd. I can sent it to you or if others want it and > >>the SD people don't mind, I'll post it. > >> > > > > Could you send me this program ?? I am interesting in manipulating SD > >packets from outside sd as I can't always be here to run SD after system > >reboots. > > > >Thanks, > > > > > >=========================================================================== > >Robert Dal Santo Phone +61 7 365 6687 > > Fax +61 7 365 4466 > >Department of Psychology, > >University of Queensland 4072, > >AUSTRALIA. > > > >"I've reached the driveway to destruction and I'm taking the stationwagon." > > > > Mhhh.... handy for non-windowed users. > > Could you send it to root@vnet2.vub.ac.be (that's me :)) . > > Thanks in advance. > > Greetings from Belgium. > -------------------------- > Brussels University > Pleinlaan 2 > Computer Center VUB/ULB (VUBnet) > Robert Jansen > B-1050 Brussels > Belgium (Europe) > > > email: rjansen@vnet3.vub.ac.be > Tel: +32-2-650.37.29 > Secr: +32-2-650.37.38 > Fax: +32-2-650.37.40 > -------------------------- > > From rem-conf-request@es.net Tue Jan 18 18:27:40 1994 Received: from viipuri.nersc.gov by osi-west.es.net via ESnet SMTP service id <29570-0@osi-west.es.net>; Tue, 18 Jan 1994 15:17:20 +0000 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA01988; Tue, 18 Jan 94 15:17:18 PST Date: Tue, 18 Jan 94 15:17:18 PST From: ari@es.net (Ari Ollikainen) Message-Id: <9401182317.AA01988@viipuri.nersc.gov> To: rem-conf@es.net Subject: A Packet Video Standard? Cc: dvtf@es.net, rcwg@gov.fnal.hepnet From Communications Week, January 10, 1994, page 62, by Margie Semilof: Forum to Adopt Packet Video Standards RESEARCH TRIANGLE PARK, N.C. The Packet Video Forum, a group of vendors and users interested in developing packet video standards, this week will try to reignite public interest in its work by championing a protocol that will let dissimilar video products work together. Jack Drescher, manager of program development at Microelectronics Center for North Carolina Center for Communications (MCNC) here, said the Packet Video Forum -- formerly called the Packet Video Consortium -- will adopt a compressed video interoperability protocol developed by Viewpoint Systems Inc., a Dallas based company that makes packet-based videoconferencing products. MCNC is a consortium of universities in North Carolina working to recruit members for the Packet Video Forum. The Forum, an advisory council to MCNC, is trying to form standards for transmitting video over packet-based networks, like Internet. MCNC last week hosted a packet-based videoconference to deliver a state of the industry message over the Internet. During the conference, Viewpoint CEO Glenn Norem said his company will use the compressed video protocol in interoperability demonstrations with other hardware vendors, including Sun Microsystems Corp., during the next few months. Drescher said the "interoperability" protocol will let various packet video products with proprietary algorithms interoperate. Since it is unlikely that vendors will quickly agree to implement a standard video protocol for packet video, this protocol can send an algorithm to the receiving end to decode the packets. "You don't have to know what protocol is being sent, you only need to know the matching decoder," Drescher said. The Forum will provide the technology to interested companies. Users said thet are interested in the protocol. Stephen Casner, project leader at the University of Southern California's Information Sciences Institute, Marina Del Rey, said, "If everyone used one standard encoding method, this [interoperability] problem would not arise, but there never may be a single packet video standard -- since [they] take so long to develop." While a number of universities are active Forum members, only two major hardware companies, IBM and Sun Microsytems Corp., are members. ----------- ari@es.net _/_/ _/_/_/_/ _/ Ari Ollikainen {VOX: 510 423-5962} _/ _/ _/ _/ _/ Energy Sciences Network {FAX: 510 423-8744} _/_/_/_/ _/_/_/_/ _/ National Energy Research Supercomputer Center _/ _/ _/ _/ _/ Lawrence Livermore National Laboratory _/ _/ _/ _/ _/ MailStop L-561, PO BOX 5509, Livermore, CA. 94551 From rem-conf-request@es.net Tue Jan 18 19:57:17 1994 Received: from picard.cmf.nrl.navy.mil by osi-west.es.net via ESnet SMTP service id <01002-0@osi-west.es.net>; Tue, 18 Jan 1994 16:48:59 +0000 Received: from riker.cmf.nrl.navy.mil (riker.cmf.nrl.navy.mil [134.207.10.69]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id TAA05802 for ; Tue, 18 Jan 1994 19:47:24 -0500 From: William C Fenner Received: by riker.cmf.nrl.navy.mil (4.1/client-1.3) id AA04329; Tue, 18 Jan 94 19:48:05 EST Date: Tue, 18 Jan 94 19:48:05 EST Message-Id: <9401190048.AA04329@riker.cmf.nrl.navy.mil> To: rem-conf@es.net Subject: Re: First shot at sd via WWW Okay, if there's anyone out there with a tcl interpreter executable (a wish interpreter might do in a pinch), I may have application launching working from Mosaic (I went home, so I can't try it). If there are any brave volunteers out there, I'll send you the code to try (it's all tcl, and you have to add something to your .mailcap for Mosaic.) Bill From rem-conf-request@es.net Tue Jan 18 21:16:14 1994 Received: from eitech.eit.COM by osi-west.es.net via ESnet SMTP service id <01712-0@osi-west.es.net>; Tue, 18 Jan 1994 18:07:57 +0000 Received: from collage.eitech.com (collage.eit.COM) by eit.COM (4.1/SMI-4.1) id AA13520; Tue, 18 Jan 94 18:07:39 PST Date: Tue, 18 Jan 94 18:07:39 PST From: vinay@eit.COM (Vinay Kumar) Message-Id: <9401190207.AA13520@eit.COM> To: fenner@cmf.nrl.navy.mil Subject: Re: First shot at sd via WWW Cc: rem-conf@es.net I am not sure if i understand the scenario here correctly, but if you are just trying to start "sd" from "Mosaic", it's fairly simple. Here's what you do: In your HTML document, point a URL to a script (assuming you are using perl) that reads: #!/usr/bin/perl print "Content-type: application/x-sd\n\n"; exit; And your $HOME/.mailcap file should read: appliation/x-sd; sd %s This should crank up "sd" at the client site via Mosaic. -- Vinay Kumar vinay@eit.com [Bill, I apologize if you recd a similar mail earlier from me via the www-talk list, my reponse to www-talk had bounced back undelivered....] ------------------------------- > From rem-conf-request@es.net Tue Jan 18 17:37:54 1994 > From: William C Fenner > Date: Tue, 18 Jan 94 19:48:05 EST > To: rem-conf@es.net > Subject: Re: First shot at sd via WWW > Content-Length: 356 > > Okay, if there's anyone out there with a tcl interpreter executable > (a wish interpreter might do in a pinch), I may have application launching > working from Mosaic (I went home, so I can't try it). If there are any > brave volunteers out there, I'll send you the code to try (it's all tcl, > and you have to add something to your .mailcap for Mosaic.) > > Bill > From rem-conf-request@es.net Wed Jan 19 12:13:01 1994 Received: from picard.cmf.nrl.navy.mil by osi-west.es.net via ESnet SMTP service id <07283-0@osi-west.es.net>; Wed, 19 Jan 1994 08:39:06 +0000 Received: from herman.cmf.nrl.navy.mil (herman-atm.cmf.nrl.navy.mil [134.207.10.3]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA08678 for ; Wed, 19 Jan 1994 11:37:26 -0500 From: William C Fenner Received: by herman.cmf.nrl.navy.mil (4.1/client-1.3) id AA15303; Wed, 19 Jan 94 11:37:25 EST Date: Wed, 19 Jan 94 11:37:25 EST Message-Id: <9401191637.AA15303@herman.cmf.nrl.navy.mil> To: rem-conf@es.net Subject: Announcing sd-launch v1.0 Here's the README for sd-launch v1.0, a tool to integrate session launching with Mosaic. sd-launch, v1.0 sd-launch is a helper for Mosaic (and other WWW browsers, and, indeed, metamail) to allow launching of MBONE sessions via WWW (or MIME). sd-launch is simply a C wrapper for two tcl programs: sd_start.tcl, as supplied with sd v1.13 from LBL (available in ftp://ee.lbl.gov/conferencing/sd/) sd_load.tcl, which parses an .sd_cache entry (or an application/x-sd datastream as supplied by my sd extension to Plexus) into the form that sd_start requires To compile, you need tcl2c, which is part of the nv distribution (available in ftp://ftp.parc.xerox.com/pub/net-research/), or you could ask me for the already-processed .c files. A binary is available for SunOS 4.1.3, the only platform I have conveniently available to me. I will make binaries available for other platforms if they are supplied to me. To use, put something similar to the following in your ~/.mailcap : application/x-sd; sd-launch %s William C. Fenner sd-launch is available via the web from http://www.cmf.nrl.navy.mil/people/fenner/dist/sd-launch . Make sure to use binary transfer mode if you're getting a tar file or an executable. From rem-conf-request@es.net Wed Jan 19 19:23:58 1994 Received: from crusher.concert.net by osi-west.es.net via ESnet SMTP service id <14508-0@osi-west.es.net>; Wed, 19 Jan 1994 16:14:39 +0000 Received: by crusher.concert.net (5.59/tas-concert/6-19-91) id AA12879; Wed, 19 Jan 94 19:14:13 -0500 From: Fengmin Gong Message-Id: <9401200014.AA12879@crusher.concert.net> Subject: Re: A Packet Video Standard? To: rem-conf@es.net Date: Wed, 19 Jan 1994 19:14:13 -0500 (EST) Cc: fmg@crusher.concert.net (Fengmin Gong) In-Reply-To: <9401182317.AA01988@viipuri.nersc.gov> from "rem-conf-request@es.net" at Jan 18, 94 05:17:18 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1159 Many of you have probably seen the Communications Week article related to the MCNC Packet Video Forum, titled "Forum to Adopt Packet Video Standards", even before the copy forwarded by Ari to this list. There are references in the article regarding MCNC's stance on the compressed video interoperability (CVI) protocol proposed by Viewpoint Systems Inc. that could lead to misunderstandings in the packet video community. We want to refer the public to the following statement authorized by MCNC that more accurately reflects MCNC's position with regard to the CVI protocol: MCNC, in Research Triangle Park, N.C., intends to incorporate the Compressed Video Interoperability Protocol concept into a general framework being developed that will foster interoperability among different video coding schemes. Supporting interoperability is consistent with the objectives of MCNC's existing Packet Video Project and associated Packet Video Forum. A detailed estimate of the scope of the effort and the required implementation resource is underway. Thanks, Fengmin -- Fengmin Gong gong@concert.net MCNC Information Technologies +1 919 248 9214 From rem-conf-request@es.net Thu Jan 20 03:58:20 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <18560-0@osi-west.es.net>; Thu, 20 Jan 1994 00:57:12 +0000 Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 20 Jan 1994 08:56:38 +0000 To: Fengmin Gong cc: rem-conf@es.net, P.Kirstein@cs.ucl.ac.uk Subject: Re: A Packet Video Standard? In-reply-to: Your message of "Thu, 20 Jan 94 00:21:54 GMT." <9401200014.AA12879@crusher.concert.net> Date: Thu, 20 Jan 94 08:56:36 +0000 From: P.Kirstein@cs.ucl.ac.uk While interoperability is a desirable goal, I find it difficult to understand how MCNC's stance aids interoperability. If there were agreement in a number of other bodies on a Standard, then this aids interopearbility - not by a decision in a MCNC forum. If you want anyone else to take notice of this, presumably you should say more about the formats, state how they relate to MPEG, H.261 etc, and try to get others to adopt it or make it the basis of some international standards; is that happening, or is this another Standards War? Excuse my ignorance, but I| know nothing about the specific "Standard" mentioned here. Peter Kirstein In message <9401200014.AA12879@crusher.concert.net> you write: >Many of you have probably seen the Communications Week article >related to the MCNC Packet Video Forum, titled "Forum to Adopt >Packet Video Standards", even before the copy forwarded by Ari >to this list. There are references in the article regarding >MCNC's stance on the compressed video interoperability (CVI) >protocol proposed by Viewpoint Systems Inc. that could lead to >misunderstandings in the packet video community. We want to refer >the public to the following statement authorized by MCNC that more >accurately reflects MCNC's position with regard to the CVI protocol: > >MCNC, in Research Triangle Park, N.C., intends to incorporate the Compressed >Video Interoperability Protocol concept into a general framework being >developed that will foster interoperability among different video coding >schemes. Supporting interoperability is consistent with the objectives of >MCNC's existing Packet Video Project and associated Packet Video Forum. A >detailed estimate of the scope of the effort and the required implementation >resource is underway. > >Thanks, >Fengmin > >-- >Fengmin Gong gong@concert.net >MCNC Information Technologies +1 919 248 9214 From rem-conf-request@es.net Thu Jan 20 09:43:30 1994 Received: from crusher.concert.net by osi-west.es.net via ESnet SMTP service id <20302-0@osi-west.es.net>; Thu, 20 Jan 1994 06:32:47 +0000 Received: by crusher.concert.net (5.59/tas-concert/6-19-91) id AA13189; Thu, 20 Jan 94 09:32:15 -0500 From: Fengmin Gong Message-Id: <9401201432.AA13189@crusher.concert.net> Subject: Re: A Packet Video Standard? To: P.Kirstein@cs.ucl.ac.uk Date: Thu, 20 Jan 1994 09:32:14 -0500 (EST) Cc: fmg@crusher.concert.net, rem-conf@es.net In-Reply-To: <9401200856.AA13119@crusher.concert.net> from "P.Kirstein@cs.ucl.ac.uk" at Jan 20, 94 08:56:36 am X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 4513 P.Kirstein@cs.ucl.ac.uk wrote earlier: > >While interoperability is a desirable goal, I find it difficult to >understand how MCNC's stance aids interoperability. If there were >agreement in a number of other bodies on a Standard, then this aids >interopearbility - not by a decision in a MCNC forum. > Peter, I hope that you have read the Comm. Week article when you replied my posting. My message said nothing about MCNC's stance aiding interoperability. What ever MCNC does alone will only be a drop of water in a sea (or make that a million drops). I am fully aware that it takes lots of "bodies" to agree on an approach to achieve interoperability. My reason for that posting is to correct the misinformation in the Comm. Week article which Ari also forwarded to the rem-conf list. If you read the statement that I referred people to, it said nothing about a standard or did it imply anything you just objected. >If you want anyone else to take notice of this, presumably you should >say more about the formats, state how they relate to MPEG, H.261 etc, >and try to get others to adopt it or make it the basis of some >international standards; is that happening, or is this another >Standards War? > First, I don't know anything about a standards war. Now let me explain to you the CVI concept (note that refer it as a CONCEPT) as I understand it. CVI assumes that people/vendors who come up with their greatest video compression schemes will be willing to provide their decoder software to who ever interested and on whatever platforms they wanted (assume it's binary). Their encoders may be implemented in hardware that you need to buy. The idea is to allow people to experience with different schemes before they commit to buy the harder and the process may also allow "good" schemes to emerge. Of course, you may already have a dozen decoders on your system for you to receive video streams of that sort, or as Glen Norm suggests, you may be able to request a binay image of the decoder before the receiving session. There may be hassles associated with generating binaries for different platforms, but that is beside the point here. I think in a sense, this concept can be thought of as an extension to what Ron Frederick is doing in nv already. Also, I happen to think that RTP will be a good transport support to start with. Now you probably see that it's not about a single compression standard, it's about a practical approach. MPEG and H.261 will fit just fine, so will Ron's scheme, etc. What is missing is some "glue logic" such as the protocol to talk about formats and the potential control parameters for various coding schemes, and conventions for invoking these decoders. >Excuse my ignorance, but I| know nothing about the specific "Standard" >mentioned here. > That does'nt surprise me. I cannot help pointing out that you are replying my posting, yet based on an article that my posting is correcting. I can forward you a copy of the Comm. Week article if you have'nt seen one and are insterested. In case you wonder what that statement was made for, that's what we gave Glen Norm of Videopoint Systems Inc. regarding our intention towards the CVI concept. Fengmin Gong >Peter Kirstein >In message <9401200014.AA12879@crusher.concert.net> you write: >>Many of you have probably seen the Communications Week article >>related to the MCNC Packet Video Forum, titled "Forum to Adopt >>Packet Video Standards", even before the copy forwarded by Ari >>to this list. There are references in the article regarding >>MCNC's stance on the compressed video interoperability (CVI) >>protocol proposed by Viewpoint Systems Inc. that could lead to >>misunderstandings in the packet video community. We want to refer >>the public to the following statement authorized by MCNC that more >>accurately reflects MCNC's position with regard to the CVI protocol: >> >>MCNC, in Research Triangle Park, N.C., intends to incorporate the Compressed >>Video Interoperability Protocol concept into a general framework being >>developed that will foster interoperability among different video coding >>schemes. Supporting interoperability is consistent with the objectives of >>MCNC's existing Packet Video Project and associated Packet Video Forum. A >>detailed estimate of the scope of the effort and the required implementation >>resource is underway. >> >>Thanks, >>Fengmin >> >>-- >>Fengmin Gong gong@concert.net >>MCNC Information Technologies +1 919 248 9214 > From rem-conf-request@es.net Fri Jan 21 16:03:47 1994 Received: from picard.cmf.nrl.navy.mil by osi-west.es.net via ESnet SMTP service id <09783-0@osi-west.es.net>; Fri, 21 Jan 1994 12:53:45 +0000 Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id PAA07207; Fri, 21 Jan 1994 15:44:19 -0500 From: Allison J Mankin Received: by radegond.cmf.nrl.navy.mil (4.1/client-1.3) id AA01032; Fri, 21 Jan 94 15:44:14 EST Date: Fri, 21 Jan 94 15:44:14 EST Message-Id: <9401212044.AA01032@radegond.cmf.nrl.navy.mil> To: ietf@cnri.reston.va.us, rem-conf@es.net Subject: IPng MBONE Meeting--Jan 25 Cc: ipng@picard.cmf.nrl.navy.mil IPNG AREA MBONE MEETING The IP Next Generation Directorate and Directors will have an open discussion meeting using the MBONE (audio and whiteboard). Time: Tues. 25 January 1994, 12:30-2 EST The conference has been listed in SD, but for those not using SD, its information is: 224.2.234.120 audio port 32783 id 41704 wb port 34805 id 10380 AGENDA: Introduction of Directorate and and External Review Panel participants Discussion: what are the Internet's requirements for connectivity between IPv4-only and IPng-only hosts? what is the timescale of those requirements? [Up to one hour] Update on white papers for IPng requirements From rem-conf-request@es.net Fri Jan 21 17:34:40 1994 Received: from POSTOFFICE2.MAIL.CORNELL.EDU by osi-west.es.net via ESnet SMTP service id <11315-0@osi-west.es.net>; Fri, 21 Jan 1994 14:25:25 +0000 Received: from [132.236.199.117] (SWB.CIT.CORNELL.EDU) by postoffice2.mail.cornell.edu with SMTP id AA21550 (5.67a/IDA-1.5 for ); Fri, 21 Jan 1994 17:21:22 -0500 Message-Id: <199401212221.AA21550@postoffice2.mail.cornell.edu> X-Sender: swb1@postoffice2.mail.cornell.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Jan 1994 17:24:55 -0500 To: P.Kirstein@cs.ucl.ac.uk, Fengmin Gong From: Scott W Brim Subject: Re: A Packet Video Standard? Cc: rem-conf@es.net, P.Kirstein@cs.ucl.ac.uk I believe I am beginning to understand. I *believe* (at least I hope to believe) that MCNC is not proposing any particular standard, but rather a practice. They are saying that whenever anyone produces an encoding scheme, that they provide free code to do the decoding. An example close to home is that nv currently knows how to decode CU-SeeMe, even though it doesn't know how to encode it (yet). This idea would have consequences for the competitive advantage of proprietary encoding schemes. ...Scott From rem-conf-request@es.net Fri Jan 21 17:43:39 1994 Received: from isse.gmu.edu by osi-west.es.net via ESnet SMTP service id <11475-0@osi-west.es.net>; Fri, 21 Jan 1994 14:34:52 +0000 From: ncho@isse.gmu.edu (Nam Cho) Received: by isse.gmu.edu (4.1/3.1.090690-ISSE) id AA08945; Fri, 21 Jan 94 17:34:48 EST Message-Id: <9401212234.AA08945@isse.gmu.edu> Subject: anyone To: rem-conf@es.net Date: Fri, 21 Jan 1994 17:34:47 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 370 Has anyone outthere worked with the SunVideo board ? It is currently available for $1249, but does it work with NV ? (I've read the SunVideo board only includes drivers for Solaris2.x do all the other multicasting apps (vat/sd/nv/wb etc.) work under 2.x ? Perhaps nv running with 4.1.3 compatibility libraries on 2.x with SunVideo ? Thanks a bunch. -- Nam Cho From rem-conf-request@es.net Sat Jan 22 09:54:42 1994 Received: from cs.tut.fi by osi-west.es.net via ESnet SMTP service id <17449-0@osi-west.es.net>; Sat, 22 Jan 1994 06:46:42 +0000 Received: from kaarne.cs.tut.fi (kaarne.cs.tut.fi [130.230.3.2]) by cs.tut.fi (8.6.4/8.6.4) with SMTP id QAA24073 for ; Sat, 22 Jan 1994 16:46:54 +0200 Received: by kaarne.cs.tut.fi id AA07962 (5.65c/IDA-1.4.4 for rem-conf@es.net); Sat, 22 Jan 1994 16:46:36 +0200 Date: Sat, 22 Jan 1994 16:46:36 +0200 From: Mikko Tsokkinen Message-Id: <199401221446.AA07962@kaarne.cs.tut.fi> Cc: rem-conf@es.net Subject: Re: Video on sun (was anyone) In-Reply-To: <9401212234.AA08945@isse.gmu.edu> References: <9401212234.AA08945@isse.gmu.edu> Nam Cho writes: > Has anyone outthere worked with the SunVideo board ? > > It is currently available for $1249, but does it work with NV ? > (I've read the SunVideo board only includes drivers for Solaris2.x > do all the other multicasting apps (vat/sd/nv/wb etc.) work under 2.x ? > > Perhaps nv running with 4.1.3 compatibility libraries on 2.x with SunVideo ? Hello I am posting this to mailing list because I thought this could interest others too. We are using mbone applications daily (actually 24hrs). The equipment I can comment on are: - Sun10/parallax multivideo(sp?)/np-fddi/sunos4.1.3 - SunIPX/parallax xvideo/videopix/np-fddi/fore sba100/sunos4.1.3 - SunIPX/sunvideo/videopix/sun-sahi/solaris2.3 The versions unless otherwise noted are: - mrouted 1.4 - wb, 1.54 - sd, 1.14 - vat 3.2 - nv, 3.3alpha - ivs, 3.2 Observations: Sun10-40/sunos4.1.3 - mrouted, multicast works on ethernet only, all tunnels are via fddi card - vat, requires quite new version in order to work properly with speakerbox (2.20 or so) - nv, requires version 3.3alpha to support parallax, works fine, good quality and speed - ivs, crashes machine completely with parallax encoding IPX/sunos4.1.3 - mrouted, routed via ethernet, tested tunnels also on fddi, no multicast on fddi - mrouted, no multicast on ATM interface, tunnels have some problems over ATM - nv, requires version 3.3alpha to support parallax xvideo, good quality and speed - nv, videopix works on older versions too, slow - ivs, works on both videopix and parallax xvideo IPX/solaris2.3 - all mbone binaries work with solaris2.3 - mrouted, ethernet routing and multicast is default in kernel, no problems - mrouted, no multicast on ATM interface, tunneling not tested - nv, videopix works, even more slowly - nv, sunvideo is not supported - ivs, not tested, does not support sunvideo General comments: - SunVideo is not supported in sunos4.1.3 - Parallax is not supported in solaris2.3 - Videopix is supported in both sunos4.1.3 and solaris2.3 - nv supports videopix and parallax boards, it does not support sunvideo Side note: - Sunvideo is supported in commercial products showme2 (sun) and communique3 (insoft) when running solaris2.3 (these I have, there might be others) DISCLAIMER: These are the general guidelines for our equipment and the software versions I have. If some other versions are released and I am not aware of them (eg. beta, test, very new) situation might be entirely different. -- Cheers Mikko Tsokkinen xxxxx Mit "I do not fear computers. I fear the lack of them." From rem-conf-request@es.net Mon Jan 24 11:42:54 1994 Received: from ninet.research.att.com by osi-west.es.net via ESnet SMTP service id <01015-0@osi-west.es.net>; Mon, 24 Jan 1994 08:29:17 +0000 Received: by research.att.com; Mon Jan 24 11:28 EST 1994 Date: Mon, 24 Jan 94 11:28:00 EST From: hgs@research.att.com (Henning G. Schulzrinne) To: rem-conf@es.net Subject: Network voice goes Windows (VocalChat) There's a new application called VocalTec which looks a lot like "vat/nevot/... for Windows". Runs only over IPX networks, from what I can tell; does ADPCM; broadcast, no multicast. Has features like voice activation, voice mail boxes and broadcast. Costs $99 per network (not per seat). Claims to use any Windows-compatible sound card. Contact: VocalTec, 157 Veterans Drive; Northvale, NJ 07647 phone: 201 768 9400; fax: 201 768 8893 I just saw the documentation (we don't run MS Windows around here), so I have no idea how good/bad the sound quality is or what the delays are like. It certainly indicates that voice-over-networks is going mainstream. (Their sales flier contains clippings from the usual PC rags.) --- Henning Schulzrinne (hgs@research.att.com) AT&T Bell Laboratories (MH 2A-244) 600 Mountain Ave; Murray Hill, NJ 07974 phone: +1 908 582-2262; fax: +1 908 582-5809 From rem-conf-request@es.net Mon Jan 24 17:17:00 1994 Received: from anu.anu.edu.au by osi-west.es.net via ESnet SMTP service id <06080-0@osi-west.es.net>; Mon, 24 Jan 1994 14:08:25 +0000 Received: from octavia.anu.edu.au. by anu.anu.edu.au (4.1/SMI-4.1) id AA01142; Tue, 25 Jan 94 09:08:21 EST Received: by octavia.anu.edu.au. (4.1/SMI-4.1) id AA26551; Tue, 25 Jan 94 09:08:18 EST Date: Tue, 25 Jan 94 09:08:18 EST From: markus@octavia.anu.edu.au (Markus Buchhorn) Message-Id: <9401242208.AA26551@octavia.anu.edu.au.> To: hgs@research.att.com, rem-conf@es.net Subject: Re: Network voice goes Windows (VocalChat) I went to a demonstration here of a product from 'Network Automation' (who are a subpart of 'Total Peripherals). They were plugging a product very similar to vat/nv, on Windows. Similar quality/frame rates, running over ethernet between two PCs. They actually had their own leased lines around Australia, so were providing a network for teleconferencing in competition to (but using...) the local telcos. About the only thing I hadn't seen before was that you could swap between the received video signal and the outgoing video signal (A-to-B-to-A communication) :-) The suits'n'ties at the demo were amazed. Those of us on the Net were bored :-). Sorry - didn't get a price list. I can hunt them down if anybody (well, likeliest in Oz) is interested. Cheers, Markus Markus Buchhorn, Parallel Computing Research Facility email = markus@octavia.anu.edu.au snail = CISR, I Block, OAA, ANU Australian National University, Canberra, 0200 , Australia. [International = +61 6, Australia = 06] [Phone = 2492930, Fax = 2490747] From rem-conf-request@es.net Mon Jan 24 18:22:12 1994 Received: from wasabi.nsi.nasa.gov by osi-west.es.net via ESnet SMTP service id <07161-0@osi-west.es.net>; Mon, 24 Jan 1994 15:12:42 +0000 Received: by wasabi.nsi.nasa.gov (920330.SGI/920502.SGI) for rem-conf@es.net id AA03167; Mon, 24 Jan 94 18:13:44 -0500 Date: Mon, 24 Jan 94 18:13:44 -0500 From: Chris Shenton Message-Id: <9401242313.AA03167@wasabi.nsi.nasa.gov> To: rem-conf@es.net, dmeyers@atlas.arc.nasa.gov Cc: nasa-multicast@nasa.gov, mnewell@lupine.nsi.nasa.gov Subject: Problem with wb importing PowerPoint-generated PostScript I'm trying to import some slides generated by Mac PowerPoint into wb for an MBONE conference. When I do the wb import, I get errors like: -wb: can't send PS pages larger than 32768 bytes (is 496474) -wb: can't send PS pages larger than 32768 bytes (is 564239) I can't find this string in the wb binary, so I assume that it's complaining that it can't *send* (mcast) a ``packet' that size, not that the .ps image data is too big. Looking at the file generated by PowerPoint, it's HUGE: over 50KB for a single page containing simply: This is a test and much more for real documents -- like the ones mentioned above -- several hundred KB and up. Examining the .ps itself, most of it is font definitions like: %%BeginFont: Helvetica-Bold %!PS-TrueTypeFont-1-1-1 25 dict begin /FontName /Helvetica-Bold def /Encoding 256 array 0 1 255{1 index exch/.notdef put}for dup 0 /.null put dup 8 /.null put dup 9 /space put [...] and other definitions like: type42known not downloadOK and{userdict/TrueDict known{TrueDict/initer known not} {true userdict begin/TrueDict 8 dict dup /version 27 put def end}ifelse}{false}ifelse{currentfile eexec}exch( %endeexec)exch checkload 1861AEDAAA5472E4FDE5287D4C4E53EBA565E192AC8F362DA1CD77A9FCA31B071701B025F68DCF4C631ED8451E912BED309E5278415CE3E471ECE22F5E04FE2BB3D1A2D8230D516E93FA22D5104354FA6E4E3829811FF537A9F7B7F5016FF9A084424DAB04EDCBABC563D12827F1CC491C3293A798745679001AC866 [...] Only a small fraction is dedicated to the actual content of the document. (By comparison, some documents produced by TeX, translated to .dvi then to .ps are scanned in fine -- the files are relatively small.) I'm wondering if I can edit out the definitions where it's interrogating the printer asking whether it knows about Helvetica and such and see if that will fly. But this stuff is painful to read and it would be easy to elide something which *is* necessary for GhostScript/wb. Anybody experiencing the same problem? Got any solutions? Alternatively, are there programs which can ingest PowerPoint .ps and spit out something more sane? Thanks. --Chris Email: cshenton@wasabi.nsi.nasa.gov Mail: Sterling Software: 700 13th Street, NW #950; Washington, DC 20005 Phone: 202-434-8954; Fax: 202-434-4599; Pager: 202-539-3317 From rem-conf-request@es.net Mon Jan 24 18:31:34 1994 Received: from nsipo.arc.nasa.gov by osi-west.es.net via ESnet SMTP service id <07307-0@osi-west.es.net>; Mon, 24 Jan 1994 15:21:57 +0000 Received: from lupine.nsi.nasa.gov by nsipo.arc.nasa.gov (4.1/1.5) id AA12493; Mon, 24 Jan 94 15:21:15 PST Received: by lupine.nsi.nasa.gov (5.65/SunOS-4.1.3) id AA14220; Mon, 24 Jan 94 18:19:16 -0500 Date: Mon, 24 Jan 94 18:19:16 -0500 From: Mike Newell Message-Id: <9401242319.AA14220@lupine.nsi.nasa.gov> To: rem-conf@es.net, dmeyers@atlas.arc.nasa.gov, cshenton@wasabi.nsi.nasa.gov Subject: Re: Problem with wb importing PowerPoint-generated PostScript Cc: nasa-multicast@nasa.gov, mnewell@lupine.nsi.nasa.gov > From cshenton@wasabi.nsi.nasa.gov Mon Jan 24 18:10:53 1994 > > I'm trying to import some slides generated by Mac PowerPoint into wb > for an MBONE conference. When I do the wb import, I get errors like: > > -wb: can't send PS pages larger than 32768 bytes (is 496474) > -wb: can't send PS pages larger than 32768 bytes (is 564239) > > I can't find this string in the wb binary, so I assume that it's > complaining that it can't *send* (mcast) a ``packet' that size, not > that the .ps image data is too big. Did you look for "send PS pages larger than" in the text??? The 32768 might be a %d... > Examining the .ps itself, most of it is font definitions like: > > %%BeginFont: Helvetica-Bold > %!PS-TrueTypeFont-1-1-1 > 25 dict begin > /FontName /Helvetica-Bold def > /Encoding 256 array > 0 1 255{1 index exch/.notdef put}for > dup 0 /.null put > dup 8 /.null put > dup 9 /space put > [...] These are the "normal" things. > > and other definitions like: > > type42known not downloadOK and{userdict/TrueDict known{TrueDict/initer known not} > {true userdict begin/TrueDict 8 dict dup /version 27 put def end}ifelse}{false}ifelse{currentfile eexec}exch( %endeexec)exch checkload > > 1861AEDAAA5472E4FDE5287D4C4E53EBA565E192AC8F362DA1CD77A9FCA31B071701B025F68DCF4C631ED8451E912BED309E5278415CE3E471ECE22F5E04FE2BB3D1A2D8230D516E93FA22D5104354FA6E4E3829811FF537A9F7B7F5016FF9A084424DAB04EDCBABC563D12827F1CC491C3293A798745679001AC866 > [...] > YES!!!! :{) With System 7 came the "TrueType" family of fonts. Since the older LaserWriters don't have TrueType, and to allow for the use of TrueType fonts, the AppleDict download had to change to add in the definitions. The only way I know to get around this is to remove all references to TrueType fonts in the document - that is, use ONLY the non-TrueType fonts. How do you tell if a font is TrueType? Look at its icon; if it's got a couple of A's that look like they are scaling up, it's TrueType. It's also possible to manually remove the TrueType definitions, but the resulting font substitution may be unpretty. > Only a small fraction is dedicated to the actual content of the document. > > > (By comparison, some documents produced by TeX, translated to .dvi > then to .ps are scanned in fine -- the files are relatively small.) > Because you aren't downloading fonts. > Alternatively, are there programs which can ingest PowerPoint .ps and > spit out something more sane? > No, but you MIGHT try saving the PowerPoint output in a Word document, or changing the PowerPoint output to bitmaps in a Draw document (hey - you asked for solutions; you didn't say PRACTICAL solutions!!!) Did you try saving the stuff as encapsulated PostScript? That might be smaller... Mike From rem-conf-request@es.net Mon Jan 24 23:17:58 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <10497-0@osi-west.es.net>; Mon, 24 Jan 1994 20:10:38 +0000 Received: from elm.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Mon, 24 Jan 1994 20:10:34 -0800 Date: Mon, 24 Jan 1994 20:10:28 -0800 From: schooler@ISI.EDU Posted-Date: Mon, 24 Jan 1994 20:10:28 -0800 Message-Id: <199401250410.AA03584@elm.isi.edu> Received: by elm.isi.edu (5.65c/4.0.3-4) id ; Mon, 24 Jan 1994 20:10:28 -0800 To: rem-conf@es.net Subject: New version of mmcc Cc: schooler@ISI.EDU, touch@ISI.EDU, casner@ISI.EDU Hi, The mmcc session orchestration tool was first released a few months ago to run on Sun Sparcs. It allows a caller to explictly invite others to participate in point-to-point or multipoint teleconferences, and alerts them to accept or decline. It automatically spawns underlying audio, video and groupware programs among members of a session, then tears them down at session completion. We've now ported mmcc to run on SGIs running IRIX, HPs running HPUX, IBM PCs running Mach3.0, Dec 5000's running Ultrix V4.3, and Dec Alphas running OSF. The release software is now available from ftp.isi.edu:confctrl/mmcc, as files mmcc-{sparc,sgi,dec5k,decalpha,intel,hp}.tar.Z. The ports have been tested more thoroughly on some configurations than others. In addition to the porting activity, we fixed a number of serious bugs, including a few addressing-related ones. Comments and feedback are most welcome (and encouraged). Eve Schooler & Joe Touch {schooler, touch}@isi.edu From rem-conf-request@es.net Tue Jan 25 00:54:08 1994 Received: from picard.cmf.nrl.navy.mil by osi-west.es.net via ESnet SMTP service id <11049-0@osi-west.es.net>; Mon, 24 Jan 1994 21:47:34 +0000 Received: from copernicus.cmf.nrl.navy.mil (copernicus-atm.cmf.nrl.navy.mil [134.207.10.37]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id AAA02691; Tue, 25 Jan 1994 00:45:25 -0500 From: Allison J Mankin Received: by copernicus.cmf.nrl.navy.mil (4.1/client-1.3) id AA02828; Tue, 25 Jan 94 00:45:33 EST Date: Tue, 25 Jan 94 00:45:33 EST Message-Id: <9401250545.AA02828@copernicus.cmf.nrl.navy.mil> To: big-internet@munnari.oz.au, ietf@cnri.reston.va.us, rem-conf@es.net Subject: IPng MBONE Open Meeting II Cc: mankin@picard.cmf.nrl.navy.mil Hi, here's a revised announcement of the IPng Area discussion meeting on the MBONE. It takes place today (Tuesday, January 25) at 12:30-2 PM EST / 5:30-7 PM UTC. We now are offering a GSM channel mixed from the default vat PCM2 channel, for those with lower bandwidth tunnels. IPNG AREA MBONE MEETING The IP Next Generation Directorate and Directors will have an open discussion meeting using the MBONE (audio and whiteboard). Time: Tues. 25 January 1994, 12:30-2 EST / 5:30-7 PM UTC The conference has been listed in SD, but for those not using SD, its information is: IPng Area Open Meeting 224.2.234.120 port 32783 id 41704 pcm ttl 191 IPng Open Meeting Whiteboard 224.2.182.104 port 57093 id 29305 ttl 255 IPng Open Meeting GSM Channel 224.2.203.194 port 65466 id 8028 ttl 255 AGENDA: Introduction of Directorate and External Review Panel participants Discussion: what are the Internet's requirements for connectivity between IPv4-only and IPng-only hosts? what is the timescale of those requirements? [Up to one hour] Update on white papers for IPng requirements From rem-conf-request@es.net Tue Jan 25 05:33:14 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <12730-0@osi-west.es.net>; Tue, 25 Jan 1994 02:32:20 +0000 Received: from danger.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 25 Jan 1994 10:31:11 +0000 From: Mark Handley Organisation: University College London, CS Dept. Phone: +44 71 380 7777 ext 3666 To: Chris Shenton cc: rem-conf@es.net, dmeyers@atlas.arc.nasa.gov, nasa-multicast@nasa.gov, mnewell@lupine.nsi.nasa.gov Subject: Re: Problem with wb importing PowerPoint-generated PostScript In-reply-to: Your message of "Mon, 24 Jan 94 23:17:45 GMT." <9401242313.AA03167@wasabi.nsi.nasa.gov> Date: Tue, 25 Jan 94 10:31:06 +0000 Sender: M.Handley@cs.ucl.ac.uk >I'm trying to import some slides generated by Mac PowerPoint into wb >for an MBONE conference. When I do the wb import, I get errors like: > > -wb: can't send PS pages larger than 32768 bytes (is 496474) > -wb: can't send PS pages larger than 32768 bytes (is 564239) Three possible solutions: 1. Find a way to generate smaller files (use fonts that dont require downloading, and then remove the downloaded fonts from the postscript, or maybe they won't appear in the fil if you don't use them) 2. Use the lzps program supplied with wb. This implements compression in Postscript. 3. use the -p flag to wbimport to specify the largest file it will support. (at least I'm sure this used to work, but I can't get it to work right now) ----------------------------------------------------------------------------- Mark Handley Multimedia Integrated Conferencing for Europe (MICE) Project UCL Computer Science Gower Street London, UK URL: http://www.cs.ucl.ac.uk/mice/mhandley.html From rem-conf-request@es.net Wed Jan 26 03:31:14 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <28060-0@osi-west.es.net>; Wed, 26 Jan 1994 00:20:51 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Wed, 26 Jan 1994 00:20:48 -0800 Posted-Date: Wed 26 Jan 94 00:19:58 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Wed, 26 Jan 94 00:19:59 PST Date: Wed 26 Jan 94 00:19:58 PST From: Stephen Casner Subject: Re: Video on sun (was anyone) To: mit@cs.tut.fi Cc: rem-conf@es.net Message-Id: <759572398.0.CASNER@XFR.ISI.EDU> In-Reply-To: <199401221446.AA07962@kaarne.cs.tut.fi> Mail-System-Version: > - nv, requires version 3.3alpha to support parallax, works fine, good quality > and speed > - ivs, crashes machine completely with parallax encoding We've had system crashes with nv and parallax as well, when using an the xnews server from Parallax. We've switched one machine to their newer X11R5-based server and have not had any system crash with it. The server crashed a couple of times. -- Steve ------- From rem-conf-request@es.net Wed Jan 26 11:00:04 1994 Received: from sun2.nsfnet-relay.ac.uk by osi-west.es.net via ESnet SMTP service id <00561-0@osi-west.es.net>; Wed, 26 Jan 1994 05:42:23 +0000 Via: uk.ac.edinburgh.castle; Wed, 26 Jan 1994 12:38:25 +0000 Received: from ucs.ed.ac.uk by castle.ed.ac.uk id aa25972; 26 Jan 94 12:38 GMT Received: from scorpio.ucs.ed.ac.uk by ucs.ed.ac.uk; Wed, 26 Jan 94 12:38:13 GMT Date: Wed, 26 Jan 94 12:38:08 GMT Message-Id: <4510.9401261238@scorpio.ucs.ed.ac.uk> From: Graeme Wood Subject: Re: Video on sun (was anyone) To: rem-conf@es.net In-Reply-To: Stephen Casner's message of Wed, 26 Jan 1994 08:19:58 +0000 Reply-To: Graeme.Wood@edinburgh.ac.uk X-Department: Unix Systems Support, Computing Services X-Organisation: The University of Edinburgh X-Phone: +44 (0)31 650 5003 X-Fax: +44 (0)31 662 4712 > > - nv, requires version 3.3alpha to support parallax, works fine, good quality > > and speed > > - ivs, crashes machine completely with parallax encoding > > We've had system crashes with nv and parallax as well, when using an > the xnews server from Parallax. We've switched one machine to their > newer X11R5-based server and have not had any system crash with it. > The server crashed a couple of times. Well I have just tried nv 3.3alpha on a Parallax Powervideo card and the speed was diabolical, about .1fps. It has not crashed the system though. From rem-conf-request@es.net Wed Jan 26 11:21:13 1994 Received: from munin.fnal.gov by osi-west.es.net via ESnet SMTP service id <02062-0@osi-west.es.net>; Wed, 26 Jan 1994 07:57:34 +0000 Received: from LOCALHOST.fnal.gov by munin.fnal.gov with SMTP id AA18050 (5.65c+/IDA-1.4.4 for rem-conf@es.net); Wed, 26 Jan 1994 09:55:01 -0600 Message-Id: <199401261555.AA18050@munin.fnal.gov> To: rem-conf@es.net Subject: Re: Problem with wb importing PowerPoint-generated PostScript In-Reply-To: Your message of Tue, 25 Jan 94 10:31:06 GMT. <01H836QNJW6Q00TC45@FNAL.FNAL.GOV> Date: Wed, 26 Jan 94 09:55:01 -0600 From: Matt Crawford > > -wb: can't send PS pages larger than 32768 bytes (is 496474) Yesterday I got this error also. I was using a set of slides form MacDraw Pro, saved as EPSF. The file was about 38kB. I deleted a few slides and the resulting file was bigger! Delete a few more, and the file was a little smaller, but not under 32k. There were no truetype or any other fonts being included in the file -- I checked. Finallky, in desperation, I tried a single-page file I used to load into an older release of wb -- no go. This file is 38685 bytes and used to work without a hitch. (I'm not using wbimport, just the import postscript button of wb.) _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab From rem-conf-request@es.net Wed Jan 26 12:27:14 1994 Received: from seismo.CSS.GOV by osi-west.es.net via ESnet SMTP service id <03239-0@osi-west.es.net>; Wed, 26 Jan 1994 09:16:46 +0000 Received: from beno.CSS.GOV by seismo.CSS.GOV (4.1/SMI-4.1) id AA09851; Wed, 26 Jan 94 12:16:42 EST Received: by beno.CSS.GOV (4.1/SMI-4.1) id AA13568; Wed, 26 Jan 94 12:16:41 EST Message-Id: <9401261716.AA13568@beno.CSS.GOV> To: Matt Crawford Cc: rem-conf@es.net Subject: Re: Problem with wb importing PowerPoint-generated PostScript In-Reply-To: Your message of "Wed, 26 Jan 1994 09:55:01 CST." <199401261555.AA18050@munin.fnal.gov> X-Mailer: exmh version 1.2 1/14/94 Date: Wed, 26 Jan 1994 12:16:40 -0500 From: David Comay wb does support a x resource, MaxPostScriptSize, as well as the -P option to change the maximum size postscript file wb will import (and send) - of course, caution should be used to not import very large postscript files. matt, did you try looking at adobe `distill' program? i believe it is available on ftp.adobe.com. dsc From rem-conf-request@es.net Wed Jan 26 13:32:18 1994 Received: from nsipo.arc.nasa.gov by osi-west.es.net via ESnet SMTP service id <04170-0@osi-west.es.net>; Wed, 26 Jan 1994 10:16:10 +0000 Received: from lupine.nsi.nasa.gov by nsipo.arc.nasa.gov (4.1/1.5) id AA10516; Wed, 26 Jan 94 10:16:00 PST Received: by lupine.nsi.nasa.gov (5.65/SunOS-4.1.3) id AA20225; Wed, 26 Jan 94 13:14:07 -0500 Date: Wed, 26 Jan 94 13:14:07 -0500 From: Mike Newell Message-Id: <9401261814.AA20225@lupine.nsi.nasa.gov> To: rem-conf@es.net, crawdad@munin.fnal.gov Subject: Re: Problem with wb importing PowerPoint-generated PostScript If you're THAT close perhaps writing a quick and dirty program to remove all blank lines/carriage returns/etc. might get you under the limit... The problem is that even if you DON'T use TrueType fonts a lot of these utilities still include them. Look at the raw PostScript to make sure. Note that a LOT of common fonts are now TrueType rather than the old format, so even when you use an old favourite you are STILL getting the TT font. (I tried converting an entire PowerPoint document to courier and geneva (!) - I *STILL* got the d....d TT fonts [and the result looked horrible!!]) Mike Newell NSI Network Services > From rem-conf-request@es.net Wed Jan 26 13:00:32 1994 > > > > -wb: can't send PS pages larger than 32768 bytes (is 496474) > > Yesterday I got this error also. I was using a set of slides form > MacDraw Pro, saved as EPSF. The file was about 38kB. I deleted a > few slides and the resulting file was bigger! Delete a few more, and > the file was a little smaller, but not under 32k. There were no > truetype or any other fonts being included in the file -- I checked. > Finallky, in desperation, I tried a single-page file I used to load > into an older release of wb -- no go. This file is 38685 bytes and > used to work without a hitch. (I'm not using wbimport, just the > import postscript button of wb.) > _________________________________________________________ > Matt Crawford crawdad@fnal.gov Fermilab > From rem-conf-request@es.net Wed Jan 26 14:33:06 1994 Received: from media-lab.media.mit.edu by osi-west.es.net via ESnet SMTP service id <05260-0@osi-west.es.net>; Wed, 26 Jan 1994 11:23:19 +0000 Received: by media.mit.edu (5.57/DA1.0.4.amt) id AA07090; Wed, 26 Jan 94 14:23:15 -0500 Date: Wed, 26 Jan 94 14:23:15 -0500 From: David Young Message-Id: <9401261923.AA07090@media.mit.edu> To: rem-conf@es.net Subject: please add me... I was told that this is a mail group on internet video conferencing. Could you please add me to your mailing list. If you have a digest version I'd prefer that - but normail mail is ok, too. My address is: dyoung@media.mit.edu thanks, david young From rem-conf-request@es.net Wed Jan 26 14:43:39 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <05400-0@osi-west.es.net>; Wed, 26 Jan 1994 11:29:46 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <15254(4)>; Wed, 26 Jan 1994 11:29:29 PST Received: from localhost by ecco.parc.xerox.com with SMTP id <16143>; Wed, 26 Jan 1994 11:29:23 -0800 To: Graeme.Wood@edinburgh.ac.uk cc: rem-conf@es.net Subject: Re: Video on sun (was anyone) In-reply-to: Your message of "Wed, 26 Jan 94 04:38:08 PST." <4510.9401261238@scorpio.ucs.ed.ac.uk> X-Mailer: exmh version 1.3alpha 1/24/94 Date: Wed, 26 Jan 1994 11:29:21 PST Sender: Ron Frederick From: Ron Frederick Message-Id: <94Jan26.112923pst.16143@ecco.parc.xerox.com> In message <4510.9401261238@scorpio.ucs.ed.ac.uk> you write: >>> - nv, requires version 3.3alpha to support parallax, works fine, good >>> quality and speed > > Well I have just tried nv 3.3alpha on a Parallax Powervideo card and the > speed was diabolical, about .1fps. It has not crashed the system though. The speed should be poor compared to doing local video with the Parallax, but it should be pretty similar to VideoPix performance, or about 3-5fps when the bandwidth slider isn't limiting things too much. The reason for the slowness is the same as the slowness on the VideoPix. We are being forced to read 32-bit wide pixels across the SBus using programmed I/O, and the cards don't respond to these read requests very quickly. In the case of the Parallax, we're reading from its frame buffer rather than a FIFO, but the effect is about the same. I don't know why you'd see anything like 0.1fps unless the Parallax board has something horrible against PAL video that I don't know about. Since the PAL image is larger, you should be losing about 30% or so on the frame rate, but no more than that unless there's something pathological going on. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Wed Jan 26 14:52:39 1994 Received: from picard.cmf.nrl.navy.mil by osi-west.es.net via ESnet SMTP service id <05621-0@osi-west.es.net>; Wed, 26 Jan 1994 11:43:04 +0000 Received: from herman.cmf.nrl.navy.mil (herman-atm.cmf.nrl.navy.mil [134.207.10.3]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id OAA00689; Wed, 26 Jan 1994 14:40:45 -0500 Received: from localhost by herman.cmf.nrl.navy.mil (4.1/client-1.3) id AA15792; Wed, 26 Jan 94 12:53:07 EST Message-Id: <9401261753.AA15792@herman.cmf.nrl.navy.mil> To: Matt Crawford Cc: rem-conf@es.net Subject: Re: Problem with wb importing PowerPoint-generated PostScript In-Reply-To: Your message of "Wed, 26 Jan 94 09:55:01 CST." <199401261555.AA18050@munin.fnal.gov> X-Face: -*.ZYbFWa}{2c8NmF| > This file is 38685 bytes and used to work without a hitch. Your two choices are to: a) get everyone to start wb with the -P xxx option b) make your postscript file smaller, possibly using lzps. See the NOTES file distributed with wb for more details. The lzps program appears to be distributed with wbimport. Bill From rem-conf-request@es.net Wed Jan 26 15:45:02 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <06356-0@osi-west.es.net>; Wed, 26 Jan 1994 12:35:33 +0000 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <15258(5)>; Wed, 26 Jan 1994 12:35:20 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Wed, 26 Jan 1994 12:35:10 -0800 To: rem-conf@es.net Subject: Re: Problem with wb importing PowerPoint-generated PostScript Date: Wed, 26 Jan 1994 12:34:57 PST Sender: Steve Deering From: Steve Deering Message-Id: <94Jan26.123510pst.12171@skylark.parc.xerox.com> I've had good luck with the version 8.0 LaserWriter driver. It offers the choice of omitting all fonts when writing the PostScript to a file. It also generates much "cleaner" PostScript, according to Van. Steve From rem-conf-request@es.net Wed Jan 26 16:43:37 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <07251-0@osi-west.es.net>; Wed, 26 Jan 1994 13:33:59 +0000 Received: from btn.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Wed, 26 Jan 1994 13:33:50 -0800 Date: Wed, 26 Jan 94 13:33:48 -0800 From: touch@ISI.EDU Posted-Date: Wed, 26 Jan 94 13:33:48 -0800 Message-Id: <9401262133.AA03308@btn.isi.edu> Received: by btn.isi.edu (NX5.67c/4.0.3-4) id ; Wed, 26 Jan 94 13:33:48 -0800 Original-Received: by NeXT.Mailer (1.87.1) PP-warning: Illegal Received field on preceding line Original-Received: by NeXT Mailer (1.87.1) PP-warning: Illegal Received field on preceding line To: Mike Newell Subject: Re: Problem with wb importing PowerPoint-generated PostScript Cc: rem-conf@es.net, crawdad@munin.fnal.gov > The problem is that even if you DON'T use TrueType fonts a lot > of these utilities still include them. Look at the raw > PostScript to make sure. Note that a LOT of common fonts are > now TrueType rather than the old format, so even when you use > an old favourite you are STILL getting the TT font. (I tried > converting an entire PowerPoint document to courier and > geneva (!) - I *STILL* got the d....d TT fonts [and the result > looked horrible!!]) There is a share/freeware (?) Mac control panel called Trimmer that avoids this. You should set it to INCLUDE only those fonts that you don't expect in PostScript. It should also be set to INCLUDE the Mac PostScript header. The file sizes will be MUCH smaller. Joe From rem-conf-request@es.net Wed Jan 26 17:40:55 1994 Received: from opus.sdsc.edu by osi-west.es.net via ESnet SMTP service id <08148-0@osi-west.es.net>; Wed, 26 Jan 1994 14:30:47 +0000 Received: by opus.sdsc.edu (4.1/IBM1.1) id AA29041; Wed, 26 Jan 94 14:34:07 PST Date: Wed, 26 Jan 94 14:34:07 PST From: Thomas Hutton Message-Id: <9401262234.AA29041@opus.sdsc.edu> To: rem-conf@es.net Subject: Re: Problem with wb importing PowerPoint-generated PostScript I would recomend the 8.1.1 LaserWriter driver over 8.0. 8.0 had some bad bugs in it according to our mac support people. Tom From rem-conf-request@es.net Wed Jan 26 20:31:35 1994 Received: from usc.edu by osi-west.es.net via ESnet SMTP service id <10260-0@osi-west.es.net>; Wed, 26 Jan 1994 17:22:40 +0000 Received: from catarina.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA24790; Wed, 26 Jan 94 17:22:33 PST Received: from catarina.usc.edu by catarina.usc.edu (4.1/SMI-4.1+ucs-3.6) id AA10600; Wed, 26 Jan 94 17:25:02 PST Message-Id: <9401270125.AA10600@catarina.usc.edu> To: rem-conf@es.net Subject: help with vat on DEC Alpha X-Mailer: exmh version 1.2 1/14/94 Date: Wed, 26 Jan 1994 17:25:01 -0800 From: "Danny J. Mitzel" I was wondering if anyone else has seen and/or knows the solution to fix the following problem: SO_REUSEPORT: Option not supported by protocol this is reported on a DEC Alpha OSF/1 v1.3 running vat-3.2 to a unicast destination. thanks for any help! danny From rem-conf-request@es.net Thu Jan 27 05:50:05 1994 Received: from milou.inria.fr by osi-west.es.net via ESnet SMTP service id <14627-0@osi-west.es.net>; Thu, 27 Jan 1994 00:37:28 +0000 Received: by milou.inria.fr (5.65c8/IDA-1.2.8) id AA02268; Thu, 27 Jan 1994 09:40:30 +0100 Message-Id: <199401270840.AA02268@milou.inria.fr> To: Stephen Casner Cc: rem-conf@es.net Subject: Re: Video on sun (was anyone) In-Reply-To: Your message of 26 Jan 1994 00:19:58 -0800. <759572398.0.CASNER(a)XFR.ISI.EDU> Reply-To: turletti@jerry.inria.fr Date: Thu, 27 Jan 1994 09:40:29 +0100 From: Thierry Turletti - Project RODEO - INRIA sophia-Antipolis -FRANCE >> - nv, requires version 3.3alpha to support parallax, works fine, good quality >> and speed >> - ivs, crashes machine completely with parallax encoding > We've had system crashes with nv and parallax as well, when using an > the xnews server from Parallax. We've switched one machine to their > newer X11R5-based server and have not had any system crash with it. > The server crashed a couple of times. > -- Steve The new PARALLAX boards (MULTIVIDEO and POWERVIDEO) are not compatible with the current version of hard_lib_px.o used in ivs. The new version of ivs should run fine both on previous and new PARALLAX boards. I hope to release it by the end of January. Thierry From rem-conf-request@es.net Thu Jan 27 09:04:30 1994 Received: from mitsou.inria.fr by osi-west.es.net via ESnet SMTP service id <16514-0@osi-west.es.net>; Thu, 27 Jan 1994 05:44:24 +0000 Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA04864; Thu, 27 Jan 1994 14:45:07 +0100 Message-Id: <199401271345.AA04864@mitsou.inria.fr> To: Ron Frederick Cc: Graeme.Wood@edinburgh.ac.uk, rem-conf@es.net Subject: Re: Video on sun (was anyone) In-Reply-To: Your message of "26 Jan 1994 11:29:21 PST." <94Jan26.112923pst.16143(a)ecco.parc.xerox.com> Date: Thu, 27 Jan 1994 14:45:06 +0100 From: Christian Huitema The TELESIA team at INRIA/Rocquencourt consistenly get reasonably high frame rates using the Parallax board with IVS -- I have seen black and white QCIF (quarter) video run at more than 20 fps. This is done with a SECAM camera, so using the same image format as PAL. One can probably achieve the same performances with NV. By the way -- the native format for the Parallax board is JPEG. There is a content type dedicated to JPEG in RTP, but the description of JPEG packetization is somewhat sketchy. Is there a full spec available somewhere? Christian Huitema From rem-conf-request@es.net Thu Jan 27 11:26:50 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <18104-0@osi-west.es.net>; Thu, 27 Jan 1994 08:25:51 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <14531(2)>; Thu, 27 Jan 1994 08:24:05 PST Received: from localhost by ecco.parc.xerox.com with SMTP id <16143>; Thu, 27 Jan 1994 08:24:00 -0800 To: Christian Huitema cc: Graeme.Wood@edinburgh.ac.uk, rem-conf@es.net Subject: Re: Video on sun (was anyone) In-reply-to: Your message of "Thu, 27 Jan 94 05:45:06 PST." <199401271345.AA04864@mitsou.inria.fr> Date: Thu, 27 Jan 1994 08:23:58 PST Sender: Ron Frederick From: Ron Frederick Message-Id: <94Jan27.082400pst.16143@ecco.parc.xerox.com> In message <199401271345.AA04864@mitsou.inria.fr> you write: > The TELESIA team at INRIA/Rocquencourt consistenly get reasonably high frame > rates using the Parallax board with IVS -- I have seen black and white QCIF > (quarter) video run at more than 20 fps. This is done with a SECAM camera, so > using the same image format as PAL. One can probably achieve the same > performances with NV. > > By the way -- the native format for the Parallax board is JPEG. There is a > content type dedicated to JPEG in RTP, but the description of JPEG > packetization is somewhat sketchy. Is there a full spec available somewhere? Right now, nv does not support QCIF sized images. You're right that it would probably give quite an increase in frame rate (as would going to greyscale) if you were willing to accept the associated loss in information. There's nothing in the nv network format which prevents it, either. It just hasn't been put into any of the video grabbers yet. I still don't understand why the nv performance would be so much worse on PAL compared to NTSC, though. I have neither a Parallax board nor a PAL source, so I can't track it down, but I'd be willing to work with someone who could. From the number above, I'd say that nv & ivs would be performing about the same on CIF color images grabs if nv PAL & NTSC performance were in line. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Thu Jan 27 11:54:43 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <18345-0@osi-west.es.net>; Thu, 27 Jan 1994 08:38:35 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <14515(5)>; Thu, 27 Jan 1994 08:38:26 PST Received: from localhost by ecco.parc.xerox.com with SMTP id <16143>; Thu, 27 Jan 1994 08:38:17 -0800 To: Christian Huitema cc: Graeme.Wood@edinburgh.ac.uk, rem-conf@es.net, fenner@cmf.nrl.navy.mil Subject: Re: Video on sun (was anyone) In-reply-to: Your message of "Thu, 27 Jan 94 05:45:06 PST." <199401271345.AA04864@mitsou.inria.fr> Date: Thu, 27 Jan 1994 08:38:16 PST Sender: Ron Frederick From: Ron Frederick Message-Id: <94Jan27.083817pst.16143@ecco.parc.xerox.com> Whoops -- I forgot to reply to the second half of this message... In message <199401271345.AA04864@mitsou.inria.fr> you write: > By the way -- the native format for the Parallax board is JPEG. There is a > content type dedicated to JPEG in RTP, but the description of JPEG > packetization is somewhat sketchy. Is there a full spec available somewhere? > A few different people have started to experiment with JPEG over RTP, and so it really is time to try and hash out a detailed agreement about what belongs in the packet. Bill Fenner proposed something at the last IETF, and I think it is actually a very reasonable starting point for this effort. Bill: Could you post a description of your ideas about the JPEG format here? We really need to reach some agreement soon, so we can begin doing some interoperability testing. We've now got our boards working at PARC, and Lance Berc at DEC has some code for the J300 board. There's also your XVideo stuff, and it wouldn't surprise me if someone at Sun was already experimenting with JPEG from the SunVideo board. I've also heard some interest in starting work on a few other platforms. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Thu Jan 27 12:36:08 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <19062-0@osi-west.es.net>; Thu, 27 Jan 1994 09:22:19 +0000 Received: from rover.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 27 Jan 1994 17:22:00 +0000 To: mice-seminars@cs.ucl.ac.uk, rem-conf@es.net Subject: MICE International Seminars - February to April 1994 Date: Thu, 27 Jan 94 17:21:57 +0000 From: Gordon Joly As this list will be updated from time to time, please see the URL http://www.cs.ucl.ac.uk/mice/seminars.html which should also contain abstracts. Abstracts for each talk will be posted nearer the talk. Please limit network traffic at these times. The usual MICE multicast addresses will be used: vat 224.5.17.12 (default port) ivs 224.5.17.12 (default port) wb 224.5.17.12 (port 32416) Date Start Fin Start Trans Speaker (Organisation) (CET) (CET) (UK) site Title Feb 8 15.00 16.00 14.00 UCL Toshikazu Kato (ETL/MITI) Human Media Technology New Perspectives on Human-Media Interaction Feb 22 15.00 16.00 14.00 GMD Bruno Struif (GMD) Electronic Prescription Mar 8 15.00 16.00 14.00 GMD Klaus Dieter Guenther (GMD) Distributed Cooperative Office Applications Mar 22 15.00 16.00 14.00 KTH Christian Huitema (INRIA) A criticisim of the OSI model and an alternative architecture Apr 5 15.00 16.00 14.00 GMD Heinz Sarbinowsky (GMD) Use of Chipcards in the Legal Area Apr 19 15.00 16.00 14.00 KTH Christer Carlsson (SICS) DIVE: Distributed Interactive Virtual Environment Apr 26 15.00 16.00 14.00 UCL Dave Feldmeier (Bellcore) Title to be announced. Gordon Joly Phone +44 71 380 7777 3703 FAX +44 71 387 1397 Email: G.Joly@cs.ucl.ac.uk UUCP: ...!{uunet,uknet}!ucl-cs!G.Joly Comp Sci, University College London, Gower Street, LONDON WC1E 6BT WWW:- http://www.cs.ucl.ac.uk/mice/gjoly.html -:WWW From rem-conf-request@es.net Thu Jan 27 14:39:03 1994 Received: from relay.hp.com by osi-west.es.net via ESnet SMTP service id <21283-0@osi-west.es.net>; Thu, 27 Jan 1994 11:27:41 +0000 Received: from it_750.ch.apollo.hp.com by relay.hp.com with SMTP (1.36.108.7/15.5+IOS 3.13) id AA28465; Thu, 27 Jan 1994 11:27:35 -0800 Message-Id: <9401271927.AA28465@relay.hp.com> Received: from york.ch.apollo.hp.com by it_750.ch.apollo.hp.com for rem-conf@es.net id AA29551; Thu, 27 Jan 1994 14:27:38 -0500 To: rem-conf@es.net Subject: another mailing list for MBONE stuff Date: Thu, 27 Jan 94 14:27:34 -0500 From: John Brezak This one always has some good discussions. rem-conf@es.net =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= John Brezak UUCP: uunet!apollo.hp!brezak Hewlett Packard/Apollo Internet: brezak@ch.hp.com 300 Apollo Drive Phone: (508) 436-4915 Chelmsford, Massachusetts Fax: (508) 436-5103 From rem-conf-request@es.net Fri Jan 28 06:25:46 1994 Received: from cs.tut.fi by osi-west.es.net via ESnet SMTP service id <01351-0@osi-west.es.net>; Fri, 28 Jan 1994 03:12:46 +0000 Received: from isosotka.cs.tut.fi (isosotka.cs.tut.fi [130.230.5.14]) by cs.tut.fi (8.6.4/8.6.4) with SMTP id NAA13096 for ; Fri, 28 Jan 1994 13:13:01 +0200 Received: by isosotka.cs.tut.fi id AA23475 (5.65c/IDA-1.4.4 for rem-conf@es.net); Fri, 28 Jan 1994 13:16:32 +0200 Date: Fri, 28 Jan 1994 13:16:32 +0200 From: Mikko Tsokkinen Message-Id: <199401281116.AA23475@isosotka.cs.tut.fi> To: rem-conf@es.net Subject: Re: Video on sun (was anyone) In-Reply-To: <94Jan26.112923pst.16143@ecco.parc.xerox.com> References: <4510.9401261238@scorpio.ucs.ed.ac.uk> <94Jan26.112923pst.16143@ecco.parc.xerox.com> Ron Frederick writes: >In message <4510.9401261238@scorpio.ucs.ed.ac.uk> you write: >>>> - nv, requires version 3.3alpha to support parallax, works fine, good >>>> quality and speed >> >> Well I have just tried nv 3.3alpha on a Parallax Powervideo card and the >> speed was diabolical, about .1fps. It has not crashed the system though. > >The speed should be poor compared to doing local video with the Parallax, but >it should be pretty similar to VideoPix performance, or about 3-5fps when the >bandwidth slider isn't limiting things too much. > >The reason for the slowness is the same as the slowness on the VideoPix. We >are being forced to read 32-bit wide pixels across the SBus using programmed >I/O, and the cards don't respond to these read requests very quickly. In the >case of the Parallax, we're reading from its frame buffer rather than a FIFO, >but the effect is about the same. > >I don't know why you'd see anything like 0.1fps unless the Parallax board has >something horrible against PAL video that I don't know about. Since the PAL >image is larger, you should be losing about 30% or so on the frame rate, but >no more than that unless there's something pathological going on. Since I wrote the first statement I can explain bit more. Works fine, good quality and speed means: - Powervideo+nv has not crashed the machine (well few times but not very recently and it is transmitting 24 hrs/day) - The colors are very near to the orginal and very little noise is visible - Screen update is few frames a second (this means I have never seen faster grabber with nv, not that it is nothing like 25fps) We use PAL system here, I have also transmitted some NTSC-LaserDisc signal and noticed no serious quality differences compared to PAL. -- Cheers Mikko Tsokkinen xxxxx Mit "I do not fear computers. I fear the lack of them." From rem-conf-request@es.net Fri Jan 28 13:12:52 1994 Received: from nic.near.net by osi-west.es.net via ESnet SMTP service id <05485-0@osi-west.es.net>; Fri, 28 Jan 1994 10:00:51 +0000 Received: from foo.near.net by nic.near.net id aa02810; 24 Jan 94 18:04 EST To: Allison J Mankin cc: rem-conf@es.net Subject: Re: IPng MBONE Meeting--Jan 25 In-reply-to: Your message of "Fri, 21 Jan 1994 15:44:14 EST." <9401212044.AA01032@radegond.cmf.nrl.navy.mil> Date: Mon, 24 Jan 1994 18:03:54 -0500 From: Ed Anselmo SD says the IPng MBONE session will be going out with a TTL of 127. I have several sites who are interested in receiving the audiocast, but don't want things like IMM satellite images and MBONE video going across their (less than T1) links. Since there's no video for this session, why not run the session with a TTL of 191? -- Ed Anselmo (anselmo@nic.near.net) From rem-conf-request@es.net Sat Jan 29 14:38:36 1994 Received: from viipuri.nersc.gov by osi-west.es.net via ESnet SMTP service id <16549-0@osi-west.es.net>; Sat, 29 Jan 1994 11:26:08 +0000 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA06245; Sat, 29 Jan 94 11:26:07 PST Date: Sat, 29 Jan 94 11:26:07 PST From: ari@es.net (Ari Ollikainen) Message-Id: <9401291926.AA06245@viipuri.nersc.gov> To: rem-conf@es.net Subject: FWD: MBONE and videoconferencing >From moon@dbas.ece.arizona.edu Thu Jan 27 02:27:15 1994 Return-Path: Received: from osi-west.es.net by viipuri.nersc.gov (4.1/ESnet-1.2) id AA04298; Thu, 27 Jan 94 02:27:14 PST Received: from dbas.ece.arizona.edu by osi-west.es.net via ESnet SMTP service id <15099-0@osi-west.es.net>; Thu, 27 Jan 1994 02:27:12 +0000 Received: by dbas.ece.arizona.edu (5.65/DEC-Ultrix/4.3) id AA18974; Thu, 27 Jan 1994 03:27:02 -0700 Date: Thu, 27 Jan 1994 03:27:02 -0700 From: moon@dbas.ece.arizona.edu (Moon) Message-Id: <9401271027.AA18974@dbas.ece.arizona.edu> To: rem-conf-request@es.net Subject: MBONE and videoconferencing Status: RO Hello, First of all, I'd like to join this mailing list. I am a graduate student at the University of Arizona, preparing for the thesis. I am also working on MBONE network and video conferencing. Our research group(Computer Engineering Research Lab., ECE) are planning to connect to MBONE and install the softwares(nv, vat, NEVOT, etc) related to video conferencing. We have several multicast capable platforms, SUN Sparc, DEC 5000, and SGI Indigo even though SUN Sparc need to be updated to suppport IP multicast. As someone in the net may have problems with searching and installing things. I also have difficulties in searching and installing softwares, buying hardwares (VideoPix card, PPP frame grabber for DEC, frame grabber for SGI, and video camera), and connecting to nearest MBONE node. I'd like to know about frame grabbers and video camera available(person to contact and cost), ways to connect to MBONE node, related papers, and any other references. I guess someone may have some suggestions and I'll appreciate any help. Thank you. ---- Moon, Gwi Dept. of Electrical & Computer Engineering University of Arizona || Tucson, Arizona 85721 Tel: (602)884-1231, Internet address: moongw@ece.arizona.edu From rem-conf-request@es.net Sat Jan 29 22:49:49 1994 Received: from UTKUX1.UTK.EDU by osi-west.es.net via ESnet SMTP service id <18948-0@osi-west.es.net>; Sat, 29 Jan 1994 19:43:24 +0000 Received: from mars.cc (MARS.UTCC.UTK.EDU) by utkux1.utcc.utk.edu (5.0/2.8s-UTK.UTCC) id AA06046; Sat, 29 Jan 1994 22:43:20 +0500 Received: by mars.cc (5.0/SMI-SVR4) id AA10830; Sat, 29 Jan 1994 22:43:18 +0500 Date: Sat, 29 Jan 1994 22:43:18 +0500 From: venu@utkux1.utk.edu (Nair Venugopal) Message-Id: <9401300343.AA10830@mars.cc> To: rem-conf@es.net Subject: subscribe Content-Length: 70 I would like to join this mailing list Nair venu@utkux.utcc.utk.edu From rem-conf-request@es.net Sun Jan 30 00:08:01 1994 Received: from taurus.cs.nps.navy.mil by osi-west.es.net via ESnet SMTP service id <19227-0@osi-west.es.net>; Sat, 29 Jan 1994 21:01:30 +0000 Received: by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA21195; Sat, 29 Jan 94 21:02:33 PST Date: Sat, 29 Jan 94 21:02:33 PST From: brutzman@cs.nps.navy.mil (Don Brutzman) Message-Id: <9401300502.AA21195@taurus.cs.nps.navy.mil> To: rem-conf@es.net Subject: MBONE underwater robotics event pre-announcement Cc: abennett@mit.edu, arm@aqua.whoi.edu, healey@lex.me.nps.navy.mil, iarp@hp850.mbari.org, jgb@mit.edu, kens@jargon.whoi.edu, mcghee@cs.nps.navy.mil Friday May 6 1994 we hope to broadcast invited talks and remote lab demonstrations for the second workshop on Mobile Robots for Subsea Environments, sponsored by the International Advanced Robotics Programme. Nations represented include France, Italy, Japan, U.K., USA and others. This MBONE event will include three capstone presentations from the weeklong workshop. We also are working on providing live demonstrations by underwater robotics laboratories at IFREMER in France, University of Tokyo, Woods Hole Oceanographic Institution Deep Submergence Lab, MIT Sea Grant, Naval Postgraduate School, and the host for the event: the Monterey Bay Aquarium Research Institute (MBARI). We hereby request that consideration be given to avoid scheduling other major MBONE events on May 6. Furthermore, since we hope to multicast from multiple sites, I propose that we have the active site transmit at the standard bandwidth of 128 Kbps while other sites continue to transmit at reduced levels (perhaps 16 Kbps) to ensure connectivity and program continuity. Our current proposal is for six concurrent multicast sites with worldwide scope. Bandwidth commentary directed to rem-conf@es.net (or to me) is welcome. Attendance at the workshop is by invitation. Workshop inquiries may be sent to Michael Lee, MBARI, 160 Central Avenue, Pacific Grove CA 93950 USA, e-mail iarp@mbari.org Thanks in advance & best regards. Donald P. Brutzman LCDR USN work (408) 656-2149 Code OR/Br Naval Postgraduate School [Glasgow 204] fax (408) 656-2595 Monterey California 93943-5000 USA home (408) 372-0190 From rem-conf-request@es.net Mon Jan 31 13:17:57 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <01897-0@osi-west.es.net>; Mon, 31 Jan 1994 10:06:20 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <14581(1)>; Mon, 31 Jan 1994 10:06:11 PST Received: from localhost by ecco.parc.xerox.com with SMTP id <16143>; Mon, 31 Jan 1994 10:04:01 -0800 To: Mikko Tsokkinen cc: rem-conf@es.net Subject: Re: Video on sun (was anyone) In-reply-to: Your message of "Fri, 28 Jan 94 03:16:32 PST." <199401281116.AA23475@isosotka.cs.tut.fi> X-Mailer: exmh version 1.3alpha 1/26/94 Date: Mon, 31 Jan 1994 10:03:55 PST Sender: Ron Frederick From: Ron Frederick Message-Id: <94Jan31.100401pst.16143@ecco.parc.xerox.com> In message <199401281116.AA23475@isosotka.cs.tut.fi> you write: > Since I wrote the first statement I can explain bit more. Works fine, > good quality and speed means: > > - Powervideo+nv has not crashed the machine (well few times but not > very recently and it is transmitting 24 hrs/day) > - The colors are very near to the orginal and very little noise is visible > - Screen update is few frames a second (this means I have never seen faster > grabber with nv, not that it is nothing like 25fps) > > We use PAL system here, I have also transmitted some NTSC-LaserDisc > signal and noticed no serious quality differences compared to PAL. > Thanks Mikko for the confirmation about PAL peformance... What you're seeing is about what I would expect, given the NTSC performance. Just as a side note, the color error which remains is due to round off introduced by the RGB->YUV lookup tables. I'm using those to pick up a bit of speed, but it does cost somewhat in accuracy. There's another set of tables which go from YUV->RGB involved as well in this case, actually. To those seeing poor peformance, make _sure_ that nv is compiled with optimization turned on! Without it on for things like the grab routines, it will definitely crawl! With gcc, it's perfectly fine to specify both -g and -O (I recommend -O2) at the same time. The -g will make the executable a bit bigger on disk, but it really shouldn't cost you in performance. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Mon Jan 31 13:32:32 1994 Received: from sun2.mhs-relay.ac.uk by osi-west.es.net via ESnet SMTP service id <02269-0@osi-west.es.net>; Mon, 31 Jan 1994 10:20:49 +0000 Via: uk.ac.edinburgh.castle; Mon, 31 Jan 1994 18:20:11 +0000 Received: from ucs.ed.ac.uk by castle.ed.ac.uk id aa17787; 31 Jan 94 18:20 GMT Received: from scorpio.ucs.ed.ac.uk by ucs.ed.ac.uk; Mon, 31 Jan 94 18:20:06 GMT Date: Mon, 31 Jan 94 18:19:43 GMT Message-Id: <3756.9401311819@scorpio.ucs.ed.ac.uk> From: Graeme Wood Subject: Re: Video on sun (was anyone) To: Ron Frederick , Mikko Tsokkinen In-Reply-To: Ron Frederick's message of Mon, 31 Jan 1994 18:03:55 +0000 Reply-To: Graeme.Wood@edinburgh.ac.uk X-Department: Unix Systems Support, Computing Services X-Organisation: The University of Edinburgh X-Phone: +44 (0)31 650 5003 X-Fax: +44 (0)31 662 4712 Cc: rem-conf@es.net > In message <199401281116.AA23475@isosotka.cs.tut.fi> you write: > > Since I wrote the first statement I can explain bit more. Works fine, > > good quality and speed means: > > > > - Powervideo+nv has not crashed the machine (well few times but not > > very recently and it is transmitting 24 hrs/day) > > - The colors are very near to the orginal and very little noise is visible > > - Screen update is few frames a second (this means I have never seen faster > > grabber with nv, not that it is nothing like 25fps) > > > > We use PAL system here, I have also transmitted some NTSC-LaserDisc > > signal and noticed no serious quality differences compared to PAL. > > > Thanks Mikko for the confirmation about PAL peformance... What you're seeing is > about what I would expect, given the NTSC performance. Just as a side note, the > color error which remains is due to round off introduced by the RGB->YUV lookup > tables. I'm using those to pick up a bit of speed, but it does cost somewhat in > accuracy. There's another set of tables which go from YUV->RGB involved as well > in this case, actually. > > To those seeing poor peformance, make _sure_ that nv is compiled with > optimization turned on! Without it on for things like the grab routines, it > will definitely crawl! With gcc, it's perfectly fine to specify both -g and > -O (I recommend -O2) at the same time. The -g will make the executable a bit > bigger on disk, but it really shouldn't cost you in performance. I have compiled it with optimization and have run a few tests since I last wrote to you. On a quiet system and pointing the camera at the wall I can get a little over 2 frames per second. With me sitting in front of the camera I get about 1 frame per second. If I also receive with nv as well as send then I get about .2-.5 frames per second. Now I admit I am not using a fast machine (this is a SPARC 1) but this system previously had a VideoPix card in it and it managed about 3-4 frames per second if not much was changing in the image or about 2-3 frames per second if there was. Graeme From rem-conf-request@es.net Mon Jan 31 15:44:03 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <04743-0@osi-west.es.net>; Mon, 31 Jan 1994 12:33:48 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <14670(7)>; Mon, 31 Jan 1994 12:33:31 PST Received: from localhost by ecco.parc.xerox.com with SMTP id <16143>; Mon, 31 Jan 1994 12:33:25 -0800 To: Graeme.Wood@edinburgh.ac.uk cc: rem-conf@es.net Subject: Re: Video on sun (was anyone) In-reply-to: Your message of "Mon, 31 Jan 94 10:19:43 PST." <3756.9401311819@scorpio.ucs.ed.ac.uk> X-Mailer: exmh version 1.3alpha 1/26/94 Date: Mon, 31 Jan 1994 12:33:15 PST Sender: Ron Frederick From: Ron Frederick Message-Id: <94Jan31.123325pst.16143@ecco.parc.xerox.com> In message <3756.9401311819@scorpio.ucs.ed.ac.uk> you write: > I have compiled it with optimization and have run a few tests since I > last wrote to you. > > On a quiet system and pointing the camera at the wall I can get a little > over 2 frames per second. With me sitting in front of the camera I get > about 1 frame per second. If I also receive with nv as well as send > then I get about .2-.5 frames per second. > > Now I admit I am not using a fast machine (this is a SPARC 1) but this > system previously had a VideoPix card in it and it managed about 3-4 > frames per second if not much was changing in the image or about 2-3 > frames per second if there was. Ok - this makes some sense. If you are receiving nv on a system with a Parallax, it is costing you significantly more than receiving video on a system with a GX frame buffer, as you are outputting 32-bit pixels to the X server rather then 8-bit pixels. So, a "normal" sized Parallax nv window is almost as expensive as a "double" sized GX window. If you've ever tried doing double size on a SPARC 1, you probably already know that it KILLS performance. Basically, it comes down to marginal CPU costs... On a SPARC 2 or above, your limiting factor by far in speed is the SBus performance. That's why a SPARC 10 is really not any faster than a SPARC 2 when using a VideoPix. A SPARC 1 can achieve this frame rate as well, if it is doing nothing else, but the cost to do any other work is much greater. So, on all of the above machines, there is a constant time cost to do the frame grabbing. The question is what the relatively magnitude of that constant is compared to the other costs. On a SPARC 10, the other costs are almost negligible for something like the VideoPix until you start receiving a LOT of incoming streams or running some huge CPU soaking program at the same time. On a SPARC 1, even the cost of displaying your own image is a large fraction of the constant (and may even exceed it for a 24-bit display like the Parallax). Our own experience with a SPARC 1 and a VideoPix running a television source at 256kbps is that we see a performance somewhere around 0.3-1.2 fps depending on the particular scene. Generally speaking, the 256kbps is not the limiting factor or even close to it. Rather, the system is CPU limited. The same TV source fed into a SPARC 10 with a VideoPix card and with no bandwidth constraint can run at the VideoPix limit of 3-4 fps pretty reliably. When we use a faster frame grabber, we get 6-15 fps, where the particular frame rate is once again CPU limited (dependent on the amount of motion in the frame). If it is at all possible (and I realize it might not be), I would recommend trying to replace and/or upgrade your SPARC 1 to a SPARC 2 or better, especially if you are going to have a 24-bit frame buffer in it. -- Ron Frederick frederick@parc.xerox.com