I just ran these past OpenAssistant and I'm seeing a much higher error detection rate. I've tried 6 so far, and it's caught bugs in about 4. OpenAssistant actually had a very good technical explanation of the bug it found in the BubbleSort example.
Wifi is a pretty difficult protocol, but fortunately Linux ships with mac80211. So all that is needed is an SDR based PHY such as https://github.com/Nuand/bladeRF-wiphy/ .
The "fix" Intel pushed out this week is a microcode update that in my experience doesn't fix or address Meltdown at all. The update does however make Spectre slightly less reliable, so I'm going to assume that the microcode update has something to do with fixing, updating, or adding new controls to the branch predictor buffer.
So absent a microcode update that outright fixes Meltdown, there will always be some level of slow-down for vulnerable devices. System calls now jump from user mode code to a stub kernel in "supervisor memory". The stub kernel then does a full context switch (touching %cr3 paging register and wiping a good portion of the TLB), and once the real kernel finishes, it does a full context switch back to the stub kernel. It's all terribly inefficient, and realistically it's unlikely that there will only be negligible performance impacts. It should also be noted that this "work-around" doesn't fix processor, it just makes it so that that there's nothing juicy in the supervisor memory.
You may have to learn to live with this for a while. Even if it takes Intel a month to design and validate a fix for Meltdown, prototype and mass production turn around times mean that no customer will have a processor that isn't vulnerable to Meltdown until April-June 2019.
Eventually yes, we can expect to see optical in desktops. Fiber connections are "better" but also much more expensive. The price should eventually come down as volumes increase. The main delaying factor is that copper is still good enough.
Multimedia is the driving force behind increased data usage, and I think we'll continue to need more throughput until we no longer get any benefits from higher resolutions (aka when we have substantially more pixels than rods and cones in our eyes). At the moment a phone with a 4K display saturates your eyes at any distance greater than 2 feet from your face. I think a 16x PCIe 4.0 link will likely provide more than enough bandwidth to generate fully immersive VR experiences, so the question then becomes... why and when will we need optical PCIe 5.0 to quadruple the datarate of PCIe 4.0...
PCIe signals are generated by transceivers -- devices within chips that are specialized in signal conditioning e.g echo cancelling, emphasis/de-emphasis, dynamic impedance matching. These transceivers and the analog and digital techniques they implement get better with time. This is easily measurable by looking at the Bit Error Rate of data or by looking at eye diagrams (see slide 15). As data rates increase things like drive strengths, impedance mismatches, and a number of other properties of silicon will "close the eye" meaning the transmitted "0"s and "1"s are not different enough for them to be distinguished by a receiver enough of the time to successfully decode a packet. (PCIe is packet based, it's surprisingly somewhat similar to Ethernet). But essentially as our understanding and processes for manufacturing semiconductor devices increase, we're able to "open the eye" more, at which point the industry decides to increase data rates.
Been working on this for a few months, and just added the finishing touches. It's a high performance ADS-B receiver that can detect and correct multiple bit errors and packet collisions. The FPGA offload allows a Raspberry Pi to process samples in realtime, where as a recent i7 would not be able to keep up without the hardware offload.
I'm planning on doing a mini series explaining the MATLAB, C, and VHDL design flow behind building a high performance hardware modem. The first article can be found here, https://www.nuand.com/blog/bladerf-vhdl-ads-b-decoder/
Questions or suggestions are welcome, I would like to use them to improve my writing style and this mini series!
Yes, you are correct. Some parts of LTE and WCDMA use a pre shared secret and rolling keys to allow UEs to identify themselves to the mobile network. There are however many non-data carrying parts of LTE that are not encrypted or authenticated, sort of how 802.11 has AES but management frames are still fully unecrypted.
It will depend on the material, but I don't think 802.11ad can even penetrate through sheetrock. Honestly it may even be so bad that a sneeze could knock your connection out for a few seconds.
The laser analogy is definitely accurate given today's technology. I just don't think they'll be able to productize something that has that high of an antenna gain. I'm really hoping and thinking that we'll see some smart antenna advances.
If you want an introduction to assembly with the hopes of achieving super complicated in the future, I would suggest taking a look at the Intel manuals [1]. Volume 1 specifically offers an overview of the processor's architecture and underlying components (registers, ALUs, branching); it's actually a pretty useful textbook. Volume 2 walks explains each and every single instruction and what it does. Volume 3 is a programmer's guide to the Intel processor, which is what might help you quite a bit, it provides examples of using stacks, function calling, memory management, and SIMD instructions.
Monitor mode is a MAC level concept, and doesn't alter any of the RF characteristics that would make operating this device illegal. (This is not legal advice. Consult with an attorney, etc etc)
OFDM 802.11 rates already have a significant amount of Forward Error Correction. 802.11g uses a convolution encoder and Viterbi Decoder [1], and 802.11 HT rates (n, ac, ad) can also use Low Density Parity Codes (LDPC) [2]. The problem with Forward Error Correction is that it can't deal with too many sequential errors, so many modems use something known as an interleaver. An reorders bits as they are sent over the air, so instead of sending LSB to MSB or vice versa you are sending bits in a random yet mutually known order. This causes link quality issues such as interference to not interfere with continuous bits (to the benefit of the FEC decoder). The problem with an interleaver is that it causes latency to go up. If you interleave based on 256 bits of 2048bits, you can't decode blocks of data until you've received all of this bits. So the 288 bit interleaver that 802.11 uses won't cause many problems if you're streaming but if you are interleaving data across multiple packets you will notice a spike in video latency.
OpenBTS and YateBTS need a full-duplex radio to function. So far only Ettus radios and bladeRFs [1] have those capabilities. The bladeRF is also the cheapest option, costing in the low 3 figures (with coupon code HKRNWS). Full-disclosure, I make the bladeRF.