Jump to content
  • Advertisement

phsan

Member
  • Content Count

    10
  • Joined

  • Last visited

Community Reputation

100 Neutral

About phsan

  • Rank
    Member
  1. phsan

    multicast packet loss

    The part that fascinates me is that the two instances lost exactly same packets. The computer is a Dell server, a couple years old. I am using all the default drivers. I am a little bit hesitatant to doubt that Dell does not write a good NIC driver. If so, many users should have complained already. But I am not ruling out the possibility. I think I should at least ask the sys admin who installed the server which driver it uses right now.
  2. phsan

    multicast packet loss

    Intel Xeon 3GHz CPU, 8 cores. 8G RAM. 1gigabit NIC port
  3. The network programming forum here is awesome. I am wondering if there is any other good forum/website for network programming. stackflow is good too, but is less organized. Thanks.
  4. On Redhat Linux, I have a multicast listener listening to a very busy multicast data source. It runs perfectly by itself, no packet losses. However, once I start the second instance of the same application. [All the settings are exactly the same, same src/dst IP address, sock buffer size, user buffer size, etc.] I started to see very frequent packet losses from both instances. And they lost exact the same packet. If I stop the second instance, the first instance return to normal without any packet loss. Initially, I though it is the CPU/kernel load issue, maybe it could not get the packets out of buffer quick enough. So I did another test. I still keep one instance of the application running, But then started a totally different multicast listener on the same computer but use the second ethernet card and listen to an even busier multicast source. Both applications run fine without any packet loss. So looks like one ether card is not powerful enough to support two multicast applications, even though they listen to exact the same thing. The possible cause to the packet loss problem might be that, in this scenario, the ether card driver needs to copy the incoming data to two sock buffers, and this extra copy task is too much for the ether card to handle so it drops packets. Any deeper analysis on this issue and any possible solutions? Thanks
  5. Agreed. This is what I thought. I just try to get a measure, from whoever has done and measured, how much overhead it might occur, so that I can know what to expect using erlang.
  6. How "ultra-low" and with what characteristics? The lowest I've seen is microsecond latency running on hard real-time systems with dedicated hardware. Most of such systems are PLCs or VHDL or similar. On commodity hardware 1000Hz resolution is next to impossible to guarantee, but can be achieved fairly easily on average. [/quote] I am hoping the data transfer from one machine to another on the same LAN can be done within 0.1 milli-second.
  7. I am about to write a distributed system using C++/Linux (ultra-low latency is one of the mandates). I worked on a distributed system before. It does its own data marshalling by the sender app, send it over the wire to the receiver app on a different machine, and de-marshalled by the receiver app. The data are C++ objects. I can do the same thing. However, I am asking for opinions about using erlang as the middleman to send data between the sender and receiver. I am new to erlang. The idea is that sender will call erlang API to send data to an erlang instance on the same machine. That erlang instance then sends the data to the erlang instance on the receiver app's machine, the receiver app gets the data from this instance through erlang API as well. I am wondering if 1) this design makes sense in an ultra-low latency environment? 2) more importantly, introducing erlang as the middleman, as supposed to the data marshalling and de-marshalling by the sender and receiver themselves, would introduce significant latency (>1 milli-second)? 3) any better idea? Thanks
  8. I am doing network socket, not files. Thanks for the replies. They answered my question.
  9. It turns out that asyn I/O in boost::asio is implemented through a Reactor pattern due to lack of asyn I/O support from OS level. See here please: http://www.boost.org/doc/libs/1_44_0/doc/html/boost_asio/overview/core/async.html. So apparently, the asyn is not on the socket I/O level, I need dig deep at which level it becomes asyn. (Any idea?) Also, is there a easy way to see if the Reactor is using select() or epoll() oe kqueue()? I found an example here, http://stackoverflow.com/questions/3106304/boost-asio-on-linux-not-using-epoll. Not sure if there is an easier way.
  10. I am about to start implementing a new messaging application on Fedora Linux, whose underlying mechanism is an event demultiplexer. I was a ACE user and now am considering switching to Boost::asio. The reason I am considering but not doing right now is that most of the UNIX platform does not provide a robust implementation of asynchronous I/O operations like Windows does. So we used ACE Reactor, instead of the ACE Proactor, implementation to do our old messaging system. See http://www.artima.com/articles/io_design_patterns2.html here details about what I just said. Now if I switch to Boost::asio, then I will be using asyn I/O on Linux (Fedora). My questions are: 1) if it is true that most Unix/Linux platforms do not provide a full robust async OS-level support, but why people are using Boost::asio. Does Boost::asio need to rely on the underlying OS support to implement asyn I/O - the Proactor mode/pattern? or Boost::asio is the underlying OS support for implementing asyn I/O? 2) With Boost::asio, does it mean we now eventually can use the Proactor implementation on Linux (I use Fedora), or Boost:asio is just a pseudo asio, it actually does/wraps the Reactor mode, which essentially is a syn I/O. 3) Is there anything that I should be worried about switching from ACE Reactor (the syn I/O) to Boost:asio (the claimed asyn I/O)? for example performance issue, scalability issue or portability issue Thanks,
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!