Data throughput of embedded ethernet

[Richard Hosking]

Dear all
There are a lot of embedded ethernet cards out there now. I was
considering the use of one of these to stream data from a fast serial
ADC to PC for analysis - digital radio app.
What sort of data rate could be achieved for 2 16-24 bit I/Q words and
what card would you use?
The max baseband bandwidth of the ADC is up to about 300KHz (ie 2 X
600KSamples/sec
What would be the limiting factor in this scenario?

Thanks
Richard

 

[Guy Macon]

There are a lot of embedded ethernet cards out there now. I was
considering the use of one of these to stream data from a fast
serial ADC to PC for analysis - digital radio app.

What sort of data rate could be achieved for 2 16-24 bit I/Q words
and what card would you use?

The max baseband bandwidth of the ADC is up to about 300KHz
(ie 2 X 600KSamples/sec) What would be the limiting factor
in this scenario?

2 channels at 300,000 24-bit samples per second is 1.2 megabytes
per second. 16-bits is 1.8 megabytes per second. A good rule of
thumb for real-world network performance is:

10baseT = 1 megabyte per second
100baseT = 10 megabytes per second
1000baseT = 30 megabytes per second

So it looks like a bog-standard 100baseT Ethernet link will handle
your data stream. and it dooesn't much matter what card you use.
Just make sure it is set up for full duplex and that nothing else
is on that network.

You will, of course, need a processor that can handle the load,
enough storage, etc.. but I don't see your network link as being
a problem.

 

[Mac]

On Sat, 13 Aug 2005 15:30:48 +0000, Guy Macon wrote:

[snip]

2 channels at 300,000 24-bit samples per second is 1.2 megabytes
per second. 16-bits is 1.8 megabytes per second.

As Willy Wonka once said: "strike that: reverse it." Or something like
that. ;-)

--Mac

 

[Richard H.]

Dear all
There are a lot of embedded ethernet cards out there now. I was
considering the use of one of these to stream data from a fast serial
ADC to PC for analysis - digital radio app.
What sort of data rate could be achieved for 2 16-24 bit I/Q words and
what card would you use?
The max baseband bandwidth of the ADC is up to about 300KHz (ie 2 X
600KSamples/sec
What would be the limiting factor in this scenario?

Thanks
Richard

300KHz * 2 ADCs * 24-bit = 14.5Mbps, including IP overhead, assuming
large packets.

Clearly 100Mb is needed; full-duplex always preferred. This is also
about 10k packets/sec. I've pushed the ASIX over 20k/sec, so you're in
the right range.

Your limiting factor will be the protocol used for the transfer. Behind
that, the MCU and the rate it can get packets into the buffer.

UDP is highly recommended, especially if you can tolerate packet loss
(which should be 0 anyway for local applications). TCP will cause you
nothing but headaches unless you absolutely need to guarantee 100% data
delivery. (It'll require a lot of buffer RAM for retransmissions, and a
lot more overhead in the MCU, and it may take a chunk of tuning to get
it up to the rates you need, even locally.) UDP can also run with
payload checksums turned off, further reducing the MCU load.

Then, finding a creative way to load the data directly from the ADC into
the Ethernet NIC will be key to how many cycles will be needed on the
MCU. (E.g., setting the NIC in bulk write mode, toggling the ADC data
onto the bus, and toggling the NIC to latch the bits; a la DMA
controller style.)

If the MCU doesn't need to manipulate the data (e.g., even for
checksums), you can avoid the overhead of copying it into the MCU and
then right back out; this is the most frequent and biggest operation, so
it's a big factor. Part of this will be driven by whether the ADC is
being read serially or 8/16/24 bits wide, and the size of its buffer (if
any). (I.e., if it can sustain pauses in the stream, and whether the
MCU needs to handle all the data.)

There are 3 ISA-style 100Mb chips out there; the rest are integrated or PCI.
http://www.asix.com.tw/emb-non_ax88796.htm
http://www.davicom.com.tw/eng/products/dm9000.htm
http://www.smsc.com/main/catalog/lan91c111.html
(http://www.edtp.com/ recommended for ASIX protos)

Cheers,
Richard

 

[Aubrey McIntosh, Ph.D.]

Then, finding a creative way to load the data directly from the ADC into
the Ethernet NIC will be key to how many cycles will be needed on the
MCU. (E.g., setting the NIC in bulk write mode, toggling the ADC data
onto the bus, and toggling the NIC to latch the bits; a la DMA
controller style.)

If the MCU doesn't need to manipulate the data (e.g., even for
checksums), you can avoid the overhead of copying it into the MCU and
then right back out; this is the most frequent and biggest operation, so
it's a big factor. Part of this will be driven by whether the ADC is
being read serially or 8/16/24 bits wide, and the size of its buffer (if
any). (I.e., if it can sustain pauses in the stream, and whether the
MCU needs to handle all the data.)

There are 3 ISA-style 100Mb chips out there; the rest are integrated or
PCI.
http://www.asix.com.tw/emb-non_ax88796.htm
http://www.davicom.com.tw/eng/products/dm9000.htm
http://www.smsc.com/main/catalog/lan91c111.html
(http://www.edtp.com/ recommended for ASIX protos)

Cheers,
Richard

Has anyone made a card where the "ADC finished" signal feeds a counter
and a DMA circuit on memory that is shared with the CPU?

Some Xilinx part could compute the CRC values in parallel so that no CPU
overhead would be used for that. I suppose the same part would pre-fill
the address, protocol, and other packet headers as well as putting the
first user data address into the counter.

 

[TheDoc]

Has anyone made a card where the "ADC finished" signal feeds a counter
and a DMA circuit on memory that is shared with the CPU?

Some Xilinx part could compute the CRC values in parallel so that no CPU
overhead would be used for that. I suppose the same part would pre-fill
the address, protocol, and other packet headers as well as putting the
first user data address into the counter.

Actel has an ethernet core module.. add some extra logic to control the ADC,
put the results directly into the ethernet controller's memory and send..
minimal cpu overhead..