A more extreme version of the ADC/DAC projects mentioned here is my (old) project that built a Bluetooth transceiver using just an FPGA and an antenna (and a low pass filter if you don't want the FCC coming after you): https://github.com/newhouseb/onebitbt
Tl;dr: if you blast in/out the right 5GHz binary digital signal from a SERDES block on an FPGA connected to a short wire you can talk to your phone!
The short but unfulfilling answer is that this is because the DOCSIS standard historically has allocated a much broader frequency range for DL than UL. Unlike other forms of communication (like cell) that can use similar frequency ranges for transmit and receive, DOCSIS tends to slice something like < 70Mhz for UL and >70Mhz to 1Ghz for DL (I'm probably remembering the details incorrectly, trust Google over me!). Switching the frequency ranges often requires different circuitry and therefore different hardware.
I would guess that unlike fiber -- rarely saturated in a consumer context -- people have ~always wanted more than what cable can provide and thus the operators needed to be strategic about the allocation of bandwidth between DL and UL, hence the asymmetry.
Actually most of the capacity problems on cable networks come from upstream congestion; not downstream congestion and this has nearly always been the case. When the upstream gets congested TCP ACKs get dropped and it kills download speed.
Upstream has always been challenging on coax. The first cable modems didn't even use the coax for upstream, instead it used a separate dial up modem.
I'm not entirely sure of the details but even after that DOCSIS has always had to use much lower frequency channels for upstream which are much more limited vs downstream which tends to use higher frequencies. Potentially because it was hard to get high frequency transmitting upstream low cost CPE devices back in the day?
It's about prioritizing downstream since that's 90% of the traffic and what customers complain about the most. No normal customer complains about their upstream cap, but they will freak out over congestion or not having the fastest download speeds
I didn’t generally see upstream congestion when I worked on Internet QoE at Comcast, downstream was more common. Cable modems do ACK suppression as well to help there.
That, also the relatively low frequency range was originally only there for the sake of public access and the like; they only expected a relatively small number of channels on the return path.
I would say that cell signals mostly can't use the same frequencies for sending and receiving. The newer TDD allocations at 2.5GHz and above that carriers in the US are rolling out today do use the same for transmit and receive, but most of the old frequency ranges are exclusively up or down.
The difference is that cellular licenses generally offered equal bandwidth to up and down (ex. 10MHz down and 10MHz up). That's because they were originally designed for somewhat symmetrical communication: phone conversations where you assume each party is talking (sending) and listening (receiving) reasonably equally. With DOCSIS, it was designed assuming (correctly) that there'd be a lot more download traffic than upload traffic (which still holds true even in the era of remote work).
Huge fan of RASP et al. If you enjoy this space, might be fun to take a glance at some of my work on HandCrafted Transformers [1] wherein I hand-pick the weights in a transformer model to do long-handed addition similar to how humans learn to do it in gradeshcool.
> We report results on two protocols: (1) Same layout: We train
on the training set in all 16 spatial layouts, and test on remaining
frames. Following [31], we randomly select 80% of the samples to
be our training set, and the rest to be our testing set. The training
and testing samples are different in the person’s location and pose,
but share the same person’s identities and background. This is a
reasonable assumption since the WiFi device is usually installed
in a fixed location. (2) Different layout: We train on 15 spatial
layouts and test on 1 unseen spatial layout. The unseen layout is in
the classroom scenarios.
Depending on how they selected various frames -- let's just say it was random -- the model could have learned something to effect of "this RF pattern is most similar to these two other readings I'm familiar with" (from the surrounding frames) and can therefore just interpolate between the resulting poses associated with those RF patterns (that the model has compressed/memorized into trained weights).
If you look at the meshes between the image ground truth and the paper's results, you'll see that they are strikingly similar. I find this also suspect because WiFi-band RF interacts a lot more with water than with clothes and so you would expect the outline/mesh to get the "meat-bag" parts of you correct but not be able to guess the contours of baggy clothes. That is... unless it has memorized them from the training set.
> It should be noted that many WiFi routers, such as TP-Link AC1750, come with 3 antennas, so our method only requires 2 of these routers.
> WiFi-based perception is based on the Channel-state-information (CSI) that represents the ratio between the transmitted signal wave and the received signal wave. The CSIs are complex decimal sequences that do not have spatial correspondence to spatial locations
AFAIK, access to raw CSI data is not available on consumer routers. You need specific FPGA/SDR boards which happens to speak the WIFI 2.4G/5G protocol.
You still charge through the USB-C / Thunderbolt ports (and use a USB-C to USB-C cable with the provided power brick to do so). The MagSafe plug is just for convenience (and perhaps slightly higher wattage than is normally specced for USB-C on the beefier MBPs).
Also if you happen to trip over the magsafe cord, the possibility of snapping the connector is non-existent compared to the risk of using a USB-C cable.
It's of course a possibility but the Type C connection was designed to sacrifice the cable part first, both on the "repeated insertion" metric and for cases like this.
An example from an earlier comment of mine on a different thread (assuming I've understood correctly):
> let's say we had a grammar that had a key "healthy" with values "very_unhealthy" or "moderately_healthy." For broccoli, the LLM might intend to say "very_healthy" and choose "very" but then be pigeonholed into saying "very_unhealthy" because it's the only valid completion according to the grammar.
That said, you can use beam search to more or less solve this problem by evaluating the joint probability of all tokens in each branch of the grammar and picking the one with the highest probability (you might need some more nuance for free-form strings where the LLM can do whatever it wants and be "valid").
This is a concern of mine, as well as limiting the amount that an LLM can talk through a problem - sometimes to nothing. Getting them to work through things IMO dramatically improves their output.
My gut feeling is that taking the output and if it's broken then start fixing it would have a better result - you could even then completely limit the output to only valid json. For your example, if it wrote "very_healthy" and was given an error message explaining that this wasn't an option it had to choose from very_unhealthy" or "moderately_healthy" I would expect a halfway decent model to pick "moderately_healthy".
This has the benefit of allowing you to use a more powerful model for reasoning (like GPT4) and a local model where you can do this kind of token probability manipulation for just fixing the data.
I think this is likely a consequence of a couple of factors:
1. Fancy token selection w/in batches (read: beam search) is probably fairly hard to implement at scale without a significant loss in GPU utilization. Normally you can batch up a bunch of parallel generations and just push them all through the LLM at once because every generated token (of similar prompt size + some padding perhaps) takes a predictable time. If you stick a parser in between every token that can take variable time then your batch is slowed by the most complex grammar of the bunch.
2. OpenAI appears to work under the thesis articulated in the Bitter Lesson [i] that more compute (either via fine-tuning or bigger models) is the least foolish way to achieve improved capabilities hence their approach of function-calling just being... a fine tuned model.
The "Bitter Lesson" indeed sheds light on the future trajectory of technology, emphasizing the supremacy of computation over human-designed methods. However, our current value functions often still need to focus on what we can achieve with the tools and methods available to us today. While it's likely that computational tools will eventually replace human-guided "outlines" or "guidance", that are used to shape LLM outputs, there will likely always be a substantial amount of human-structured knobs necessary to align computation with our immediate needs and goals.
Also important to call out that anytime you have a freeform string it's pretty much an open invitation for the LLM to go completely haywire and run off into all sorts of weird tangents. So these methods are best used with other heuristics to bias sampling once you get to free-form text territory (i.e. a repetition penalty etc)
The way LLMs work is they output probabilities for every _token_, so you don't really need to backtrack you can just always pick a token that matches the provided grammar.
That said, you might want to do something like (backtracking) beam-search which uses various heuristics to simultaneously explore multiple different paths because the semantic information may not be front-loaded, i.e. let's say we had a grammar that had a key "healthy" with values "very_unhealthy" or "moderately_healthy." For broccoli, the LLM might intend to say "very_healthy" and choose "very" but then be pigeonholed into saying "very_unhealthy" because it's the only valid completion according to the grammar.
That said, there are a lot of shortcuts you can take to make this fairly efficient thanks to the autoregressive nature of (most modern) LLMs. You only need to regenerate / recompute from where you want to backtrack from.
Whether or not backtracking is needed is really down to the grammar's ambiguity.
The auto-regressive nature of LLMs is actually something that counts against them, at least as some tell it. Although, really, the root problem is generating autoregressively from LLMs precludes planning ahead while also lacking any iterative refinement stage.
Backtracking, look-ahead, early failure pruning and staged generation are all very useful for fitting both concepts (refinement and planning ahead) in an auto-regressive generation framework.
Tl;dr: if you blast in/out the right 5GHz binary digital signal from a SERDES block on an FPGA connected to a short wire you can talk to your phone!