Two Ethernet or One?

I am thinking of developing an embedded device, and the device will transfer the data to the server via ethernet interface to internet. At the same time I would like to debug the device in remote. I think I can either use one ethernet, or two ethernet for the task. By using one ethernet, I can use one port address to exchange data between the device and the server, and another port address for debugging between the developer and the device, so there should be no confliction. By using two ethernet, I can assign two IP address to them. So the debugging task and data transfer task won't interfere each other too. However, I am not sure which one is the more popular engineer practice for this kind of applications? What are the pros and cons of these two solutions? Any insight? BTW, I may use either DHCP or static IP to allocate the IP address. Thank you very much!

Reply to
like2learn
Loading thread data ...

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.

Reply to
d_s_klein

Thank you for sharing your experience!

Reply to
like2learn

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

--
--------------------------------- --- -- -
Posted with NewsLeecher v4.0 Beta 20
 Click to see the full signature
Reply to
joolzg

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

formatting link

Reply to
Sink0

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.

Reply to
Hans-Bernhard Bröker

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

formatting link

Reply to
Sink0

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).

Reply to
D Yuniskis

re

e

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!

Reply to
like2learn

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.

Reply to
like2learn

.
i

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.

Reply to
Jose

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.