On Sat, May 05, 2018 at 01:33:51PM -0400, Patrick Hemmer wrote: > > Also I'm thinking that we can even use 32-bit by putting the frontier > > between the date and the fixed priority (let's call it class) somewhere > > else : > > - 8 bit class + 24 bit offset => 256 classes and +/- 2.3 hours offsets > > - 12 bit class + 20 bit offset => 4096 classes and +/- 8 minutes offsets > > - 16 bit class + 16 bit offset => 64k classes and +/- 32 second offsets > What's the benefit to using 32-bit over 64-bit, and is that benefit > worth the cost of the added code complexity and processing time?
Slightly smaller memory footprint (doesn't count much), but more importantly much smaller processing time especially on 32-bit systems. > If we > used 64-bit, we could do a 16/48 bit split and have an absolute > timestamp out to year 10889 at millisecond precision. Not really because that would force us to implement yet another clock and then to have two distinct set of clocks for queues and for all other internal events and timeouts (including the queue timeout!). That would really be the beginning of a mess. We've been running with 32-bit millisecond-precise ticks for over a decade without ever a complain that it was not enough nor that the wrapping at 49.7 days was an issue. If one day we'd decide to change this, it would be to support finer-grained timestamps (eg: nanoseconds or CPU cycles) which would not necessarily protect us from wrapping either. > > I'm pretty sure that the two first options are way enough to cover almost > > everyone's needs. > For me a 12-bit class should work. My intention is to implement > something similar to email spam filtering, where you generate a score > based on the rules that match, and some rules are worth more than > others. 8 bits might be a bit difficult to work within. Makes sense. > I also suspect the 16-bit option (32 second offset) is too small for > date based. Yes I agree. I'm pretty sure that for some TCP connections certain users will want to have a long delay (eg: wait a minute before your FTP transfer starts). > The rest of this all seems fine. I've got no other thoughts to add. Great, thanks! > So the question is, which route do we go? > 1. 32-bit int (12/20 split) > 2. 64-bit int (32/32 split) I think you can start with the 12/20 split first, knowing that if anybody ever requests an extension of either time or classes we can switch to 64 without much effort. Until this happens we'll be more efficient on small systems. Conversely we can't do it the other way around because we could break some setups :-) > 3. 64-bit int (16/48 split) with absolute timestamps I don't like it much for the reasons above. > 4. 64-bit int with a single `set-priority` action. Let the user use the > a new`ms()` fetch for time based. The user does the bit shifting if they > want to use both (using the `mul()` converter, or we can add a `shift()`). I think this level of complexity ought to be done once in the code and not each and every time for all users. It would only be manageable for a number of the people on this list, but newcomers would call us words for this :-) Thanks, Willy
