Two Ethernet or One?

The ability to control a device while transferring data from another port is supported in every TCP/IP stack I've seen for quite some time now. Simultaneous FTP and Telnet, for example; no wheel re-inventing.

I have had problems with 2-port implementations. For example in one device, I had 100Mb and GigE on separate ports; the 100Mb for control, and the GigE for data. The device application would often try to send the data on the 100Mb port (because the GigE port was busy) and performance would suck.

I would go with the one port solution.

RK.

Thank you for sharing your experience!

I would stick to one port until you have proven the stack and hardware are robust then you can move over to 2, we usually only put 2 ports on when we want to seperate the control from the outside world.

joolz

robust then you can move over to 2, we usually only put 2

I may be saying something stupid, but how he can control the band sharing among both (debug and control/data)? Using one connection would reduce the data trhoughtput no? That could lead to a non real-time behavior. Just to make sure, the discussion is if he should use two physical ports or two TCP ports right?

Cya

--------------------------------------- Posted through

That's what you have an operating system and its TCP/IP stack for, among other things. No need to re-invent every single wheel in the universe.

It might. But he didn't give any believable indication of being so severely bandwidth limited that that would actually make a difference. Frankly, if had managed to saturate a 100Mb/s or faster Ethernet link with payload data, he would surely be well beyond asking the kind of questions he does.

All debugging usually does that.

sharing

Very good answers but the first. I think you did not understand my point and it is pure ignorance of my part. Is there any way to hard share the network band, something like this port CANT at any moment use more than certain amount of the band? Probably there is someway on how to do that, i just dont know how.

But after all the answers...yes, one ethernet would be the best option i think.

--------------------------------------- Posted through

Unless you truly *need* two i/f's, stick with one. Some possible reasons for *needing* two include:

- the pipe for your "normal" interface is "almost full"

- you have particular QoS requirements (that your stack doesn't correctly implement)

- the traffic on the "debug" i/f is "sensitive" in nature (and you don't want to risk a packet sniffer's attention)

- you are using UDP and worry about the traffic on one wire resulting in lots of dropped packets, (etc)

You haven't explained what "this kind of applications" is so it's not possible to tell you what *is* "the more popular engineering practice" for your domain.

If you go with two i/f's, try to put them on separate subnets so your stack doesn't get upset trying to route over a particular i/f (else you end up with *one* i/f doing all the work and/or other unpredictable behavior).

re

CP

Hi Cya, Our application is not a real-time application, since we don't have to send out the data in real-time. However, we do hope the device respond to the control command in real-time. So bandwidth is really not a concern. Thanks!

Good points. I will try my best to describe the applications. It is a non-life-critical, not-so-real-time, not-so-bandwidth-hungry type of applications.

I think you can create as many limits on bandwidth over ports, applications, etc as your OS allows you to. Regarding real time beahvior: TCP/IP is not intended for real time applications. If you mean "human" real time then you don't even have worry for debug signals since they're narrowband compared to -for instance- media streaming.