Re: Optimizing network throughput over Ethernet with TCP/IP

2004-02-13 Thread greenkiwi
Ethernet packets are range from 46-1500bytes, or there abouts, so
anything is being broken up.  Well, anything over 1500 bytes.

I'll give the even multiples of 32768 a try and see how that goes.

(Well, there seems to be support for frame sizes up to 9000 bytes in
Gigabit Ethernet.)

I'm going to have to experiment a bit more to see whether the delays
are caused.  I may also try to create an app in C or find a test app
that will pump data through, to test out LV's receive limitations.

Adam



Re: Optimizing network throughput over Ethernet with TCP/IP

2004-02-12 Thread Ben
I encourage people to answer their own questions!

This way you get the stars you deserve.

Your numbers look good.

Ben



Re: Optimizing network throughput over Ethernet with TCP/IP

2004-02-11 Thread Ben
Adding to my previous;

I have gotten good results using VI server technology and using call
by reference to get data.

I have never attempted to push the trasfer rates you are looking at
but I think it is worth a quick try.

The beauty of this approach (IMHO) is ZERO TCP DETAILS (sorry) to
code.

Please briefly outline the solution once you crack this performance
nut. I would be interested in hearing how you end solving this
challenge.

Ben



Re: Optimizing network throughput over Ethernet with TCP/IP

2004-02-10 Thread Ben
Hi Adam,

It has been a couple of days and no response on this Q so I will
relpy.

First, you have done your homework well. I have not used the TCP
functions from Sheldon Instruments so I can not comment on that.

I think the Naegel option would help if you were send alot of small
packets that need individual resposnes.

I am a bit concerned about your target of 30mbps.

It has been years since I dug this low but I think 30mbps is going to
be the upper limit of a 100Mbps LAN. This is based on the old days
when ethernet ran over coax. The issue as I see it is how the hardware
gets access to the LAN. Ethernet adapters have to do a number of
things when transmitting a packet. First it has to check the network
to see if anyone else is talking. If the network is free, it will then
transmit the data while simultaneously read from the network. If
another node is trying to do the same thing at the same time, they
will corrupt each others transmission resulting in a bad CRC being
detected by each transmitting node. This is a collision. The
interfaces are then supposed to execute a random wait and then retry.
You probably new this already.

When the network utilization is low, collisions are less likely and
data can fly. Once the network utilization starts to climb, the
collisions become more frequent and over-all throughput will decline.

In the old days we used to recomend trying to keep utilization below
30% of the theoretical max.

This is why I am concerned about you trying to do 30mbps over a
100mbps LAN. You are right on the edge where performance starts to
drop off. Remember that TCP packets are ack'd by the reciever! This
ack'ing is going to introduce collisions because this has to happen to
support the integrety of the transmision.

Enough about me fears, how about some ideas.

First;
Keep LV out of the mix and just try your hardware and OS out using
file transfers. Just try copying large files from one machine to the
other on your dedicated LAN. If you can transfer files at 30mbps, then
you may be able to do the same with an app in LV. (Note File sharing
is generally implemented using TCP/IP).

Second;
I think you probably will have to go for the 1Gig route. Your 30mbps
is only 3% of that bandwidth so provided your hardware can pump as
fast as the net can suck, you should be able to pull this off.

In closing I would like to clearly state that I am not an expert in
this area and it has been years since I got into the low-level
details, so please forgive me if I have got something wrong here.

I will watch this Q to see how things work out for you and see if
anyone else would like to jump in here and straighten me out.

Trying to help,

Ben


a
href=http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101RPAGEID=261HRedirected=TrueHUserId=101_3529RFORMNUMBER=6;Ben
Rayner/a
a href=
http://volt.ni.com/niwc/common.jsp?page=products_certification_cldnode=10638;
Certified LabVIEW Developer /a
www.DSAutomation.com