Live data from Hacker News

This Blog is now hosted on a GPS/LTE modem

nns.ee

201–210 of 212 posts

Re: This Blog is now hosted on a GPS/LTE modem

#201
post #80

So a modem on a pine phone can survive the HN hug of death (and the number one post no less)? Am I missing something here? Because there's no way I believe that!

HN traffic isn't all that demanding[1]. Websites falling under the load are a testament to the poor quality of the software stack used to host them. [1]: https://xyrillian.de/thoughts/posts/latency-matters-aftermat... >

One of my favorite bike shedding topics.

My mind is blown that anyone writes software for stacks that max out at few hundred requests per second.

Everything I've seen comparing "high level" languages says programmers work around the same efficiency whatever the language. So why isn't everything done in Go, C#, and Java where 100,000 requests/second is trivial?

Even if you don't have much load, isn't the possibiliy of a cat DDoS'ing you by sleeping on someone's F5 key at least slightly concerning?

I swear half these companies that claim their site is "being DDoS'ed!" it's just somebody just running HTTrack to archive an article they like.

Re: This Blog is now hosted on a GPS/LTE modem

#202
post #92
post #83

Earlier quoted context omitted.

A static site is really easy to host and HN's hug of death isn't actually that intense; the site itself only gets like six million views a day, a fraction of those click on every link, and no syndicated page has much reach.

People badly overestimate what it takes to serve a website nowadays. I don't know whether it's just because we're all used to 10+ second website loads as our browser groans under the weight of all the trackers, or if we all have too much experience with web pages that run multiple 10ms+ unoptimized queries against databases that pull way too much data back, etc. and so we all think web pages are some sort of challeng…

We have a Rails app that struggles at 50 req/sec. It has an embedded Angular app whose back end easy handles 10,000 .

One of the reasons were trying to migrate is that Rails servers cost us almost an engineer salary, where our other backend is ~200/month

Re: This Blog is now hosted on a GPS/LTE modem

#203
post #74

Earlier quoted context omitted.

A Pentium II was more than enough to decode MP3's in parallel.

What's interesting is, I used to have this old 486 laptop. With Linux on it, I could run XMMS playing my MP3s and do other things and you could barely tell it was there. In Windows, playing an MP3 file with WinAmp took up so much CPU, you were stuck running only WinAmp.

My off-brand 486dx4 120mhz was the first cpu I had that could play mp3 without skipping in Winamp.

Re: This Blog is now hosted on a GPS/LTE modem

#204
post #194
post #126

> While developing software on the PinePhone, I came across this peculiar message in dmesg: Beautiful seeing this on top of HN. :) That message is from me. Nice to see someone using the access for something cool. One of the reasons I decided to add it there was to give some visibility to this "feature" of EG-25G FW to people interested enough to look at dmesg.

Can you think of a more efficient protocol between the modem and main cpu then the AT-based ril with constant status checks? Is there anyway to make the modem more efficient, since its cpu is just consuming power and not adding much to the functionality of the phone? Can it be a smarter gateway that only triggers a main cpu wakeup when there's something important to notify the user of, like an incoming call or sms?

> Can it be a smarter gateway that only triggers a main cpu wakeup when there's something important to notify the user of, like an incoming call or sms?

That's how it works.

> Is there anyway to make the modem more efficient, since its cpu is just consuming power and not adding much to the functionality of the phone?

Modem is sleeping most of the time. (at least with my driver) It's much more efficient than the main A64 SoC. Like 10mW sleep vs 100mW sleep.

> Can you think of a more efficient protocol between the modem and main cpu then the AT-based ril with constant status checks?

ModemManager/ofono are not using AT interface, I think. They are using QMI.

Anyway, you don't need constant status checks even with AT interface. You just enable status indications you want to receive and that's what you'll get without polling.

And you can setup wakeup on call/sms too.

Re: This Blog is now hosted on a GPS/LTE modem

#205
post #141

Earlier quoted context omitted.

I’m not aware of any desktop CPUs (now or before) that had hardware MP3 decoding. Do you mind enlightening me?

In my interpretation, "dedicated hardware for things like MP3s" doesn't necessarily mean "hardware MP3 decoding." Intel MMX (multimedia extensions) introduced dedicated hardware to accelerate things like MP3 decoding.

MMX is integer math only. MP3s require floating point unless you hand code fixed point version of the decoder. In real life just recompiling with MMX support gives marginal difference https://www.cs.cmu.edu/~barbic/cs-740/mmx_project.html

MMX was pretty useless (reuses FPU registers = cant run FPU code in parallel) marketing gimmick from Intel designed to tick boxes, promoted with fake "designed for MMX" campaign https://www.mobygames.com/images/covers/l/51358-pod-windows-... spoilers: MMX enables one sound filter in the whole game, no speed difference. Ubisoft just made some extra cash by printing this on the box.

MMX was one of Intel's many Native Signal Processing (NSP) initiatives. They had plenty of ideas for making PCs dependent on Intel hardware, something Nvidia is really good at these days (physx, cuda, hairworks, gameworks). Thankfully Microsoft was quick to kill their other fancy plans https://www.theregister.co.uk/1998/11/11/microsoft_said_drop... Microsoft did the same thing to Creative with Vista killing DirectAudio, out of fear that one company was gripping positional audio monopoly on their platform.

Re: This Blog is now hosted on a GPS/LTE modem

#206
post #205
post #141

Earlier quoted context omitted.

In my interpretation, "dedicated hardware for things like MP3s" doesn't necessarily mean "hardware MP3 decoding." Intel MMX (multimedia extensions) introduced dedicated hardware to accelerate things like MP3 decoding.

MMX is integer math only. MP3s require floating point unless you hand code fixed point version of the decoder. In real life just recompiling with MMX support gives marginal difference https://www.cs.cmu.edu/~barbic/cs-740/mmx_project.html MMX was pretty useless (reuses FPU registers = cant run FPU code in parallel) marketing gimmick from Intel designed to tick boxes, promoted with fake "designed for MMX" campaign htt…

> MP3s require floating point unless you hand code fixed point version of the decoder.

This is a weird statement. "MP3 encode/decode requires floating point unless you implement in fixed point such that you don't need floating point." It's perfectly possible to write fixed point MP3 decoders.

Sure, MMX wasn't that great, but it was Intel's first SIMD extension, was definitely intended to help with "things like MP3 decoding," and was followed by a ton of improved extensions with similar goals.

Re: This Blog is now hosted on a GPS/LTE modem

#207
post #70

Earlier quoted context omitted.

For a while I've really liked the thought of small little cheap hardened devices that could be surreptitiously dropped to act like wifi extenders as a "guerilla mesh". Of course there'd probably need to be some thought put into making them safe and look harmless enough not to trigger any kind of severe response if found. But imagine taking a bag around town and dropping "disposable" devices with low enough power use…

Seems quite a lot of us have had the same idea. I keep thinking the Meshtastic network is heading in that direction, maybe Disaster.Radio might have some features, and generally there seem to be a ton of projects that contain some but not all of the pieces you'd want. I'm down to build the hardware, I just haven't a clue on the software side of things.

I think it really depends on use-case. A lot of mesh projects get stuck on really large scale, but if your goal is just to be able to build networks where the number of hops between any given node and one with uplinks is realtively limited - so more "range extender" than a replacement for normal ISPs, the software is an "easy" problem.

If you can come up with a hardware package that is resilient enough, then "all" you need on the software side is a small Linux install and a bootloader setup that will try either of at least two boot partitions. You'll want a watchdog to force a reboot to a know good install if it doesn't respond after a while. Routing is the tricky bit, but as mentioned if the number of nodes is small enough a small routing daemon to periodically exchange routing information and discovery performance fluctuations is not a big deal.

Re: This Blog is now hosted on a GPS/LTE modem

#208
post #48

Now it just needs to charge / run from solar and it can be dropped anywhere with signal. I wonder what sort of wattage this thing draws.

Author here! I'll try to figure the power draw out some time in the future. Currently, the phone's just always plugged in and being powered over USB.

The Pinephone is weird in that you'll need to either have or emulate a battery to have the modem turn on.

Re: This Blog is now hosted on a GPS/LTE modem

#209
post #72

Does the modem have access to GPS? If so, it would be interesting to implement theft protection or things alike. Do binaries built with "GOARCH=ARM ARM=7 GOOS=linux go build" work?

Author here! Seems to work fine: https://arse.ee/4uQ6R5Ck.png edit: And yes, the modem has access to the GPS data, which is passed from the modem to the main OS.

[deleted]

Re: This Blog is now hosted on a GPS/LTE modem

#210
post #45

Earlier quoted context omitted.

I splurged in high school for a 4x cdrw drive by Sony. I had to kill all extra processes or else the machine (maybe the fault of the HDD) couldn't keep the buffer filled and the write operation would fail. I made a lot of coasters, but that was my favorite time with computers (1999 or so).

Oh yes and then right around the time 8x became possible (but cd-r only, cd-rw was still 4x initially I think) someone invented a way to continue after a buffer underrun instead of throwing away the disc. I think that really sold the faster burners because otherwise they were kind of useless for the increased risk of having a buffer underrun skmewhe in the process.

Burn-proof! (a quick search says there were other names for this, but it was all similar technology)
Post reply on HN