flote21
Advanced Member level 1
- Joined
- Jan 22, 2014
- Messages
- 411
- Helped
- 1
- Reputation
- 2
- Reaction score
- 3
- Trophy points
- 1,298
- Activity points
- 5,595
Yes ads-ee you are right. Actually after several improvements in the ETH IP, we can achieve 990Mb/s of data trasferring. But anyway it is not enought to transfer frames of 1920x360 pixesl and 16 bits/pixel at 350Hz. The PEAK of the ETH load is over 1Gbps. The my idea is to do some kind of video compression in the FPGA and descompressed this video in the PC side...But I need to prepare myself to program this kind of algorithm in the FPGA because I have done it. Any suggestion?
Thanks
Thanks
What you need to do is work on your skills at analyzing where the bottle neck is located. It doesn't seem like you've got a handle on why the 673 Mbps is too
much for a 700 Mbps channel.
First of all how is your UDP packets being constructed? Are you adding the headers after you have the entire packet stored? If so have you looked at how that affects the amount of dead time you are getting between adjacent packet transmissions?
I hope you are seeing where I'm going with this. I don't think you've analyzed the effects of encapsulation on the time it takes to send a packet after the preceding packet was sent. You've probably added enough dead time between packets where you've wasted 30% (=1-(350/500)) of the 700 Mbps you have.
I still think 700 Mbps is an extremely low value for payload on a Gigabit Ethernet connection using UDP packets that are quite large (1.4kB). Does this mean that most of the packets are very tiny like Ehternet_framing(42-octets)/IP(24-bytes)/UDP headers(8-bytes) (total:74-bytes) plus 106-bytes of payload? I can't envision any other way you're losing 30% of the bandwidth to overhead, unless you are sharing bandwidth with something else that is sending Ethernet frames?