They are different concepts, yes, window size can be reduced to below MTU size on small systems to ensure that you don't get fragmentation, and you don't need to resend more than one low-level packet. But it is not a level of detail that I have needed to work at, so I have no personal experience of that.
TCP is worse than most. Partly because it's jack of all trades in terms of latency and bandwidth. Partly, because it's stream (rather than datagram) oriented, which makes recovery, based on selective retransmission far more complicated=less practical.
Sure. But not a rare corner case. And again, far less likely to happen to datagram-oriented reliable transports.
FEC does reduce bandwidth in some sense, but in all of the Ethernet FEC implementations I've done, the 64B66B signal is recoded into something more efficient to make room for the FEC overhead. IOW, the raw bit rate on the fibre is the same whether FEC is on or off.
Perhaps a more important issue is latency. In my experience these are block codes, and the entire block must be received before it can be corrected. The last one I did added about 240ns when FEC was enabled.
Optics modules (e.g. QSFP) that have sufficient margin to work without FEC are sometimes marketed as "low latency" even though they have the same latency as the ones that require FEC.
I've done it, not a full every single RFC implemented job, but a limited UDP support. The way it worked (initially) was to use Lattice's tri-speed Ethernet MAC with Marvell Gigabit Phy (and later on a switch). The FPGA handled UDPs in and out in real time and offloaded any traffic it didn't understand (like tcp stuff) to an Arm Cortex M4. It needed 32 bit wide SDRAM to keep up with the potential peak data transfer rate. We did it because the FPGA was acquiring the data and sending it to a PC (and sometimes getting data from a PC and streaming it out), the FPGA did some data processing and buffering - to get the data to the PC it had to use Ethernet, it could have been done (at the time, several years ago) with a PCI interface to a PC class processor running a full OS, but this would have used far too much power. The Lattice XP3 FPGA did all the grunt work and used a couple of watts (might have been as much as three watts). The UDP system supported multi fragment messages and used a protocol which would allow for messages to be sent again if needed.
If any one wants to pay for tcp-ip and all the trimmings I'd be happy to consider it.
MK
--
This email has been checked for viruses by AVG.
https://www.avg.com
to spartan 6, but I don't want to connect any such controller just spartan
> >>> So how can it be done?
kout with any another boards I would really like to know. Thanks
ve designed comms stuff at lower rates but still fast enough that things co uldn't be done in single width, rather they had to be done in parallel. Th at gets complicated and big real fast as the speeds increase. But then "bi g" is a relative term. Yesterday's "big" is today's "fits down in the corn er of this chip".
igger!
To that level, who didn't have it done? Me, personally, I lost count for how many times I did it in last 15 years. But only a transmitters. It's not that UDP reception to pre-configured port would be much harder, I just never had a need for it. But TCP is a *completely* different story. And then standard application pr otocols that run on top of TCP.
But if you need absolute maximum throughput, it's often advantageous to move the retransmission mechanism up the software stack. You can take advantage of local specialized knowledge rather than pay the "TCP tax".
-------------------------------------------------------------------------------- An indirect solution would be to offload Ethernet to a hard wired UDP/TCP asic. Wiznet has developed such devices and I have somewhat more than 10k designs in the field that use them. Unless you require a cheap high volume solution (requiring development, Verification and Validation time and money) then Wiznet may well be a zero time and minimal cost solution. I have used both W5300
formatting link
and W3150A+
formatting link
devices.
TCP has the drawback of latency and automatic resends. In real time application my preference is UDP, packets lost are okay but packets resend by TCP is a waste of bandwidth because these packets are out of date. My application have been in heavy industry machine vision where fibre is too fragile and RF by line of sight and interference is not suitable.
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.