-
Notifications
You must be signed in to change notification settings - Fork 29
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
UGE showing wrong wallclock and/or dispatch time? #199
Comments
It depends on which method the code is calling in batch.rb |
We might want to combine this with issue #197 |
You're right that it's the JR listener, and But looking at the example output it's the under This can't go into native attributes, because things like the dashboard access the wall_time directly. They shouldn't have to toggle to do something strange for separate adapters. Native is for things that can't go everywhere, or it's a catch all for things that don't fit. wall time is one of those things all schedulers use (classic schedulers anyhow). |
My bad, it is qstat_xml_r that where |
No issues, that's what the 'needs investigation' tag means, it's not clear why it's going on. i And looking at the spec file, this is supposed to work so there could be something amiss either in the way we parse, or the test case or UGE is somehow different from SGE. I'm sure the discourse user would be happy to provide new output to test against. Maybe the first step would be just to copy this test case and run it against the UGE output. Btw, you can get a trial version of UGE to test against here. |
OK I got it. UGE's
ood_core/lib/ood_core/job/adapters/sge/qstat_xml_j_r_listener.rb Lines 128 to 132 in 9eaf3cf
To get the remaining time, we subtract this from the time limit, say an hour (3600), resulting in a very large positive number.
|
I guess we could use a UGE image :-) |
But with that description we can write a test. |
Some Grid Engines (like UGE) use milliseconds were others use seconds past the epoch. Fix for #199.
This discourse topic about UGE showing the wrong time remaining in a batch connect application came in today. It's assumed this is a bug in the adapter and not the dashboard.
Here's the output of uge's 'qstat -r -xml' to help replicate the issue. I'd say we need a test case to replicate the issue as I cannot by hacking around in irb. Here's the relevant dashboard code that displays the time remaining time.
It should be noted that
Time.now
is taken into account for these calculations so that should be stubbed to appropriately reflect a time > dispatch time but < 4 hours past the dispatch time.The text was updated successfully, but these errors were encountered: