Some notes on high speed networking on PCs
mailman.nanog.org
mailman.nanog.org
See recent Intel presentation on Time Sensitive Networking, https://schd.ws/hosted_files/elciotna18/b6/ELC-2018-USA-TSNo...
Probably, something popular needs building that demands 10G-in-the-home to use, in order to get volume up so pricing can come down a bit. VR, if it actually does hit this time, is a candidate.
As far as fragility, copper is the way to go at home, unless you're entirely pet and child-free or have your own cage in the garage.
Hence only useful in homes with protected installations like a server enclosures.
So, yes, all the common stuff is pretty flexible, because its plastic.
That being said, I've seen people do some horrific things with copper, and it tends to survive things it shouldn't. But if you treat glass even half as gently as copper wants to be treated, they'll both be fine.
I think fiber gets a bad rep because large multi-strand cables have stiffeners to keep the jacket from kinking, and people assume the individual strands are similarly stiff. They really aren't.
Had 20+db of loss while it was pinched, but after unpinching it and massaging the kink out, it went right back to normal.
What are these actually called, and what do I look for?
What people mostly mean here is multimode vs single mode glass fiber, though.
Why spend money on SFP's and optical cables, when you can just pick up cheap 10GbaseT hardware?
10GBASE-T is showing up in more and more small business targeted equipment but I think more likely 2.5GBASE-T and 5GBASE-T will make it to consumer home equipment instead of 10GBASE-T.
2.5GBASE-T supports a distance of up to 100m on CAT5e. 5GBASE-T supports up to 100m on CAT6 and may operate on some Cat5e infrastructure. Additionally they both support PoE which 10GBASE-T does not.
Also, for a 10-20m run, the price difference is literally in the single figures. The effort alone to send something back is (should be) worth more to you than that.
That depends on the country. E.g. in the EU you can return goods bought online within 14 days (for any reason).
You can certainly buy 10GBASE-T equipment meant for small business and give it a go on your network. If you are lucky you may have success.
The cable modem OTOH... (a few bad packets a day).
Edit: Also for most purposes 'modern' 5e (which tends to be more an ad-hoc standard due to people exceeding the base requirements) is basically as good as cat 6, its only with 6A do you get the longer runs with are a result of stricter termination rules, larger gauge cable, better cross pair (foil) shielding, and a bunch of other rules.
As far as 2.5/5G, I was really annoyed that it wasn't just an optional part of the 10G standard. The idea being that vendors sell 10G switches and if the cables arn't up to the task to degrade to something slower. Initially the big vendor pushing seemed to be trying to market segment 2.5/5 and 10G, but more recently it seems sanity has prevailed and more recent switches are doing exactly that. You get 10G if the switching thinks the cable run is good, otherwise it drops to 1/2.5/5.
HDMI 2.0 for 4K is 14.4 Gbit/s
HDMI 2.1 for 8K is 42.7 Gbit/s
Receiving non-visual data from the GPU has the interesting property that the shaders and video RAM are generally kind of very close to the HDMI port, so I could potentially be "sending" the result of running a shader on data in video RAM.
Something something using VRAM for caching...?
I've been meaning to figure out how to capture HDMI, at line speed, for a while. My current thinking is to use a PCIe FPGA capable of bus-master DMA, a horribly-hacked-apart kernel that doesn't touch a few GB of RAM, and a kernel driver to "chase" after the gigantic ring buffer the FPGA copies into.
Hmm, I probably wouldn't be able to copy at HDMI 2.1 line rate.
Unless there are very very scary FPGA contraptions that use TWO PCI-e slots? :D:D [EDIT: I now realize this would need two PCI-e root complexes. Woops]
I believe any FPGA with a decent PCIe implementation should be able to bus-master, and if you set up the drivers properly you don't have to do anything with the kernel, it'll just allocate a block of transfer RAM for you.
You can use multiple PCIe lanes easily? If you need more than an x16 slot I'd be very surprised.
Right. I wouldn't be surprised if that encoder is a single chip designed to ingest TMDS so the 10-40Gb/s of raw data only travels a few mm.
And MPEG encoding is the only reasonable way to handle data of this size, considering that it compresses 10Gbps down to <80Mbps and typically <10Mbps.
> I believe any FPGA with a decent PCIe implementation should be able to bus-master, and if you set up the drivers properly you don't have to do anything with the kernel, it'll just allocate a block of transfer RAM for you.
As for the first part, cool.
With the 2nd part, you're seeing my complete lack of hardware knowledge :)
I was envisaging having the host system "ignore" several GB of RAM - have linux's memory manager simply not touch it - and then turning it into a gigabyte+-wide circular buffer to copy into.
Then, the processing/do-whatever code is written as a kernel module that "chases" after wherever the "head" is in the circular buffer (presumably this would be a pointer written to a fixed memory location). Because the buffer is gigabytes wide the kernel driver can stall (for whatever reason) for multiples of seconds and have wild swings in "chase performance" before there are any real issues.
This design enables an important goal which I wanted to implement: pressing PrtScr or hitting a hardware button flushes the last few seconds of whatever was on the screen to disk - ie, you can achieve hardware-level, pixel-perfect, video capture. Frame glitch? Saved. "LOOK, the GPU displayed a single frame wrong again, agh, you missed it"? Saved. Weird timing glitch in graphics stack you can't reproduce? Saved. Weird timing/race-condition-related graphics issues that only happen when your test code is removed and are too fast to diagnose? Saved. Suddenly you can just spray debug data into the corner of the screen and analyze the captures later.
Ideally, some simple compare-while-copying code running in the FPGA could store simple frame deltas and distil whole-screen updates into a list of changed rects. Maybe you could even do that on-CPU, as a kernel task.
But here's the thing. In the worst case, with no compression/reduction code present, you'd be able to store 1 minute of 60fps 1080p in 20.85GB of RAM, and 6 minutes in 125.15GB. 1 minute of 3840x2160 uses 83.42GB, 3 minutes uses 250.28GB. 1 minute of 8K takes 333GB :D
Of course, flushing to disk is a major operation; it would likely require multiple PCI NVMe devices, in either RAID or driven via a threaded storage engine, to flush the memory to storage fast enough - in the 8K example, you need to copy 333GB of RAM to disk in 1 minute, so your solution needs to receive 5GB (44.4Gb) per second, sustained, no performance spikes/dips. :P
(This is where the gigantic circular buffer comes in to play; the idea is that the wraparound hits RAM with new data just as the old data got saved.)
What's potentially interesting with this are the situations doing desktop-type work, small-scale tests, etc, where not all of the screen is going to be updated, and the reduction system will diff the updates very effectively. In these situations, if you're careful, you may go from minutes to tens-of-minutes or even hours of recording time, on a 128GB or 256GB RAM system. And that's only spending a few hundred $. (For the RAM, that is.)
If you're doing game development - every screen effectively new data - and you need pixel-perfect HDMI capture, well, 2TB RAM workstations are only low/mid-5 figures now...
> You can use multiple PCIe lanes easily? If you need more than an x16 slot I'd be very surprised.
The GP mentioned that HDMI 2.1 is 42.7Gbps. Elsewhere in this thread it's mentioned that PCI-e's limit is 50Gbps. [EDIT: Just noticed the other comment about PCI-e speed. This makes things a little easier!]
Oh, but these only have two 10Gb ports, I was looking at 8 port 10Gb switches eg Netgear XS508M which still has a fan. It peaks at 40W.
Networking has been measured in 'bits' (per second), even when modern packets* (within the data payload anyway) are always octet (8 bits per unit) based.
The speed quoted is always in "marketing" (human engineering notation) units, not in binary units (even though we presently only hook up things that count in binary).
A stupidly cut-rate device might use 100mbit Ethernet: ~11MBytes/sec (base 2).
A reasonable expectation is 1000mbit (gitabit) Ethernet: ~119MBytes/sec (base 2).
Most /spinning/ media disks now transfer faster than gigabit Ethernet (for large file transfers); SSDs obliterate this.
10Gbit networking would eliminate a bottle-neck for even 'lightly' raided SSDs and would be ideal for interlink between switches.
According to the Wikipedia article ( https://en.wikipedia.org/wiki/10_Gigabit_Ethernet ) 10GBASE-T (50-100 meters over copper; assuming high grade) first appeared as a standard in 2006. As a conservative estimate, the patents involved will expire in 2025. THAT is probably when we'll really see 10G take off. A bunch of the fiber modes appeared in 2002 though, so in higher end fiber gear we might see those appearing more commonly next year.
Edit: would the one who downvoted me like to explain where I’m mistaken? If there’s a good resource I’d like to see it.
Sounds like there is something wrong with your config, or your using ebay adapters that are 15+ years old. All the modern adapters have multiqueue, TSO, etc and it really helps...
Depends on what your idea of relatively cheap is of course - low end 10gbase-t switches cost about $200-$500 (cheapest ones have just 2 fast ports and rest are 1G). NICs are about $100.
Newer had a trouble with this cheap setup. The only bottleneck is ssd speed in NAS.
anything above 10g might be a trouble, but I didn't try it.
And there is no usage for that of course. Home devices cannot handle 10gb/s of incoming data.
It gets worse. Users have massively abandoned Ethernet in favor of Wifi. Many devices are manufactured without Ethernet support.
So, there's always that kind of thing to consider. I wonder if 10-100Gbps have better price/performance than TCP/IP over PCI by now. I cant even rember the company or tech's name.
Did you by chance come across something smaller than a full-blown, PCIe3x4 per node, TOR switch? I don't need that much capacity, but a cheap enough high speed switch would allow using some slower (individually) servers that got kicked out from the previous owner, instead of getting new, larger machines. A certain level of microservice-thinking/scale of (distributed) Haskell/Erlang does often require much faster connections than one would like to afford with Ethernet, to keep the coding overhead for the sharding to a minimum. At a certain point one can stop worrying about minimizing transfers, and just rely on page-faulting and similar things for less-critical (in a performance sense) data accesses.
All of these chips have smaller sizes available.
I think now that 10gb Ethernet prices are coming down to about $100 per card and switch port there's no way specialized direct pcie would compete off the shelf.
Still I think it would be cool to have a direct 32 lane pcie 3 of 4. It could operate as fast as ram speeds. If you connected two 2P beasts it would be close to having a 4P.
Of course there would probably be protocol issues and overhead as the no-two-masters issue would mean you can't use the native protocol directly.
Far as your other idea, a Distributed, Shared Memory setup was one of my potential applications. I was looking at Beowulf clusters and old MPP systems trying to find ways to get more CPU's with large RAM and simplified programming. I found quite a few software implementations of DSM model. Infiniband and Myrinet were main thing in networking. So, PCI idea was partly about connecting them with something that already had DMA. That at least led me to NUMAscale's products for scaling AMD systems.
If you could get the smallest chip they make, it should not be hard to get a PCB made for it that fans out to e.g. a set of USB-C receptacles. One such receptacle can handle 2 PCIe3 lanes, and some power/USB-2 on the side. The main reason being the relatively low price, compared to e.g. mini SAS HD, which has a similar density and twice the lanes per connector, but also a slightly higher target impedance at the upper end of the PCIe spec, whereas USB-C is specifically targeting the perfect PCIe impedance.
https://www.digikey.com/products/en?keywords=expressfabric
They all have a part status of "Discontinued at Digi-Key" though. Not seeing any further info of where they _are_ available either. :/
Did you want to buy such technology?
[0]: https://www.broadcom.com/products/pcie-switches-bridges/expr... [1]: https://www.broadcom.com/applications/datacenter-networking/... (bottom of the page, grep "ExpressFabric Reference Platform")
Nope, just merely curious
For most of the use cases I can think of that these would suit, Infiniband seems like it would also work and that's fairly widely available already.
That being said, there's probably use cases this would suit better. They're just not coming to mind easily. :)
Also, the latency is much smaller than for Infiniband, and it is nice to e.g. combine blades with NICs or similar configurations, without the NICs being special multi-host ones like Mellanox offers.
Things break in new ways and are fun to troubleshoot.
We had a write intensive workload for a user community that would generate short (~5s) periods of high traffic (6-9Gb) against a file server — this would impact everyone because sessions would be interrupted. It was devilishly difficult to troubleshoot because it was lost in the statistics, aggregated in 30-100s chunks.
Fixing that revealed another constraint where we hit a constraint with the file server process itself.
It’s one of these things that was interesting because the storage with fancy SSD can handle the workload no sweat. In the old days, monitoring would catch the io constraint first.
Another key thing is to be aware where heavy write load generators are on SMB, and scope the SMB shares around them to scope failure domains. There are limits, and the vendors (Microsoft or 3rd party NAS) have a hard time finding them too.
This one is about "Some notes on high speed networking on PCs" - not sure how Apple comes into it?