[HN Gopher] Nvidia researchers setup an open source sensor netwo...
___________________________________________________________________
Nvidia researchers setup an open source sensor network on Antartica
Author : wienke
Score : 66 points
Date : 2023-03-10 12:11 UTC (10 hours ago)
(HTM) web link (www.thethingsnetwork.org)
(TXT) w3m dump (www.thethingsnetwork.org)
| deusum wrote:
| NVIDIA would rather bring open source to Antarctica than Linux.
| abudabi123 wrote:
| http://www.emperorlinux.com/search/?q=nvidia
|
| EmperorLinux Inc lists Dells, Thinkpads with Nvidia graphics
| cards.
| godelski wrote:
| And Pop's main appeal is that Nvidia graphics cards (nearly)
| "just work". But that's not what the parent is getting at.
| KeplerBoy wrote:
| Apparently not all penguins are equal.
| detrites wrote:
| *Antarctica
| jmclnx wrote:
| Very nice they are doing that, but you know what would be a real
| altruism move ? Open up the source for Nvidia Chips so projects
| like OpenBSD and the other BSDs can run on hardware from Nvidia.
| freedomben wrote:
| It seem self-defeating that they don't. If nvidia fully opened
| up their driver, they would de-facto own the GPU market (at
| least for ML, but probably gaming as well). Conversely if AMD
| could get support into most of the ML libs, they could start
| cleaning up.
| godelski wrote:
| > Conversely if AMD could get support into most of the ML
| libs, they could start cleaning up.
|
| This is happening, albeit slowly, fwiw. Pytorch has ROCm
| support, but not great. AMD did win the exascale machine
| contracts and have custom hardware in the machines that are
| built. It does look like they've been using those contracts
| to invest more into computational sciences/ML. I can only
| hope that they continue at the pace they have in the consumer
| market. Competition between AMD and Nvidia (and hopefully
| Intel -- a pipe dream) can only be beneficial to us in the ML
| community.
| DigiDigiorno wrote:
| They already own the data center gpu market, what are you
| taking about?
|
| Last I checked they already had monopoly evoking shares of
| that market. Like 80+ or 90+ percent
| smoldesu wrote:
| There's a better chance of hell freezing over, but it would
| certainly benefit users. From a economic standpoint though,
| it's entirely unsurprising why they do this. CUDA _owns_ ,
| and in the AI age it's hard to beat the parallelism Nvidia
| offers. If Nvidia cedes their acceleration advantage, they're
| leaving themselves open for attack. DirectX is a funny
| example of this, still being closed-source despite a reverse-
| engineered version existing with often better performance.
|
| It would be nice if everyone writing UNIX-like drivers gave
| away their source code, but then the books wouldn't balance.
| It's a tale that's half a century old now.
| deusum wrote:
| NVIDIA on FreeBSD is better than ever, but Wayland is broken,
| still, if my failed attempts are a fair measure.
| dotnet00 wrote:
| https://developer.nvidia.com/blog/nvidia-releases-open-sourc...
|
| Coming up on a year since they've had source code available.
| jmclnx wrote:
| >NVIDIA is now publishing Linux GPU kernel modules as open
| source with dual GPL/MIT license, starting with the R515
|
| Seems only for a specific chip rev, does nothing for older
| revs.
|
| Also since it is a module, I presume just for Linux, does
| nothing for OpenBSD (especially) and probably do nothing for
| NetBSD. FYI, OpenBSD does not support kernel modules like
| Linux does.
| dotnet00 wrote:
| It's open source, which was the point being referenced by
| the post I replied to. The BSDs can use the code to guide
| their own implementations, as they have done for various
| other drivers.
|
| Also, it supports everything Turing onwards, which, while
| not ideal, does cover all the hardware they've made in the
| past 4.5 years.
| junon wrote:
| For closed source blob adapters, which I suppose is
| _something_. It will allow kernel developers to integrate
| their drivers, without a really having the sources to the
| driver itself. You still get a closed source blob.
| dotnet00 wrote:
| Even AMD has closed source blobs as firmware though?
| junon wrote:
| Not sure they have open source adapters though. Maybe
| they do. But the big release from Nvidia last year was
| that you can see and use the code that calls into their
| blobs.
| brink wrote:
| Is this Nvidia's repentance for the crypto mining and price
| gouging?
| thewopr wrote:
| Having been in technology, antarctic research, and remote
| monitoring of environmental systems down there, my take: don't
| read into this this too much.
|
| This is mostly a PR piece, probably pushed by the university or
| non-profit researchers involved. They are trying to use some sort
| of partnership with NVIDIA (as loose as that partnership might
| be) to draw attention and show they are having "Broader Impacts"
| for their impact statement.
|
| Most eco research is based on historical comparisons of
| months/years/decades of data So the use of real-time/streaming
| data down there is pretty limited. You can just as easily shove
| the data into storage and have a researcher pick it up next time
| they go down (often *much* easier as you don't have to worry
| about powering comms systems).
|
| Climate/weather data may be different, if only because some of
| the data might go into current/real-time weather models. But even
| there, it's probably a stretch (I know of very little work being
| done with anything near real-time as far as data goes down
| there).
| earthscienceman wrote:
| Hey @thewopr.
|
| I'm actually working on real-time measurement transmission of
| the climate parameters, though at the other pole in the Arctic.
| I always imagined people working on such things were here on
| HN.
|
| This article is absolutely a PR/puff piece. This type of
| transmission isn't novel, unique, or "AIoT"... using that
| acronym for this is beyond hilarious, I'd challenge anyone on
| the project to describe how AI is in any way relevant to the
| project beyond NVIDIA PR blurbs. I've looked through the
| research and the only thing I've found is a nebulous "we will
| analyze the data with AI at some point". But! People have been
| doing these sorts of measurements and transmitting them from
| these sorts of places for... ever... basically. Also entirely
| based on open source. The autonomous station I(we)'ve designed
| uses a custom Linux box/SoC for low power data processing and
| amalgamation and the results are transmitted in realtime back
| here to the USA to be ingested by models, without a single chip
| designed by NVIDIA. From places much more remote than a few kms
| from a base in Antarctica, we had a station running in the
| Arctic ice pack during winter. Not to add more criticism, but I
| also always love how these puff pieces don't actually link to
| the research of the people who put in the work on the
| project[1].
|
| As an aside, AI could actually very relevant/important for
| these types of measurements. One idea I'm working to spin up:
|
| Vertical profile retrievals of important atmospheric
| measurements (cloud properties, and more) are extremely power
| intensive and nearly impossible to do autonomously via
| lidar/radar. However, there are many ways one could imagine
| designing a low power implementation of those retrievals using
| a combination of different sensors and a cleverly trained
| algorithm to get at the parameters of interest.
|
| Anyway, link/tell me about some of your remote monitoring. I'm
| pretty disconnected from the south side of these things.
|
| [1] https://www.uow.edu.au/media/2023/world-first-mosscam-and-
| sm...
| thewopr wrote:
| My experiences were with the McMurdo Dry Valleys LTER program
| [1]. They have (things may have changed) a number of sites
| sending telemetry back to the states via the Iridium network.
| Nothing too fancy. It worked. Biggest challenge really was
| that iridium was slow and relatively high power (and somewhat
| flaky deep in the valley where we were). I also had some
| involvement with the NTL LTER program[4], but that type of
| work has even easier telemetry constraints (these days, just
| use a cell modem).
|
| I totally agree with you on the "using a combination of
| different sensors and a cleverly trained algorithm to get at
| the parameters of interest". This is something not too far
| from, in a way, how many sensors work already. They are
| *proxies* of the actual thing being measured. From my world,
| the s-can DOC sensor was always a good example, using in-situ
| spectroscopy to estimate DOC concentration.
|
| Crux of the challenge is "what is the parameter of interest"
| and "can you come up with a way to estimate it with something
| easily measured?
|
| Because this is HN, I'll say there is another interesting
| route possible. If you can change the economics of a
| situation and decrease the cost of a basic sensor, then you
| can often increase the volume of applicable uses. I was
| tangentially involved with the development of the miniDOT
| [3], which ended up being one of the first "inexpensive" (as
| in less than $5k) dissolved oxygen sensor. It really changed
| how people used them and increased the amount of DO sensing
| by probably an order of magnitude.
|
| [1]: https://mcm.lternet.edu/ [2]:
| https://www.s-can.at/en/product/carbolyser-v3/ [3]:
| https://www.pme.com/new-products/minidot-usb-oxygen-logger
| [4]: https://lter.limnology.wisc.edu/
| [deleted]
| whitemary wrote:
| > _SAEF (Securing Antarctica's Environmental Feature)_
|
| What exactly is an "Environmental Feature?" I would think
| Antarctica has multiple.
| justinpowers wrote:
| "Feature" can mean "physical beauty" as well as simply
| "appearance" or "form", though all such are considered obsolete
| usages.
| nico wrote:
| It's a typo, it should be "future" instead of "feature". Good
| catch.
|
| SAEFs website: https://arcsaef.com/
| junon wrote:
| "Securing Antarctica's Future [and] Environment" aka SAFE
| ("and" being optional) would have been a bunch clearer, imo.
___________________________________________________________________
(page generated 2023-03-10 23:01 UTC)