Re: TEMAC Performance Issues with Virtex 4FX




I can only transmit through the board data at a maximum rate of 1Mbps.
Anything more than that is lost.

You mean "to the board", not "through", yes ?

eg. When i transmit at 1.4Mbps, 400Kbps of data is lost, etc.
And when I try to transmit at data rates over 3Mbps, I get on
Hyperterminal the error messege that the Rx Fifo is full.

Well, I have never used Virtex4, but I have used a FPGA board (Suzaku) with LAN91c111 MAC chip.
This, running Microblaze/ucLinux, achieved an ethernet bandwidth of... 2 Mbps. Yes, that's a bit more than 200 kilobytes per second, ie. ridiculous.

TCP handles retransmissions, so full FIFOs causing lost packets will slow down your throughput, but the packets will be retransmitted.
If, however, you need more throughput, or use UDP, you have a problem.

If you only need a few megabits/s with UDP, you still have a problem : the PC will sometimes pause for a few tens of milliseconds (disk access, whatever), and then send the backlog of packets at full wire speed, which will zap your RX buffers.

So if you need UDP without packet loss, you need to be able to absorb the full wire speed (100M or 1G depending on your application). If you need less than 100 Mbps throughput, it can be useful to configure the ethernet on 100 Mbits instead of 1 Gbits (but then the switch might zap the packets if you use a switch !)

UDP has no transmission guarantee ; however if your receiving hardware can pull the packets from the FIFO faster than they come (ie. handles 100 Mbps without sweating), and your network has no funky topology like inter-switch bottlenecks etc, you will find that you can run the thing for 10 hours straight and not lose a single packet. Wired Ethernet is very reliable.

Your problem is that lwIP is a TCP stack designed for simple embedded aplications, to add TCP-IP to a microcontroller, at low bandwidth, with a small code footprint. It is not at all designed for high throughput !
Embedded Linux has another problem : it has too many features, so a lot of CPU is used to process the received network data. This is not a problem when you have a 3 GHz Core 2 CPU. However, on a 50 MHz Microblaze, that's a different story.

So, if you intend to use UDP for high throughput data transfer, you'll need to ditch lwIP and write your own very simple network stack.
If your TEMAC supports scatter/gather DMA, set it up with a large RX ring buffer, preferably a few megabytes in SDRAM, so that it can receive many packets and write them to memory very fast.
Then, to handle a received packet, write simple C code like this :

- If packet is ARP query, answer query
- If packet is UDP with destination = myself, parse packet
- all other cases, drop packets

This will take about 3 pages of C code, very simple, very efficient.

If you can't use hardware for UDP checksums, ignore them on receive, set them to 0 on sends. UDP checksums are useless on LAN anyway, since there is Ethernet CRC for data integrity check.
Do not copy packet data at least 3 times like lwIP does ! Do everything in-place, recycle your buffers, etc.
If you need to copy data, use a DMA core, but first ask yourself, do you really need this copy ? You could do some clever buffer recycling instead.
.



Relevant Pages

  • Re: Can we use xPC Target with this hardware configuration?
    ... Your UDP packets should be smaller than 1500 bytes or the stack will split up the packet into fragments of 1500 bytes. ... Using xpcexplr in the connected mode puts a lot of traffic on the Ethernet link which might cause more dropped packets. ... xPC Target Development ...
    (comp.soft-sys.matlab)
  • Re: Can we use xPC Target with this hardware configuration?
    ... Your UDP packets should be smaller than 1500 bytes or the stack will split up the packet into fragments of 1500 bytes. ... Using xpcexplr in the connected mode puts a lot of traffic on the Ethernet link which might cause more dropped packets. ... xPC Target Development ...
    (comp.soft-sys.matlab)
  • Re: UPD better than TCP in streaming video/audio ?
    ... > UDP gains speed over TCP because it carries no information that would ... it doesn't even know that packets were lost. ... which is perfect for UDP. ... > Finally, there's the possibility of multicast data - for instance, a live ...
    (microsoft.public.win32.programmer.networks)
  • Re: Linux equivalent for ioctlsocket(FIONREAD) on datagram sockets
    ... Imagine that fast CPU sends a burst of UDP ... spirit of UDP standard should do in that particular case? ... blocking a clling thread until the NIC hardware ... reads one or more packets from socket's send buffer freeing up space ...
    (comp.os.linux.development.apps)
  • Re: NTP and Firewall help needed.
    ... >>port 123 for udp and tcp. ... The action here is applied for packets that fall off ... > - ACCEPT any and all traffic coming from the localhost interface ...
    (comp.os.linux.setup)