I hope they have a robot for physically handeling the SD card insertions and retrieval. Even then, lets say you can load or swap 1 card per second, by the time you are dealing with the 200th card, would the first one not already be ingested?
Seems like more of a scale out than a scale up problem, with a view on the whole operation from recording footage down to final archive to tackle the real bottleneck.
Or how about 999 additional computers? They could be really tiny ones, running some kind of operating system designed for putting inside small single purpose machines. You could also add a coloured light on the front of each one and a button that says "copy to NAS".
Or each SD-card-reader node could copy to its own hard drive (to free things up for another card) and asynchronously upload from there to the central unit... Or possibly send metadata/thumbnails first, and then alternate between sending specifically-requested content versus uploading the backlog.
The physical interface itself is going to be a big deal, people are going to be just swapping cards constantly and you'll need multiple people just doing this. Status of read is a big part of this as well so some amount of custom LEDs and such for status of ingress will be required. What a horrible job being in a room with 100s of thousands of SD cards just feeding them into slots and then into an empty bin!
Its possible from a PCI-E bandwidth point of view but its going to require some seriously specialist USB interfaces. I am tempted by the same solution others suggest, smaller amounts per machine less expensive and extreme solutions into normal switches and then out across fibre.
What a crazy thing to be doing, the mad situations companies get themselves into when they should just have networked cameras and VPNs or at the very least distributed ingress machines!
Perhaps some kind of "SD-card multiplexer" arduino project, where you have 50 SD breakout boards all mounted in a tall stack, each with an LED, and maybe a "reset" button if it doesn't detect ejections. Some circuitry in the middle would set each LED status color, and switch which of the 50 is currently connected to a single set of access pins.
It still involves annoying work by humans, but it would be much more straightforward: See a bay that is showing the "idle" color, remove any finished card and put it in the finished-box, grab a card from the to-do box and put it in, then press the button to signal a new card is waiting.
If that process took 6 seconds, 1000 cards would mean 100 minutes of tedious work, but you can spread it over multiple people or (since the card-read takes time) do it in short bursts interspersed with other activities.
In most cases I've seen scales similar to this - body cams in security, scanners at postal services and such, the physical part is offloaded to the individuals working with the thing: at the end of the day, you put your thing into a charger, or into a box and connect it up or something like that.
So from there, my thought is indeed: Why shouldn't we get 1000 micro sd card readers (or multi readers), attach those to a bunch of PIs streaming the cards to a central server, have people put their SD card in there at the end of a day? After that, you can kick off the reads in a batch, re-seat the cards that aren't set correctly and that's it.
One could reduce hardware cost by having some LED turn on or off if a card in a reader can be swapped, but with a thousand people doing this, complicated instructions tend to be a bad thing. Unless the transfer is fast enough to wait for it.
But it's always fun how complicated some of these physical problems become if you scale them up. Like, consider how many storm drains are out there in a city. If each needs to be touched once every 3 years... suddenly you've created a dozen jobs.
Such a nerd bait request. I’m like “wait, how long between downloads of cards do you need? How many people will be placing these cards in? How will you know when one is downloaded??”
Only reading the comments did I think “Wait, who needs this and why?” I like the Mr. Beast angle - it’s fun to think about if nothing else.
One use case is to mount 360 cams on a bunch of motorcycles (fleet) and do a google streetview equivalent. You build a city level streetview pretty quickly.
I think at that point you'd just need to do 1 pc every 200 readers and pull the videos to a local server for processing. There's no magic here, just work.
I'd go in a completely different direction from this.
I'm assuming the SD cards come from a fleet of dashcams or similar, and that the driver is responsible for turning in their card at the end of a run or whatever.
I'd deploy a fleet of tiny WiFi card readers. Just an ESP32 and a card slot. Each individual unit is not fast, but if you have a few dozen units running at once you could easily saturate the dedicated ingest WiFi network at each hub location. The readers are dirt cheap and the only supporting infrastructure required is WiFi and a bunch of 5v power adapters.
You'd have a rack of these guys next to the key locker or timeclock. Pick up your keys and a blank card, drop off your keys and card at the end of the shift. Could even get extra fancy and use LEDs to indicate which card is yours for the day, or flip on an error light when the card is worn out.
You probably don't need each video to transfer as fast as possible, more likely you just want maximum overall throughput. So just build a bunch of very cheap and slow nodes. On aggregate you should get decent performance.
I was not expecting that thread to go in that direction. At first my nerd brain kicked in and I started doing the PCIe napkin math - but then I got to the post asking "why?" and found myself asking the same question.
I am also a bit perplexed on why they'd need to ingest 1,000 micro-SD cards at once. If they are such a large org, why not investigate alternative solutions?
When only reading the title, my first assumption was that it's a micro-SD card hardware validation test engineer trying to outsource their test station design.
I saw that Beast Games used 1100 simultaneous cameras in the opening days to record every contestant, so I could see something wild like that, where you have 1000 GoPros out in the field all day.
> I am also a bit perplexed on why they'd need to ingest 1,000 micro-SD cards at once. If they are such a large org, why not investigate alternative solutions?
Action cameras use microSD cards as their main storage medium. You could connect them via WiFi on some models, but that would be painfully slow compared to dumping the SD cards directly.
One of the comments in the linked thread also suggested a fleet of dash cams which also sounds plausible, I could totally see some manager saying "we need to archive all the dash cam video for legal liability reasons!" and now someone is stuck with this job.
Readit News
Seems like more of a scale out than a scale up problem, with a view on the whole operation from recording footage down to final archive to tackle the real bottleneck.
Its possible from a PCI-E bandwidth point of view but its going to require some seriously specialist USB interfaces. I am tempted by the same solution others suggest, smaller amounts per machine less expensive and extreme solutions into normal switches and then out across fibre.
What a crazy thing to be doing, the mad situations companies get themselves into when they should just have networked cameras and VPNs or at the very least distributed ingress machines!
It still involves annoying work by humans, but it would be much more straightforward: See a bay that is showing the "idle" color, remove any finished card and put it in the finished-box, grab a card from the to-do box and put it in, then press the button to signal a new card is waiting.
If that process took 6 seconds, 1000 cards would mean 100 minutes of tedious work, but you can spread it over multiple people or (since the card-read takes time) do it in short bursts interspersed with other activities.
So from there, my thought is indeed: Why shouldn't we get 1000 micro sd card readers (or multi readers), attach those to a bunch of PIs streaming the cards to a central server, have people put their SD card in there at the end of a day? After that, you can kick off the reads in a batch, re-seat the cards that aren't set correctly and that's it.
One could reduce hardware cost by having some LED turn on or off if a card in a reader can be swapped, but with a thousand people doing this, complicated instructions tend to be a bad thing. Unless the transfer is fast enough to wait for it.
But it's always fun how complicated some of these physical problems become if you scale them up. Like, consider how many storm drains are out there in a city. If each needs to be touched once every 3 years... suddenly you've created a dozen jobs.
Deleted Comment
Only reading the comments did I think “Wait, who needs this and why?” I like the Mr. Beast angle - it’s fun to think about if nothing else.
I think at that point you'd just need to do 1 pc every 200 readers and pull the videos to a local server for processing. There's no magic here, just work.
I'm assuming the SD cards come from a fleet of dashcams or similar, and that the driver is responsible for turning in their card at the end of a run or whatever.
I'd deploy a fleet of tiny WiFi card readers. Just an ESP32 and a card slot. Each individual unit is not fast, but if you have a few dozen units running at once you could easily saturate the dedicated ingest WiFi network at each hub location. The readers are dirt cheap and the only supporting infrastructure required is WiFi and a bunch of 5v power adapters.
You'd have a rack of these guys next to the key locker or timeclock. Pick up your keys and a blank card, drop off your keys and card at the end of the shift. Could even get extra fancy and use LEDs to indicate which card is yours for the day, or flip on an error light when the card is worn out.
You probably don't need each video to transfer as fast as possible, more likely you just want maximum overall throughput. So just build a bunch of very cheap and slow nodes. On aggregate you should get decent performance.
https://en.wikipedia.org/wiki/Eye-Fi
I am also a bit perplexed on why they'd need to ingest 1,000 micro-SD cards at once. If they are such a large org, why not investigate alternative solutions?
Action cameras use microSD cards as their main storage medium. You could connect them via WiFi on some models, but that would be painfully slow compared to dumping the SD cards directly.