On Mar 14, 6:01 pm, "Daniel Pitts" <googlegrou...@coloraura.com>
wrote:

The java test program is multithreaded.  I reused the tool code for
the test program, stripping out all the functionality except the part
of the swing gui that prompts the user for the IP address.  After the
user enters the address, the program creates a thread with normal
priority to handle reading from the datagram socket.

Today I plan to try again but with a more simple test program that
does not use any swing, and just uses the main thread.

The fact that UDP is not reliable has to do with delivery of the
packets.  That means that the packets can be discarded and not
retransmitted by the source.  I don't have that problem - the packets
are being delivered to my test platform just fine.

I don't think TCP would help in this situation, but I could be wrong.
Can you provide a technical explanation for why the Socket
implementation would outperform the DatagramSocket implementation in
this situation?

On Mar 14, 7:13 pm, Knute Johnson <nos...@rabbitbrush.frazmtn.com>
wrote:

The packets are all 125 bytes, or less, in length.  The packets are
being generated on a DSP board that is connected to my test platform
through a D-Link gigabit switch.  The board has an ethernet device
that supports 10BaseT.  The network card in my test platform supports
100BaseT.

On Mar 15, 4:46 pm, "Chris Uppal" <chris.up...@metagnostic.REMOVE-
THIS.org> wrote:

I really appreciate you trying your own performance test.  I should
have mentioned up front that I'm not concerned with bursty behaviour
at this time.  My source for UDP packets sends them out a constant
rate.  If the java program can't keep up at the start, then it will
never get a chance to catch up later.

But I agree that my sender is generating messages faster than my
receiver can process them.  I can't figure out why.  I don't think 75
messages / second should be too much.  The C program can handle it, so
I know that the problem isn't with the network or the network card,
and also probably isn't in the OS protocol stack.  I think that leaves
the JVM and my own code.  I hope I'm doing something wrong! :)

Can you estimate the rates in your performance test?  How long do you
think it took your generator to finish sending out those
1000/10000/100000 messages?  Do you think you could time it with a
stop watch or add some timestamps to your program?

On Mar 15, 7:36 pm, Esmond Pitt <esmond.p...@nospam.bigpond.com>
wrote:

I certainly can!

I retried the test with a version that does not use swing and does not
create any additional threads.  The source is below.  I get the exact
same result.

The messsage source (DSP board) is sending UDP packets of 125 bytes to
a PC that is running a C and Java program that do nothing but count
these arrivals and print out message counts every 1000 messages.  I
can control the send rate at the source.  At 50/messages per second,
the C and Java program are both printing out 1000, 2000, 3000, etc at
the same time, and in addition this also matches the count of sent
messages at the source.  I increase to 75/messages per second.  The C
program message count continues to match the send count on the DSP
board, but the Java program starts to lag behind (the C program prints
out 1000...the java program prints out 1000 several seconds later).

import java.io.IOException;
import java.net.DatagramPacket;
import java.net.DatagramSocket;
import java.net.InetSocketAddress;
import java.net.SocketException;
import java.net.SocketTimeoutException;

public class test
{
  public static final int SERVER_PORT = 4242;

  public static final String SERVER_IP = "192.168.1.10";

  public static final int RECV_BUFFER_SIZE = 1024;

  public static void main(String args[])
  {
     int messageCount = 0;
     byte[] recvBytes = new byte[ RECV_BUFFER_SIZE ];
     InetSocketAddress address = new
InetSocketAddress(test.SERVER_IP, test.SERVER_PORT );
     DatagramPacket packet = new DatagramPacket( recvBytes,
RECV_BUFFER_SIZE);
     DatagramSocket socket;

     try
     {
        socket = new DatagramSocket();
        socket.connect( address );
        // Send registration message
        byte[] sendBuf = new byte[1];
        sendBuf[0] = 1;
        DatagramPacket sendPacket = new DatagramPacket( sendBuf,
           sendBuf.length,
           address );
        socket.send( sendPacket );

        // Wait for registration response
        socket.setSoTimeout(30000);
        socket.receive( packet );
        socket.setSoTimeout(0);

        while( true )
        {
           socket.receive( packet );

           messageCount++;

           if( (messageCount % 1000) == 0 )
           {
              System.out.println( "Messages = " + messageCount );
           }
        }
     }
     catch (IOException ex)
     {
        ex.printStackTrace();
        System.exit(1);
     }
  }
}

When you receive into a DatagramPacket its length is reset to the length
of the incoming data if it's shorter than the original length. So if you
keep receiving variable-length datagrams into the same DGP the DGP will
keep shrinking, and you will be losing data at the end of the larger
datagrams received.

See src/{solaris,windows}/native/java/net/PlainDatagramSocketImpl.c, end
of the receive0() function.