Has anyone successfully added any protocol to the mini pcie higher than 1Gbps? I saw that someone got a one gigabit card working, but I haven’t seen any 10 gigabit Ethernet working. It doesn’t necessarily have to be ethernet but any type of protocol over one gigabit per second would be nice.
I’ve seen the TK1 mini-PCIe make it to link speed of revision 2, although some devices will only hit revision 1. Revision 2 lists as 5GT/s, which I’m not sure how to convert to byte-nomenclature bandwidth (“gigatransfers/sec”).
EDIT: Found this:
2.5GT/s == 2.5Gb/s == 312.5MB/s, and then overhead reduces actual throughput. So a 10Gb/s ethernet on revision 2 would require 4 lanes.
The TK1 mini-PCIe is only a single lane, I suspect a single USB3 port requiring 5Gb/sec would more or less fully utilize that lane…something like 10Gb/s ethernet would definitely require x4 at least two PCIe lanes, probably x4 would be prudent. I can’t imagine anyone manufacturing a 10Gb/s ethernet on a mini-PCIe slot under revision 2 (perhaps on rev. 3)…but the TX1 version of Jetson has a full-size revision 2 x4 PCIe slot which could handle those bandwidths.
Yeah, sorry I thought the tk1 had the same pcie specs, but I’m mostly looking at the tx1. The main problem is I can’t find any 10Gbe cards that work with arm64. If you know anything that might work please let me know!
Technically, the cards themselves are not the issue, it’s the drivers. Latency and efficiency are a big deal with a 10Gb NIC, which means code almost has to be tailored specifically to the hardware the NIC connects to…the PCIe bus itself is known and can deal with this with the x4 lanes or better (like TX1’s full-sized slot), but actual operations inside of the CPU have to be very efficient. I’ve seen recent discussion on the linaro compiler list of people trying to deal with this in a portable way, but generalized drivers at those speeds just don’t exist (and compiler-based optimizing options so far are not enough). TX1 will be the first embedded product that can actually deal with that much data and have a real chance at consuming and making use of the data. It would be a very very interesting project to port the first 10Gb NIC to TX1/AARCH64.
What I’d suggest is to start looking at 10Gb NIC chipsets, and finding one which is already widely ported, even if it isn’t to AARCH64…this would mean a certain modularity and thought in design took place, and might make the AARCH64 port a bit easier.
Dear All,
Just recently I received my-own TX1 and was really curious to see the expandability of it using on board PCIe slot. Meaning to have an expansion card with several USB and Ethernet port connected to TX1 PCIe slot.
Were there any activities in this direction?
I assume there shouldn’t be any issue with bandwidth and power compatibility of course if we fit into 10Gb frame, however I didn’t catch the point about drivers. Could you elaborate please?
Thanks
This should probably be moved to the JTX1 forum (this is JTK1), but what it came down to is that in the discussions I saw so much data had to be moved so quickly that the usual pointer dereferencing had to occur so often and so fast that it was interfering with getting data out before incoming data had to slow down. Things like dedicated CPU register use handles this as a replacement to using multiple pointer dereference, but this is specific to the CPU architecture. I think the group I was seeing this from was specifically discussing ARM as one example, but possibly wanted a solution which could be rebuilt on other architectures without custom source code using different compiler flags and/or tools…i.e., whether a compiler or related tools could somehow be built to have such cross-platform optimizations. The general conclusion seemed to be that to do the job right without undue complexity that each architecture would need to be specifically coded for latency reasons.
I have seen inquiries related to 10GBaseT, I have not seen any testing or compatibility information. I think that if you have the driver source code it could be ported to ARMv7 or ARMv8a, though 32-bit ARMv7 is unlikely to make use of it. For ARMv8a I suspect that once the driver “works”, that fine-tuning for acceptable performance could take significant time, but pay off if you really need small and power-efficient 10GBaseT.