Hello BrowserUk,

Just a small follow up to this thread. I got this to work very well, but it doesn't correspond with any of the documentation I've seen. ( Maybe I'm looking in all the wrong places ). I searched the web and found a article that stated that you can't max out a GigE connection unless you use a MTU of 9000 octets ( jumbo frame ) which is very hard to do since all interfaces must support jumbo frames. Since I was using a Read buffer of 87380 and a Send buffer of 16384, that didn't make much sense to me. The article talked about using the default MTU ( 1500 octets ) which couldn't give the full GigE speed, but could get close to 90%.

Using my original defaults, I was getting only 10Mbps, but when I reduced the Send/Receive packets to 1500, I was able to get approximately 850Mbps. I modified my test case to send the 1st data packet of only 1 octet and receive it back and then loop incrementing by 1 octet on each cycle and test that each send/receive data was equal (Note: This gave approximately 400Mbps in both directions ). This worked, and I let it run. The next time I looked, the test case was hung on a size that was a little more that 128 times the MTU size.

After this happened several times, I concluded that I had some timing problem or buffer management problem in the Perl or Debian system drivers. I added to the send routine a pause of

usleep 500;           # 1st guess for waiting
[download]

after each 64 writes to the socket and I was able to eliminate the hang.

I ran the test for 7 days and transferred 156TBytes in each direction without any errors and without any hangs. I used the system monitor for this and includes TCP/IP overhead.

This may be unique to me ( network/hardware/software ), and I wanted to test on other hardware, but I only have GigE interfaces on a few servers and they are plugged into 10/100 switches.

Summary: it's working now and I'm on to the next project. Thanks for the help.

Regards...Ed