Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
datasocket too slow, fastest way to transport data between two computers
10 views
Skip to first unread message
graduate student
Jun 17, 2004, 2:43:08 PM6/17/04
to
i'm having an aquisition system running on one computer that needs to
feed the data in real time to another computer at ~40mbyte/s to
process. i'm running a datasocket server at the aquisition computer
and have the second computer read packages of data from the datasocket
server. but turns out it takes close to 2 sec to write 1 sec worth of
data onto the localhost datasocket server. the two computers are
connected through a private 2Gbyte local private network, so LAN
speed is not an issue. is there some trick i can use to configure the
datasocket server or client? or what is fastest way to stream data
between two computers?
feed the data in real time to another computer at ~40mbyte/s to
process. i'm running a datasocket server at the aquisition computer
and have the second computer read packages of data from the datasocket
server. but turns out it takes close to 2 sec to write 1 sec worth of
data onto the localhost datasocket server. the two computers are
connected through a private 2Gbyte local private network, so LAN
speed is not an issue. is there some trick i can use to configure the
datasocket server or client? or what is fastest way to stream data
between two computers?
Bob P
Jun 17, 2004, 3:24:31 PM6/17/04
to
In your case, I recommend using the UDP VIs, which offer the least
amount of overhead of all the network communication methods. UDP is
an unassured service, meaning your packets might not get to the
receiver in order, or might not get to the receiver, period. On a
private network, you can minimize UDP packet losses if you have a way
to avoid collisions. If you have control over the network topology,
you may even be able to ensure all UDP packets arrive in order.
amount of overhead of all the network communication methods. UDP is
an unassured service, meaning your packets might not get to the
receiver in order, or might not get to the receiver, period. On a
private network, you can minimize UDP packet losses if you have a way
to avoid collisions. If you have control over the network topology,
you may even be able to ensure all UDP packets arrive in order.
If you need an assured service, use TCP VIs. They'll guarantee all
your packets arrive (and arrive in order).
The disadvantage is you lose the convenience of Datasocket.
graduate student
Jun 17, 2004, 3:45:09 PM6/17/04
to
thanks a lot Bob! i'll look into that. so does that mean that
~40mbyte/s is just too much for datasocket to handle, and its overhead
cannot be reduced?
~40mbyte/s is just too much for datasocket to handle, and its overhead
cannot be reduced?
Bob P
Jun 17, 2004, 4:54:43 PM6/17/04
to
I think it's safe to say network throughput with Datasocket, TCP, or
UDP is a function of how much data you hand to the Write function in
LabVIEW in addition to the raft of other characteristics that define a
network. I mention the Write function because it's the one thing you
have most control over, including how much data you pass to it as well
as how frequently you call it. You have a ton of bandwidth, so it
might be possible to hit the desired rate with DataSocket if you find
the "right" packet size.
UDP is a function of how much data you hand to the Write function in
LabVIEW in addition to the raft of other characteristics that define a
network. I mention the Write function because it's the one thing you
have most control over, including how much data you pass to it as well
as how frequently you call it. You have a ton of bandwidth, so it
might be possible to hit the desired rate with DataSocket if you find
the "right" packet size.
Here's a <a
href="http://sine.ni.com/apps/we/niepd_web_display.display_epd4?p_guid=B45EACE3EF0956A4E034080020E74861&p_node=174821">tool</a>
for doing just that with TCP. You should try the tool, and use the
solution as a starting place for DataSocket. Good luck.
mnap...@gmail.com
Jun 4, 2014, 11:22:40 AM6/4/14
to
0 new messages