The other efficiency quote says ~82% with planned design tweaks and even better efficiency hinted at for future iterations.
In any case, if individual cells have 76% peak efficiency, it does not matter how many of them there are, the overall regulator cannot be more than 76% efficient. However, it can be less efficient if the load drifts too far off the cell's peak efficiency point which is 8A/cell in the prototype so FIVR would need to enable/disable cells to keep average load as close to that as possible or at least within the 5-12A range if FIVR behaves like the IVR prototype, which would keep efficiency above 72%.
Poorly designed regulators with poorly chosen components fail often. What kills most PSUs in my experience is failure to use capacitors with adequate AC current ripple rating which causes capacitors to heat up, dry up and inevitably fail. I have repaired a bunch of such PSUs over the years using capacitors rated for 3-4X higher AC ripple and none of them have failed afterward to my knowledge - two of these are in my PCs which have been on almost 24/7 for 5+ after the repair. The oldest of my refurbished PSUs is about 13 years old (11 since repair) and was still kicking when I retired the PC it was in late last year.
It is pretty sad that less than $1 on the BOM separates a PSU/VRM that lasts 1-3 years from one that lasts 7+ years.
Expertly designed regulators with quality components rarely fail unless there is a catastrophic failure upstream or downstream from them.
My bet is that FIVR will lead to a net reliability improvement by taking the most delicate part of voltage regulation on-die where Intel has full control over quality using ceramic/glass capacitors, inductors and MOSFETs all tightly integrated in an equally tightly controlled process.
The voltage regulation issue can easily be solved by having a feedback connection from the die to the external VRM.
Not quite. Part of the reason why Intel went for FIVR is due to response time.
Haswell can change power states about 10X faster than SB/IB and needs a VRM that can adjust voltage outputs that much faster to minimize wasted power and time. The motherboard's VRM has a response time measured in tens if not hundreds of microseconds due to how far away it is from the load, how large its components are and how slow it is operating relative to its load - Haswell has time to wakeup/sleep a few times in the time it take most regulators to adjust to SB/IB's state changes. FIVR's much more tightly coupled components and load bring response time down to microsecond scale to better accommodate Haswell's highly dynamic power usage so the motherboard's VRM does not need to respond impossibly quickly.
FIVR being only ~82% efficient (at least in Intel's experimental design) is somewhat of a disappointment but to be expected when converting low voltage to even lower voltage at high currents. Since there isn't much that can be done about reducing losses on the output side, the most obvious way to improve losses on the input side would be to increase input voltage. 3.3V and 5V seem like logical next steps up for desktop parts if they can be accommodated.
While the paper is about a "test device" produced several months ago, Haswell is a shipping 22nm product coming out early next month that already integrates this on-die and calls it FIVR - Fully Integrated Voltage Regulator. If the IVR was stacked die, it would not be quite "[b]Fully[/b] Integrated", wouldn't it?
Stacked die would also have a problem with dissimilar die areas: Haswell itself will be over 140mm^2 while the IVR powering it would only be around 15mm^2. That does not stack very well unless you want to waste over 125mm^2 per 90nm stacked chip. Not to mention all the thermal resistance stacking the VRM on the CPU would add.
If Intel's experimental IVR was intended to remain discrete, they would likely have chosen some higher voltage than 2.4V for the feed voltage since they would not have had to worry about keeping it compatible with their CPU process. I'm betting that they will increase the input voltage it as they refine the design, techniques, process and materials... maybe Broadwell will step it up to 3.3-5V to be more PC-friendly and efficient through reduced input I2R losses.
The main reason Intel used 90nm for their experiment most likely is that 90nm is much cheaper to experiment with than 22nm and high-voltage/high-power electronics does not really care about features below 100nm anyway: at 2.4V, you would need about 100nm insulation between input and ground/low(er)-voltage structures so 90nm has just about the right resolution to provide representative results.
Delivering power at 2.4V is still far more efficient than delivering it at ~1V thanks to significantly reduced I2R and contact losses. While it does not eliminate off-chip pre-regulation, it does eliminate the need for having several regulators for various chip circuits and it reduces the remaining regulator's output requirement from ~100A to ~40A.
So Haswell's FIVR does allow cutting off-chip regulators to less than half or using components with half the current rating, which should save up to maybe $3 on parts. It definitely allows for some savings, just nowhere near Rotten's "tens of dollars."
Nothing new about physics there. It has been known for decades that a piece of wire starts behaving like an inductor at high frequencies and parallel wires or planes behave like capacitors. Both notions have been in use for high-speed analog and RF ICs and PCBs for a long time. For capacitors, there is even a whole class called "Multi-Layer Chip Capacitor" which is basically an IC with several metallization layers connected at alternating ends.
This is simply the somewhat unexpected but logical application of well-known principles to an old problem: making PSUs smaller.
The real breakthrough here is a VRM solution capable of operating reasonably efficiently at 30+MHz with a multi-phase architecture that brings ripple frequency over 500MHz; within the realm of what can be filtered on-chip.
The big problem with bringing 12V on-chip is not Ohm's law. It is silicon's breakdown voltage at 22nm.
Trace-to-trace and channel/gate breakdown voltages can be addressed by patterning high-voltage areas with wider insulation gaps but that does not address insulation between metallization layers. It would be feasible but it would also make the fabrication process a fair bit more complex to accommodate the different insulation thickness in the high-voltage area vs the digital stuff.
I'm guessing the ~2.5V happens to be the safe maximum working voltage for Intel's insulation layers. For mobile applications, it would be nice if they brought this up to the 3-4V range so the CPU could be powered right off a single-cell lithium battery instead of requiring a pre-regulator.
If Intel wanted to bring straight 12V into 22nm CPUs, it could most likely be done at the expense of more wasted space around high-voltage vias between MOSFETs and high-voltage layers. I see no obvious reasons why they couldn't do this in future iterations - the extra fraction of a mm^2 it may cost in surface area would likely be easily recovered from eliminating several Vcc/GND pads.
I imagined the concept of clean rag should still exist even in industrial settings. Simply clean the sensor a little before applying the printed fingerprint - the fake fingerprint does not need to be manufactured/printed on-site.
Fingerprints as biometric are almost useless. The only way to make sure they work is to have a trained finger inspector look at every finger before it's used. In a MythBusters episode on security device, they showed - much to their own surprise - that some of those fancy biometric fingerprint readers can be tricked by a plain paper copy.
Yup, fingerprints are extremely weak security checks since a normal person leaves hundreds of prints behind them every day.
That's not exactly correct. CRTC forced Bell to open up access to the last mile. Some ISPs (like Teksavvy) have their own network equipments and bandwidth not from Bell, they only rent the last mile from Bell. Bell is actually messing with the data in the last mile. Actually, TSI leases a whole lot more than the last mile: all of TSI's core networking equipment and connections to transit providers PoPs for ON/QC are located at 151 Front-Street in Toronto. TSI actually leases everything from the GbE links to 151 Front St from Bell's GAS down to the DSLAM port in the CO or remote and the copper loop from there to the customers.
TSI does not own anything nor operate any equipment in Quebec - this is why they they are not required to collect the QST.
But what do you mean by TSI's own transit providers? What are these transit providers owned by Teksavvy? And why would Teksavvy bother with transit providers if they're already set up in the Toronto Internet Exchange exchange? 151 Front-Street is a major Canadian networking hub and nearly every significant transit provider who has fiber passing through Ontario has a PoP there.
TSI does business with multiple transit providers to improve its overall routing, for redundancy and bargaining power. TSI also has GbE links provisioned by Peer1, Cogent and 3-4 others. This effort at improving routing and not congesting the network on TSI's end is mooted by throttling from Bell's end.
Great! Now for my next question. How could Bell possibly be throttling your packets if Teksavvy is your ISP? Because Bell is the telco.
Bell owns the copper line, RDSLAM, ATM network, COs, BRAS and L2TP routers that are between me and TSI. TSI leases the line, RDSLAM, bandwidth through Bell's ATM network and L2TP routers to back-haul everything to their PoP at 151 Front-Street from which traffic is then re-routed through TSI's own transit providers to the rest of the internet.
TSI pays Bell over $20/month/subscriber to lease all this stuff plus another ~$1500/Gbps for the transit between Bell's ATM network and TSI's 151 Front-St PoP.
How on earth can you tell if a packet is encrypted?
Who cares? If Bell is throttling based on the number of concurrent connections and patterns in which these connections are established, being able to decode the protocol and identifty the actual content is unimportant.
I too am a Teksavvy customer. I am running Azureus with both tracker and peer encryption enabled yet my torrenting has become throttled to 30K/30K as of March 25. Up until March 24, I used to be able to reach at least 150KB/s and could download from kernel.org at up to 520KB/s. Now, even plain HTTP transfers appear to be throttled to 200-250KB/s.
I second the studies that say hands-free is overrated: simply having a non-driving-related discussion with a passenger who isn't paying any attention to road conditions (little devils on the back-seats as a common example) can be every bit as distracting as (if not more than) a non hands-free cell phone. I do not make calls while driving in moderate to heavy traffic and I only answer them on flat highways where I know I have many more minutes of mostly straight road ahead of me... or when I am stuck in still traffic.
For the very few times I had to shift or needed both hands for steering while holding a phone, I simply used the edge of my palm while still holding the phone... the phone does not systematically write my phone-holding hand off when the situation requires it.
DRM is security through obscurity. If you have the code, you can break any DRM
What do you need the DRM scheme's source code for? Most major algorithms are loosely guarded if not totally open secrets.
DRM schemes rely on playback software and devices managing to keep their decryption keys hidden from their users... and so far, breaking them (finding a way to bypass safeguards and traps to locate plain-text keys) has always been a matter of days or weeks. Since OSS DRM would have no way of hiding the keys from people reading the source code, OSS DRM is futile.
In hybrid (Windows-*nix) environments, logging off, suspend or hibernate means terminating all networked application (X-Windows and Xterm) sessions and having to waste 20 minutes each morning to re-login on the hosts and re-open everything. With even junior engineer wages being $20+/hour, those minutes can easily cost over $5 each day and make spending $1/day on the power bill save $4/day on the bottom line.
Every power or network outage and mandatory-reboot Windows update, even overnight, usually causes major cursing across the office.
I wonder if you lose any speed with the ethernet-to-usb conversion.
Between 802.11N that delivers ~100Mbps of real-world bandwidth and an USB2-100TX adapter that can deliver 100Mbps steady full-duplex real-world bandwidth, it mostly depends on whether or not you are willing to tolerate loss of signal and volatile performance on 11N.
BTW, USB2-Ethernet adapters are small compared to 11N access point + power brick if your destination does not have an existing 11N network. If I had a laptop without Ethernet port and needed rock-solid network performance, the ~$35 USB2 adapters would be an easy choice: cheap, compact, self-contained and lightweight.
Until solar and wind power exceed overall power demand, there is no real need to store that power: any power from clean/renewable sources will reduce the amount of non-renewable resources used in other power plants and this in itself could be considered as a form of grid-based storage. Another form of grid-based storage is to operate hydroelectric turbines in reverse during low-demand hours to pump water back to the high-side, basically using the water reservoirs like capacitors to even out production requirements from other power plants.
This was suggested years ago and someone proposed a simple counter to it: averaging.
Given copies of multiple specimens of a watermarked title, it would be possible to compare them and identify the watermarking algorithm then devise a filtering/averaging algorithm to mangle the watermark without affecting the resulting file's usability. The more specimens get used in the "averaging attack", the harder it becomes to positively identify any of the original specimens from the diluted watermark.
Since implementing watermarks would require producing CD/DVD/HD media unit-by-unit and re-processing/transcoding downloadable media for each download, it does not appear economically viable for most scenarios.
The moral of the story is, buying something simply because it's on sale doesn't save you anything. It just costs you money.
It does save money... but only when you need to buy said thing anyhow and the regular price is unlikely to drop below the on-sale price any time soon.
Buying extra perishables or depreciables before they are needed just because they're on sale is as you said... wasted money and more unnecessary clutter in closets/fridge/etc.
When they overheat, things just tend to melt. No low-voltage IC should ever "burst into flames", even in a poorly ventilated case. In fact, the poorer the ventilation, the fewer the flames.
ICs are not immune to manufacturing defects and some manufacturing defects can lead to working ICs that develop into spontaneous combustion months later. One of my friends had a DRAM chip burst into flames in his (back then) year-old 486... the flame scorched the montherboard, second DIMM and the computer casing. The damned PC shop that built the computer refused to honor the in-shop 1-year guarantee on this "impossible" catastrophic failure.
The problem is not with recovering the helium... it is that the amount of fused hydrogen to produce megawatts is so small that fusion reactors with by-product helium recovery equipment (simply liquefy the "exhaust", dumping the "unburnt" hydrogen back in the fuel tank and pumping the He into the cooling system's tank) might not even be helium self-sufficient due to leakage in the cooling/pumping system without building a low pressure double-wall to catch and recycle leaked helium.
A fusion power plant would only produce enough helium to fill a few balloons each day so man-made helium will be a really expensive commodity once natural stocks are exhausted.
Save helium and save money by switching to hydrogen balloons. Just remember to open windows when popping them indoors to avoid detonable accumulation and keep them away from hairy surfaces when lighting them up for safe fun/show or closed-quarters disposal.
If continuous fusion is achieved, the process will include some mean of extracting mass from the cavity to maintain a constant hydrogen and helium mass. I see no reason why diverting the "exhaust" to a liquefaction plant to recover helium should be a problem.
The problem with this approach is that a nuclear fusion power plant would only consume a few grams of hydrogen per day and therefore produce only a few grams of helium daily whereas worldwide helium consumption is several orders of magnitude higher. Even if all power was produced from hydrogen fusion, power plants would only supply a tiny fraction of overall helium demand. A fusion plant's own He production might not even cover the plant's leakage.
Since fusion reactors cycle thousands of liters of He to keep their plasma levitation/containment coils nice and frosty, it would be a shame to end up in a scenario where scavenging enough He to start the reactor became problematic.
On single-mode glass fiber, bandwidth is primarily limited by the optical transceivers. However, on multi-mode fibers made of whatever material, speed becomes limited by modal dispersion: in multi-mode fibers, light can propagate at various angles along the fiber and this causes photons to arrive at the RX with various delays. As the speed ramps up, fewer photons are contained in mid-pulse while the previous pulse's slowest photons start overlapping the latest pulse's fastest photons causing contrast degradation until contrast drops below reliable detection threshold.
Even ideal multi-mode whatever-material fiber has very finite bandwidth.
Slashdot Mirror
The other efficiency quote says ~82% with planned design tweaks and even better efficiency hinted at for future iterations.
In any case, if individual cells have 76% peak efficiency, it does not matter how many of them there are, the overall regulator cannot be more than 76% efficient. However, it can be less efficient if the load drifts too far off the cell's peak efficiency point which is 8A/cell in the prototype so FIVR would need to enable/disable cells to keep average load as close to that as possible or at least within the 5-12A range if FIVR behaves like the IVR prototype, which would keep efficiency above 72%.
Poorly designed regulators with poorly chosen components fail often. What kills most PSUs in my experience is failure to use capacitors with adequate AC current ripple rating which causes capacitors to heat up, dry up and inevitably fail. I have repaired a bunch of such PSUs over the years using capacitors rated for 3-4X higher AC ripple and none of them have failed afterward to my knowledge - two of these are in my PCs which have been on almost 24/7 for 5+ after the repair. The oldest of my refurbished PSUs is about 13 years old (11 since repair) and was still kicking when I retired the PC it was in late last year.
It is pretty sad that less than $1 on the BOM separates a PSU/VRM that lasts 1-3 years from one that lasts 7+ years.
Expertly designed regulators with quality components rarely fail unless there is a catastrophic failure upstream or downstream from them.
My bet is that FIVR will lead to a net reliability improvement by taking the most delicate part of voltage regulation on-die where Intel has full control over quality using ceramic/glass capacitors, inductors and MOSFETs all tightly integrated in an equally tightly controlled process.
The voltage regulation issue can easily be solved by having a feedback connection from the die to the external VRM.
Not quite. Part of the reason why Intel went for FIVR is due to response time.
Haswell can change power states about 10X faster than SB/IB and needs a VRM that can adjust voltage outputs that much faster to minimize wasted power and time. The motherboard's VRM has a response time measured in tens if not hundreds of microseconds due to how far away it is from the load, how large its components are and how slow it is operating relative to its load - Haswell has time to wakeup/sleep a few times in the time it take most regulators to adjust to SB/IB's state changes. FIVR's much more tightly coupled components and load bring response time down to microsecond scale to better accommodate Haswell's highly dynamic power usage so the motherboard's VRM does not need to respond impossibly quickly.
FIVR being only ~82% efficient (at least in Intel's experimental design) is somewhat of a disappointment but to be expected when converting low voltage to even lower voltage at high currents. Since there isn't much that can be done about reducing losses on the output side, the most obvious way to improve losses on the input side would be to increase input voltage. 3.3V and 5V seem like logical next steps up for desktop parts if they can be accommodated.
While the paper is about a "test device" produced several months ago, Haswell is a shipping 22nm product coming out early next month that already integrates this on-die and calls it FIVR - Fully Integrated Voltage Regulator. If the IVR was stacked die, it would not be quite "[b]Fully[/b] Integrated", wouldn't it?
Stacked die would also have a problem with dissimilar die areas: Haswell itself will be over 140mm^2 while the IVR powering it would only be around 15mm^2. That does not stack very well unless you want to waste over 125mm^2 per 90nm stacked chip. Not to mention all the thermal resistance stacking the VRM on the CPU would add.
If Intel's experimental IVR was intended to remain discrete, they would likely have chosen some higher voltage than 2.4V for the feed voltage since they would not have had to worry about keeping it compatible with their CPU process. I'm betting that they will increase the input voltage it as they refine the design, techniques, process and materials... maybe Broadwell will step it up to 3.3-5V to be more PC-friendly and efficient through reduced input I2R losses.
The main reason Intel used 90nm for their experiment most likely is that 90nm is much cheaper to experiment with than 22nm and high-voltage/high-power electronics does not really care about features below 100nm anyway: at 2.4V, you would need about 100nm insulation between input and ground/low(er)-voltage structures so 90nm has just about the right resolution to provide representative results.
Delivering power at 2.4V is still far more efficient than delivering it at ~1V thanks to significantly reduced I2R and contact losses. While it does not eliminate off-chip pre-regulation, it does eliminate the need for having several regulators for various chip circuits and it reduces the remaining regulator's output requirement from ~100A to ~40A.
So Haswell's FIVR does allow cutting off-chip regulators to less than half or using components with half the current rating, which should save up to maybe $3 on parts. It definitely allows for some savings, just nowhere near Rotten's "tens of dollars."
The second chip in the IVR demonstration is the regulator and is integrated in the Haswell die as FIVR - Fully-Integrated Voltage Regulator.
The second chip seen in some Haswell articles is the 64MB eDRAM for Intel's GT3e IGP.
Nothing new about physics there. It has been known for decades that a piece of wire starts behaving like an inductor at high frequencies and parallel wires or planes behave like capacitors. Both notions have been in use for high-speed analog and RF ICs and PCBs for a long time. For capacitors, there is even a whole class called "Multi-Layer Chip Capacitor" which is basically an IC with several metallization layers connected at alternating ends.
This is simply the somewhat unexpected but logical application of well-known principles to an old problem: making PSUs smaller.
The real breakthrough here is a VRM solution capable of operating reasonably efficiently at 30+MHz with a multi-phase architecture that brings ripple frequency over 500MHz; within the realm of what can be filtered on-chip.
The big problem with bringing 12V on-chip is not Ohm's law. It is silicon's breakdown voltage at 22nm.
Trace-to-trace and channel/gate breakdown voltages can be addressed by patterning high-voltage areas with wider insulation gaps but that does not address insulation between metallization layers. It would be feasible but it would also make the fabrication process a fair bit more complex to accommodate the different insulation thickness in the high-voltage area vs the digital stuff.
I'm guessing the ~2.5V happens to be the safe maximum working voltage for Intel's insulation layers. For mobile applications, it would be nice if they brought this up to the 3-4V range so the CPU could be powered right off a single-cell lithium battery instead of requiring a pre-regulator.
If Intel wanted to bring straight 12V into 22nm CPUs, it could most likely be done at the expense of more wasted space around high-voltage vias between MOSFETs and high-voltage layers. I see no obvious reasons why they couldn't do this in future iterations - the extra fraction of a mm^2 it may cost in surface area would likely be easily recovered from eliminating several Vcc/GND pads.
I imagined the concept of clean rag should still exist even in industrial settings. Simply clean the sensor a little before applying the printed fingerprint - the fake fingerprint does not need to be manufactured/printed on-site.
Yup, fingerprints are extremely weak security checks since a normal person leaves hundreds of prints behind them every day.
TSI does not own anything nor operate any equipment in Quebec - this is why they they are not required to collect the QST.
TSI does business with multiple transit providers to improve its overall routing, for redundancy and bargaining power. TSI also has GbE links provisioned by Peer1, Cogent and 3-4 others. This effort at improving routing and not congesting the network on TSI's end is mooted by throttling from Bell's end.
Bell owns the copper line, RDSLAM, ATM network, COs, BRAS and L2TP routers that are between me and TSI.
TSI leases the line, RDSLAM, bandwidth through Bell's ATM network and L2TP routers to back-haul everything to their PoP at 151 Front-Street from which traffic is then re-routed through TSI's own transit providers to the rest of the internet.
TSI pays Bell over $20/month/subscriber to lease all this stuff plus another ~$1500/Gbps for the transit between Bell's ATM network and TSI's 151 Front-St PoP.
Who cares? If Bell is throttling based on the number of concurrent connections and patterns in which these connections are established, being able to decode the protocol and identifty the actual content is unimportant.
I too am a Teksavvy customer. I am running Azureus with both tracker and peer encryption enabled yet my torrenting has become throttled to 30K/30K as of March 25. Up until March 24, I used to be able to reach at least 150KB/s and could download from kernel.org at up to 520KB/s. Now, even plain HTTP transfers appear to be throttled to 200-250KB/s.
I second the studies that say hands-free is overrated: simply having a non-driving-related discussion with a passenger who isn't paying any attention to road conditions (little devils on the back-seats as a common example) can be every bit as distracting as (if not more than) a non hands-free cell phone. I do not make calls while driving in moderate to heavy traffic and I only answer them on flat highways where I know I have many more minutes of mostly straight road ahead of me... or when I am stuck in still traffic.
For the very few times I had to shift or needed both hands for steering while holding a phone, I simply used the edge of my palm while still holding the phone... the phone does not systematically write my phone-holding hand off when the situation requires it.
What do you need the DRM scheme's source code for? Most major algorithms are loosely guarded if not totally open secrets.
DRM schemes rely on playback software and devices managing to keep their decryption keys hidden from their users... and so far, breaking them (finding a way to bypass safeguards and traps to locate plain-text keys) has always been a matter of days or weeks. Since OSS DRM would have no way of hiding the keys from people reading the source code, OSS DRM is futile.
In hybrid (Windows-*nix) environments, logging off, suspend or hibernate means terminating all networked application (X-Windows and Xterm) sessions and having to waste 20 minutes each morning to re-login on the hosts and re-open everything. With even junior engineer wages being $20+/hour, those minutes can easily cost over $5 each day and make spending $1/day on the power bill save $4/day on the bottom line.
Every power or network outage and mandatory-reboot Windows update, even overnight, usually causes major cursing across the office.
Between 802.11N that delivers ~100Mbps of real-world bandwidth and an USB2-100TX adapter that can deliver 100Mbps steady full-duplex real-world bandwidth, it mostly depends on whether or not you are willing to tolerate loss of signal and volatile performance on 11N.
BTW, USB2-Ethernet adapters are small compared to 11N access point + power brick if your destination does not have an existing 11N network. If I had a laptop without Ethernet port and needed rock-solid network performance, the ~$35 USB2 adapters would be an easy choice: cheap, compact, self-contained and lightweight.
Until solar and wind power exceed overall power demand, there is no real need to store that power: any power from clean/renewable sources will reduce the amount of non-renewable resources used in other power plants and this in itself could be considered as a form of grid-based storage. Another form of grid-based storage is to operate hydroelectric turbines in reverse during low-demand hours to pump water back to the high-side, basically using the water reservoirs like capacitors to even out production requirements from other power plants.
It does save money... but only when you need to buy said thing anyhow and the regular price is unlikely to drop below the on-sale price any time soon.
Buying extra perishables or depreciables before they are needed just because they're on sale is as you said... wasted money and more unnecessary clutter in closets/fridge/etc.
ICs are not immune to manufacturing defects and some manufacturing defects can lead to working ICs that develop into spontaneous combustion months later. One of my friends had a DRAM chip burst into flames in his (back then) year-old 486... the flame scorched the montherboard, second DIMM and the computer casing. The damned PC shop that built the computer refused to honor the in-shop 1-year guarantee on this "impossible" catastrophic failure.
The problem is not with recovering the helium... it is that the amount of fused hydrogen to produce megawatts is so small that fusion reactors with by-product helium recovery equipment (simply liquefy the "exhaust", dumping the "unburnt" hydrogen back in the fuel tank and pumping the He into the cooling system's tank) might not even be helium self-sufficient due to leakage in the cooling/pumping system without building a low pressure double-wall to catch and recycle leaked helium.
A fusion power plant would only produce enough helium to fill a few balloons each day so man-made helium will be a really expensive commodity once natural stocks are exhausted.
Save helium and save money by switching to hydrogen balloons. Just remember to open windows when popping them indoors to avoid detonable accumulation and keep them away from hairy surfaces when lighting them up for safe fun/show or closed-quarters disposal.
If continuous fusion is achieved, the process will include some mean of extracting mass from the cavity to maintain a constant hydrogen and helium mass. I see no reason why diverting the "exhaust" to a liquefaction plant to recover helium should be a problem.
The problem with this approach is that a nuclear fusion power plant would only consume a few grams of hydrogen per day and therefore produce only a few grams of helium daily whereas worldwide helium consumption is several orders of magnitude higher. Even if all power was produced from hydrogen fusion, power plants would only supply a tiny fraction of overall helium demand. A fusion plant's own He production might not even cover the plant's leakage.
Since fusion reactors cycle thousands of liters of He to keep their plasma levitation/containment coils nice and frosty, it would be a shame to end up in a scenario where scavenging enough He to start the reactor became problematic.
This is true only for ideal single-mode fiber.
On single-mode glass fiber, bandwidth is primarily limited by the optical transceivers. However, on multi-mode fibers made of whatever material, speed becomes limited by modal dispersion: in multi-mode fibers, light can propagate at various angles along the fiber and this causes photons to arrive at the RX with various delays. As the speed ramps up, fewer photons are contained in mid-pulse while the previous pulse's slowest photons start overlapping the latest pulse's fastest photons causing contrast degradation until contrast drops below reliable detection threshold.
Even ideal multi-mode whatever-material fiber has very finite bandwidth.