Hacker News new | comments | show | ask | jobs | submit | meatmanek's comments login

Another interesting regulatory hurdle when using FRS is that you are only allowed to transmit data once per 30 seconds, and packets can only be 1 second long. [1, p.11]

1. https://www.gpo.gov/fdsys/pkg/CFR-2009-title47-vol5/pdf/CFR-...

-----


This device almost certainly doesn't do mesh networking, as the FCC rules for FRS disallow it:

"FRS units are prohibited from transmitting data in store-and-forward packet operation mode."[1, p.11]

1. https://www.gpo.gov/fdsys/pkg/CFR-2009-title47-vol5/pdf/CFR-...

-----


FFC :) this is a European product, and since all of the "software" side of things is in your phone this can be available in other regions, and in the worse case scenario you can hack it in yourself. Any radio equipment which is compatible with FRS/GMRS will work with PMR446/KDR444/FREENET and the likes which legally "support" mesh networking and repeaters.

FFC regulations are pretty much bull in regards to many handheld radio frequencies and pretty much force limitations on communication equipment which doesn't require a fee. If you pay for GMRS license you all of a sudden can have repeaters etc. which you can't with FRS even tho they share a frequency range.

-----


The upgraded clock would be really nice; I have a standard RTL-SDR without that, and the clock can drift a lot with temperature: it'll start up a few dozen PPM off, and shift another few dozen when it warms up. Depending on frequency, that ends up being many kilohertz, which is really annoying if you're shifting/filtering/downsampling, as your target signal can drift outside of your filter window.

A constant ppm error is easy to compensate for; less so when it changes.

-----


Since the HackRF is open source, there's a group that makes a lower-cost clone called the HackRF Blue: http://shop.hackrfblue.com/. Their model is $215, and they have some units that have some minor issues (can transmit jut fine) for $150.

I haven't used the HackRF Blue, so I can't compare it to the HackRF One. There are a few comparisons floating around the internet.

-----


That is getting closer to my price range. I saw something called the SDRX01B and was wondering if anyone heard of it or was able to comment on its performance.

-----


In the context of queueing theory, there are many service disciplines[1] that can be used, which are not necessarily FIFO.

Depending on what you're optimizing for, and the behaviors of your system (arrival process, task size distribution, number of servers, preemption overhead, etc.), it can be much better to process things in an order other than arrival order.

In particular, FIFO can mean small tasks end up waiting a long time behind large tasks. (Imagine going into a shop that sells sandwiches and pre-packaged salads; you want a salad, and there are 5 people waiting for sandwiches. Should you have to wait until the clerk makes 5 sandwiches before you can get your salad and leave?)

1. https://en.wikipedia.org/wiki/Queueing_theory#Service_discip...

-----


Conceptually they are very similar; as you mention, Kalman is generally online, and trying to estimate the current state, whereas Viterbi can factor 'future' information into its estimate as well.

Another big difference is that Viterbi works on a discrete state space (DNA base pairs, bits in a convolutional code, etc), while the Kalman filter works in a continuous space (e.g. position).

https://en.wikipedia.org/wiki/Recursive_Bayesian_estimation

-----


Time zones are offsets in UTC, which change over time (DST, political changes, etc).

UTC is an offset from TAI, which changes over time (leap seconds).

The time zone files already keep track of historical changes[1].

Conceptually, they're pretty similar; the only difference is that leap seconds have a special clock value (23:59:60 instead of showing you 23:59:59 twice).

  1. https://en.wikipedia.org/wiki/Tz_database#Example_zone_and_rule_lines

-----


I would imagine that some hardware RTCs would not support the :60 leap second value. In fact I cannot recall a single RTC that I have dealt with, that understands leap seconds.

-----


DNS is surprisingly tricky as a service discovery tool. A lot of clients are poorly behaved, and will cache values for too long (or forever). It'd also be another dependency critical for site functionality.

-----


We're using this for internal load balancing, so we control both ends of the connection. If this started misbehaving, we'd see timeouts, dropped connections, or errors, which would show up in logs.

-----


I see. Any reason not to patch HA to reload config?

-----


Patching HAProxy to reload config is really hard. There have been ideas, patches, and discussions on the HAProxy mailing list for a few years now trying to get zero downtime reloads natively supported in HAProxy, but the reality is that it just is not as easy as it might seem.

For more details check out the mailing list: http://marc.info/?l=haproxy

-----


Not sure; I'm not the author of the post (a colleague), but I'd guess it's a fairly complicated patch. I know the author has made some changes to the HAProxy codebase[1], so I'm sure he considered it.

[1] http://comments.gmane.org/gmane.comp.web.haproxy/21025

-----


The HAProxies in question are dealing with at least one port per service, with dozens of services. If you were to remap ports, you'd end up with a lot of port mapping rules.

We also considered using different loopback IPs per HAProxy, so ports could stay consistent, but decided against it:

- We have other things (like scribe) listening on the same loopback IP address, so we'd either have to move those to different IPs or exclude them from iptables rules.

- We thought it could be confusing/misleading to see HAProxy listening on one IP/port, but connections being made to a different IP/port.

-----

More

Applications are open for YC Summer 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: