Extend support for specifying quotas with u64

[Arqu]

I'm looking to run the governor with a rate limit of >~4GB/s ie 10GB/s which cannot be specified with the u32 values passed into Quota. I understand this might be slightly over what most people expect but we all know the story of "16 bits ought to be enough for everyone".

Looking at the code, this might not be as straightforward of a change as the title would imply.

[antifuchs]

Huh! That's a new one!

I think we can change the quota type and others to accommodate that number, but this is getting really really close to the 1-nanosecond granularity that our time duration types dictate. Are you accounting for single bytes?

[Arqu]

We are, though we might just shim our own end to do some unit upsizing. However a large chunk of the traffic we want to be able to track are <1KiB frames at very high rates.

[antifuchs]

That makes sense! Hm, ok, doing the math with frink a bit:

> 1 second -> nanoseconds
1000000000
> 2^32
4294967296

I thiiink u32 is actually the highest we can go, since intervals can't go smaller than 1ns, in any of the clock abstractions that I have found so far... and GCRA requires non-zero intervals to keep track of that theoretical arrival time.

The more scaling-down of the measured values you can do (even by a factor of 10, better by 100 or even 1000), the more suitable the GCRA in governor will be for your use case.

[Arqu]

Yeah makes sense, I'll try to do my own take on it at some point. It's not a super urgent thing, it's a very specialized case where we can work around it by using a slightly larger factor. Also not rate limiting is an option for some of these setups.

Just wanted to get it out there so that in some future we don't have to bill by the KB :D

Appreciate the quick responses!

[antifuchs]

Sounds great! I'm actually thinking about this now and ... I think there's a trade-off that could be made between higher granularity of timekeeping (not time measurement, mind! Clocks will still return values scaled to the next nanosecond) and duration over which you can keep time:

• The main thing about a positive rate-limiting outcome is that it must move the TAT (expected arrival) timestamp back.
• You can move that timestamp back by a fraction of a nanosecond.
• The time measurement readings could be scaled to those fractions.

Now, that means that the "~200 years max lifetime" of a live ratelimiter object would get reduced. But then, since those live in memory only, I would still count a 20 years uptime of in-memory state a success (:

I think together with #89, a design is crystallizing in my mind around scaling these timekeeping granularities (such that larger and smaller timekeeping types could both be supported, at the cost of timekeeping lifetime). What do you think?

[Arqu]

Oh nice! Yes, down scaling the max lifetime would be a decent tradeoff and I guess a process restart every 20 years ain't all that bad 😄
Following that thought train, doing basically the same logic to go down in resolution to support 32bit architectures would be wonderful (we have a usecase for it, though limited usefulness).
Even a crude preset of 2-3 possible configurations would very much expand the domain governor can serve. I do foresee a bunch of feature flagging though.

[antifuchs]

Looking at how to implement this, I think const generics would be good to use for the Nanos abstraction (bubbling up to Clock and Reference traits). However, the limitations around generic type arguments make this difficult for now.

I'd say until we have at least something like rust-lang/rust-project-goals#161 (for trait inherent consts to be valid const generic arguments), this will be hard to implement and result in a very gross public API.