SI Units for Request Rate | Hacker News Reader

SI Units for Request Rate

two-wrongs.com

111 pointsDaveFlater93 comments

As a controls engineer, I strongly discourage using hertz as a measure of events. It's an abuse of notation.

In control theory and signal processing, we refer to the frequencies that make up a signal in hertz. The maximum frequency a control law can track is called its bandwidth, which is in hertz. Frequencies a filter is passing or stopping are in hertz.

Computers being digital, we have to run that control law or signal processing algorithm at some rate. That rate also gets referred to in hertz, a lot, and it is a cause of no end of confusion, because the running rate of the algorithm is very much not the same as the bandwidth or filter bandpass. The Nyquist criterion says that the algorithm has to run at least twice as fast as the frequency of interest, but practice more like ten times faster. SO when we refer to a control law as "500 Hz" or whatever, I have to explain which sense I mean every damn time.

Don't do it. Events happen at events per second. Hertz refers to sine waves, and NOTHING ELSE.

Given that any waveform can be produced out of "sine waves", we can call those events call composite sine, falling back to Hertz.

The said request most likely have originated as some sines as well, think of your phone for instance.

Seriously, though, using Hertz would be confusing to a high degree.

The sine wave thing is technically true, but if you try it in practice, as I did extensively in a college acoustics course, you’ll find that making even a decent approximation of a square or a saw wave requires sine waves at many multiples of the upper threshold of human hearing. You need those insanely high overtones to produce sharp “corners” in the wave form.

Of course, making square wave oscillators is very difficult at any frequency - there is always some rounding around the 'corners'

I propose that we shall use bananas as the unit for request rate (one banana = one request per second); it's obviously appropriate as:

1. Bananas are the de-facto standard for measuring the relative size of things posted online. Request rate is a relative quantity, since requests can have varying payload sizes, transfer rates, or server-side resource usage, even within the context of a single service (unlike decay rate, which to my understanding is usually considered within the context of a uniform sample of radioactive material).

2. The web has been steadily turning more toxic over the past several decades; you could call it a form of decay, but all radioactive decay eventually produces stable elements; no such trend has been observed with the web.

3. While bananas can trip up radiation detectors, they are much more likely to just go bad - same with web requests on your server; if you can't process them in a timely manner, better just throw them away.

I think 1 banana should be 16 requests per second.

This is because a banana has around 12 - 18 Becquerels of radiation. 16 is a nice power of 2 number.

Americans will use any unit of measure but SI units… /s

SI derived units are still SI.

The foot is defined as exactly 0.3048 meters, does that mean it’s an SI unit?

No, while the Mendenhall order 1893 defined all US customary units off of the Metric system, in SI "Derived units" are defined as products of powers of the base units.

If you look at section 2.3.4 in the link below you will notice that there are no scalars in those derived units.

They will all have the form:

x^n * y^m * z^o

Also note how they define a 'degree Celsius' which is equivalent to a degree K, but then invoke a T_0 to include it to avoid breaking the above rule.

https://www.bipm.org/documents/20126/41483022/SI-Brochure-9-...

The sievert has a hidden numerical factor.

Tell them that the only patriotic measurement unit is a gun, specifically the American M16.

Since there are multiple versions, we use the latest and greatest: the M16A4. It is 39.97 inches long.

That‘s what American distances and lengths are measured in! I‘m 1.9 M16s tall!

After a while we swap M16 for meters, since the M16 is not only 39.97in, but also -quelle surprise!- exactly one meter long.

1 meter is 39.37”, as is one M16A3. The other A’s are different.

The M16 is capable of about 900 rounds per minute, which is about 15 rounds per second, so we can call the Si "banana" the "M16" in America and have it be the same measure of requests per second.

That’s a good switcharoo right there… Just as remark, it’s 39.37in :)

Bananas are a measure of complexity dating back to the Jargon File. E.g., you could easily persuade a trained monkey to fix a one-banana problem.

The "two wrongs" hostname is apt. Hertz is for periodic phenomena; becquerel is for radioactive decay. The SI brochure discourages the use of counting units such as 'request'. The number of requests is regarded as just a number, or at best a quantity that is referred to the unit one. The applicable SI unit therefore is just the reciprocal second, s^(-1).

In practice, counting units are used everywhere (e.g., in MB/s, the byte is a counting unit), but I am relaying what the SI brochure actually says on this question.

Ref: https://www.bipm.org/en/publications/si-brochure/

No way the same org that named the mole a unit discourages the use of counting units.

I think what we are really after is yoctomole Becquerels.

Interestingly, a "conservation of matter" law can exist independently of atoms. I.e. it is mathematically consistent to create a universe in which a "mole" is necessary, but matter is not discrete. Therefore "mole" can be considered a bit more fundamental (in any universe). I find it reasonable to stick to using a "mole" unit on that basis, although I would not be dying on this hill.

The yoctomole is a wonderful unit, for example when you want just slightly more than half a cup of coffee!

But the mole as a "counting unit" is different from OP's idea of assigning units to things like network requests. The mole is just a shorthand for a number, like a dozen or a score. We don't have different kind of "moles" for, say, carbon atoms and water molecules. Or coffee.

It can, in my experience, be very useful to introduce a unit for ‘requests’, as well as one for ‘CPUs’.

It lets us produce dimensionally valid formulae for relating request rates (in requests per second) to compute requirements (in CPU seconds per request), data transfer (in bytes per request), and bandwidth (in bytes per second).

I kind of wish software engineering’s computer science underpinnings offered a few more of the kind of notational underpinnings that physics offers mechanical or electronic engineers.

Why don’t we have a standard set of letters for representing data sizes, requests, compute units, etc; and a set of widely known formulae as familiar to every programmer as V=IR is to an electrical engineer?

The only standard symbol computer science has given us (or maybe more accurately that we have taken up) is n, as in O(n), for collection sizes.

I wonder if we can do better?

ISO 80000 Part 13 gives some symbols within the scope of communication technology (its scope is more narrow than its title would suggest). The standard itself is copyrighted but the quantity symbols are listed on Wikipedia, https://en.wikipedia.org/wiki/ISO/IEC_80000#Part_13:_Informa...

That is fascinating. Are there any examples of ‘fundamental laws’ expressed in these terms?

Being careful to distinguish 'fundamental laws' from just 'quantities that we defined', information theory and queueing theory have some good examples of proven laws.

Personally I like variable names better than symbols anyway.

A cpu second means very little without more context. CPU performance depends a lot on things like cache, branch prediction, out of order execution. Each second represents something fairly distinct from the others.

It’s not ambiguous when the Amazon bill arrives.

In reference to (per duration) values "requests per second" is ambiguous, what is a request?

Instructions per seconds exists but is only useful for comparing tasks on the same hardware and architecture. We saw the abuse of MIPS for comparing machines in the past just as we see it with FLOPS in GPUs today.

MIPS benchmarks like whetstone differ even on the same CPU depend on the language used, compiler used, and the options at compile time. TPC, SPEC and other synthetic benchmarks just succumbed to game theory and usually don't apply to real world loads.

The field you want to look into is "Queuing Theory"

If you are lucky enough that you can assume your system is Markovian you get simple formula like:

mean service time == 1/(mean service rate)

To show just how old it is here is a good paper about M/M/1 queues from 1958 that is still useful today.

https://msp.org/pjm/1958/8-1/pjm-v8-n1-p08-s.pdf

In reference to V=IR, ‘current’ is ambiguous. Current over what?

Depends what system you’re analysing. But the dimensional validity of that statement is applicable in numerous circumstances.

1 Amp == the flow of 1/(1.602176634 × 10^−19) elementary charges per second.

The medium used for flow isn't important for that calculation at all. Just as it would be for liters per second.

> relating request rates (in requests per second) to compute requirements (in CPU seconds per request)

The exist SI unit which specifically applies to queueing problems is the erlang, a unit originally used in telecommunications. Applied to computers, it would translate to CPU use per request.

https://en.wikipedia.org/wiki/Erlang_(unit)

It's considered to be a dimensionless unit (according to wiki), implying that CPUs and requests are also dimensionless.

There are exactly 7 SI units and exactly 22 special names for coherent derived units - Erlang is not one of them.

> Hertz is for periodic phenomena

> The applicable SI unit therefore is just the reciprocal second, s^(-1).

That's the hertz.

While Hertz are 1/s, there is implications between using frequencies in Hertz and rates in 1/s. Units are not just something to mechanically check, but also for communication with other humans. So connotations matter in addition to denotation.

Hertz, becquerel, et al. are algebraically defined as s^(-1) yet intended to be used for different kinds of quantities. The SI brochure also allows replacing radian by 1, which brings angular velocity into the fight. Further reading: https://doi.org/10.1088/0026-1394/52/1/40

And that brings up the difference between frequency and angular frequency.

When you use hertz meaning ‘cycles per second’ it’s far more natural to associate it with an angular velocity of 2pi radians per second - which throws a bit of a spanner in the dimensionless works, and makes it feel like using 1/2pi as a radian makes more sense.

Score another point for tau I guess.

Would you say that one watt is equal to one joule-hertz?

In exactly the same way that a torque measured in newton-meters can as easily be measured in joules.

Are you suggesting it is sensible to measure airplane crashes in hertz?

It's not algebraically incorrect, but it contains something dangerously wrong connotations about what kind of data it is.

https://xkcd.com/687/

SI has several cursed units. My favourite of them is the kWh.

A watt is just a joule per second. Making 1 kWh === 3.6 MJ.

Second that! (No pun intended.) Dunno how many times I have had to explain to people that the kWh is an amount, not a rate.

Seems like that’d be the default assumption - I pay zero point one bucks per kWh, of course it’s an amount. What’s more interesting is kW/h, it feels like a rate but it’s more like an acceleration.

how does kW/h even work? because W = J/s, making kW/h kJ/s/h.

Like he said, it would measure the rate of change between two kilowatt levels. You might ask questions like "how quickly can this power plant adjust the amount of power it's producing?", and the answer would take the form of an amount of power over an amount of time.

This is one of the most salient ways in which different types of power plants differ; it's something that people are very concerned with.

In the EU they measure fuel efficiency in liters per 100km, which dimensionally is a unit of area.

In the US we use miles per gallon, which is the inverse - a ‘per area’.

Dimensionally, "liters of gasoline per 100km" and "miles per gallon of gasoline" are already stated in simplest form. Your only hope of demonstrating that a car's fuel efficiency can be measured in "liters per 100km", as opposed to "liters of gasoline per 100km", is to show that the car will function just as efficiently no matter what you put in the fuel tank, that if you put in a liter of sand you can drive just as far as if you put in a liter of gas. Among other problems, if you tried to cancel the linear kilometers of the denominator with one dimension of the liters of gasoline in the numerator, you'd end up with incompatible units being paired together. Gasoline can't be measured in two-dimensional units, and there is no "linear gasoline" in the denominator that would let you transform the gasoline in the numerator anyway.

You see this problem pop up all the time in chemistry, where a mole of some substance and a mole of some other substance are incompatible units. There is no such unit as "mole", only "mole of [whatever]". But there are people who would like to believe that "mole" is a unit.

(In contrast, there is such a unit as "liter", but it isn't used in fuel efficiency ratings.)

Okay, let’s humor this new lGas unit and see if it works.

If my engine consumes 10lGas/100km when traveling at 100km/h, that means it uses 10lGas/h, or .002778 lGas/s.

If the pipe feeding my engine has a cross sectional area of 10^-6m^2, how fast is the gasoline flowing through that pipe?

Naively I would expect I could divide flow rate by area to get mean velocity. But I’m expecting the result to be in m/s. But if I divide .002778 lGas/s by 10^-6m^2 I get 2778lGas/sm^2.

Unless an lGas is 10^-3mGas^3 and I can measure gas area in mGas^2, so I can get my gas speed in mGas/s?

If you want a mathematical way to capture ‘of gasoline’ the right way to think of it is not as a unit dimension but rather as a basis vector, kinda like ‘up’ or ‘across’.

1m * up is the vector quantity ‘1m up’, which has dimension ‘length’. 1m * across is the vector quantity ‘1m across’ which also has dimension length (we call it a displacement, but it’s a vector in the length dimension). We can add them together even though they point in different directions because they share the same dimension. The result is the vector quantity ‘1m up and 1m across’ and it is also a length.

Similarly 1l * of gas is a vector quantity ‘1l of gas’ with dimension ‘volume’. I can add it to ‘1l of air’ to get ‘1l of gas plus 1l of air’ which is still a vector volume. It might describe the contents of my fuel tank when it’s half empty for example.

Not necessarily. As mentioned by others the Hertz is for frequencies of periodic phenomena. While its dimension is indeed s^-1, that says nothing about periodicity.

The Becquerel is also s^-1.

Hertz is the SI unit of frequency.

Within the area of viscosities reciprocal seconds is an accepted standard unit

There is a standard for these kinds of things, the IEC-80000 part 13 defines quantities related to information science and technology. The one that is closest to request rate is probably "call intensity / calling rate".

https://en.wikipedia.org/wiki/ISO/IEC_80000#Part_13:_Informa...

This standard doesn't get much use. Mateusz Pusz, author of the C++ library mp-units, recently discovered it and has incorporated it into v2. https://www.youtube.com/watch?v=l0rXdJfXLZc

Well si doesn't really care about distributions. So it's a gamma distribution with an average rate in hz. Don't bother looking for the distribution in the units.

Counts per second doesn’t need a unit. It’s probably closer to flux (generic definition, not specific definition).

counts per second is common in particle physics

Flux is a quantity of ‘something’ per unit time per unit ‘area’.

The value of flux measurements is to be comparable across different scales.

When looking at scaling software systems the equivalent is looking at ‘requests per second per process’, which is sort of a flux metric. One way to think of auto scaling is as a process that adjusts the number of processes to keep constant request flux as the overall request volume changes.

I like this line of thinking! We should be able to set up differential equations that express how traffic flows through the process network and solve performance like a fluid dynamics problem!

Feynman already did that: https://longnow.org/essays/richard-feynman-connection-machin...

"By the end of that summer of 1983, Richard had completed his analysis of the behavior of the router, and much to our surprise and amusement, he presented his answer in the form of a set of partial differential equations."

Understanding how that could possibly have worked is one of the goals of my long-lived side quest of learning CFD.

Wikipedia has short section for this

> Aperiodic frequency is the rate of incidence or occurrence of non-cyclic phenomena, including random processes such as radioactive decay. It is expressed with the unit of reciprocal second (s⁻¹)[14] or, in the case of radioactivity, becquerels.[15]

> It is defined as a rate, f = N/Δt, involving the number of entities counted or the number of events happened (N) during a given time duration (Δt);[citation needed] it is a physical quantity of type temporal rate.

https://en.wikipedia.org/wiki/Frequency#Aperiodic_frequency

We already have a unit: RPS. Requests per second.

I don’t understand what’s wrong with Hz. Bq is almost viciously misguided.

By the books, Hz is only for regular phenomena. To the extent human activity is a magnifying lens of underlying quantum activity, as is radioactive activity, Bq are better suited.

It is indeed the unit of “activity”, not rate.

Hz is for frequency, which is for periodic phenomena (1/period equals frequency).

Usually requests to a server are not periodic, there is no period. They are random and follow something like the Poisson distribution.

Requests per seconds is as SI as it gets since the second is the base SI unit for time.

> They are random and follow something like the Poisson distribution.

In "stable conditions":

* The number of requests in a given time interval will follow a poisson distribution.

* The times of requests will be uniformly distributed

* the duration between two consecutive requests will be exponentially distributed.

I thought qps (queries per second) was bog standard.

> Saying “ninety kilobecquerel” and writing “90 kBq” is a lot more convenient than “ninety thousand requests per second” and “90,000 requests/s”.

I think current norm is 90k rps (or qps, but it's clear in both cases).

Easier solution which increases your chance of being compatible with the rest of the world:

Just use the ECMAScript Language Specification's Time-related Constants algorithms like SecFromTime (t)

https://tc39.es/ecma262/#sec-time-related-constants

Even the draft of w3c's High Resolution Time just incorporate them.

https://www.w3.org/TR

The ECMAScript Language Specification algorithms will help with rounding

SI allows for Quotients of SI units using either a solidus (/) or a negative exponent.

Herz is just the reciprocal of the second, 1/s or s^-1

Just as meters per second == m/s == m*s^−1

1 Hz == ∆_Cs/9,192,631,770 1 Sec == 9,192,631,770/∆_Cs

As Hertz is just a special name for s^-1 or 1/s, one can simply use the common prefixes and be mostly in sync with common standards from place like the w3c or their incorporated sources is far better than using SI for SI's sake.

Most languages have those typedefs for their duration classes/methods/functions anyway. But the ECMAScript spec above allows you to implement one that will be inter-compatible without trying to invent new or use obscure units.

> It should be emphasized that activity measures the source disintegration rate, which is not synonymous with the emission rate of radiation produced in it's decay. Frequently, a given radiation will be emitted in only a fraction of all the decays, so a knowledge of the decay scheme of the particular isotope is necessary to infer a radiation emission rate from its activity.[1]

It's a metric for a source - not a receiver. So if we're going to use Becquerels, then we're really talking about needing to characterize the sources making the requests, not the servers receiving them. Which is great information to characterize, but still leaves us needing a metric for counting the requests seen vs those that are started but never reach the server.

If we're still excited about doing things like people measuring radiation, then we could use counts per time unit. Like, counts per second, for example.

BUT - not all requests are equal. Next up, we measure how many resources are consumed in serving each request. I expect my next system dashboard to have a metric for RES (Röntgen Equivalent Server).

[1] Knoll, 'Radiation Detection and Measurement' (3rd Ed) p2.

Hopefully, anyone who is using becquerels for request rates is also using the delightfully obscure SI unit, the erlang.

https://en.wikipedia.org/wiki/Erlang_(unit)

The unit symbol for Erlang is E.

The Erlang unit is used in telecommunications, where it is used in calculations that involve queueing problems. In telecommunications, it can be used to measure the load placed on a communications channel by an average request.

This leads to the delightful identity (for those who were asking for identities):

   E = Bq/Bq[Max]

Where Bq[Max] is the the maximum possible number of requests that can be serviced in one second of CPU time if those request were serviced sequentially.

So obscure it's not listed as an SI base unit nor as an SI derived unit?

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

The Erlang unit is defined in

ISO/IEC 80000-13:2008

alongside the bit (bit), octet (o), byte (B), baud (Bd) and shannon (Sh).

The ISO/IEC 80000 series of standards supersede the old ISO 30 SI standards.

How about a third unit, baud [1]? It looks no worse than hertz to me:

In telecommunication and electronics, baud (/bɔːd/; symbol: Bd) is a common unit of measurement of symbol rate, which is one of the components that determine the speed of communication over a data channel. It is the unit for symbol rate or modulation rate in symbols per second or pulses per second.

[1] https://en.wikipedia.org/wiki/Baud

Baud is indeed symbols per second.

For a server, requests per seconds is the best SI unit you can do. In practice requests to a server are random so there is no periodicity and all periodic/frequency-related units do not apply.

> The becquerel, or Bq, is the si unit of (radio)activity. It is also defined as one event per second.

Bq is not defined as "one event per second". One becquerel is defined "as the activity of a quantity of radioactive material in which one nucleus decays per second." https://en.wikipedia.org/wiki/Becquerel

Just because something can be counted in a fixed timeframe doesn't mean it makes sense to slap a Hz unit on it.

What's your frequency (in Hz) of sexual intimacy?

We alteady have time as measured in seconds. "Requests" are at best an ill defined concept measured as a discrete quantify. I see no reason to 'standardize' beyond requests per second in a given context imho.

This is stupid. The unit is "requests/s".

“rips” -> “kilorips” etc.

When you say that someone is 1.90 m tall what you're actually saying is that their height is given by a random variable whose expected value is 1.90 m. Usually that random variable is a Gaussian with a very small standard deviation. In case of human height perhaps 0.005 m since height varies slightly during the day and measurements are inexact. Saying the request rate is 4 Hz works the same, except here the random variable (probably) is Poisson distributed with expected value 4.

I only count my requests in pints per fortnight.

Beers per on-call shift

mechanical watches use a weird vibrations per hour. so instead of 4hz you get an unintuitive but impressive 28,800vph

https://en.m.wikipedia.org/wiki/Vibrations_per_hour

for some reason i got a lot of pushback when i tried to implement this terminology at a previous job

Naming things. Requests per second is clear and unambiguous

But the question isn't about naming things. It's about what UNITs to use.

Unhelpfully, one of the standards cited earlier suggests using the symbol 'r' for request rate. That's a symbol, which is how you would name the variable in a math or physics paper. But let's ignore that.

The base unit is 1/s, which causes all kinds of problems in SI, not the least of which is: how do you apply prefixes? μ/s, m/s, k/S, M/s, G/s?

If the unit is Bq (Becquerel), the prefix problem goes away: μBq, mBq, kBq, MBq, GBq?

yeah, i mostly wanted to be able to use abbreviations: 'given that this process has an error rate of about 3 μBq, and it's invoked with a frequency of about 1 mBq, it seems like it fails about one out of every 300 times'

Nice repurposing. Bq it is!

If becquerel why not microfortnight? (about a second)

That’s not the same thing at all. You obviously mean the inverse microfortnight.

And the problem with that of course is whether the µfn is 1,000/(2 weeks) or 1/(2,000 weeks).

All in all the Bq is a cool unit! I learned something today.

Because the point is to have a Si unit of event rate (becquerel), not of time. Otherwise, if micro-fortnight (about a second), why not ... second?

Maybe we can generalize the becquerel to mean the average number of events per second of an arbitrary Poisson process? (The number requests per second and the number of decayed particles per second usually follow Poisson distribution.)

Reply on news.ycombinator.com