Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linlog cuts off extremes #9

Open
MarcelWaldvogel opened this issue Feb 2, 2022 · 3 comments
Open

Linlog cuts off extremes #9

MarcelWaldvogel opened this issue Feb 2, 2022 · 3 comments

Comments

@MarcelWaldvogel
Copy link
Contributor

I like the linlog layout, thanks @inkdot7!

However, it should ensure that a ytic beyond the maximum is set, to make the value visible. For example, in the following graph, the downward peak goes to -16 seconds (the time it took for the Raspi to reboot/resync time).

grafik

In the next graph, the ±RTT/2 lines are not visible at all and entirely cut off.

grafik

I expect that the outermost part becomes logarithmic; RTT/2 is ~100 ms.

It would be really great if these minor glitches could be improved.

@inkdot7
Copy link
Contributor

inkdot7 commented Feb 2, 2022

In the first graph, there are two problems, correct?:

  • Should also have -20000000 us tick.
  • Should not have the (+) 200 us tick, or at least not outside in the title.

Second graph:

  • Missing data lines. (again, need ticks outside the data to make the data appear).

It might be helpful with a dataset that reproduces the issues.

@MarcelWaldvogel
Copy link
Contributor Author

Yes, that seems to be about it.

I have put the files (state: UTC midnight) into https://gpstime.trifence.ch/statistics.{GPS,200.160.7.197}. I hope they help (and thousand thanks for looking into it!)

In case the result is gnuplot-dependent: V5.4 patchlevel 1 on Debian bullseye (Raspberry Pi).

@MarcelWaldvogel
Copy link
Contributor Author

I wanted to change the percentile of the linear range to tune some graphs and I noticed two things:

  1. linscalelimit seems to assume a one-sided graph (from 0 to some +x), however, for two-sided graphs (-y to +x) it might be useful to have a lower and upper linscalelimit (maybe even symmetric around y=0)
  2. I've had graphs where the tics were 10, 20, 200; however, the values did not go above 30, i.e., even though the percentile-based logic requires the outermost range to be logarithmic, not more space would be used by keeping that linear. Can we augment the logic as follows?
  • If none of the values is greater than 1.5 * linscalelimit, do not switch to logarithmic mode
  • (The downside: This probably requires an additional pass (or a third/fourth return value to keep track of), as this decision should only be made after all the input files have been analyzed.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants