Re: [Flightgear-devel] Broadcast Address
Hi, Let us know what you come up with on the broadcast stuff. Regards, Curt. Was the broadcast fix included in the 0.9.8 pre-release? Recapping: plib expects the string to be broadcast in netsocket.cpp line#80; Simgear rejects either an explicit broadcast address xxx.xxx.xxx.255 or the above string, preferring broadcast which it dutifully passes on to plib which fails trying to resolve host named broadcast. Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Broadcast Address
John Wojnaroski wrote: Hi, Let us know what you come up with on the broadcast stuff. Regards, Curt. Was the broadcast fix included in the 0.9.8 pre-release? Recapping: plib expects the string to be broadcast in netsocket.cpp line#80; Simgear rejects either an explicit broadcast address xxx.xxx.xxx.255 or the above string, preferring broadcast which it dutifully passes on to plib which fails trying to resolve host named broadcast. John, as I look at the code, I don't see anything that explicitely accepts or rejects any host names. However I do notice that and are special characters to the unix (and probably dos) shells. The shell will try to pass input from a file called broadcast as stdin to fgfs and send the output to whatever is after the . Try enclosing the entire option in double quotes to hide these characters from the shell interpreter ... fgfs --native-gui=socket,out,1,broadcast,5504,udp You *shouldn't* need these for options included in your .fgfsrc file. I'm not in a place where I can test if this actually works though ... Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Broadcast Address
Curtis wrote: are special characters to the unix (and probably dos) shells. The shell will try to pass input from a file called broadcast as stdin to fgfs and send the output to whatever is after the . Try enclosing the entire option in double quotes to hide these characters from the shell interpreter ... fgfs --native-gui=socket,out,1,broadcast,5504,udp You *shouldn't* need these for options included in your .fgfsrc file. I'm not in a place where I can test if this actually works though ... Tried it, and the shell punted.. This aircraft model is a BETA release!!! This aircraft model probably will not fly as expected. Use this model for development purposes ONLY!!! --opengc=socket,out,32,broadcast,6000,udp: not found Using bash. Don't understand why pilb is coded in the manner it is, but I've hacked a patch into plib to just test for broadcast instead of broadcast and that works (at least for my purposes) Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Broadcast Address
- Original Message - From: John Wojnaroski [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Sunday, December 12, 2004 5:43 PM Subject: Re: [Flightgear-devel] Broadcast Address Curtis Olson wrote: Let us know what you come up with on the broadcast stuff. Regards, Curt. Okay, here's the answer... In plib line #80 Ooops, that's line #80 in netsocket.cpp JW ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Broadcast Address
Curtis Olson wrote: Let us know what you come up with on the broadcast stuff. Regards, Curt. Okay, here's the answer... In plib line #80 if (host[0] == '' strcmp(host, broadcast) == 0) sin_addr = INADDR_BROADCAST; expects the string argument as noted above. There does not appear to be any option to set the address expicitly, as in 192.168.2.255, which results in an error and program termination. SimGear expects the string argument to be broadcast and passes that on to plib. If you try to set the string in the command option; e.g. native-fdm=socket,32,broadcast,6000,udp then FG/SimGear complains and exits. So the fix can be in either place, change SimGear to pass the string as required or change plib to if ( strcmp(host, broadcast) ==0) you make the call Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Broadcast Address
- Original Message - From: Steven Beeckman [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Friday, December 10, 2004 2:08 PM Subject: Re: [Flightgear-devel] Broadcast Address Citeren John Wojnaroski [EMAIL PROTECTED]: I've been thinking of moving over to RTLinux (there is an open-source GPL'd version) in 2005. It fits nicely with the structure of the opengc display code. I'd like to mention RTAI (http://www.rtai.org), a Linux kernel patch to get the kernel working in real-time (even hard real-time!). RTAI is open source too, and even GPL if I remember correctly. I don't know how it fits with opengc, as I haven't found much info on the linux-port of OpenGC (which actually looks very interesting to me :-D). There is also http://www.rtlinux.org which links over to http://www.fsmlabs.com/ which has a version and source with a GPL license. Without going into a long recap of the history, there was a earlier version of OpenGC that ran under Linux that was my child. A few years back Damion made some major changes to the project and licensing to allow for commercial use in experimental aircraft. Something I was (am not) too keen on and that software was removed. For some pics of OpenGC running with FlightGear browse over to the Project page on the FG website. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Broadcast Address
Let us know what you come up with on the broadcast stuff. Regards, Curt. I will do that... Your short discussion on timing brought to mind an interesting question. Since there is some unpredictability to the scheduling algorithms and device drivers and system calls, can the 60Hz rate really be locked. Short of going to a real-time OS like RTLinux, is this a case of where getting close is good enough... I've been thinking of moving over to RTLinux (there is an open-source GPL'd version) in 2005. It fits nicely with the structure of the opengc display code. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Broadcast Address
John Wojnaroski wrote: I will do that... Your short discussion on timing brought to mind an interesting question. Since there is some unpredictability to the scheduling algorithms and device drivers and system calls, can the 60Hz rate really be locked. You are right, without taking additional measures, it's not really locked. The best you can hope for is that if you have enough hardware, and you don't throw too much rendering load at it, you can stay within your time slice limit and draw at 60 hz. You can cheat and if you realize you can't quite do 60hz, you can artificially thottle to some even divisor of that ... i.e. 30hz, 20hz, 15hz, etc. so that you are pretty much guaranteed to be locked at that rate, but you can never erase all certainty. A more sophisticated systems might be able to detect if you are having trouble sustaining 60hz and can perhaps tell if it's more of a fill rate problem or a geometry overload problem or some other problem, but you almost need a combination of hardware support, scene graph support, and application support to really do that well. High end sgi's have features where they can lower the pixel resolution of the screen sort of transparently so that you have less fill work to do, and can thus raise the frame rate back up if you are fill rate limited, I believe this can be done automatically at the hardware level. The scene get's blurrier, but your frame rates stay locked. The scene graph itself might be able to time your rendering phase and stop walking the scene graph when some time limit expires ... if you've sorted your geometry by priority, that might work well. At the application level you could tune texture usage, LOD, and other things to help make sure you hit your rendering speeds. I haven't dabbled much in these things though so I'm not an expert. There are probably other techniques or nuances that I'm not aware of. It's not an easy problem to deal with because performance bottlenecks can come at you from a lot of different direction, and you can't cleanly deal with it only in hardware, or only in the scene graph, or only in your application. For us poor folks on commodity hardware, we have to live with whatever we can do in the scene graph and application level and make blind assumptions about what the hardware will be able to do in the upcoming time slice. Short of going to a real-time OS like RTLinux, is this a case of where getting close is good enough... Personally, I think it all depends on how you define close, and how you define good enough. :-) If you can limit your drop outs to one every 60 seconds, that seems pretty close to perfection, is it good enough? Probably for 99.% of applications. If you are doing multiple displays, the bigger the gap between the displays, the more discrepancy you can tolerate. If you are edge blending projected displays, you have to have *much* tighter tolerances. If someone is piecing together some old hardware in their basement for fun and hobby, they might be perfectly happy with their side channels chunking along at 10-15fps, just because the added peripheral view gives them more than the jittery display takes away. I've been thinking of moving over to RTLinux (there is an open-source GPL'd version) in 2005. It fits nicely with the structure of the opengc display code. RTLinux might give you some additional fine grained timing tools to throw at the problem, but it's still a hard problem. You still have to detect a situation where you aren't going to finish drawing in time, reliably identify the reason you aren't finishing in time (fill rate? too much geometry? texture thrashing? running 3 other apps in the background on the machine?) and come up with some way to resolve the problem ... are you going to draw less geometry? Pull in the far clip plane, go to a lower LOD on some of your objects (which ones?) Your solution needs to directly address the cause of the problem our your fix might not help you. In practice you can probably find some trends and narrow the problem scope significantly, but it's still not easy. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Broadcast Address
Citeren John Wojnaroski [EMAIL PROTECTED]: I've been thinking of moving over to RTLinux (there is an open-source GPL'd version) in 2005. It fits nicely with the structure of the opengc display code. I'd like to mention RTAI (http://www.rtai.org), a Linux kernel patch to get the kernel working in real-time (even hard real-time!). RTAI is open source too, and even GPL if I remember correctly. I don't know how it fits with opengc, as I haven't found much info on the linux-port of OpenGC (which actually looks very interesting to me :-D). Greets, Steven ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Broadcast Address
One thing to be concerned about is that pinging your broadcast address may not be as meaningful as you'd like. Pinging 224.0.0.1 will probably yield the same results, as all multicast aware computers should respond to a ping at that address. I don't use multicast very much, in fact I try to avoid it when possible. Broadcast packets tend to live too long on a network (as long as standard unicast messages, which almost got me into trouble once...). Since I don't use broadcast, I'm not sure why you are getting an error binding to the broadcast address. Jonathan Polley On Thursday, December 09, 2004, at 03:38PM, John Wojnaroski [EMAIL PROTECTED] wrote: - Original Message - From: Jonathan Polley [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, December 09, 2004 1:00 PM Subject: Re: [Flightgear-devel] Broadcast Address You will want to use multicast. The multicast address range is 224.0.0.0 thru 239.255.255.255. 224.0.0.0 is reserved, so don't use it. Also, multicast has a default time to live (TTL) of 1 hop, so it will be limited to devices on the same subnet. I don't know if FlightGear handles receiving multicast, tho. Jonathan Polley Ooops, should have been a bit more expicit. The machines are running on a private LAN that supports my 747 sim. All four machines require FG data. While two machines require a full set of data (plus what I've added from JSBSim) the remaining two require a smaller subset and I'll probably add a fifth to run the MCDUs which requires even a smaller set. Plus there is additional data using the opengc protocol which is also redundant. Was not conptemplating the idea of going onto the Internet... Running Debian with linux-2.4.26 on all machines. The network configuration appears okay, in that a ping 192.168.2.255 from any and all machines generates a response from all machines Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Broadcast Address
John Wojnaroski wrote: Hi, Trying --native-fdm=socket,out,30,192.168.2.255,7000,udp to broadcast the data onto a LAN for multiple machines returned the following error: *** Error: connect() failed in make_client_socket() SG_IO_OUT socket creation failed Error opening channel communications layer. I/O channel config failed *** Addressing multiple individual machines with the protocol works fine but is a terrible waste of bandwidth. Has anyone tried to use the broadcast address and been successful? Wondering if this is a SimGear or plib or other problem? John, I seem to recall having this working once. There is an extra flag you have to enable on the socket to make it actually broadcast. My understanding is that this is a safety/sanity check to avoid broadcast storm type problems. I don't recall if this had to be enabled at the plib level or the simgear level? I seem to recall it was working for a while and then didn't work, but I haven't looked into it for a year or two. plib's net libs are a bit strange. They seem to tickle a dns lookup even for local ip address connections. I haven't been able to figure that one out ... it's ok if you don't have a dns server configured, but can be an annoyance if you are configured to auto-dial on any net activity. For some reason it seemed like the workingness of broadcast was tied to dns availability or something ... but I'm grasping at fading memories here so I could be way off. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Broadcast Address
John, I seem to recall having this working once. There is an extra flag you have to enable on the socket to make it actually broadcast. Yes, that jogs the ole' brain cells. (See Unix Network Programming, H.R.Stevens, page 318) I don't recall if this had to be enabled at the plib level or the simgear level? I seem to recall it was working for a while and then didn't work, but I haven't looked into it for a year or two. plib's net libs are a bit strange. They seem to tickle a dns lookup even for local ip address connections. I haven't been able to figure that one out ... it's ok if you don't have a dns server configured, but can be an annoyance if you are configured to auto-dial on any net activity. For some reason it seemed like the workingness of broadcast was tied to dns availability or something ... but I'm grasping at fading memories here so I could be way off. Curt. Thanks, that helps -- guess I'll dig around in the plib and Simgear code Part of the question also relates to any penalty imposed on the FG frame rate by adding multiple socket options for each IP address and unique port. Any SWAG on the percentage for each additional socket? linear, geometric, exponential? Or is it in the noise? Given that the current data packet is about 700 bytes, the LAN is a long way from any performance limits, at least for datagrams. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Broadcast Address
John Wojnaroski wrote: Thanks, that helps -- guess I'll dig around in the plib and Simgear code Part of the question also relates to any penalty imposed on the FG frame rate by adding multiple socket options for each IP address and unique port. Any SWAG on the percentage for each additional socket? linear, geometric, exponential? Or is it in the noise? Given that the current data packet is about 700 bytes, the LAN is a long way from any performance limits, at least for datagrams. I don't have hard data, but my observation is that the network overhead is not much ... the biggest factor in getting good sync between all your machines is to have the all run at the same fixed, sustained frame rate. i.e. all your machines are locked at 60hz. If you master drops a frame, all your slaves will stutter. If a slave drops a frame, that is obviously a stutter. If the master is running at a different frame rate from any of the slaves, you will typically see some sort of jitter. If you are feeding FG from an external FDM, it's important to ensure that is feeding data at the same rate that FG is trying to render (which isn't always as simple as it might seem!) Just try and write a program on a stock unix box that does something at exactly 60hz, doesn't do anything related to graphics (thus can't depend on monitor sync), and doesn't use a busy-wait type loop for the timing (thus is cpu friendly.) Let us know what you come up with on the broadcast stuff. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
