I like the idea of using the stdint types. Since we don’t have negative sequence numbers, we could use uint64_t to take the maximum from 9,223,372,036,854,775,807 (INT64_MAX) to 18,446,744,073,709,551,615 (UINT64_MAX).
The upper bound really controls how many job IDs can be active (queued, running, held, exiting, etc.) at any given time. This will always be something less than infinity, so I think having an upper bound is fine for our purposes.
Any decimal number beyond about ten digits starts getting a little intimidating for us puny humans. Even with hexidecimal we’re looking at a string of 16 hex digits to represent UINT64_MAX. That’s a little better than 20, but not much. Even with hexatridecimal (base 36) it’s still 13 characters, with the possibility of some vulgar words embedded.
Hi All,
Thanks for inputs. As per the recent replies we can think of the following possible approaches:
Approach 1: Use long long with the upper bound.
Approach 2: Use int64_t. The issue here might be that, since Microsoft Visual Studio is not fully C99 compliant. We are not sure if int64_t is supported.
Approach 3: Use long long or unsigned long long with no upper bound. Let it go to the max value and wrap itself.
Approach 4: Use long or unsigned long without upper bound. Assuming we ignore 32bit. On both architectures reaching the max values, they wrap around. Though max values are different.
Approach 5: Use long or unsigned long with upper bound. Again assuming we ignore 32bit. In 64bit, wrap around happens at the upper bound while on 32bit, it happens earlier on reaching the max value.
As of now we are working on “Approach 1”.
Please vote on the “Approach” with which we should go ahead. Or please suggest, if I have missed something.
FWIW, I wrote a small program and ran it on a VM to see just how long it would take to increment a uint64_t and measure the amount of time it took to consume each bit in the variable. Obviously, performance will vary, but it gives an idea of how large the domain should be. I gave up after 48 bits…
@varunsonkar - sorry i looked at your reply only now. yes internal variables like sv_jobidnumber exist today since we increment the jobid inside pbs server. However, if we loaded the next id from a database sequence we could easily read that large number as a string…so internally we never deal with the ID as a number at all. If and when we move towards a multiple server approach, we would need to get the job id sequence etc from the database anyway instead of incrementing inside the server.
Anyways for the time being, loading the sv_jobidnumber from database into a int64_t would be fine. The postgres field corresponding to sv_jobidnumber is defined as integer, which can take only this much:
integer 4 bytes typical choice for integer -2147483648 to +2147483647
So, along with changing the variable in C we will need to change the database column type to bigint. And this would also need an alter statement in case of upgrades.
Hi @subhasisb,
Thanks for the reply.
Yes we will be modifying the database column type to “BIGINT”. Also we will handle the cases as you mentioned like upgrade.
I think we do not need to validate the implementation here. The only real question I saw in this discussion was whether we need to support 1 trillion jobs for a 32 bit build as well, and I believe I heard the answer as “yes”. I myself believe we need to support for the case of Windows where we build PBS in 32 bit mode currently.
As far as implementation of how to handle (hold) a 64 bit value properly, that should be adequately reviewed during code review.
Hi All,
I have updated the EDD mentioning the limitation on the length of “job name” which gets affected with this implementation. Please review the updated EDD and provide the comments/signoff.
At the PBS Pro User Group meeting I got face to face feedback of a strong desire to not have to deal with job ids of longer than ~7 digits. Users and admins regularly have to speak the job ID numbers out loud and it is bothersome when they get long. The customer in question has flipped the job ID counter multiple times in the past few years and basically wants the ability to preserve existing behavior. Can we add the max_sequence_id interface from v1 of the EDD back in (updated with the direction of the discussion around uint64_t)?
That looks like a good interface that meets the customer need. That said, I don’t see a discussion here of why it was dropped. Was there a specific reason?
Hi folks. Have there been any further developments or discussions on this issue? For sites that don’t want to use larger than 7 digits, nothing would stop them from flipping the counter back when they desire. For those who require growth past 9999999 jobs, seeing this issue revived would be quite helpful.
we are planning to start the implementation for this requirement.
we are seeing that there are some suggestions for max_sequence_id which was mentioned in the v1 of the EDD.
So let’s start the discussion and finalize the design. @scc,
could you please provide more feedback on the requirement on max_sequence_id if any ?
Hello @Bhagat, rather than something like an explicit max_sequence_id to arbitrarily set a max, I believe it would be acceptable for the behavior to be configurable in a binary way: either limit to the current 7 digits max or allow up to 1 trillion (at least).
This should reduce testing burden but still provide the behavior desired by some sites (who regularly speak job ID number out loud and don’t want them to get any longer). We’d still have to consider what happens if the new behavior is in use, the sequence number is greater than 10 million, and the switch is flipped to use the 10 million limit. I’d propose that the next job ID issued after that be 0.
The formatting change proposed in the EDD is right and necessary, but may need adjustment if the actual limit goes beyond 12 digits.
I feel the older interface does just fine. I think the binary switch might be just too limiting. For sites who might fit their jobs in a slightly longer jobid format, but do not necessarily want to go all the way till max, they would have the option to specify the number of digits (with the older interface). The amount of testing is almost the same.
The requirement does not seem to specify that we absolutely need numbers and sequentially incrementing ones. So question to the community? Do users really care about sequentially incrementing numbers as job-id? If not, there could be several other ways to encode a trillion ids into a smaller set of digits. We could, for example, consider characters a-z as part of the character set to use in a job id (in the id part). We could generate 36^9 unique ids with 9 char-wide ids (and 26 chars + 10 digits)
Current value of job ID field width (PBS_MAXSEQNUM): 7 characters
Representing 40 bits (numbers slightly exceeding 1 trillion) in various bases:
Decimal: 13
Hexadecimal: 10 (plus 2 if you prefix with “0x”)
Trigesimal (base 30): 9 (think of this as all digits and lower case consonants)
Hexatrigesimal (base 36): 8 (all digits and all letters)
base 96: 7
base 128: 6
base 256: 5
One may conclude that if we want to maintain the current field width we would have to use base 128 with a one character prefix or base 256 with a two character prefix. Even with base 128, good luck finding 128 printable ASCII characters that might work.
I think the real question is what the new setting for PBS_MAXSEQNUM will be? I think we should increase it to 13 and continue to use decimal representation. We’ll need to make appropriate adjustments to qstat, the PBS Pro database schema, and probably other areas. I also think the time has come to ignore the 80 character line width limit. It’s been a long time since I used a WYSE or VT-100 terminal. I think the new “sane” limit should be 100 characters per line.
Increasing the width is no problem, was done before for another branch, so should just work. In that case:
We can keep the default as current (7 digits).
Allow PBS_MAXSEQNUM to be extended as required by a site (to the allowed max)
I was going a bit beyond and trying to figure out whether we need to absolutely have numbers, and even sequential numbers? Thanks @dtalcott for your opinion. I will add a bit more to my question (assuming we need numbers):
a. Do these numbers have to be incremental? I.e. if we get jobid 100 first and then get jobid 2 after that, would that be a problem for users? (The reason I ask is that as we go towards multi-server, it might be easier and less contentious, lock-wise, to dish our separate blocks of job-ids per server) - so do we care?