integer tw_stime

[JohnPJenkins]

Another thought to document...

By having a 64-bit integer tw_stime rather than a floating-point, you can basically eliminate any precision issues while still having a very long time-frame available. For instance, if you work in picoseconds (1e-12), the max time you can have is approx 213 days. Bumping that up to nanoseconds would get you 213,000 days.

Not sure what the implications are of changing this type - I know for example the RNG is floating point. Though I would think that most uses of tw_stime in ROSS are comparisons, as the users drive event times.

[laprej]

Some of the OMNeT++ documentation discusses some of the benefits of having a 64-bit integer based time representation.

[gonsie]

I believe that we use floating points so that users can easily add jitter (via RNG) and avoid ties. Ties would be one negative to switching to integer time-stamps.

[gonsie]

resolved by #159 and the new TW_STIME API

Model developers now can use their own tw_stime types. Thus, it would be up to the model to decide if a 64-bit integer is appropriate.