my collection of Thunderbolt 3 10 gigabit Ethernet adapters has grown again, with the arrival of my QNAP SFP+ adapter
from bottom left, clockwise:
- QNAP QNA-T310G1S, SFP+, fanless
- QNAP QNA-T310G1T, RJ45, not (!) fanless
- Sonnet Solo10G, RJ45, fanless
- Sonnet Solo10G SFP+, SFP+ (duh), fanless
they're largely the same: all of them use Aquantia/Marvell AQtion Ethernet chips, and they use Intel's Alpine Ridge TB3 controllers, and they can run on the firmware provided on Marvell's website, but there *are* other differences as well:
- The RJ45 adapters use an AQC107 (which includes a PCIe endpoint controller, an Ethernet MAC, and an Ethernet PHY), while the SFP+ adapters use an AQC100(S), which omits the PHY (obviously)
- The Sonnet adapters are obviously larger (but also thinner) than the QNAP adapters. The Solo10G SFP+ specifically is a bit longer than the Solo10G RJ45 for some reason, which is a little weird since the QNAP adapters are of the exact same physical size, and the Solo10G RJ45 is just as long as the QNAP adapters
- The RJ45 QNAP adapter has a fan that seems to run all the time (but not at the same speed). It's kind of an annoying sound, like the fan is rubbing against some plastic — perhaps I'll have to take it apart to make sure that's not the case. All the other adapters are fanless (especially the Sonnet ones, which have much more external surface area)
- The Sonnet adapters use a JHL6340, while the QNAP adapters use a JHL6240. TDP on the JHL6340 is 0.5W higher than the JHL6240's 1.2W TDP, but you do get 4 lanes of PCIe 3.0 (4GB/s) instead of only 2 lanes (2GB/s). Not that it matters though — 2GB/s full-duplex is more than enough for 10Gbps Ethernet, and you can only realistically get ~22Gbps of PCIe bandwidth from a Thunderbolt 3 host — but perhaps Sonnet picked the JHL6340 for parts commonality between their Solo10G and Twin10G adapters
other than that, there's really not much of a tangible difference between these adapters -- though I'd probably avoid the QNAP RJ45 adapter for the fan
from bottom left, clockwise:
- QNAP QNA-T310G1S, SFP+, fanless
- QNAP QNA-T310G1T, RJ45, not (!) fanless
- Sonnet Solo10G, RJ45, fanless
- Sonnet Solo10G SFP+, SFP+ (duh), fanless
they're largely the same: all of them use Aquantia/Marvell AQtion Ethernet chips, and they use Intel's Alpine Ridge TB3 controllers, and they can run on the firmware provided on Marvell's website, but there *are* other differences as well:
- The RJ45 adapters use an AQC107 (which includes a PCIe endpoint controller, an Ethernet MAC, and an Ethernet PHY), while the SFP+ adapters use an AQC100(S), which omits the PHY (obviously)
- The Sonnet adapters are obviously larger (but also thinner) than the QNAP adapters. The Solo10G SFP+ specifically is a bit longer than the Solo10G RJ45 for some reason, which is a little weird since the QNAP adapters are of the exact same physical size, and the Solo10G RJ45 is just as long as the QNAP adapters
- The RJ45 QNAP adapter has a fan that seems to run all the time (but not at the same speed). It's kind of an annoying sound, like the fan is rubbing against some plastic — perhaps I'll have to take it apart to make sure that's not the case. All the other adapters are fanless (especially the Sonnet ones, which have much more external surface area)
- The Sonnet adapters use a JHL6340, while the QNAP adapters use a JHL6240. TDP on the JHL6340 is 0.5W higher than the JHL6240's 1.2W TDP, but you do get 4 lanes of PCIe 3.0 (4GB/s) instead of only 2 lanes (2GB/s). Not that it matters though — 2GB/s full-duplex is more than enough for 10Gbps Ethernet, and you can only realistically get ~22Gbps of PCIe bandwidth from a Thunderbolt 3 host — but perhaps Sonnet picked the JHL6340 for parts commonality between their Solo10G and Twin10G adapters
other than that, there's really not much of a tangible difference between these adapters -- though I'd probably avoid the QNAP RJ45 adapter for the fan
picked up this Helium "miner" (a SenseCAP M1) for a reasonably cheap price, because the last owner apparently lost their wallet keys (and by extension, access to the account that this miner, or its secure element, is associated with)
Helium is this blockchain protocol thing, involving selling access to a supposedly LoRa network (I think they're also doing something with 5G in the US now). miner operators can buy one of these miners for exorbitant prices (because you also need a secure element, and there are fees involved in getting each device registered), then run these in hopes of getting funny internet money from "proof of coverage" (attestations from other nearby miners that they can see your node) and data transfers (which doesn't need the fancy secure element stuff). and of course, users can onboard their lil LoRa sensors and whatnot, and pay these miners to get data sent to/received from their sensors
I'm not sure how much actual use Helium actually sees, but basically, if you associate the miner with an account that you subsequently lose the keys to, it practically becomes useless (since you can't really get ahold of awards from PoC, and I don't think you earn much from data transfers -- not that there's a lot of that to begin with)
okay well, it becomes useless *as a Helium miner*, but if you look at the pics, you can tell it's got a SX1303, a RPi 4 Model B, and a somewhat decent case, so just parting it out might earn you a bit of profit, because of the stupid price premium RPis attract
for me, though, I'd probably just use it as a The Things Network gateway (kind of a similar idea as Helium, I guess... just that I'm not getting paid) -- and perhaps as a super duper overkill Meshtastic router node once SX1302/3 support gets fleshed out?
suggestions welcome
Helium is this blockchain protocol thing, involving selling access to a supposedly LoRa network (I think they're also doing something with 5G in the US now). miner operators can buy one of these miners for exorbitant prices (because you also need a secure element, and there are fees involved in getting each device registered), then run these in hopes of getting funny internet money from "proof of coverage" (attestations from other nearby miners that they can see your node) and data transfers (which doesn't need the fancy secure element stuff). and of course, users can onboard their lil LoRa sensors and whatnot, and pay these miners to get data sent to/received from their sensors
I'm not sure how much actual use Helium actually sees, but basically, if you associate the miner with an account that you subsequently lose the keys to, it practically becomes useless (since you can't really get ahold of awards from PoC, and I don't think you earn much from data transfers -- not that there's a lot of that to begin with)
okay well, it becomes useless *as a Helium miner*, but if you look at the pics, you can tell it's got a SX1303, a RPi 4 Model B, and a somewhat decent case, so just parting it out might earn you a bit of profit, because of the stupid price premium RPis attract
for me, though, I'd probably just use it as a The Things Network gateway (kind of a similar idea as Helium, I guess... just that I'm not getting paid) -- and perhaps as a super duper overkill Meshtastic router node once SX1302/3 support gets fleshed out?
suggestions welcome
🥰2☃1
and here's one more: a variant of the RAKwireless miners.
photos are taken in reverse order, so you'll notice that I left the USB port plugs halfway in, and the sticker covering the microSD slot has been shifted
it comes in a much more compact form factor, and the case is a lot easier to reuse (seeing that almost all ports are accessible, or just covered by easily removable plugs/stickers)
you might think the case is great for heat dissipation, but as far as I can tell, the only direct thermal interface is from the bottom of the RPi. thankfully, the RPi 4B doesn't put out much heat to begin with -- I put yesterday's SenseCAP M1 in a laptop bag and started a stress test, and the CPU is struggling to break 82°C
anyway, this thing seems to be made up of a (gold) RAK7244(C) metal case, a variant of the RAK2287 PiHAT, a RAK2287 LoRaWAN concentrator (SX1302?), and of course, a RPi 4B 8GB. the entire kit is probably also known as the RAK7248, or so that's what the label on the side tells me
photos are taken in reverse order, so you'll notice that I left the USB port plugs halfway in, and the sticker covering the microSD slot has been shifted
it comes in a much more compact form factor, and the case is a lot easier to reuse (seeing that almost all ports are accessible, or just covered by easily removable plugs/stickers)
you might think the case is great for heat dissipation, but as far as I can tell, the only direct thermal interface is from the bottom of the RPi. thankfully, the RPi 4B doesn't put out much heat to begin with -- I put yesterday's SenseCAP M1 in a laptop bag and started a stress test, and the CPU is struggling to break 82°C
anyway, this thing seems to be made up of a (gold) RAK7244(C) metal case, a variant of the RAK2287 PiHAT, a RAK2287 LoRaWAN concentrator (SX1302?), and of course, a RPi 4B 8GB. the entire kit is probably also known as the RAK7248, or so that's what the label on the side tells me
👍1
in other news, i was trying to figure out why one of my Proxmox cluster nodes (a HP EliteDesk 800 G4 DM) was running a lot hotter than the other one
found out that it had one or two cores pegged at 100% because of
a quick Google search revealed that... apparently, if one of the ports is experiencing an overcurrent condition and there's an attempt to suspend the USB bus, the kernel will end up busywaiting, checking the port over and over again until the overcurrent condition is gone, before suspending the bus. this was apparently a new change in Linux 5.7, which kind of explains why I wasn't seeing it being an issue last month (before I upgraded Proxmox on everything)
and yeah, the overcurrent condition was because I accidentally put 20V into that port and fried it (back when this node was my main desktop), so it's probably never going to leave the overcurrent condition state. (perhaps I have HP to thank for limiting the damage to just that one single port)
ended up disabling the port in BIOS (thanks again, HP), and now i'm saving 20 watts of power, yay
found out that it had one or two cores pegged at 100% because of
kworker+pm, and that persisted even after a reboota quick Google search revealed that... apparently, if one of the ports is experiencing an overcurrent condition and there's an attempt to suspend the USB bus, the kernel will end up busywaiting, checking the port over and over again until the overcurrent condition is gone, before suspending the bus. this was apparently a new change in Linux 5.7, which kind of explains why I wasn't seeing it being an issue last month (before I upgraded Proxmox on everything)
and yeah, the overcurrent condition was because I accidentally put 20V into that port and fried it (back when this node was my main desktop), so it's probably never going to leave the overcurrent condition state. (perhaps I have HP to thank for limiting the damage to just that one single port)
ended up disabling the port in BIOS (thanks again, HP), and now i'm saving 20 watts of power, yay
😢1
i just had a fun (/s) 3-hour troubleshooting session trying to figure out why my storage server died and stopped POSTing while I was replacing a fan
1) i hear the rear fan rattling
2) i unplug it to replace it with a spare
3) the connector's between the CPU heatsink and the case walls, so i bump into the heatsink while trying to unplug it
4) server probably reboots spontaneously and stops POSTing properly (hangs at enumerating the PCIe bus)
i thought i had maybe shorted something out or... idk, ESD'd the RAM (even though it's not really likely for that to happen in humid Singapore), so I tried unplugging the spare fan and the two DIMMs installed next to the fan connector
it boots! (though the BMC reports there's only one DIMM installed, which I chalked up to a BMC quirk or something)
i re-insert the two DIMMs, it stops POSTing
i remove the two DIMMs, it still doesn't POST
(a bunch more troubleshooting happened here)
i shuffle the four DIMMs around and plug the fan back in, it POSTs, but with only 3 of the DIMMs detected
i reseat the DIMM that wasn't detected, it stops POSTing
(cont.)
1) i hear the rear fan rattling
2) i unplug it to replace it with a spare
3) the connector's between the CPU heatsink and the case walls, so i bump into the heatsink while trying to unplug it
4) server probably reboots spontaneously and stops POSTing properly (hangs at enumerating the PCIe bus)
i thought i had maybe shorted something out or... idk, ESD'd the RAM (even though it's not really likely for that to happen in humid Singapore), so I tried unplugging the spare fan and the two DIMMs installed next to the fan connector
it boots! (though the BMC reports there's only one DIMM installed, which I chalked up to a BMC quirk or something)
i re-insert the two DIMMs, it stops POSTing
i remove the two DIMMs, it still doesn't POST
(a bunch more troubleshooting happened here)
i shuffle the four DIMMs around and plug the fan back in, it POSTs, but with only 3 of the DIMMs detected
i reseat the DIMM that wasn't detected, it stops POSTing
(cont.)
today's ebay junk repair session troubleshooting session involves this IP KVM from... probably nearly two decades ago
the KVM part (seems to) work just fine (switching between the 4 inputs, and the OSD configuration menu), but the IP part doesn't seem to work -- Ethernet links up fine, but no packets show up; the IP KVM configuration screen that was supposed to appear also doesn't appear.
I started checking this out last night, but got stuck because I didn't have the right serial console cables. but I have RJ45 crimping tools now, and with that, I now have the correct serial console cable
time to pull this apart then
the KVM part (seems to) work just fine (switching between the 4 inputs, and the OSD configuration menu), but the IP part doesn't seem to work -- Ethernet links up fine, but no packets show up; the IP KVM configuration screen that was supposed to appear also doesn't appear.
I started checking this out last night, but got stuck because I didn't have the right serial console cables. but I have RJ45 crimping tools now, and with that, I now have the correct serial console cable
time to pull this apart then
🔥1
FINALLY
i spent the last two or so hours trying to get the "IP" board to boot outside of the carrier board, but it just wouldn't, even if i connected most of the PCB stacking connectors (maybe my jumper wires are just dogshit)
in the end, all i had to do was to take a thin cable tie, strip off a bit off the end, and reach under the board to poke the data pins on the NOR flash right before it starts loading the kernel etc
yeah, the flash is under the board which makes it hard to poke at, but removing the two smaller boards gives me enough space to see what's going on
i spent the last two or so hours trying to get the "IP" board to boot outside of the carrier board, but it just wouldn't, even if i connected most of the PCB stacking connectors (maybe my jumper wires are just dogshit)
in the end, all i had to do was to take a thin cable tie, strip off a bit off the end, and reach under the board to poke the data pins on the NOR flash right before it starts loading the kernel etc
yeah, the flash is under the board which makes it hard to poke at, but removing the two smaller boards gives me enough space to see what's going on
🔥3