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.

Sign up for GitHub

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

Jump to bottom

TransferTime is wrong again #1061

Closed
Space2Man opened this issue Dec 16, 2019 · 8 comments
Closed

TransferTime is wrong again #1061

Space2Man opened this issue Dec 16, 2019 · 8 comments
Labels
confirmed bug Confirmed bugs. Highest priority to fix.
Milestone
4.3.0

Comments

@Space2Man
Copy link
Contributor

Space2Man commented Dec 16, 2019 •
edited

Hi,

on Windows the transfertime seems to be wrong again. We fixed this in #653 but somehow on an completely idle disk (like CDROM) I see that transfertime == timestamp.

This is with OSHI 3.13.4.

Best regards, Space
@Space2Man
Copy link
Contributor Author

Issue seems to come from #763 ...

@Space2Man
Copy link
Contributor Author

I opened pull request #1063

dbwiddis pushed a commit that referenced this issue Dec 17, 2019
@Space2Man @dbwiddis
#1061 Fix transferTime in WindowsDisks by using 1-%Idle (#1063)
97da0a4 
* Fix transferTime in WindowsDisks by using 1-%Idle - transferTime should be set to 0 if no value is detected
@Space2Man
Copy link
Contributor Author

Ah, now I see why #763 broke it ... it applied the 1-x part, but it uses the diskTime, not the idleTime. I guess we should rename it for 3.13.x as well.

Although it might very well be that 4.2.x was working before that. I noticed that my test systems all are running against 3.13.4 at the moment. And there we have the 1-%diskTime which is of course wrong.

@dbwiddis
Copy link
Member

or remove the 1-x part? Heh.

@Space2Man
Copy link
Contributor Author

Space2Man commented Dec 19, 2019 •
edited

I think it's better to use 1-%idle, see http://support.demandtech.com/index.php?pg=kb.page&id=47
On laptops this probably does not matter (that much) but I think on pretty busy database servers the numbers get wrong otherwise. I don't want to have a disk to be reported as >100% busy ...

But 1-%disk is definitely wrong :)

@dbwiddis
Copy link
Member

I concur 1-%idle is probably the best. Is the PR good to go? I haven't had time to look at it yet.

@Space2Man
Copy link
Contributor Author

Hi, I have not been able to test this as I switched my workstation to Linux and for the other systems there is currently a change freeze :-\

dbwiddis pushed a commit that referenced this issue Dec 23, 2019
@Space2Man @dbwiddis
#1061 Feature/windows transfertime 3.13.x (#1065)
19f404f
@dbwiddis
Copy link
Member

Fixed in #1063 and #1065

@dbwiddis dbwiddis added the confirmed bug Confirmed bugs. Highest priority to fix. label Jan 2, 2020
@dbwiddis dbwiddis added this to the 4.3.0 milestone Jan 2, 2020
@dbwiddis dbwiddis mentioned this issue Jan 22, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
confirmed bug Confirmed bugs. Highest priority to fix.
Projects
None yet
Milestone
4.3.0
Development

No branches or pull requests
2 participants
@dbwiddis @Space2Man